Re: Managing JESYSMSG size
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: 07 March 2018 01:41 To: IBM-MAIN@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 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price :>Sent: 03 March 2018 10:10 :>To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price :>Sent: 03 March 2018 10:10 :>To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: 05 March 2018 19:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size On 2018-03-05 5:50 PM, Robin Atwood wrote: > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
On 2018-03-05 5:50 PM, Robin Atwood wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: 03 March 2018 10:10 To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
Robin Atwood wrote: >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. >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?" ;-) >Thanks Pleasure! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 02 March 2018 18:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size Robin Atwood wrote: >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
Robin Atwood wrote: >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
Wouldn't JESLOG=SUPPRESS on the job card do the trick? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
