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
