Re: LOAD a module into CSA/ECSA
In a message dated 10/7/2007 10:45:51 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >Of course we can use a batch job to do it and the initiator will not terminate as the job ends. But in my opinion, it's still not safe. It's still possible that the operator will recycle the initiator and the module will be deleted. Also the Initiator/Terminator address space has been known to self-terminate without any help at all from the operator. Bill Fairchild Plainfield, IL ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
Use the ADDR= parameter with the LOAD macro. You've got to request the CSA storage yourself and pass its address via ADDR= to the load service. The description of that parameter says: "The system does not search for the module and does not maintain a record of the module once it is loaded." I.e. the module is not placed on the task's load list, so the system will not delete it when the task ends. In fact the system doesn't remember it had loaded that module. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Sun, 7 Oct 2007 19:03:06 +0200 "Hunkeler Peter (KIUK 3)" <[EMAIL PROTECTED]> wrote: :>Use the ADDR= parameter with the LOAD macro. You've got to request :>the CSA storage yourself and pass its address via ADDR= to the load :>service. :>The description of that parameter says: "The system does not :>search for the module and does not maintain a record of the module :>once it is loaded." I.e. the module is not placed on the :>task's load list, so the system will not delete it when the task :>ends. In fact the system doesn't remember it had loaded that :>module. Let us see if he will go to the effort to determine how big the storage area should be, or if that will be his next question. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
In a message dated 10/7/2007 12:21:29 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >Let us see if he will go to the effort to determine how big the storage area should be, or if that will be his next question. If he's reading all these posts, he just might get a clue from this post of yours and not have to ask the question. :-) Bill Fairchild Plainfield, IL ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
Actually took me some trouble to think of a way to accomplish this :) Reading directory of PDS/PDSE seems to be the solution, but it means a lot of codes. LOAD it into jpa and then retrieve the info from CDE? Then I realized that there is CSVQUERY. So my solution would be: 1. First LOAD the module into JPA 2. Retrieve the size of the module using CSVQUERY 3. GETMAIN and do the real LOAD On 10/8/07, (IBM Mainframe Discussion List) <[EMAIL PROTECTED]> wrote: > > > > In a message dated 10/7/2007 12:21:29 P.M. Central Daylight Time, > [EMAIL PROTECTED] writes: > >Let us see if he will go to the effort to determine how big the > storage area > should be, or if that will be his next question. > > If he's reading all these posts, he just might get a clue from this post > of > yours and not have to ask the question. :-) > > Bill Fairchild > Plainfield, IL -- Best Regards, Johnny Luo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
Bill, I cannot fully understand what you mean by 'self-terminate'. As I know, when the initiator is started the address space will always be there ready for the incoming job assigned by JES. On 10/8/07, (IBM Mainframe Discussion List) <[EMAIL PROTECTED]> wrote: > > > > Also the Initiator/Terminator address space has been known > to self-terminate > without any help at all from the operator. > > Bill Fairchild > Plainfield, IL > > > -- Best Regards, Johnny Luo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Mon, 8 Oct 2007 02:25:42 +0800 Johnny Luo <[EMAIL PROTECTED]> wrote: :>Actually took me some trouble to think of a way to accomplish this :) :>Reading directory of PDS/PDSE seems to be the solution, but it means a lot :>of codes. Not at all - a few instructions will do it. Look at the PDS directory mapping. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
In a message dated 10/7/2007 1:30:54 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >I cannot fully understand what you mean by 'self-terminate'. >As I know, when the initiator is started the address space will always be there ready for the incoming job assigned by JES. One out of every few thousand jobs that pass through an initiator will do something bad that causes the initiator code itself to break. That's what I meant. Also the initiator code is not perfect. Once in a great while a bug is found somewhere in IBM's code. An initiator is more permanent than many other things, but if it should go away and your module goes away then what will happen to the next user who executes your missing SVC? The point is that you should find some SERIOUSLY permanent way to load your module. If you are planning to LOAD the module, then I think you might be interested in using the LOAD macro to do it. If so, then read the LOAD macro doc and you will quickly see how to find out how long the module is. Bill Fairchild Plainfield, IL ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Sun, 7 Oct 2007 19:21:00 +0200, Binyamin Dissen <[EMAIL PROTECTED]> wrote: > >Let us see if he will go to the effort to determine how big the storage area >should be, or if that will be his next question. > And the question after that can be: "How do you prevent the module in the library from being replaced by another (potentially larger) one after the time you work out the length but before you get to issue the LOAD?" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
Hmmh well did you try GLOBAL=YES and EO=NO? Make sure you follow the documentation. I used GLOBAL=YES and EOM=YES in the past and it works as documented. Never used EOM=NO Roland >Hi, > >I'm just reading an assembler language book and there is one coding example >showing how to dynamically install user-written SVC. What I'm interested in >is the way it places the SVC load module into common area. > >It uses LOAD macro to do it and says: unless the original task deletes it, >it will be there. > >However, I checked the description of LOAD macro and found out that even >with EOM=YES the module will be deleted from CSA after the requesting >address space terminates. > >Of course we can use a batch job to do it and the initiator will not >terminate as the job ends. But in my opinion, it's still not safe. It's >still possible that the operator will recycle the initiator and the module >will be deleted. > >Since the book was written in 1999 I guess for the current z/os a better >method would be: > >1. Add the SVC module into dynamic LPA >2. Update SVC table > >Do I miss something? > >-- >Best Regards, >Johnny Luo > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Sun, 7 Oct 2007 16:25:07 -0500, Andy Wood <[EMAIL PROTECTED]> wrote: >... >"How do you prevent the module in the library from being replaced by another >(potentially larger) one after the time you work out the length but before you >get to issue the LOAD?" >... I guess it's possible someone might be moving random load modules into CSA just for the fun of it, but I suspect usually the person moving the load module is also the person responsible for maintaining the load module. He would (in theory) know when it had changed size. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Mon, 8 Oct 2007 02:25:42 +0800, Johnny Luo wrote: >Actually took me some trouble to think of a way to accomplish this :) > >Reading directory of PDS/PDSE seems to be the solution, but it means a lot >of codes. > >LOAD it into jpa and then retrieve the info from CDE? Then I realized >that there is CSVQUERY. > >So my solution would be: > >1. First LOAD the module into JPA > >2. Retrieve the size of the module using CSVQUERY > >3. GETMAIN and do the real LOAD You are doing more work than you need to -- re-read the LOAD macro service documentation and pay more attention to what it returns in its registers. Specifically, pay attention to what it returns in register 0 and register 1 BUT ONLY IF register 15 has the expected/required return value. For example, your GETMAIN will need to be in the appropriate 31-bit/24-bit MODE (RMODE) and the hint for that is in the high-order bit of register 0. The GETMAIN length is derived from the low-order 3 bytes of register 1. (Be careful here: the length is DERIVED from the low-order 3 bytes -- you will need to do a little (simple) arithmetic AND pay attention to some special cases.) You only really need to use CSVQUERY if the low-order 3 bytes of register 1 are zero because the load module's length is greater than 16M, per the documentation. (And you might want to reconsider whether you really want that module loaded into dynamic ECSA if it is bigger than 16M... at least I would be more pensive under that condition.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Sun, 7 Oct 2007 18:35:33 -0500 "Patrick O'Keefe" <[EMAIL PROTECTED]> wrote: :>On Sun, 7 Oct 2007 16:25:07 -0500, Andy Wood <[EMAIL PROTECTED]> wrote: :>>"How do you prevent the module in the library from being replaced by another :>>(potentially larger) one after the time you work out the length but before you :>>get to issue the LOAD?" :>I guess it's possible someone might be moving random load modules :>into CSA just for the fun of it, but I suspect usually the person moving :>the load module is also the person responsible for maintaining the :>load module. He would (in theory) know when it had changed size. Considering that the directory entry is the best way to get the length, it would require clumsy coding to get a different copy. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
For the purpose that this was being used for -- do not use LOAD with GLOBAL=YES Re-read EOM. LOAD with GLOBAL=YES does NOT persist across end of memory. The EOM parameter determines whether the area is cleaned up at task termination or at memory termination. There is no way with this option to indicate never to clean it up. -- do not use LOAD with ADDR= Why go to the trouble of figuring out the proper attributes from the directory for obtaining the module storage when the system can do it for you? -- do use CSVDYLPA 'nuff said. While you are at it, work on your user groups to submit a requirement for dynamic LPA to support "put this module into LPA, and it is SVC nn so update the SVC table while you are at it" Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
