Discussion:
Jes2 Initiator number
(too old to reply)
Tony Cieri
2018-08-07 19:34:24 UTC
Permalink
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-08-07 19:41:32 UTC
Permalink
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-----
Tony Cieri
Sent: Tuesday, August 07, 2018 12:34 PM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cieri, Anthony
2018-08-07 19:58:53 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, August 07, 2018 3:42 PM
To: IBM-***@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-----
Tony Cieri
Sent: Tuesday, August 07, 2018 12:34 PM
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
----------------------------------------------------------------------
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
Martin Packer
2018-08-07 20:00:58 UTC
Permalink
SMF 30 has the ASID, in case that’s useful.

Cheers, Martin

Sent from my iPad
Post by Cieri, Anthony
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.
Post by Cieri, Anthony
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.
Post by Cieri, Anthony
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.
Post by Cieri, Anthony
This could all be accomplished through some syslog research. I was
hoping to find a more automated solution...........
Post by Cieri, Anthony
Thanks again.
Tony
-----Original Message-----
Behalf Of Lizette Koehler
Post by Cieri, Anthony
Sent: Tuesday, August 07, 2018 3:42 PM
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?
Post by Cieri, Anthony
Lizette
-----Original Message-----
Tony Cieri
Sent: Tuesday, August 07, 2018 12:34 PM
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
Post by Cieri, Anthony
started.
I would appreciate any pointers that anyone can provide.
Thanks
Tony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-08-07 20:35:03 UTC
Permalink
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 Time End 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-----
Cieri, Anthony
Sent: Tuesday, August 07, 2018 12:59 PM
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-----
Behalf Of Lizette Koehler
Sent: Tuesday, August 07, 2018 3:42 PM
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-----
Behalf Of Tony Cieri
Sent: Tuesday, August 07, 2018 12:34 PM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Cieri, Anthony
2018-08-07 21:06:03 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, August 07, 2018 4:35 PM
To: IBM-***@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 Time End 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-----
Cieri, Anthony
Sent: Tuesday, August 07, 2018 12:59 PM
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-----
Behalf Of Lizette Koehler
Sent: Tuesday, August 07, 2018 3:42 PM
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-----
Behalf Of Tony Cieri
Sent: Tuesday, August 07, 2018 12:34 PM
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
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
2018-08-09 13:28:32 UTC
Permalink
Post by Cieri, Anthony
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barry Merrill
2018-08-07 19:49:49 UTC
Permalink
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
***@mxg.com






-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Cieri
Sent: Tuesday, August 7, 2018 2:34 PM
To: IBM-***@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 ***@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
Cieri, Anthony
2018-08-07 20:47:49 UTC
Permalink
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-***@LISTSERV.UA.EDU] On Behalf Of Barry Merrill
Sent: Tuesday, August 07, 2018 3:50 PM
To: IBM-***@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
***@mxg.com






-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Cieri
Sent: Tuesday, August 7, 2018 2:34 PM
To: IBM-***@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 ***@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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Beverly Caldwell
2018-08-07 21:16:14 UTC
Permalink
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.
Post by Tony Cieri
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...