There are at least two jobstep TCBs in your address space. ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Joseph Reichman <[email protected]> Sent: Thursday, September 28, 2023 7:42 AM To: [email protected] 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 <[email protected]> On Behalf Of Michael Stein Sent: Thursday, September 28, 2023 2:12 AM To: [email protected] 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 [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
