I pointing to the first that would be IKJEFT01 I can interrogate the FLAG bytes RBSTAB at +A to make sure it’s a PRB and then look at RBCDE to make sure it points to IKJEFT01
On Thu, Sep 28, 2023 at 8:22 PM Seymour J Metz <sme...@gmu.edu> wrote: > There are at least two jobstep TCBs in your address space. > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Joseph Reichman <reichman...@gmail.com> > Sent: Thursday, September 28, 2023 7:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SCHEDIRB > > Thanks > > Again, for getting back went to sleep as I had to be up for work > > One more idea you said TSO does SVC screening which is why my LOAD abended > > I could go one step higher to the initiator > > So instead of > > L R4,PSATOLD > L R4,TCBJSTCB-TCB(R4) > > I could > > L R4,PSAAOLD > L R4,ASCBASXB-ASCB(,R4) > L R4,ASXBFTCB-ASXB(R4) > > This code would probably stop my LOAD from abending and have the module in > the JOB PAC QUEUE > > There is only ONE STEP in the TSO JOB > > EXEC PGM=IKJEFT01 > > Thanks > > > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > Michael Stein > Sent: Thursday, September 28, 2023 2:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SCHEDIRB > > On Thu, Sep 28, 2023 at 01:30:05AM -0400, Joseph Reichman wrote: > > Thanks > > > > The one glaring thing that was happening was that load was indeed > > abending you said linking it with ac=1 would solve that issue > > No, but it needs to come from an authorized library. > > > I don't understand your suggestion about doing a storage obtain and > > load to the obtained area isn't storage also tied into the TCB ? > > Yes, it's tied to a TCB, but which TCB? Branch entry (storage > linkage=branch and others) allows specifying the TCB to use/own the > storage. > This could be follwed by LOAD ADDR=. > > In this case the system would track the storage ownership but won't > remember > anything about the module (it's not in the job pack queue). > It's just storage (which happens to have code in it). > > Your idea of scheduling an IRB to the task and doing the load from there is > similar in that a different TCP winds up owning the storage/module. > In that case the system would track the module. Also this might cause > problems for batch jobs as the initiator (used to?) free the whole region > between job steps -- where did your storage go? > > > And your suggestion about identify I mean if I gave it an alternate > > name on the fly that would insure the load module remains in core once > > the running TCB goes away ? > > No, it would go away with the module it's an alternate for (in some sense). > > > Regardless of a module use count I thought once the TCB in control > > while the load was done goes away so would all the resources tied into > > that TCB go away such as storage and load module > > Right. End of task cleans up resources. If there are other users it might > just lower use counts but if it's the last *poof*. > > End of jobstep does/might free the region & other things. > > End of address space, well it's gone and the end of memory routines likely > run in masters address space... > > > Also Micheal had suggested that I do not need to be running under an > > IRB to do SCHEDIRB > > Right, from the manual, this is the SCHEDIRB RBPTR "directed IRB" case that > needed to be running on an IRB. That case also restricted to only > scheduling the IRB to the current task. > > > In that case I could get rid of the stimer ? > > Yes. > > > ---------------------------------------------------------------------- > 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
