I looked at the storage statistics created in the JESJCL logs. I can see that
the batch
job run of VPS allocated and used more region than the STC run of VPS.
BATCH JOB VPSDCS
VIRT: 10900K SYS: 540K EXT: 76720K SYS: 27268K
ATB- REAL: 10068K SLOTS: 0K
VIRT- ALLOC: 263M SHRD: 0M
STC VPSDCS
VIRT: 10976K SYS: 400K EXT: 48988K SYS: 15076K
ATB- REAL: 6312K SLOTS: 0K
VIRT- ALLOC: 74M SHRD: 0M
"Confidentially doc, I am the wabbit."
Bugs Bunny
Sent with Proton Mail secure email.
On Tuesday, January 28th, 2025 at 9:29 AM, Ituriel do Neto
<000003427ec2837d-dmarc-requ...@listserv.ua.edu> wrote:
> Did you compare the memory usage in the JESJCLMSG sysout of both STC and JOB?
>
>
> Best Regards
>
> Ituriel do Nascimento Neto
> z/OS System Programmer
>
>
>
>
>
>
> Em terça-feira, 28 de janeiro de 2025 às 10:46:18 BRT, rpinion865
> 0000042a019916dd-dmarc-requ...@listserv.ua.edu escreveu:
>
>
>
>
>
>
> I did a $DEXIT(*), and all of our exits have ROUTINES=(),STATUS=DESABLED. So
> no JES2
> modifications.
>
>
>
> "Confidentially doc, I am the wabbit."
>
> Bugs Bunny
>
> Sent with Proton Mail secure email.
>
>
> On Tuesday, January 28th, 2025 at 8:35 AM, David Spiegel
> 00000468385049d1-dmarc-requ...@listserv.ua.edu wrote:
>
> > Hi Rich,
> > Do you have any JES Exits which modify submitted JCL and/or Internal Text?
> >
> > Regards,
> > David
> >
> > On 2025-01-28 07:58, rpinion865 wrote:
> >
> > > We have the default IEFUSI, compile date of 05/13/1990, and IBM's
> > > Application Performance Analyzer IEFUSI.
> > > I looked at SYS1.SAMPLIB(IEEUSI) and I do not think that code does
> > > anything different for a batch job vs.
> > > a STC. The SMFPRMxx parmlib member (and no it has not changed) has
> > > MEMLIMIT(8G).
> > >
> > > "Confidentially doc, I am the wabbit."
> > >
> > > Bugs Bunny
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > On Tuesday, January 28th, 2025 at 7:38 AM, Ituriel do Neto
> > > 000003427ec2837d-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > > The JCL statement REGION overrides the one defined at JOBCLASS.
> > > > Do you have an IEFUSI exit? There may be differences related to REGION
> > > > definition because of LSQA settings for JOB and STC.
> > > >
> > > > Best Regards
> > > >
> > > > Ituriel do Nascimento Neto
> > > > z/OS System Programmer
> > > >
> > > > Em terça-feira, 28 de janeiro de 2025 às 09:28:46 BRT, rpinion865
> > > > 0000042a019916dd-dmarc-requ...@listserv.ua.edu escreveu:
> > > >
> > > > I forgot to add, the VPS PROC has REGION=0M. The JES2 STC JOBCLASS has
> > > > REGION=4M.
> > > > When I ran VPS as a batch job, I had REGION=0M coded on my job
> > > > statement. Does
> > > > anyone know if the JES2 STC JOBCLASS REGION would override what is
> > > > coded on the EXEC
> > > > statement of a STC?
> > > >
> > > > I will dig around and see if I have any programs that report on SMF
> > > > type 30 records.
> > > > I would need something that would show region statistics. Perhaps, that
> > > > would show
> > > > VPS region usage over the last couple of months.
> > > >
> > > > "Confidentially doc, I am the wabbit."
> > > >
> > > > Bugs Bunny
> > > >
> > > > Sent with Proton Mail secure email.
> > > >
> > > > On Tuesday, January 28th, 2025 at 7:22 AM, rpinion865
> > > > 0000042a019916dd-dmarc-requ...@listserv.ua.edu wrote:
> > > >
> > > > > Since I am the z/OS system programmer, I can say with 99% confidence,
> > > > > nothing has changed.
> > > > > But I have learned the hard way, never say never. I did not make any
> > > > > parmlib or JES2 parm
> > > > > changes. As for the IPL, it was the scheduled monthly IPL (not my
> > > > > decision, that is
> > > > > way it has been for many, many years, predating my start date of May
> > > > > 2022).
> > > > >
> > > > > LRS had us run a GTF trace and send them the output. After analyzing
> > > > > the GTF trace and
> > > > > VPS logs, they suggested we remove printer definitions for printers
> > > > > that were no longer
> > > > > present. Again, this company has a bad habit of maintaining
> > > > > pre-historic artifacts.
> > > > > After the dead printers were removed, VPS, as a STC, came up and is
> > > > > stable.
> > > > >
> > > > > "Confidentially doc, I am the wabbit."
> > > > >
> > > > > Bugs Bunny
> > > > >
> > > > > Sent with Proton Mail secure email.
> > > > >
> > > > > On Tuesday, January 28th, 2025 at 1:55 AM, Brian Westerman
> > > > > 000006ba4ed225c9-dmarc-requ...@listserv.ua.edu wrote:
> > > > >
> > > > > > Someone could have changed the location of some control blocks in
> > > > > > parmlib and now they are in 64bit areas. Or someone could have
> > > > > > added the TIOT constraint relief stuff or any of several other
> > > > > > "minor" parm changes that upset where VPS is able to touch things.
> > > > > > It could also be that the VPS software itself was changed with some
> > > > > > maintenance.
> > > > > >
> > > > > > Since it's a STC vs JOB thing, then it could be that someone made a
> > > > > > change to the JES2PARMS and moved some of the constraint relief
> > > > > > stuff around. Probably SWA.
> > > > > >
> > > > > > The good news is that VPS can run as a batch job without any reall
> > > > > > issues, but you do need to make sure that you code TIME=1440 on the
> > > > > > execute card or jobcard.
> > > > > >
> > > > > > The A03 is probably because one of the internal VPS tasks has
> > > > > > abended before it detached it's subtasks. The S0C4 will probably be
> > > > > > pointing to some area above the line or the 64bit line and your
> > > > > > program is likely either 24bit and can't see the 31 bot area or
> > > > > > 31bit and cant see the 64bit area.
> > > > > >
> > > > > > So, you can run as a batch job for a while, but you need to run
> > > > > > down the changes to parmlib (could be DIAGxx), or JES2parms to see
> > > > > > what they changed.
> > > > > >
> > > > > > Nobody IPLs just for the fun of it so someone cahnged something. If
> > > > > > it's been a while since the last one then lots of stuff could have
> > > > > > changed.
> > > > > >
> > > > > > If you can't find the culprit, then restore your res volume from a
> > > > > > previous point in time (like from your previous IPL time) and you
> > > > > > will likely see that things run just fine, then you will need to
> > > > > > compare the parmlibs to see what changed. If it's a VPS change,
> > > > > > then look at the last update date on your VPS loadlibs, if thoe
> > > > > > dates are before the previous IPL, (the one where things still
> > > > > > worked) then the problem is outside VPS and you need to track down
> > > > > > the varmint that changed stuff on the res pack on you.
> > > > > >
> > > > > > You might be able to find the culprit just by looking at what has
> > > > > > changed since the previous IPL in parmlib by looking at the dates
> > > > > > on the members.
> > > > > >
> > > > > > Remember, if everyone says "nobody changed nothin", then someone is
> > > > > > not telling the truth. Something changed, software doesn't just
> > > > > > break for no reason.
> > > > > >
> > > > > > The first thing that should tip you off that something changed was
> > > > > > the fact that you IPLed. There must have been a reason, and maybe
> > > > > > someone thought to slip some other changes in on you.
> > > > > >
> > > > > > Look closely, you'll find it.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > ----------------------------------------------------------------------
> > > > > > 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
> > > > ----------------------------------------------------------------------
> > > > 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
