Managing JESYSMSG size

[Robin Atwood]

We have a customer using our file server to synchronise 200,000 odd members
with a PC-based source manager. Each download

requires a data set allocation which generates IGD10xI messages in the
server's JESYSMSG file, about five lines per member.

So they are getting millions of messages filling up the spool resulting in
their ops shutting down the server. Is there anyway via

JES2 or SMS to suppress these messages? Preferably on a per-job basis rather
than globally, although since this is only a problem on

the initial sync globally might be acceptable for a short while. These are
not syslog messages so the usual techniques using MPF, NetView, etc will not
work.



Thanks

Robin




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Dan D.]

Wouldn't JESLOG=SUPPRESS on the job card do the trick?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Elardus Engelbrecht]

We have a customer using our file server to synchronise 200,000 odd members with a PC-based source manager. Each download requires a data set allocation which generates IGD10xI messages in the server's JESYSMSG file, about five lines per member.

That is a PITA. I can't remember how you can suppress it in the first place, but I believe it should be possible, via SPIN or something else?.

So they are getting millions of messages filling up the spool resulting in their ops shutting down the server. Is there anyway via JES2 or SMS to suppress these messages? Preferably on a per-job basis rather than globally, although since this is only a problem on the initial sync globally might be acceptable for a short while. These are not syslog messages so the usual techniques using MPF, NetView, etc will not work.

Rather try use FTP (SFTP or FTPS if you can) with mget or mput depending where you start your transfer. No worries about gazillion messages. Of course if you let your FTP messages sitting somewhere, say in a OMVS file, just check the space that you dont run out of space.

Or just do your transfers in stages, say 50 000 members. Repeat a few times with next members.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Robin Atwood]

Elardus-
Dan has the solution, use the JESLOG parameter.

I don't think management would respond well to me suggesting we replace our server with ftp!

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: 02 March 2018 18:20
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Managing JESYSMSG size

We have a customer using our file server to synchronise 200,000 odd members with a PC-based source manager. Each download requires a data set allocation which generates IGD10xI messages in the server's JESYSMSG file, about five lines per member.

That is a PITA. I can't remember how you can suppress it in the first place, but I believe it should be possible, via SPIN or something else?.

So they are getting millions of messages filling up the spool resulting in their ops shutting down the server. Is there anyway via JES2 or SMS to suppress these messages? Preferably on a per-job basis rather than globally, although since this is only a problem on the initial sync globally might be acceptable for a short while. These are not syslog messages so the usual techniques using MPF, NetView, etc will not work.

Rather try use FTP (SFTP or FTPS if you can) with mget or mput depending where you start your transfer. No worries about gazillion messages. Of course if you let your FTP messages sitting somewhere, say in a OMVS file, just check the space that you dont run out of space.

Or just do your transfers in stages, say 50 000 members. Repeat a few times with next members.

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Elardus Engelbrecht]

Post by Robin Atwood
Elardus-
Dan has the solution, use the JESLOG parameter.

Yes and thanks to Dan. I simply could not remember that word "JESLOG", but I am pretty sure there is a way to suppress messages. Thanks to Dan for refreshing my memory.

Post by Robin Atwood
I don't think management would respond well to me suggesting we replace our server with ftp!

Understood. "If it works, why break or fix it?" ;-)

Post by Robin Atwood
Thanks

Pleasure!

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Greg Price]

Post by Robin Atwood
Is there anyway via
JES2 or SMS to suppress these messages? Preferably on a per-job basis rather
than globally

Would MSGLEVEL=(n,0) do the trick?

If the DYNALLOCs are under your control, you can request this in the
relevant SVC 99 text unit.

Cheers,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Robin Atwood]

Greg-
The SVC 99s are under my control and that is very useful to know!

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Greg Price
Sent: 03 March 2018 10:10
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Managing JESYSMSG size

Post by Robin Atwood
Is there anyway via
JES2 or SMS to suppress these messages? Preferably on a per-job basis
rather than globally

Would MSGLEVEL=(n,0) do the trick?

If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit.

Cheers,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Greg Price]

Post by Robin Atwood
Greg-
The SVC 99s are under my control and that is very useful to know!
Thanks
Robin

Robin,

