Re: Jes2 Initiator number
On 2018-08-08 5:58 AM, Cieri, Anthony wrote: The audit trail is needed to determine what job(s) instigate the S822 ABENDs. Well, maybe that audit trail will work now (and maybe it won't)- but it definitely would not have been reliable in the past. In the olden days - even before the iPhone 6 was invented - the JES2 INIT number was more of a logical concept or a virtual queue - and did not mean any particular address space. For example, suppose the "INIT 2" address space A1 was doing job termination. Then "INIT 2" would be eligible to run a new job. But suppose there were other started initiators that had no work in their assigned classes, and so address spaces A2 and A3 were idle initiators. JES2 may well start the next job under "INIT 2" in address space A2 or A3 as JES2 saw fit, perhaps before address space A1 had become truly idle. S822 abends are probably caused by LSQA fragmentation, where LSQA is sloppy terminology for "private high" virtual storage. If you want to find out who the "culprit" is, you need to track the ASID, not the INIT number, in my view. In a previous life as a sysprog, I wrote and implemented an MPF exit to append the ASID to the STARTED and ENDED messages - the ones produced by the MONITOR or MN command IIRC, but it might also work for the JES2 messages. It reported the ASID for started tasks and TSO users as well, without actually increasing the number of messages. You may not be interested in messages as such, but the most convenient window into the past I had at the time was the SYSLOG. If you want to look at SMF, then you probably do not need to change much because the ASID is in the type 30 (SMF30ASI). Even if my observations about JES2 INIT numbers are out of date or even totally incorrect, ASID is still a valid thing to track when trying to track storage fragmentation within the private area of an individual address space, so you still don't need to audit JES2 INIT numbers. And don't forget there is always the el cheapo version of the therapeutic IPL - just drain and restart all the initiators every so often when convenient for pristine unfragmented private storage for your batch jobs. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Jes2 Initiator number
Just wondering why that would be of interest. If it is anywhere it will be in the type 30 i would think. There is an indicator that the init is wlm managed. On Tue, Aug 7, 2018 at 12:34 PM, Tony Cieri wrote: > Is the JES2 initiator number that runs a job recorded in any SMF records?? > > The only "audit" trail that I can find is the $HASP373 message when a job > is started. > > I would appreciate any pointers that anyone can provide. > Thanks > Tony > > -- > 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: Jes2 Initiator number
Lizette / Alan / Martin,
Thank you all for your replies that the detailed information. It looks
like exactly what I need (and somehow missed).
It's never a bad day when you learn something new!!!
Thanks again
Tony
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Tuesday, August 07, 2018 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Jes2 Initiator number
1) I have used a scheduling software in the past called CA Workload Automation
(CA ESP). It has a report function where I can select all jobs that had a S822
from date - to date, and then list things like Start Date/Start TimeEnd
date/End time Jobclass etc...
2) there is a parm in DIAGxx to reduce S822 abends
VSM CHECKREGIONLOSS(bbb{K|M},aaa{K|M})
Indicates the amount of region size loss that can be tolerated in an
initiator address space. The initiator remembers the initial maximum available
region size (below and above 16 MB) before it selects its first job. After the
termination of each job run in the initiator, if the maximum available region
size (below or above 16 MB) has decreased from the initial value by more than
the CHECKREGIONLOSS specification, the initiator terminates with message
IEF093I or IEF094A, depending on whether the subsystem automatically restarts
the initiator. JES2, JES3, WLM, OMVS, and APPC all automatically restart
initiators, so initiator issues IEF093I in most cases. CHECKREGIONLOSS allows
the installation to avoid 822 abends in subsequent jobs that are selected by an
initiator. The available region size of the initiator has decreased because of
storage fragmentation or problems that have caused storage not to be freed.
Because the initiator notifies the owning subsystem that the initiator is
being terminated on the job termination SSI call, the CHECKREGIONLOSS detection
must be done before some storage that will eventually be freed actually gets
freed. The SWA subpool is an example (and for some jobs, a large example) of
this. The detection processing recognizes storage that is part of the SWA
subpool, and treats it as if it was freed. However, if you are looking at a
dump of an IEF093I message, you still need to manually ignore the SWA storage.
Some fragmentation (especially above 16 MB) is normal. A job that uses a
lot of SWA (or other system control blocks in high extended private) might
cause fragmentation because this forces another system control block that
persists across jobs to be allocated at a lower address. The VSM cell pool
extents (VSMP eye catcher at the beginning of a 4 KB page) are an example of
persistent storage. Compression of VSM cell pool extents requires a large
amount of CPU time (much more than the CPU time for terminating and restarting
an initiator). Recycling of initiators under the control of CHECKREGIONLOSS is
the intended mechanism for dealing with fragmentation.
In addition to normal fragmentation, IEF093I might in some cases expose a
storage leak problem that can be investigated and fixed. Differentiating
between normal fragmentation and a storage leak is a time consuming manual
process done by analyzing dumps.
Selecting the CHECKREGIONLOSS values:
Select values small enough to avoid 822 abends for the jobs in your
installation that have the largest REGION requirements. That depends on the
size of your private area above and below 16 M, and the REGION requirements of
your largest jobs.
Select values large enough so that the frequency of IEF093I messages is
not excessive, and so that the frequency of initiator recycling is not a
performance issue.
Start with something like:
CHECKREGIONLOSS(256K,10M)
Decrease the values if you see 822 abends, and increase the values if
you frequently see IEF093I messages.
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Cieri, Anthony
> Sent: Tuesday, August 07, 2018 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Jes2 Initiator number
>
>
> For this particular exercise/issue I do not need to consider WLM Inits.
>
> Initially, I would like to be able to produce a list of jobs that ran
> in a particular JES2 initiator.
>
> We occasionally have an issue with S822 abends. They don't occur very
> often, but when they do, that is a rash of them. Once it starts, the ABENDs
> seem to reoccur in the same JES2 Initiator (or two). It would be ideal, If I
> could come up with an automate solution that would capture the initiator and
> drain/restart it. They is usually how we recover from the issue.
>
> The audit trail is needed to determine what job(s) instigate the S822
> ABENDs. If we can identify them, we could get the appropriate application
> owners involved.
>
> Thi
Re: Jes2 Initiator number
Many thanks for this suggestion. I have found a copy of IEFU84/MXGU84 in our MXG.SOURCLIB. This should solve the audit trail issue. Thanks again. Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barry Merrill Sent: Tuesday, August 07, 2018 3:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Jes2 Initiator number In 2004, MXG Change 19.269 provided an IEFU84 exit that captures and moves the Initiator Number and Initiator Number into the SMF 30 Subtype 1, and MXG type 30 processing picks them up. I have no recent confirmation that exit code runs but I also have no recent confirmations that it's in use anywhere. Barry Herbert W. “Barry” Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 www.mxg.com ba...@mxg.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Cieri Sent: Tuesday, August 7, 2018 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Jes2 Initiator number Is the JES2 initiator number that runs a job recorded in any SMF records?? The only "audit" trail that I can find is the $HASP373 message when a job is started. I would appreciate any pointers that anyone can provide. Thanks Tony -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Jes2 Initiator number
1) I have used a scheduling software in the past called CA Workload Automation
(CA ESP). It has a report function where I can select all jobs that had a S822
from date - to date, and then list things like Start Date/Start TimeEnd
date/End time Jobclass etc...
2) there is a parm in DIAGxx to reduce S822 abends
VSM CHECKREGIONLOSS(bbb{K|M},aaa{K|M})
Indicates the amount of region size loss that can be tolerated in an
initiator address space. The initiator remembers the initial maximum available
region size (below and above 16 MB) before it selects its first job. After the
termination of each job run in the initiator, if the maximum available region
size (below or above 16 MB) has decreased from the initial value by more than
the CHECKREGIONLOSS specification, the initiator terminates with message
IEF093I or IEF094A, depending on whether the subsystem automatically restarts
the initiator. JES2, JES3, WLM, OMVS, and APPC all automatically restart
initiators, so initiator issues IEF093I in most cases. CHECKREGIONLOSS allows
the installation to avoid 822 abends in subsequent jobs that are selected by an
initiator. The available region size of the initiator has decreased because of
storage fragmentation or problems that have caused storage not to be freed.
Because the initiator notifies the owning subsystem that the initiator is
being terminated on the job termination SSI call, the CHECKREGIONLOSS detection
must be done before some storage that will eventually be freed actually gets
freed. The SWA subpool is an example (and for some jobs, a large example) of
this. The detection processing recognizes storage that is part of the SWA
subpool, and treats it as if it was freed. However, if you are looking at a
dump of an IEF093I message, you still need to manually ignore the SWA storage.
Some fragmentation (especially above 16 MB) is normal. A job that uses a
lot of SWA (or other system control blocks in high extended private) might
cause fragmentation because this forces another system control block that
persists across jobs to be allocated at a lower address. The VSM cell pool
extents (VSMP eye catcher at the beginning of a 4 KB page) are an example of
persistent storage. Compression of VSM cell pool extents requires a large
amount of CPU time (much more than the CPU time for terminating and restarting
an initiator). Recycling of initiators under the control of CHECKREGIONLOSS is
the intended mechanism for dealing with fragmentation.
In addition to normal fragmentation, IEF093I might in some cases expose a
storage leak problem that can be investigated and fixed. Differentiating
between normal fragmentation and a storage leak is a time consuming manual
process done by analyzing dumps.
Selecting the CHECKREGIONLOSS values:
Select values small enough to avoid 822 abends for the jobs in your
installation that have the largest REGION requirements. That depends on the
size of your private area above and below 16 M, and the REGION requirements of
your largest jobs.
Select values large enough so that the frequency of IEF093I messages is
not excessive, and so that the frequency of initiator recycling is not a
performance issue.
Start with something like:
CHECKREGIONLOSS(256K,10M)
Decrease the values if you see 822 abends, and increase the values if
you frequently see IEF093I messages.
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Cieri, Anthony
> Sent: Tuesday, August 07, 2018 12:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Jes2 Initiator number
>
>
> For this particular exercise/issue I do not need to consider WLM Inits.
>
> Initially, I would like to be able to produce a list of jobs that ran
> in a particular JES2 initiator.
>
> We occasionally have an issue with S822 abends. They don't occur very
> often, but when they do, that is a rash of them. Once it starts, the ABENDs
> seem to reoccur in the same JES2 Initiator (or two). It would be ideal, If I
> could come up with an automate solution that would capture the initiator and
> drain/restart it. They is usually how we recover from the issue.
>
> The audit trail is needed to determine what job(s) instigate the S822
> ABENDs. If we can identify them, we could get the appropriate application
> owners involved.
>
> This could all be accomplished through some syslog research. I was
> hoping to find a more automated solution...
>
> Thanks again.
> Tony
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, August 07, 2018 3:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Jes2 Initiator number
>
> It depends. You indicate JES2 INITs b
Re: Jes2 Initiator number
This was added sometime in the z/OS 1.9-1.13 time frame (sorry don't remember which release. JES will automatically detect region loss and (automatically) drain/restart the initiator. Look up VSM CHECKREGIONLOSS(?). It should do what you want. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Cieri, Anthony Sent: Tuesday, August 7, 2018 2:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Jes2 Initiator number For this particular exercise/issue I do not need to consider WLM Inits. Initially, I would like to be able to produce a list of jobs that ran in a particular JES2 initiator. We occasionally have an issue with S822 abends. They don't occur very often, but when they do, that is a rash of them. Once it starts, the ABENDs seem to reoccur in the same JES2 Initiator (or two). It would be ideal, If I could come up with an automate solution that would capture the initiator and drain/restart it. They is usually how we recover from the issue. The audit trail is needed to determine what job(s) instigate the S822 ABENDs. If we can identify them, we could get the appropriate application owners involved. This could all be accomplished through some syslog research. I was hoping to find a more automated solution... Thanks again. Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 07, 2018 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Jes2 Initiator number It depends. You indicate JES2 INITs but would you also consider WLM Inits as well? JES2 initiators are just a place to start a job. What specifically are you trying to work on that requires that information? Lizette > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tony Cieri > Sent: Tuesday, August 07, 2018 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Jes2 Initiator number > > Is the JES2 initiator number that runs a job recorded in any SMF records?? > > The only "audit" trail that I can find is the $HASP373 message when a > job is started. > > I would appreciate any pointers that anyone can provide. > Thanks > Tony > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Jes2 Initiator number
SMF 30 has the ASID, in case that’s useful. Cheers, Martin Sent from my iPad > On 7 Aug 2018, at 20:59, Cieri, Anthony wrote: > > >For this particular exercise/issue I do not need to consider WLM Inits. > >Initially, I would like to be able to produce a list of jobs that ran in a particular JES2 initiator. > >We occasionally have an issue with S822 abends. They don't occur very often, but when they do, that is a rash of them. Once it starts, the ABENDs seem to reoccur in the same JES2 Initiator (or two). It would be ideal, If I could come up with an automate solution that would capture the initiator and drain/restart it. They is usually how we recover from the issue. > >The audit trail is needed to determine what job(s) instigate the S822 ABENDs. If we can identify them, we could get the appropriate application owners involved. > >This could all be accomplished through some syslog research. I was hoping to find a more automated solution... > >Thanks again. >Tony > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler > Sent: Tuesday, August 07, 2018 3:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Jes2 Initiator number > > It depends. You indicate JES2 INITs but would you also consider WLM Inits as well? > > JES2 initiators are just a place to start a job. > > > What specifically are you trying to work on that requires that information? > > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Tony Cieri >> Sent: Tuesday, August 07, 2018 12:34 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Jes2 Initiator number >> >> Is the JES2 initiator number that runs a job recorded in any SMF records?? >> >> The only "audit" trail that I can find is the $HASP373 message when a job is >> started. >> >> I would appreciate any pointers that anyone can provide. >> Thanks >> Tony >> >> -- >> 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 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAINUnless > stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Jes2 Initiator number
For this particular exercise/issue I do not need to consider WLM Inits. Initially, I would like to be able to produce a list of jobs that ran in a particular JES2 initiator. We occasionally have an issue with S822 abends. They don't occur very often, but when they do, that is a rash of them. Once it starts, the ABENDs seem to reoccur in the same JES2 Initiator (or two). It would be ideal, If I could come up with an automate solution that would capture the initiator and drain/restart it. They is usually how we recover from the issue. The audit trail is needed to determine what job(s) instigate the S822 ABENDs. If we can identify them, we could get the appropriate application owners involved. This could all be accomplished through some syslog research. I was hoping to find a more automated solution... Thanks again. Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, August 07, 2018 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Jes2 Initiator number It depends. You indicate JES2 INITs but would you also consider WLM Inits as well? JES2 initiators are just a place to start a job. What specifically are you trying to work on that requires that information? Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tony Cieri > Sent: Tuesday, August 07, 2018 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Jes2 Initiator number > > Is the JES2 initiator number that runs a job recorded in any SMF records?? > > The only "audit" trail that I can find is the $HASP373 message when a job is > started. > > I would appreciate any pointers that anyone can provide. > Thanks > Tony > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Jes2 Initiator number
In 2004, MXG Change 19.269 provided an IEFU84 exit that captures and moves the Initiator Number and Initiator Number into the SMF 30 Subtype 1, and MXG type 30 processing picks them up. I have no recent confirmation that exit code runs but I also have no recent confirmations that it's in use anywhere. Barry Herbert W. “Barry” Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 www.mxg.com ba...@mxg.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Cieri Sent: Tuesday, August 7, 2018 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Jes2 Initiator number Is the JES2 initiator number that runs a job recorded in any SMF records?? The only "audit" trail that I can find is the $HASP373 message when a job is started. I would appreciate any pointers that anyone can provide. Thanks Tony -- 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: Jes2 Initiator number
It depends. You indicate JES2 INITs but would you also consider WLM Inits as well? JES2 initiators are just a place to start a job. What specifically are you trying to work on that requires that information? Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tony Cieri > Sent: Tuesday, August 07, 2018 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Jes2 Initiator number > > Is the JES2 initiator number that runs a job recorded in any SMF records?? > > The only "audit" trail that I can find is the $HASP373 message when a job is > started. > > I would appreciate any pointers that anyone can provide. > Thanks > Tony > > -- > 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
Jes2 Initiator number
Is the JES2 initiator number that runs a job recorded in any SMF records?? The only "audit" trail that I can find is the $HASP373 message when a job is started. I would appreciate any pointers that anyone can provide. Thanks Tony -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
