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-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> 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 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 <IBM-MAIN@LISTSERV.UA.EDU> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
