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 <[email protected]> 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 <[email protected]> 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 > > [email protected] 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 > > > [email protected] 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 > > > [email protected] 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 > > > > [email protected] 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 [email protected] with the message: INFO IBM-MAIN > > > > > ---------------------------------------------------------------------- > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > > send email to [email protected] with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
