Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
This will be the last thing I say on this subject. I am NOT calling anyone "out." I am simply asking...nicely,,, that this thread stop, and with it, the vituperative comments, insults, nastiness, etc. that seems to permeate this forum lately. From EVERYONE! Please, don't we have enough of this in the world these days? Can't we be decent and civil to each other? Is it really THAT difficult? Doug Fuerst -- Original Message -- From "Jon Perryman" To IBM-MAIN@LISTSERV.UA.EDU Date 10/31/2023 20:04:24 PM Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8 On Tue, 31 Oct 2023 23:15:44 +, Doug Fuerst wrote: I am not OK with any of it, and after Mr. Johnson, I suspect the list is not as well. I'm also not ok with this but it's Crayford you should be calling out. By ignoring his insults the first couple of times, I showed far more respect and restraint to Crayford than he has shown to me. As long as Crayford is respectful, the problem does not exist nor would it have arose in the first place. I must say that things are much better after Mr. Johnson. -- 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
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
On Tue, 31 Oct 2023 23:15:44 +, Doug Fuerst wrote: >I am not OK with any of it, and after Mr. Johnson, I suspect the list is >not as well. I'm also not ok with this but it's Crayford you should be calling out. By ignoring his insults the first couple of times, I showed far more respect and restraint to Crayford than he has shown to me. As long as Crayford is respectful, the problem does not exist nor would it have arose in the first place. I must say that things are much better after Mr. Johnson. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
I am not OK with any of it, and after Mr. Johnson, I suspect the list is not as well. I'd just like it to be kept civil, and limited to real exchanges of technical issues. I hope you all realize that you can take this off the forum and discuss amongst yourselves. But let's try and keep this civil and professional. Please? Doug Fuerst -- Original Message -- From "Jon Perryman" To IBM-MAIN@LISTSERV.UA.EDU Date 10/31/2023 19:06:25 PM Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8 On Tue, 31 Oct 2023 21:53:36 +, Doug Fuerst wrote: Did we just trade Bill Johnson for Jon Perryman? Are you two related? We are back to backbiting and insults. Can we just stop? If I'm showing a pattern of being confused or being constantly wrong (as claimed by Crayford), please show me where. So you are ok with Crayford intentionally insulting me but my finally getting fed up with him puts me into the Bill Johnson classification? My last response was not intended to be insulting. If it was, I apologize. I greatly respect Peter's insights but this was the perfect example for Crayford that demonstrated take the high road In this case, there was no benefit in pursuing an obscure situation that others will never see. It was better to ignore it and allow others to think I was wrong. The last response was driven by Crayford responding with "confused again" after I showed how wrong and confused he was on his last 3 responses to my comments. What has emboldened Crayford to be insulting? It certainly is not based on his real knowledge. -- 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
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
On Tue, 31 Oct 2023 21:53:36 +, Doug Fuerst wrote: >Did we just trade Bill Johnson for Jon Perryman? Are you two related? We >are back to backbiting and insults. >Can we just stop? If I'm showing a pattern of being confused or being constantly wrong (as claimed by Crayford), please show me where. So you are ok with Crayford intentionally insulting me but my finally getting fed up with him puts me into the Bill Johnson classification? My last response was not intended to be insulting. If it was, I apologize. I greatly respect Peter's insights but this was the perfect example for Crayford that demonstrated take the high road In this case, there was no benefit in pursuing an obscure situation that others will never see. It was better to ignore it and allow others to think I was wrong. The last response was driven by Crayford responding with "confused again" after I showed how wrong and confused he was on his last 3 responses to my comments. What has emboldened Crayford to be insulting? It certainly is not based on his real knowledge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
Did we just trade Bill Johnson for Jon Perryman? Are you two related? We are back to backbiting and insults. Can we just stop? Doug Fuerst -- Original Message -- From "Jon Perryman" To IBM-MAIN@LISTSERV.UA.EDU Date 10/31/2023 17:34:02 PM Subject Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8 On Fri, 29 Sep 2023 14:35:45 +, Peter Relson wrote: As this related to a purported need to link with AC=1, I was perfectly sure that that was not correct. And I remain so. Is it truly a coincidence that this group failed in 1 week to solve a simple SCHEDIRB and LOAD failing when shortly after my first attempt, the op solved his problem? The OP sent his source and the op said it failed on LOAD. If this were not TSO involving LOAD, Peter might be correct. TSO does not follow conventional wisdom and rules. As a product developer, we had a LOAD fail in our product where (if I remember correctly) the solution was to link the module AC=1. Our product address space included multi-tasking TSO (concurrent TSO commands). Most people don't experience the quirks of TSO and would be surprised to learn that TSO changes many of the rules. For instance, I am painfully aware of JSCBAUTH because there are times it must be restored in TSO. Unix dubbing is also a problem. I bring this up because clueless Crayford is now saying "you're confused AGAIN" which I find offensive. Clearly I was not confused in my response to his comments. Clearly I'm not confused here although it's possible I'm wrong about TSO AC=1. When exactly am I repeatedly confused? I have a different life experience than most. Just because I don't respond does not mean I'm wrong. It's very rare for anyone to experience TSO quirks when there are only a couple of products running multi-tasking TSO in their product address space. There are few people with vast experience in a single diverse address space where many products are executing concurrently. Why should I continue a discussion that is irrelevant for most people and not beneficial to me? Why do people consider me confused when I make completely relevant recommendations that many do not understand. This is my style of problem solving and it clearly works. -- 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
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
On Fri, 29 Sep 2023 14:35:45 +, Peter Relson wrote: > As this related to a purported need to link with AC=1, > I was perfectly sure that that was not correct. And I remain so. Is it truly a coincidence that this group failed in 1 week to solve a simple SCHEDIRB and LOAD failing when shortly after my first attempt, the op solved his problem? The OP sent his source and the op said it failed on LOAD. If this were not TSO involving LOAD, Peter might be correct. TSO does not follow conventional wisdom and rules. As a product developer, we had a LOAD fail in our product where (if I remember correctly) the solution was to link the module AC=1. Our product address space included multi-tasking TSO (concurrent TSO commands). Most people don't experience the quirks of TSO and would be surprised to learn that TSO changes many of the rules. For instance, I am painfully aware of JSCBAUTH because there are times it must be restored in TSO. Unix dubbing is also a problem. I bring this up because clueless Crayford is now saying "you're confused AGAIN" which I find offensive. Clearly I was not confused in my response to his comments. Clearly I'm not confused here although it's possible I'm wrong about TSO AC=1. When exactly am I repeatedly confused? I have a different life experience than most. Just because I don't respond does not mean I'm wrong. It's very rare for anyone to experience TSO quirks when there are only a couple of products running multi-tasking TSO in their product address space. There are few people with vast experience in a single diverse address space where many products are executing concurrently. Why should I continue a discussion that is irrelevant for most people and not beneficial to me? Why do people consider me confused when I make completely relevant recommendations that many do not understand. This is my style of problem solving and it clearly works. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
Thanks I have verified the IRB ran to completion while at a test breakpoint in the originating TCB the IRB ran under IKJEFT01 on a different cpu > On Oct 4, 2023, at 10:56 PM, Jon Perryman wrote: > > On Mon, 2 Oct 2023 16:18:24 -0400, Joseph Reichman > wrote: > >> Do suggest when scheduling an Async IRB I have a Wait/Post > > Joseph, yes you need to wait/post because an async IRB only serializes on 1 > TCB (TCB with the IRB). If you do use WAIT, then you should implement > recovery in the IRB. While it's unlikely to abend, the wait must be posted > otherwise you have a hang. For instance, what happens if the LOAD does not > find the module? At the very least, code error return. > > -- > 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
Re: SCHEDIRB
On Mon, 2 Oct 2023 16:18:24 -0400, Joseph Reichman wrote: >Do suggest when scheduling an Async IRB I have a Wait/Post Joseph, yes you need to wait/post because an async IRB only serializes on 1 TCB (TCB with the IRB). If you do use WAIT, then you should implement recovery in the IRB. While it's unlikely to abend, the wait must be posted otherwise you have a hang. For instance, what happens if the LOAD does not find the module? At the very least, code error return. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
On Wed, 4 Oct 2023 12:06:15 + Seymour J Metz wrote: :>Peter: is there a redbook that discusses the role of the IRB, or, more generally, a document suitable for citing on Wikipedia that discusses the RB types in lay terms? Not Peter, but I have used IRBs in two cases. (1) In SRB mode, but need to do stuff that requires TCB. (2) I want to get control between RBs, i.e., my coded is invoked under a PRB and I want to get control when that RB ends (not the TCB since it may end much later). Think IMS. Don't recall any applications where in task mode in that memory I want to run an RB under a different task. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
The whole point of scheduling an IRB is that it is asynchronous but allowed to issue SVCs. Peter: is there a redbook that discusses the role of the IRB, or, more generally, a document suitable for citing on Wikipedia that discusses the RB types in lay terms? From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Tuesday, October 3, 2023 10:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCHEDIRB On Mon, 2 Oct 2023 16:18:24 -0400, Joseph Reichman wrote: >Do suggest when scheduling an Async IRB I have a Wait/Post I only know the basics about IRB because none of the products I've worked on use it. Is async for the address space or for the TCB? In other words, does the SCHEDIRB wait for IRB completion? The doc only mentions the TCB so I've always assumed only the TCB running the IRB. It wouldn't take much to test it but I wouldn't trust until 100% sure the address space waits on the IRB completion. -- 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
Re: SCHEDIRB
>does the SCHEDIRB wait for IRB completion? No. Any coordination between the scheduler of the IRB and the IRB routine itself is up to the scheduler and IRB routine to provide. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
No, it does not. On Tue, 3 Oct 2023 21:19:58 -0500 Jon Perryman wrote: :>On Mon, 2 Oct 2023 16:18:24 -0400, Joseph Reichman wrote: :>>Do suggest when scheduling an Async IRB I have a Wait/Post :>I only know the basics about IRB because none of the products I've worked on use it. Is async for the address space or for the TCB? In other words, does the SCHEDIRB wait for IRB completion? The doc only mentions the TCB so I've always assumed only the TCB running the IRB. It wouldn't take much to test it but I wouldn't trust until 100% sure the address space waits on the IRB completion. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
On Mon, 2 Oct 2023 16:18:24 -0400, Joseph Reichman wrote: >Do suggest when scheduling an Async IRB I have a Wait/Post I only know the basics about IRB because none of the products I've worked on use it. Is async for the address space or for the TCB? In other words, does the SCHEDIRB wait for IRB completion? The doc only mentions the TCB so I've always assumed only the TCB running the IRB. It wouldn't take much to test it but I wouldn't trust until 100% sure the address space waits on the IRB completion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
Do suggest when scheduling an Async IRB I have a Wait/Post > On Sep 29, 2023, at 4:16 AM, Binyamin Dissen > wrote: > > On Thu, 28 Sep 2023 20:37:02 -0500 Jon Perryman wrote: > > :>Another problem with your code dawned on me. Your IRB routine and passed > storage could be freed while the IRB is still executing. The IRB routine only > does a LOAD but the I/O time could be long enough for the originating program > to end and possibly the TCB. Remember you are running sup key 0 which makes > you the destroyer of worlds. > > Other than via a CALLRTM (which should drive the ESTAE) the task cannot be > ripped out while an RB is running (and still have a useable address space). > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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
Re: SCHEDIRB
Joseph Reichman wrote on 9/28/2023 5:25 PM: I pointing to the first that would be IKJEFT01 Most of the time. But not on _my_ typical TSO sessions. And since I'm using an IBM program for this, other sites would also be using it. If I remember when I'm working I'll go check where T01 is in the TCBs/RBs on my TSO sessions. 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 What about a batch job using one of the various alternate entry points for IKJEFT01? One more idea you said TSO does SVC screening which is why my LOAD abended I would be astounded to find out that TSO does SVC screening. However, if you're running under [bleah] TSO TEST / TESTAUTH, I'm pretty sure that TEST[AUTH] somehow has its hooks into LINK and LOAD, and probably deep enough into LOAD that it also gets ATTACH[X] and every other program-fetch-related function. This code would probably stop my LOAD from abending Anytime you ask for help with an abend you need to say what the abend code is, other it's just "my program didn't work" to which my standard answer is either "so?" or "my condolences". /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
Looking into it now > On Sep 29, 2023, at 10:36 AM, Peter Relson wrote: > > >> >> even Peter Relson wasn't sure if this correct > > As this related to a purported need to link with AC=1, I was perfectly sure > that that was not correct. And I remain so. > > Joe R: you've mentioned multiple times that you abended after the load. > But did you ever share what abend code and abend reason code you got? Perhaps > I missed it... > > It's never helpful to talk about getting an abend without describing what > that abend (or completion code because it might not have been an error from > the ABEND macro). > > Peter Relson > z/OS Core Technology Design > > > -- > 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
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
> even Peter Relson wasn't sure if this correct As this related to a purported need to link with AC=1, I was perfectly sure that that was not correct. And I remain so. Joe R: you've mentioned multiple times that you abended after the load. But did you ever share what abend code and abend reason code you got? Perhaps I missed it... It's never helpful to talk about getting an abend without describing what that abend (or completion code because it might not have been an error from the ABEND macro). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
TSO/E added, e.g. authorized commands, and ATTACH RSAPF=YES tests for AC(1). From: IBM Mainframe Discussion List on behalf of Michael Stein Sent: Friday, September 29, 2023 1:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCHEDIRB On Thu, Sep 28, 2023 at 08:37:02PM -0500, Jon Perryman wrote: > I don't have access to z/OS. Joseph, can you run a simple test to > find out if this is a problem because others say it's not. Assemble, > link (with AC=1) and run from JCL the following prog: Unless something major has changed (which would break lots of things), only the EXEC PGM= module has to be AC(1). Here's an abstract from the UCLA/IPC linked: // EXEC LKED,PARM.LKED='RENT,REUS,XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCMAIN SETCODE AC(1) NAME IPCMAIN(R) -- IPC STC/TASK ROUTINE(S) ..several include statments.. ..several order statements.. ENTRY IPCINIT NAME IPCINIT(R) -- IPC SUBSYSTEM INIT ROUTINE // EXEC LKED,PARM.LKED='XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCGCA *** ENTRY POINT AT OFFSET 0 *** NAME IPCCSA(R) -- IPC CSA MODULE (SVC/SRB RTNS) This worked and the IPCMAIN routine received control authorized. No other modules are AC(1). Issuing loads on the other modules which are not AC(1) but are in an authorized library worked just fine. > Can you let me know if the load failed? It's been a long time but I > vaguely recall problems loading unauthorized programs from an authorized > program. If the search program fetch does finds the module in a non-authorized library it will issue an abend. A concatenation can not have any non-authorized libraries in it and remain authorized. > >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 ? > A RENT/REUS load module is shared by all TCB's and not freed when the > TCB goes away. Instead, it is loaded to jobstep storage and when it's > use count goes to 0 (no TCB is using it), the module is freed. Be extra careful with this desciption as it likely only applies to a single job step. (The job pack queue of modules is related to the job step task. There's likely more than one in the TSO address space related to this discussion...) > 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 LOAD requests are tied to the TCB issuing them however the module is fetched into the job pack area anchored to the jobstep task (and has a JPQ use count). At some point in task termination all the modules loaded by the terminating task get unloaded. This decreases the use count for each of the modules which were loaded by this task in the JPQ too. I'd expect that task termination causes each RB on the TCB to exit which frees any module requested via ATTACH/LINK/ATTACH as these requests (and use counts) normally get lowered by normal exit. For more information which is slightly outdated see: SY28-0764-0_OS_VS2_System_Logic_Library_Vol_4_Rel_3.7_Jul76.pdf https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 A lot can change in 47 years but not everything... > When a TCB terminates, cleanup is performed. TCB storage is freed. I > don't know the specifics for how load modules. I assume load module > cleanup occurs during TCB termination but it would make more sense that > RB termination does this cleanup so that load modules are freed after > they have been used instead of waiting for the TCB to terminate. They are likely freed when the use counts get to zero. As above load requests are tied to the task issuing load. The use counts for LINK/ATTACH/XCTL are tied to the RB created for that transfer of control and are released when the RB exits (or issues XCTL which is similar to exit as far a module usage goes). Abnormal termination likely walks the RB chain and points all the saved PSW instruction pointers to EXIT so they all go away. The last RB calling exit is end of task. -- 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
Re: SCHEDIRB
On Thu, 28 Sep 2023 20:37:02 -0500 Jon Perryman wrote: :>Another problem with your code dawned on me. Your IRB routine and passed storage could be freed while the IRB is still executing. The IRB routine only does a LOAD but the I/O time could be long enough for the originating program to end and possibly the TCB. Remember you are running sup key 0 which makes you the destroyer of worlds. Other than via a CALLRTM (which should drive the ESTAE) the task cannot be ripped out while an RB is running (and still have a useable address space). -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
On Thu, Sep 28, 2023 at 08:37:02PM -0500, Jon Perryman wrote: > I don't have access to z/OS. Joseph, can you run a simple test to > find out if this is a problem because others say it's not. Assemble, > link (with AC=1) and run from JCL the following prog: Unless something major has changed (which would break lots of things), only the EXEC PGM= module has to be AC(1). Here's an abstract from the UCLA/IPC linked: // EXEC LKED,PARM.LKED='RENT,REUS,XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCMAIN SETCODE AC(1) NAME IPCMAIN(R) -- IPC STC/TASK ROUTINE(S) ..several include statments.. ..several order statements.. ENTRY IPCINIT NAME IPCINIT(R) -- IPC SUBSYSTEM INIT ROUTINE // EXEC LKED,PARM.LKED='XREF,LIST,LET,NCAL,MAP' //LKED.SYSLMOD DD DISP=SHR,DSN=SYS1.IPCAPF,UNIT=,SPACE= //LKED.IPCMOD DD DISP=SHR,DSN=SYS9.IPCMOD //LKED.SYSIN DD * ..several include statments.. ..several order statements.. ENTRY IPCGCA *** ENTRY POINT AT OFFSET 0 *** NAME IPCCSA(R) -- IPC CSA MODULE (SVC/SRB RTNS) This worked and the IPCMAIN routine received control authorized. No other modules are AC(1). Issuing loads on the other modules which are not AC(1) but are in an authorized library worked just fine. > Can you let me know if the load failed? It's been a long time but I > vaguely recall problems loading unauthorized programs from an authorized > program. If the search program fetch does finds the module in a non-authorized library it will issue an abend. A concatenation can not have any non-authorized libraries in it and remain authorized. > >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 ? > A RENT/REUS load module is shared by all TCB's and not freed when the > TCB goes away. Instead, it is loaded to jobstep storage and when it's > use count goes to 0 (no TCB is using it), the module is freed. Be extra careful with this desciption as it likely only applies to a single job step. (The job pack queue of modules is related to the job step task. There's likely more than one in the TSO address space related to this discussion...) > 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 LOAD requests are tied to the TCB issuing them however the module is fetched into the job pack area anchored to the jobstep task (and has a JPQ use count). At some point in task termination all the modules loaded by the terminating task get unloaded. This decreases the use count for each of the modules which were loaded by this task in the JPQ too. I'd expect that task termination causes each RB on the TCB to exit which frees any module requested via ATTACH/LINK/ATTACH as these requests (and use counts) normally get lowered by normal exit. For more information which is slightly outdated see: SY28-0764-0_OS_VS2_System_Logic_Library_Vol_4_Rel_3.7_Jul76.pdf https://archive.org/details/bitsavers_ibm370OSVSystemLogicLibraryVol4Rel3.7Jul76_23459458 A lot can change in 47 years but not everything... > When a TCB terminates, cleanup is performed. TCB storage is freed. I > don't know the specifics for how load modules. I assume load module > cleanup occurs during TCB termination but it would make more sense that > RB termination does this cleanup so that load modules are freed after > they have been used instead of waiting for the TCB to terminate. They are likely freed when the use counts get to zero. As above load requests are tied to the task issuing load. The use counts for LINK/ATTACH/XCTL are tied to the RB created for that transfer of control and are released when the RB exits (or issues XCTL which is similar to exit as far a module usage goes). Abnormal termination likely walks the RB chain and points all the saved PSW instruction pointers to EXIT so they all go away. The last RB calling exit is end of task. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
On Thu, 28 Sep 2023 01:30:05 -0400, Joseph Reichman wrote: Another problem with your code dawned on me. Your IRB routine and passed storage could be freed while the IRB is still executing. The IRB routine only does a LOAD but the I/O time could be long enough for the originating program to end and possibly the TCB. Remember you are running sup key 0 which makes you the destroyer of worlds. >The one glaring thing that was happening was that > load was indeed abending you said linking it with ac=1 would solve that issue I don't have access to z/OS. Joseph, can you run a simple test to find out if this is a problem because others say it's not. Assemble, link (with AC=1) and run from JCL the following prog: YREGS , TESTPGM CSECT , BAKR R14,0Save regs on the stack without destroying R13 LR R12,R15 USING TESTPGM,R12 WTO 'TESTPGM SETTING MODE' MODESET MODE=SUP,KEY=ZERO WTO 'TESTPGM PERFORMING LOAD' LOAD EP=IEFBR14,ERRET=LOADFAIL WTO 'TESTPGM LOAD SUCCESS' SR R15,R15 RC=0 success RC PR ,Return LOADFAIL EQU * WTO 'TESTPGM LOAD FAILED' LA R15,16 RC=16 failed RC PR , Return Can you let me know if the load failed? It's been a long time but I vaguely recall problems loading unauthorized programs from an authorized program. >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 ? Freeing storage depends upon the type of storage being used which is controlled by the subpool specified in STORAGE OBTAIN. https://www.ibm.com/docs/en/zos/2.1.0?topic=summary-storage-subpools has a column called OWNER. Using a subpool owned by the job step will be freed at step termination. A subpool owned by the address space will be freed at asid termination. System owned will never be automatically freed. Be sure the storage is obtained with the correct key you need. LOAD to storage address is only freed according to the subpool owner. Be aware that another LOAD to this program will not reference this storage. You must keep a pointer to the module (e.g. named token). >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 ? A RENT/REUS load module is shared by all TCB's and not freed when the TCB goes away. Instead, it is loaded to jobstep storage and when it's use count goes to 0 (no TCB is using it), the module is freed. I'm guessing that IDENTIFY increments the use count to keep the alternate name around for the life of the job. Since I don't have access to a system, you will need to test this. You can test this by using identify in a program from the ISPF 6 (TSO command) and then exit ISPF. Try the name specified in the identify as a TSO command. If you get command not found, then it's deleted at TCB termination instead of job termination. >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 When a TCB terminates, cleanup is performed. TCB storage is freed. I don't know the specifics for how load modules. I assume load module cleanup occurs during TCB termination but it would make more sense that RB termination does this cleanup so that load modules are freed after they have been used instead of waiting for the TCB to terminate. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
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 wrote: > There are at least two jobstep TCBs in your address space. > > > From: IBM Mainframe Discussion List on behalf > of Joseph Reichman > 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 > > LR4,PSAAOLD > LR4,ASCBASXB-ASCB(,R4) > LR4,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 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
Re: SCHEDIRB
There are at least two jobstep TCBs in your address space. From: IBM Mainframe Discussion List on behalf of Joseph Reichman 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 LR4,PSAAOLD LR4,ASCBASXB-ASCB(,R4) LR4,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 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
Re: SCHEDIRB
All I can say the SVC 8 abended in the IRB routine when I re-linked it with AC=1 everything was fine > On Sep 28, 2023, at 8:18 PM, Seymour J Metz wrote: > > AC(1) is only relevant with ATTACH RSAPF=YES, and AFAIK nobody but the > Initiayor and the TMP does that. > > > From: IBM Mainframe Discussion List on behalf of > Joseph Reichman > Sent: Thursday, September 28, 2023 9:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SCHEDIRB > > I did get an abend after SVC 8 in the code that ran the IRB the module was > not linked AC=1 > > > >> On Sep 28, 2023, at 9:11 AM, Peter Relson wrote: >> >> Jon P wrote >> >> I believe that LOAD will abend if the module is not linked with the AC=1 >> attribute when running authorized. >> >> >> It will not. You should have AC=1 only for a module that is the target of >> something akin to EXEC PGM= (i.e., the jobstep program). It's easier to obey >> this rule than to ensure that unnecessarily-marked AC=1 modules properly >> protect system security/integrity. The module would need to be in an >> APF-authorized library/concatenation. >> >> >> TSO does SVC screening to protect itself from SUP and non-KEY8 security >> exposures. >> >> >> That seems quite unlikely to me. But you could be right. >> >> Peter Relson >> z/OS Core Technology Design >> >> >> -- >> 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
Re: SCHEDIRB
AC(1) is only relevant with ATTACH RSAPF=YES, and AFAIK nobody but the Initiayor and the TMP does that. From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Thursday, September 28, 2023 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCHEDIRB I did get an abend after SVC 8 in the code that ran the IRB the module was not linked AC=1 > On Sep 28, 2023, at 9:11 AM, Peter Relson wrote: > > Jon P wrote > > I believe that LOAD will abend if the module is not linked with the AC=1 > attribute when running authorized. > > > It will not. You should have AC=1 only for a module that is the target of > something akin to EXEC PGM= (i.e., the jobstep program). It's easier to obey > this rule than to ensure that unnecessarily-marked AC=1 modules properly > protect system security/integrity. The module would need to be in an > APF-authorized library/concatenation. > > > TSO does SVC screening to protect itself from SUP and non-KEY8 security > exposures. > > > That seems quite unlikely to me. But you could be right. > > Peter Relson > z/OS Core Technology Design > > > -- > 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
Re: SCHEDIRB Jon Perryman is correct re-linked as AC=1 no ABEND ON SVC 8
Jon Kudos to you even Peter Relson wasn’t sure if this correct -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Wednesday, September 27, 2023 10:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCHEDIRB On Tue, 19 Sep 2023 20:29:52 -0400, Joseph Reichman wrote: > Source code below. Sorry for chiming in so late but I've had other priorities. I think you're being led down the wrong path. A 30 second glance at your code shows obvious coding errors. SRB and IRB are the the real danger. Running key 0 and sup makes you the destroyer of worlds. Always make this code obvious. 1. Labels IRBPTR and STIMER are not preceded by a "DROP ,". As exit routines, prior USINGs are not guaranteed. They may be using a bad reg. 2. IRBLST and TIMERLST are in a DSECT that is not obvious they have been initialized correctly. It's not obvious that generated eye catchers and default values were copied or if the area was simply zeroed. 3. Use "save (R14,R12),'exit eyecatcher' will simplify debugging when looking at a dump for the PSW address. 4. I believe that LOAD will abend if the module is not linked with the AC=1 attribute when running authorized. 5. TSO does SVC screening to protect itself from SUP and non-KEY8 security exposures. Does TSO allow an unknown LOAD from the job step TCB. 6. Is there a reason you haven't tried IDENTIFY for the module? I've never tested this situation but I suspect it increments the use count to ensure the alternate name remains available when the TCB goes away. 7. Another possibility is STORAGE OBTAIN and LOAD to the obtained area. 8. If you need to refresh the module, using LOAD from the IKJEFT01 TCB will require logoff / logon or the implementation of another IRB to refresh the LOAD module. I suspect there are other problems. With so many possible problems, you need to get familiar with IPCS because analyzing the dump would tell you quickly where and what abended. Since you don't have XDC, you may find IPCS useful when looking at the active system with the SAF BLSACTV resource permitted because you can view all address spaces. Alternatively, insert WTO's in you code to see where you are failing. > > STIMERM SET, X > ID=TIMER, X > BINTVL=NOW, X > ERRET=ERROR,X > EXIT=STIMER,X > PARM=TIMER_PLIST, X > WAIT=NO,MF=(E,TIMERLST) > > >STIMER DS 0D > STM R14,R12,12(R13) > * > LRR4,R15 > DROP R3 > USING STIMER,R4 > LRR10,R13 > L R13,4(,R1)Get Save area > DROP R13 > USING TIMERSVE,R13 > STR10,4(R13) > * > SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE > * > * > * Chain rb pointer to put this IRB as next > * > LAR5,IRBPTR > O R5,=X'8000' > STR5,IRBADD > L R6,PSATOLD > USING TCB,R6 > L R6,TCBJSTCB Get the Job Step tcb > STR6,JSTCB > SCHEDIRB EPPTR=IRBADD,X >TCBPTR=JSTCB, X >SVAREA=YES, X >MODE=SUPR, X >KEY=SUPR,
Re: SCHEDIRB
On Thu, 28 Sep 2023 11:48:37 -0400 Joseph Reichman wrote: :>I known that if I am running TESTAUTH and I do the test LOAD subcommand and the pds(member) is not from an APF authorized library I get a nasty message from TEST LOAD from non-APF when APF is not allowed. Integrity violation. 306-C abend (I believe) Not surprised that TESTAUTH would object. :>> On Sep 28, 2023, at 11:40 AM, Binyamin Dissen wrote: :>> ?On Thu, 28 Sep 2023 07:42:37 -0400 Joseph Reichman :>> wrote: :>>> One more idea you said TSO does SVC screening which is why my LOAD abended :>> I have written programs that did SVC screening, including setting up screening :>> before invoking the TMP. Never saw that TSO did SVC screening, and there :>> should mot be a need for it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
I known that if I am running TESTAUTH and I do the test LOAD subcommand and the pds(member) is not from an APF authorized library I get a nasty message from TEST > On Sep 28, 2023, at 11:40 AM, Binyamin Dissen > wrote: > > On Thu, 28 Sep 2023 07:42:37 -0400 Joseph Reichman > wrote: > >> One more idea you said TSO does SVC screening which is why my LOAD abended > > I have written programs that did SVC screening, including setting up screening > before invoking the TMP. Never saw that TSO did SVC screening, and there > should mot be a need for it. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > -- > 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
Re: SCHEDIRB
On Thu, 28 Sep 2023 07:42:37 -0400 Joseph Reichman wrote: >One more idea you said TSO does SVC screening which is why my LOAD abended I have written programs that did SVC screening, including setting up screening before invoking the TMP. Never saw that TSO did SVC screening, and there should mot be a need for it. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
I did get an abend after SVC 8 in the code that ran the IRB the module was not linked AC=1 > On Sep 28, 2023, at 9:11 AM, Peter Relson wrote: > > Jon P wrote > > I believe that LOAD will abend if the module is not linked with the AC=1 > attribute when running authorized. > > > It will not. You should have AC=1 only for a module that is the target of > something akin to EXEC PGM= (i.e., the jobstep program). It's easier to obey > this rule than to ensure that unnecessarily-marked AC=1 modules properly > protect system security/integrity. The module would need to be in an > APF-authorized library/concatenation. > > > TSO does SVC screening to protect itself from SUP and non-KEY8 security > exposures. > > > That seems quite unlikely to me. But you could be right. > > Peter Relson > z/OS Core Technology Design > > > -- > 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
Re: SCHEDIRB
Jon P wrote I believe that LOAD will abend if the module is not linked with the AC=1 attribute when running authorized. It will not. You should have AC=1 only for a module that is the target of something akin to EXEC PGM= (i.e., the jobstep program). It's easier to obey this rule than to ensure that unnecessarily-marked AC=1 modules properly protect system security/integrity. The module would need to be in an APF-authorized library/concatenation. TSO does SVC screening to protect itself from SUP and non-KEY8 security exposures. That seems quite unlikely to me. But you could be right. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 LR4,PSAAOLD LR4,ASCBASXB-ASCB(,R4) LR4,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 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
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
Re: SCHEDIRB
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 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 ? 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 ? 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 Also Micheal had suggested that I do not need to be running under an IRB to do SCHEDIRB In that case I could get rid of the stimer ? > On Sep 28, 2023, at 12:17 AM, Michael Stein wrote: > > On Wed, Sep 27, 2023 at 09:00:13PM -0500, Jon Perryman wrote: >> 4. I believe that LOAD will abend if the module is not linked with >> the AC=1 attribute when running authorized. > > No, it has to be in an authorized library. Only the EXEC PGM= name > needs AC=1 (TSO APF in addtion needs to be in some special list). > > -- > 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
Re: SCHEDIRB
On Wed, Sep 27, 2023 at 09:00:13PM -0500, Jon Perryman wrote: > 4. I believe that LOAD will abend if the module is not linked with >the AC=1 attribute when running authorized. No, it has to be in an authorized library. Only the EXEC PGM= name needs AC=1 (TSO APF in addtion needs to be in some special list). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB
On Tue, 19 Sep 2023 20:29:52 -0400, Joseph Reichman wrote: > Source code below. Sorry for chiming in so late but I've had other priorities. I think you're being led down the wrong path. A 30 second glance at your code shows obvious coding errors. SRB and IRB are the the real danger. Running key 0 and sup makes you the destroyer of worlds. Always make this code obvious. 1. Labels IRBPTR and STIMER are not preceded by a "DROP ,". As exit routines, prior USINGs are not guaranteed. They may be using a bad reg. 2. IRBLST and TIMERLST are in a DSECT that is not obvious they have been initialized correctly. It's not obvious that generated eye catchers and default values were copied or if the area was simply zeroed. 3. Use "save (R14,R12),'exit eyecatcher' will simplify debugging when looking at a dump for the PSW address. 4. I believe that LOAD will abend if the module is not linked with the AC=1 attribute when running authorized. 5. TSO does SVC screening to protect itself from SUP and non-KEY8 security exposures. Does TSO allow an unknown LOAD from the job step TCB. 6. Is there a reason you haven't tried IDENTIFY for the module? I've never tested this situation but I suspect it increments the use count to ensure the alternate name remains available when the TCB goes away. 7. Another possibility is STORAGE OBTAIN and LOAD to the obtained area. 8. If you need to refresh the module, using LOAD from the IKJEFT01 TCB will require logoff / logon or the implementation of another IRB to refresh the LOAD module. I suspect there are other problems. With so many possible problems, you need to get familiar with IPCS because analyzing the dump would tell you quickly where and what abended. Since you don't have XDC, you may find IPCS useful when looking at the active system with the SAF BLSACTV resource permitted because you can view all address spaces. Alternatively, insert WTO's in you code to see where you are failing. > > STIMERM SET, X > ID=TIMER, X > BINTVL=NOW, X > ERRET=ERROR,X > EXIT=STIMER,X > PARM=TIMER_PLIST, X > WAIT=NO,MF=(E,TIMERLST) > > >STIMER DS 0D > STM R14,R12,12(R13) > * > LRR4,R15 > DROP R3 > USING STIMER,R4 > LRR10,R13 > L R13,4(,R1)Get Save area > DROP R13 > USING TIMERSVE,R13 > STR10,4(R13) > * > SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE > * > * > * Chain rb pointer to put this IRB as next > * > LAR5,IRBPTR > O R5,=X'8000' > STR5,IRBADD > L R6,PSATOLD > USING TCB,R6 > L R6,TCBJSTCB Get the Job Step tcb > STR6,JSTCB > SCHEDIRB EPPTR=IRBADD,X >TCBPTR=JSTCB, X >SVAREA=YES, X >MODE=SUPR, X >KEY=SUPR, X >PARAMPTR=PLIST, X >MF=(E,IRBLST) > SETLOCK RELEASE,TYPE=LOCAL,REGS=SAVE > *
Re: SCHEDIRB with CIRB
On Fri, Sep 22, 2023 at 04:50:23PM -0400, Joseph Reichman wrote: > Micheal > > Thanks for looking at it I see 8E76D0 at IQETCB Oh, I mangled it when aliging the hex data, the 0s are from the 64 bit address high word... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB with CIRB
Micheal
Thanks for looking at it I see 8E76D0 at IQETCB
+0 (4) link
+4 (4) 00026A6C IQEPARAM
+8 (4) 008AA7a8 IQEIRB
+c (4) IQETCB
why isn't IQETCB set? I see 8E76D0 at that location
I am begging to think that because I am running under TESTAUTH the IRB is
getting dispatched
_008AA7A8 >77B8 010F404E 9FF01E81 *>..
+.0.a*
_008AA7B8078D 9FF01E80 008AA80C 008FEA90
*.0y.*
_008AA7C80001 FF735894 852CAB40 052CBB3F *...me..
*
_008AA7D8808CACD0 008CACA8 008CACD0
*...y*
_008AA7E8008CACD8 008C9AB8 052CCB3E
*...Q*
_008AA7F8008CA2C0 008CA2C0 852CB72C 808FEA90
*..s...s.e...*
_008AA808008AA80C 00026A6C 008AA7A8
*..y%..xy*
_008AA818008E76D0
**
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Michael Stein
Sent: Friday, September 22, 2023 4:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SCHEDIRB with CIRB
On Fri, Sep 22, 2023 at 01:58:00PM -0400, Joseph Reichman wrote:
> I am posting my code in addition to some displays I captured as I am
> getting the feeling my IRB was not dispatched for some reason
>
> So here is the code in my STIMER routine from where I issue the
> SCHEDIRB pointing to the IQE generated by the CIRB
I don't see why you need the stimer routine. The description of SCHEDIRB
says that is for "directed IRB" where you specify your IRB is to run before
the specified RB.
> Here using LOOK is a display of the IRB Address 8AA7A8 don't know Why
> RBEPA has bit 0 a 0 looking at the RBOPSW it's a 0 LAST CMD - 8AA7A8
{storage display text realligned..}
_008AA7A8 >77B8 010F404E 9FF01E81 *>..
+.0.a*
_008AA7B8078D 9FF01E80 008AA80C 008FEA90
*.0y.*
_008AA7C80001 FF735894 852CAB40 052CBB3F *...me..
*
_008AA7D8808CACD0 008CACA8 008CACD0
*...y*
_008AA7E8008CACD8 008C9AB8 052CCB3E
*...Q*
_008AA7F8008CA2C0 008CA2C0 852CB72C 808FEA90
*..s...s.e...*
_008AA808008AA80C 00026A6C 008AA7A8
*..y%..xy*
_008AA818008E76D0
**
The RB mapping includes fields for all types of RBs: PRB, SVRB, IRB, SIRB
and perhaps for types & flavors which don't exist anymore (since before
MVT). A lot of these fields overlap as they aren't used at them same time.
Looking at our IRB:
+0 (4) 77B8 address of problem program save area
+8 (2) 010f length of RB in double words
+a (1) 40 is an IRB
+b (1) 4d ? bits about has IQE, don't return IQE
+c (4) 9ff01e81 rbepa, looks like low bit is flag bit for mode=defined
+10 (8) 078d 9ff01e80 -> psw
+18 (4) 008aa80c list orig for iqe
+60 (4) 008aa80c rbnexav => @ next avail IEQ
+64 (.) ..IQE..
The IQE: 00026A6C 008AA7A8
+0 (4) link
+4 (4) 00026A6C IQEPARAM
+8 (4) 008AA7a8 IQEIRB
+c (4) IQETCB
why isn't IQETCB set?
https://www.ibm.com/docs/en/zos/2.1.0?topic=routines-using-cirb-macro-initia
lize-irb
The same TCB needs to be used to allocate the storage for the IRB and to
free it, thus CIRB needs the TCB address in addition to the TCB address in
the IQE (task to run the IRB).
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu <mailto: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
Re: SCHEDIRB with CIRB
On Fri, Sep 22, 2023 at 01:58:00PM -0400, Joseph Reichman wrote:
> I am posting my code in addition to some displays I captured as I am getting
> the feeling my IRB was not dispatched for some reason
>
> So here is the code in my STIMER routine from where I issue the SCHEDIRB
> pointing to the IQE generated by the CIRB
I don't see why you need the stimer routine. The description of
SCHEDIRB says that is for "directed IRB" where you specify your IRB
is to run before the specified RB.
> Here using LOOK is a display of the IRB Address 8AA7A8 don't know Why
> RBEPA has bit 0 a 0 looking at the RBOPSW it's a 0
> LAST CMD - 8AA7A8
{storage display text realligned..}
_008AA7A8 >77B8 010F404E 9FF01E81 *>.. +.0.a*
_008AA7B8078D 9FF01E80 008AA80C 008FEA90 *.0y.*
_008AA7C80001 FF735894 852CAB40 052CBB3F *...me.. *
_008AA7D8808CACD0 008CACA8 008CACD0 *...y*
_008AA7E8008CACD8 008C9AB8 052CCB3E *...Q*
_008AA7F8008CA2C0 008CA2C0 852CB72C 808FEA90 *..s...s.e...*
_008AA808008AA80C 00026A6C 008AA7A8 *..y%..xy*
_008AA818008E76D0 **
The RB mapping includes fields for all types of RBs: PRB, SVRB, IRB,
SIRB and perhaps for types & flavors which don't exist anymore (since
before MVT). A lot of these fields overlap as they aren't used at them
same time.
Looking at our IRB:
+0 (4) 77B8 address of problem program save area
+8 (2) 010f length of RB in double words
+a (1) 40 is an IRB
+b (1) 4d ? bits about has IQE, don't return IQE
+c (4) 9ff01e81 rbepa, looks like low bit is flag bit for mode=defined
+10 (8) 078d 9ff01e80 -> psw
+18 (4) 008aa80c list orig for iqe
+60 (4) 008aa80c rbnexav => @ next avail IEQ
+64 (.) ..IQE..
The IQE: 00026A6C 008AA7A8
+0 (4) link
+4 (4) 00026A6C IQEPARAM
+8 (4) 008AA7a8 IQEIRB
+c (4) IQETCB
why isn't IQETCB set?
https://www.ibm.com/docs/en/zos/2.1.0?topic=routines-using-cirb-macro-initialize-irb
The same TCB needs to be used to allocate the storage for the IRB
and to free it, thus CIRB needs the TCB address in addition to
the TCB address in the IQE (task to run the IRB).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SCHEDIRB with CIRB
Hi I am posting my code in addition to some displays I captured as I am getting the feeling my IRB was not dispatched for some reason So here is the code in my STIMER routine from where I issue the SCHEDIRB pointing to the IQE generated by the CIRB STIMER DS 0D STM R14,R12,12(R13) * LRR2,R15 DROP R3 USING STIMER,R2 LRR10,R13 L R13,4(,R1)Get Save area DROP R13 USING TIMERSVE,R13 STR10,4(R13) * LAR5,IRBPTR O R5,=X'8000' ST R5,IRBADD *LAR5,IRBADD * L R4,PSATOLD USING TCB,R4 L R4,TCBJSTCB * * SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE * CIRB EP=(R5), X SVAREA=YES, X RETIQE=YES, X STAB=DYN, X WKAREA=255, X BRANCH=YES, X AMODE=DEFINED * USING RBBASIC,R1 L R5,RBNEXAVGet IQE Pointer USING IQESECT,R5 STR5,IQEADD STR1,IQEIRB LAR15,PLIST STR15,IQEPARAM STR4,IQETCB * * * SCHEDIRB IQEPTR=IQEADD, X MF=(E,IRBLST) * SETLOCK RELEASE,TYPE=LOCAL,REGS=SAVE * * LR13,4(,R13) XR R15,R15 LR14,12(R13) LM R0,R12,20(R13) BR R14 DROP R13 USING WORKAREA,R13 DROP R2 IRBPTR DS0D * * STM R14,R12,12(R13) LRR5,R15 USING IRBPTR,R5 LRR10,R1Save Plist pointer LOAD EP=GETVECT STR0,0(R10) Store Pointer XRR15,R15 L R14,12(R13) LMR0,R12,20(R13) BRR14 DROP R5 Here is a SJ display from SDSF to can see my IRB Right before IKJEFT01 NP TCB RB Type Program Storage FreeStor CPU-Ti 008FD6A0 TCB 839680 134584 0.0 008FD6A0 008FFF98 PRB IEAVAR00 0.0 008FED90 TCB 71680094120 0.6 008FED90008E7ED8 PRB IEFSD060 0.0 008FED90008FEC80 PRB IEESB605 0.0 008E76D0TCB 794624 101152 0.0 008E76D0 008AA7A8 IRB 0.0 008E76D0 008FEA90 PRB IKJEFT01 0.0 008B8E88 TCB 12288
Re: SCHEDIRB getting real close showing the code
It didn’t seem to work that way Ep= didn’t equal RBEPA RBEPA documented in the data areas Manuel At location +C from RBBASIC say entry point of irb routine in fact the last digit was odd The cirb is running amode 31 I’ll re-read again But and set a breakpoint after the the cirb And look at the IRB it built Thanks > On Sep 20, 2023, at 8:06 PM, Michael Stein wrote: > > On Wed, Sep 20, 2023 at 06:00:06PM -0400, Joseph Reichman wrote: >> I decided to use the CIRB macro so that way I could build my own IRB >> >> The problem seems to be the AMODE of my RBOPSW is 24 so the high order >> byte of my rbepa gets chopped off > > RPEPA doesn't belong to you, you should not touch it. > > You specified EP= so thats the entry point the IRB will be set > up to use. > > AMODE=CALLER specifies the AMODE for the routine to be run by the IRB > routine. What AMODE is the caller of CIRB running in? > > Go read the CIRB desscription and pay attention to interactions of the > various operands. > >> 8 * >> 9 CIRB EP=IRBADD, X >> 0SVAREA=YES, X >> 1KEY=SUPR, X >> 2MODE=SUPR, X >> 3RETIQE=YES, X >> 4STAB=DYN, X >> 5WKAREA=255, X >>RETRN=YES, X >>AMODE=CALLER > > As noted by a prevous poster XR R15,R14 won't usually clear R15. > >> XR R15,R14 > > -- > 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
Re: SCHEDIRB getting real close showing the code
On Wed, Sep 20, 2023 at 06:00:06PM -0400, Joseph Reichman wrote: > I decided to use the CIRB macro so that way I could build my own IRB > > The problem seems to be the AMODE of my RBOPSW is 24 so the high order > byte of my rbepa gets chopped off RPEPA doesn't belong to you, you should not touch it. You specified EP= so thats the entry point the IRB will be set up to use. AMODE=CALLER specifies the AMODE for the routine to be run by the IRB routine. What AMODE is the caller of CIRB running in? Go read the CIRB desscription and pay attention to interactions of the various operands. > 8 * > 9 CIRB EP=IRBADD, X > 0SVAREA=YES, X > 1KEY=SUPR, X > 2MODE=SUPR, X > 3RETIQE=YES, X > 4STAB=DYN, X > 5WKAREA=255, X > RETRN=YES, X > AMODE=CALLER As noted by a prevous poster XR R15,R14 won't usually clear R15. > XR R15,R14 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SCHEDIRB getting real close showing the code
Hi I decided to use the CIRB macro so that way I could build my own IRB The problem seems to be the AMODE of my RBOPSW is 24 so the high order byte of my rbepa gets chopped off So here is my IRB entry from SDUMP IRB: 008AC7A8 KEYSTA... 0CWLIC. 00040011 EPA.. 9FF01E80 OPSW. 070C 00F01E80LINK. 008FFF98 As you can clearly the first byte of program EPA is getting chopped off in the RBOPSW Here is the code that produced this 1 * 2 L R4,PSAAOLD 3 USING ASCB,R4 4 L R4,ASCBASXB 5 DROP R4 6 USING ASXB,R4 7 L R4,ASXBFTCB 8 * 9 CIRB EP=IRBADD, X 0SVAREA=YES, X 1KEY=SUPR, X 2MODE=SUPR, X 3RETIQE=YES, X 4STAB=DYN, X 5WKAREA=255, X RETRN=YES, X AMODE=CALLER * USING RBBASIC,R1 LAR5,IRBPTR O R5,=X'8000' STR5,RBEPA OIRBOPSWA,RBOPSW31 Set the amode L R5,RBNEXAV USING IQESECT,R5 STR5,IQEADD STR1,IQEIRB LAR15,PLIST STR15,IQEPARAM STR4,IQETCB * SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE * * * SCHEDIRB IQEPTR=IQEADD, X MF=(E,IRBLST) SETLOCK RELEASE,TYPE=LOCAL,REGS=SAVE * * LR13,4(,R13) XR R15,R14 LR14,12(R13) LM R0,R12,20(R13) BR R14 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCHEDIRB with a timer
There are conditions that temporarily disable the Stage 3 Exit Effector. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Adam Johanson [031ca9d720a7-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, August 5, 2020 1:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCHEDIRB with a timer The IRB will be driven the next time the task gets interrupted... note that SCHEDULEing the IRB does not in itself cause the interrupt that drives the IRB. If the task was already WAITing, however, the IRB will run. == Adam Johanson R Software Engineer adam.johan...@broadcom.com On Wed, Aug 5, 2020 at 12:13 PM Joseph Reichman wrote: > Hi > > > > I am looking for an exit that will be executed after a time interval, > in addition I need a parameter. The SCHEDIRB gives the parameter but I am > not quite sure when it will execute > > > > Looking at the data area manual for IQE there is a it setting for IQETIMER > the comments refer to STIMER. > > > > STIMER on the other I have a better idea of when the routine will get > control however it does not receive parameters > > > > > > I guess since I know I am running under the same TCB I can do a TCBTOKEN > and > then create a name token pair. > > > > Thanks > > > > > -- > 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
Re: SCHEDIRB with a timer
The IRB will be driven the next time the task gets interrupted... note that SCHEDULEing the IRB does not in itself cause the interrupt that drives the IRB. If the task was already WAITing, however, the IRB will run. == Adam Johanson R Software Engineer adam.johan...@broadcom.com On Wed, Aug 5, 2020 at 12:13 PM Joseph Reichman wrote: > Hi > > > > I am looking for an exit that will be executed after a time interval, > in addition I need a parameter. The SCHEDIRB gives the parameter but I am > not quite sure when it will execute > > > > Looking at the data area manual for IQE there is a it setting for IQETIMER > the comments refer to STIMER. > > > > STIMER on the other I have a better idea of when the routine will get > control however it does not receive parameters > > > > > > I guess since I know I am running under the same TCB I can do a TCBTOKEN > and > then create a name token pair. > > > > Thanks > > > > > -- > 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
Re: SCHEDIRB with a timer
Thanks > On Aug 5, 2020, at 1:38 PM, mike.lamartina > wrote: > > STIMERM supports a parameter. > > On 8/5/2020 10:13:48 AM, Joseph Reichman wrote: > Hi > > > > I am looking for an exit that will be executed after a time interval, > in addition I need a parameter. The SCHEDIRB gives the parameter but I am > not quite sure when it will execute > > > > Looking at the data area manual for IQE there is a it setting for IQETIMER > the comments refer to STIMER. > > > > STIMER on the other I have a better idea of when the routine will get > control however it does not receive parameters > > > > > > I guess since I know I am running under the same TCB I can do a TCBTOKEN and > then create a name token pair. > > > > Thanks > > > > > -- > 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
Re: SCHEDIRB with a timer
STIMERM supports a parameter. On 8/5/2020 10:13:48 AM, Joseph Reichman wrote: Hi I am looking for an exit that will be executed after a time interval, in addition I need a parameter. The SCHEDIRB gives the parameter but I am not quite sure when it will execute Looking at the data area manual for IQE there is a it setting for IQETIMER the comments refer to STIMER. STIMER on the other I have a better idea of when the routine will get control however it does not receive parameters I guess since I know I am running under the same TCB I can do a TCBTOKEN and then create a name token pair. Thanks -- 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
SCHEDIRB with a timer
Hi I am looking for an exit that will be executed after a time interval, in addition I need a parameter. The SCHEDIRB gives the parameter but I am not quite sure when it will execute Looking at the data area manual for IQE there is a it setting for IQETIMER the comments refer to STIMER. STIMER on the other I have a better idea of when the routine will get control however it does not receive parameters I guess since I know I am running under the same TCB I can do a TCBTOKEN and then create a name token pair. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
