This sounds very much like the VPS STC is memory constrained and the actions to remove some redundant definitions has relieved the HWM ... for the time being.
I would strongly suggest some analysis of the memory usage in the address space whilst it is active to examine the limits (LDA/LDAX) and usage (VSMDATA) of virtual storage. IPCS can do this in detail, or for a simpler "bird's eye view" you can use the SDSF "AS" screen and then the JM action to drill down to each subpool. Note the new columns on SDSF "AS" that show you the Private and E-Private region sizes and their current percentage usage (most likely off to the far RHS of the panel). Rob Scott Rocket Software ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of rpinion865 <[email protected]> Sent: 28 January 2025 3:25 PM To: [email protected] <[email protected]> Subject: Re: VPS STC run as a batch job EXTERNAL EMAIL No we have not added or deleted any printers since third quarter last year. LRS suggested we remove old printers definitions, for printers that no longer exist. After removing the dead definitions, VPS came up as a STC. "Confidentially doc, I am the wabbit." Bugs Bunny Sent with Proton Mail secure email. On Tuesday, January 28th, 2025 at 10:04 AM, Dave Gibney <[email protected]> wrote: > 1. There is a healthcheck that watches for memory boundary > (sqa/esqa/csa/ecsa) over ipls. > 2. Djd you add additional printers? > > > -----Original Message----- > > From: IBM Mainframe Discussion List [email protected] On > > Behalf Of rpinion865 > > Sent: Tuesday, January 28, 2025 6:55 AM > > To: [email protected] > > Subject: Re: VPS STC run as a batch job > > > > 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 > > [email protected] 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 > > > [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 > > > > ---------------------------------------------------------------------- > > 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 ================================ Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