Great!
:)
But I was slightly inaccurate.
:(

It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte
S99FLG11.

In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag
in both the allocation and deallocation requests to reduce spooled
output size, as well as the number of pages one has to scroll down to
get to the start of the SYSPRINT report. (Sometimes this is being viewed
outside SDSF where N 3 works well.)

The main purpose I like all those allocation and data set disposition
messages in the general case is so that I can quickly see which data
sets are allocated at the time of an abend, and can usually figure out
which DDs are allocated to which data sets.

Naturally, the data sets disposed of after the abend are the ones which
were allocated at the time of the abend.

Of course, sometimes customer flower boxes from their IEFACTRT routine
can be helpful in this area too.

Anyway, in the SYSPRINT report line which reports the data sets as they
are processed I now also display the DD name just in case it's needed.

IIRC, I went looking for this flag one day when trying to figure out how
BPXWDYN can do allocations and deallocations without generating such
messages. Given its component prefix, perhaps it was written with a view
to operating in spawned address spaces which usually leave no spooled
relic of their existence.

Cheers,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Robin Atwood]

Yes, after a fruitless search through the text units I found the flag in the RB. I will implement a configuration option so customers can turn off the allocation messages when doing initial check-outs or other operations involving large numbers of members.

Thanks for the tip!
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Greg Price
Sent: 05 March 2018 19:39
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Managing JESYSMSG size

Post by Robin Atwood
Greg-
The SVC 99s are under my control and that is very useful to know!
Thanks
Robin

Robin,

Great!
:)
But I was slightly inaccurate.
:(

It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte S99FLG11.

In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag in both the allocation and deallocation requests to reduce spooled output size, as well as the number of pages one has to scroll down to get to the start of the SYSPRINT report. (Sometimes this is being viewed outside SDSF where N 3 works well.)

The main purpose I like all those allocation and data set disposition messages in the general case is so that I can quickly see which data sets are allocated at the time of an abend, and can usually figure out which DDs are allocated to which data sets.

Naturally, the data sets disposed of after the abend are the ones which were allocated at the time of the abend.

Of course, sometimes customer flower boxes from their IEFACTRT routine can be helpful in this area too.

Anyway, in the SYSPRINT report line which reports the data sets as they are processed I now also display the DD name just in case it's needed.

IIRC, I went looking for this flag one day when trying to figure out how BPXWDYN can do allocations and deallocations without generating such messages. Given its component prefix, perhaps it was written with a view to operating in spawned address spaces which usually leave no spooled relic of their existence.

Cheers,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Binyamin Dissen]

As this is your code, it may be worth it to use BPAM rather than do a separate
allocation for each member. Will also save lots of CPU.

On Mon, 5 Mar 2018 13:51:48 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>Greg-
:>The SVC 99s are under my control and that is very useful to know!
:>
:>Thanks
:>Robin
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Greg Price
:>Sent: 03 March 2018 10:10
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: Managing JESYSMSG size
:>
:>On 2018-03-02 9:53 PM, Robin Atwood wrote:
:>> Is there anyway via
:>> JES2 or SMS to suppress these messages? Preferably on a per-job basis
:>> rather than globally
:>
:>Would MSGLEVEL=(n,0) do the trick?
:>
:>If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit.
:>
:>Cheers,
:>Greg
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Robin Atwood]

For PDS members I already do that and, yes, it is very fast! However, in the
current situation the customer is retrieving
Endevor members and, for various reasons, they need to be saved in a
short-lived catalogued data set.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: 07 March 2018 01:41
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Managing JESYSMSG size

As this is your code, it may be worth it to use BPAM rather than do a
separate allocation for each member. Will also save lots of CPU.

On Mon, 5 Mar 2018 13:51:48 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>Greg-
:>The SVC 99s are under my control and that is very useful to know!
:>
:>Thanks
:>Robin
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Greg Price
:>Sent: 03 March 2018 10:10
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: Managing JESYSMSG size
:>
:>On 2018-03-02 9:53 PM, Robin Atwood wrote:
:>> Is there anyway via
:>> JES2 or SMS to suppress these messages? Preferably on a per-job basis
:>> rather than globally :> :>Would MSGLEVEL=(n,0) do the trick?
:>
:>If the DYNALLOCs are under your control, you can request this in the
relevant SVC 99 text unit.
:>
:>Cheers,
:>Greg
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN :>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen <***@dissensoftware.com> http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you
should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially
those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN