This is very good, thank you!
"Confidentially doc, I am the wabbit." Bugs Bunny Sent with Proton Mail secure email. On Wednesday, January 29th, 2025 at 4:09 AM, Rob Scott <00000618c90e6fdf-dmarc-requ...@listserv.ua.edu> wrote: > 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 IBM-MAIN@LISTSERV.UA.EDU on behalf of > rpinion865 0000042a019916dd-dmarc-requ...@listserv.ua.edu > > Sent: 28 January 2025 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > 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 > 000006fb76de82cb-dmarc-requ...@listserv.ua.edu 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 IBM-MAIN@LISTSERV.UA.EDU On > > > Behalf Of rpinion865 > > > Sent: Tuesday, January 28, 2025 6:55 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > 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 > > > 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 > > > > ---------------------------------------------------------------------- > > 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 > > > ================================ > 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 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
