Re: CSNBENC in LPA?
This was an old requirement that RACF had. It should never have been required (in my opinion) and I got on their (RACF's) case so that it was no longer required. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Wednesday, December 20, 2023 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: CSNBENC in LPA? Sri, I think there is some mess here. You quoted documentation, which is relevant to z/OS 2.3, not 2.5. Yes, the chapter was changed. In other words: z/OS 2.3 and older mention CSNBENC, but z/OS 2.4 and newer does not mention this name at all. However I have found the same text in OMEGAMON 5.5 and I do have it. However I'm not sure whether is it no longer valid due to changes in ICSF and/or RACF. Unfortunately I did not found any clue in Summary of changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSNBENC in LPA?
W dniu 20.12.2023 o 22:46, Sri h Kolusu pisze: Q: is it really required to put the library into LPA? I searched ICSF documentation and found no reference. Radoslaw, It is documented in RACF Security Administrator's Guide. https://www.ibm.com/docs/en/zos/2.5.0?topic=keys-storing-passticket-encrypted-in-icsf When using the secured signon facilities with encryption, the following Integrated Cryptographic Service Facility (ICSF) modules must be installed as follows so they can be accessed by RACF. The CSNBENC module must reside in the link pack area (LPA) if not already there. It can be dynamically loaded, or added to PLPA or MLPA with the respective PARMLIB members. The following modules must reside in APF-authorized link-listed data sets: CSNBCKI CSNBDEC CSNBKRC CSNBKRD CSNBKRW Thanks, Kolusu Sri, I think there is some mess here. You quoted documentation, which is relevant to z/OS 2.3, not 2.5. Yes, the chapter was changed. In other words: z/OS 2.3 and older mention CSNBENC, but z/OS 2.4 and newer does not mention this name at all. However I have found the same text in OMEGAMON 5.5 and I do have it. However I'm not sure whether is it no longer valid due to changes in ICSF and/or RACF. Unfortunately I did not found any clue in Summary of changes. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSNBENC in LPA?
I found the same statement in a few documents too. I assume a dynamic load into LPA of the single CSNBENC module would be sufficient. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com On Wednesday, December 20th, 2023 at 4:30 PM, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > I have found the following statement iin some documentation: > "KEYENCRYPTED requires that the CSNBENC module reside in the link pack > area (LPA) if not already there. " > > The module resides in SCSFMOD0 library, which is on LNKLST concatenation. > > Q: is it really required to put the library into LPA? > I searched ICSF documentation and found no reference. > > Any clue? > > The system level is z/OS 2.5 > > -- > Radoslaw Skorupka > Lodz, Poland > > -- > 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: CSNBENC in LPA?
>> Q: is it really required to put the library into LPA? I searched ICSF >> documentation and found no reference. Radoslaw, It is documented in RACF Security Administrator's Guide. https://www.ibm.com/docs/en/zos/2.5.0?topic=keys-storing-passticket-encrypted-in-icsf When using the secured signon facilities with encryption, the following Integrated Cryptographic Service Facility (ICSF) modules must be installed as follows so they can be accessed by RACF. The CSNBENC module must reside in the link pack area (LPA) if not already there. It can be dynamically loaded, or added to PLPA or MLPA with the respective PARMLIB members. The following modules must reside in APF-authorized link-listed data sets: CSNBCKI CSNBDEC CSNBKRC CSNBKRD CSNBKRW Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CSNBENC in LPA?
I have found the following statement iin some documentation: "KEYENCRYPTED requires that the CSNBENC module reside in the link pack area (LPA) if not already there. " The module resides in SCSFMOD0 library, which is on LNKLST concatenation. Q: is it really required to put the library into LPA? I searched ICSF documentation and found no reference. Any clue? The system level is z/OS 2.5 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
Paul wrote Regarding CSVDYLPA REQUEST=ADD . The documentation states: .Modules added to the system via dynamic LPA processing are placed into CSA or ECSA storage. . Further more It is expected that the caller will free the work area, using either FREEMAIN or STORAGE RELEASE, after processing it. Does this mean the work area used by CSVDYLPA is also acquired from CSA/ECSA storage since the caller is responsible for freeing the storage occupied by the "work area" ? No it does not mean that. There is no such correlation either stated or implied. Where is the referenced documentation? I don't see it in the 2.5 IBM Docs site. It appears to be paraphrased, which is rarely a good idea for communicating detailed info. CSVDYLPA does not have a "work area". It has an "output area". The documentation about outareasp describes the subpool that is used (the system chooses a subpool - 230 - only if you do not do so). That is for the cases where the system does not write the info to the area provided by the caller which identifies the names to process. 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: Dynamic LPA Services
Paul, I very much doubt that the csvdylpa workarea is in common storage. It is much more likely to be in an authorised private subpool. You can check by inspecting the output subpool value returned by the service. Rob Scott Rocket Software From: IBM Mainframe Discussion List on behalf of esst...@juno.com Sent: Monday, October 31, 2022 5:06:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services EXTERNAL EMAIL Hello . Regarding CSVDYLPA REQUEST=ADD . The documentation states: .Modules added to the system via dynamic LPA processing are placed into CSA or ECSA storage. . Further more It is expected that the caller will free the work area, using either FREEMAIN or STORAGE RELEASE, after processing it. . Does this mean the work area used by CSVDYLPA is also acquired from CSA/ECSA storage since the caller is responsible for freeing the storage occupied by the "work area" ? . Paul - . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dynamic LPA Services
Hello . Regarding CSVDYLPA REQUEST=ADD . The documentation states: .Modules added to the system via dynamic LPA processing are placed into CSA or ECSA storage. . Further more It is expected that the caller will free the work area, using either FREEMAIN or STORAGE RELEASE, after processing it. . Does this mean the work area used by CSVDYLPA is also acquired from CSA/ECSA storage since the caller is responsible for freeing the storage occupied by the "work area" ? . Paul - . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA
> and SETPROG LPA,DELETE In almost all cases, deleting from LPA is considered an integrity exposure. 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: LPA
Ensure that CSA and ECSA are large enough that SETPROG LPA,ADD and SETPROG LPA,DELETE don't have fragmentation issues. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob Schramm [rob.schr...@gmail.com] Sent: Monday, April 4, 2022 8:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LPA Listers, I am feeling particularly annoyed. I don't want to use LPALSTxx for products. I want to be able to upgrade a product with a minimum of fuss. I would like to use PROGXX and manage LPA dynamically. But the PROGxx and SETPROG seem woefully under-powered for such a thing. This is more pointed when systems have infrequent IPLs. Rob Schramm -- 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: LPA
As the OP and responders thus far are experienced and aware... Mind your (E)CSA allocations and utilization. Suggestion: use CSAMIN= other than the default (0,0), particularly with MASK=*. When moving modules/libraries from LPALSTxx to Dynamic LPA, remember to adjust IEASYSxx CSA= accordingly, and validate the Private areas before and after the IPL. Just stating for anyone who isn't as familiar with SETPROG LPA and/or CSVDYLPA. Which reminds me if any of the modules in question are also dynamic exit routines, those pointers may need to be refreshed as well. There are other restrictions, e.g., adding SVCs, entry points in the PC table, etc. Regards, Art Gutowski On Tue, 5 Apr 2022 07:29:56 +, Rob Scott wrote: >Also consider putting all LPA modules into a single function pack load module >so that the SETPROG LPA is always for the same module name (if a contained >CSECT is updated by maintenance). CSVQUERY SEARCH=LPA can be used to locate >your function pack when server/client starts. > >You need a header structure that is a vector table of the included CSECTs at >the start of the LPA load module. > >Your server/client code just need a mapping of the vector table so that it can >slice-and-dice the LPA load module to find the service entry points. > >Rob Scott >Rocket Software > >From: IBM Mainframe Discussion List On Behalf Of Ed >Jaffe >Sent: 05 April 2022 04:04 >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: LPA > >On 4/4/2022 5:13 PM, Rob Schramm orote: >> I am feeling particularly annoyed. I don't want to use LPALSTxx for >> products. I want to be able to upgrade a product with a minimum of fuss. >> I would like to use PROGXX and manage LPA dynamically. But the PROGxx and >> SETPROG seem woefully under-powered for such a thing. This is more pointed >> when systems have infrequent IPLs. > >SETPROG LPA,ADD,MASK=*,DSN=data.set.name -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA
Also consider putting all LPA modules into a single function pack load module so that the SETPROG LPA is always for the same module name (if a contained CSECT is updated by maintenance). CSVQUERY SEARCH=LPA can be used to locate your function pack when server/client starts. You need a header structure that is a vector table of the included CSECTs at the start of the LPA load module. Your server/client code just need a mapping of the vector table so that it can slice-and-dice the LPA load module to find the service entry points. Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: 05 April 2022 04:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPA EXTERNAL EMAIL On 4/4/2022 5:13 PM, Rob Schramm wrote: > I am feeling particularly annoyed. I don't want to use LPALSTxx for > products. I want to be able to upgrade a product with a minimum of fuss. > I would like to use PROGXX and manage LPA dynamically. But the PROGxx and > SETPROG seem woefully under-powered for such a thing. This is more pointed > when systems have infrequent IPLs. SETPROG LPA,ADD,MASK=*,DSN=data.set.name -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/<https://www.phoenixsoftware.com> This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA
On 4/4/2022 5:13 PM, Rob Schramm wrote: I am feeling particularly annoyed. I don't want to use LPALSTxx for products. I want to be able to upgrade a product with a minimum of fuss. I would like to use PROGXX and manage LPA dynamically. But the PROGxx and SETPROG seem woefully under-powered for such a thing. This is more pointed when systems have infrequent IPLs. SETPROG LPA,ADD,MASK=*,DSN=data.set.name -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LPA
Listers, I am feeling particularly annoyed. I don't want to use LPALSTxx for products. I want to be able to upgrade a product with a minimum of fuss. I would like to use PROGXX and manage LPA dynamically. But the PROGxx and SETPROG seem woefully under-powered for such a thing. This is more pointed when systems have infrequent IPLs. Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA Load module hits or usage
Mark J wrote: >instruction fetch GTF trace, action=trace, I think Mark meant an instruction fetch SLIP trap with action=trace to get a GTF trace. Or ACTION=STRACE - you won't want to look at the data from the action itself, but this will let a DISPLAY SLIP,ID=xxx show you what you want, if you don't mind learning only about the number of times that can be represented in a SLIP matchlim value (the limit is 65535). The display will show the number of matches so far (until the trap gets disabled for reaching the limit) In the general case, there is no tool you could use, whether free or not, that would provide that information. The general case is where a program learns of the address to use by using CSVQUERY and just branches there. The specific case of using LINK/LOAD/ATTACH/XCTL to route control to the module could be determined by such tools. 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: LPA Load module hits or usage
Off the top of my head a instruction fetch GTF trace, action=trace, at the entry point of the LPA module should work. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, October 28th, 2021 at 3:39 AM, Jake Anderson wrote: > Hello > > Is there a way to know or understand about how many times a module in LPA > > got used or called without using any priced products ? > > Jake > > --- > > 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
LPA Load module hits or usage
Hello Is there a way to know or understand about how many times a module in LPA got used or called without using any priced products ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA - IPL or dynamic
I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? I do not think that the responses I saw addressed the actual questions asked. The responses targeted whether dynamic would work at all and why it might not. Those responses were all correct. To summarize, "it depends". Consider even the case of the product that uses the CSVDYLPA exit to watch for updates via dynamic LPA to modules of interest to the product so that the product can update pointers that it has previously stashed related to the "original" LPA copy of the module, now to be related to the "new" LPA copy. If there is more than one such update, it can be challenging (sometimes impossible, given the performance needs of the product) to make all the updates in such a way that there is no window in which could could be using a mixture of new and old. And writing things so that a mixture of new and old can be expensive and is not always worth it. And that's only for multiple updates to LPA. Some correctly mentioned the concern about a mixture of LPA and LNKLST updates. Having all your parts at the same level can be really important, for obvious reasons. Maybe you can get away with stopping and restarting your product. But when you have parts in LPA, that usually means that things could be within those modules across the stop/restart and that can be complicated. Anyway, back to the OP's questions: nothing comes to mind, unless the product is stashing away information in a repository that persists across IPLs so that "after the first install" the product is relying on data that it built on that first install. Otherwise, whether "first install" or "re-IPL after install", you're just talking about modules and configuration files that (usually) the customer has set up and they often could not tell the difference between "first install" and "re-IPL". "Upgrade" might be able to make do (if the conditions allow) with "dynamic". And if they do, so normally would "first install" (keeping in mind that "dynamic" consumes common storage resources that might conceivably not be available at the time of the dynamic update). 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: LPA - IPL or dynamic
Here I must completely agree with Lennie (and not just because of the great tag-line) on the first bullet. While the product I am most responsible for hasn't required an IPL in many years (not for a new install or even a release upgrade) the idea of doing an IPL as part of a new installation does validate that a future IPL will also work. Nothing worse than running for weeks/months after a dynamic upgrade only to find that the IPL parameters were never correctly modified and now the system doesn't come active correctly with the once-a-quarter IPL. Now, a good product (in my opinion) should be one that can be dynamically activated for testing purposes and then dynamically de-activated (removing all traces of itself) after the testing is complete so that an IPL is used for the final installation. But, that does cause problems for sites with a once-a-quarter IPL routine when you include the caveat that only 1 "change" should be made with an IPL. How many of us have had to fight the "6 things changed, and now the system won't IPL - what do we back-out first" problem? But, making one-change per IPL and only doing quarterly IPL's means you are always going to be VERY behind in maintenance and releases and taking advantage of new features/functions. Just my opinion. I have a sandbox that I can IPL as often as I want on a daily basis - lucky me. Russell Witt Broadcom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Monday, September 16, 2019 2:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPA - IPL or dynamic Peter, I think it depends entirely on how the product is installed. The various methods required might include, 1. LPA modules 2. Nucleus extensions 3. SVC(s) 4. New APF libraries 5. New linklist libraries 6. PPT modifications 7. Front-ending of existing SVCs 8. Console definition modifictions 9. Sub-system defintions ...and many other types of changes to system libraries or definitions. Each site will have standards about whether they allow such changes in-flight, or require an IPL. There are benefits with the IPL method. One is that you prove the system configuration. You might also wish to consider that installing on one system is fine, but then the product may need to be activated on another LPAR in the Sysplex. Often however, the system initialisation changes can be mode for the first install and then library updates can be performed for an update. Hope that helps. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: 16 September 2019 18:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] LPA - IPL or dynamic Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- 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: LPA - IPL or dynamic
On 9/16/2019 1:54 PM, Peter wrote: Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter Peter, If you have one or two LPA modules, or perhaps an LPA dataset that is standalone and doesn't require any other updates to function, then by all means, dynamically activate. If, however, you also have STEPLIB or LINKLIST dependencies, SVC entries, etc., it's much safer to IPL. There is currently no mechanism to serialize updating both LPA and LINKLIST at the same time, so if you try to do this with SMP/E maintenance hitting both, you'll likely fail spectacularly. Good luck. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA - IPL or dynamic
> If it's upgrade then it's not required. The first question is whether it is true. If they install something that requires an IPL, how sure are they that they will never have to upgrade it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Sent: Monday, September 16, 2019 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LPA - IPL or dynamic Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- 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: LPA - IPL or dynamic
In short, an IPL is easier than develping a program that installs SVCs dynamically, load LPA modules, etc. some products does that. IBM's IMS for example. ITschak On Mon, Sep 16, 2019 at 10:49 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Peter, > > I think it depends entirely on how the product is installed. The various > methods required might include, > > 1. LPA modules > 2. Nucleus extensions > 3. SVC(s) > 4. New APF libraries > 5. New linklist libraries > 6. PPT modifications > 7. Front-ending of existing SVCs > 8. Console definition modifictions > 9. Sub-system defintions > > ...and many other types of changes to system libraries or definitions. > > Each site will have standards about whether they allow such changes > in-flight, or require an IPL. There are benefits with the IPL method. One > is that you prove the system configuration. > > You might also wish to consider that installing on one system is fine, but > then the product may need to be activated on another LPAR in the Sysplex. > > Often however, the system initialisation changes can be mode for the first > install and then library updates can be performed for an update. > > Hope that helps. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Peter > Sent: 16 September 2019 18:54 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] LPA - IPL or dynamic > > Hi > > I have seen few vendors suggesting an IPL as requisite if you are doing > the product install for first time and If it's upgrade then it's not > required. > > I am ignorant here. How does this makes a difference ? Why a dynamic > update won't work if it's a first install ? > > Programmatically how does it work from zOS perspective. > > Apology if this question was already discussed here if so please point me > to the discussion link . > > Regards > Peter > > -- > 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 > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA - IPL or dynamic
> On Monday, September 16, 2019, 10:54:02 AM PDT, Peter wrote: > I have seen few vendors suggesting an IPL as requisite Product vendor's do not want to be the cause for an IPL unless it's absolutely necessary. z/OS has many features that we can use to avoid IPL's. SVC's can be replaced by PC calls. MVS setprog allows APF, linklst, LPA and various other changes. Is there something specific you have in mind? Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPA - IPL or dynamic
Peter, I think it depends entirely on how the product is installed. The various methods required might include, 1. LPA modules 2. Nucleus extensions 3. SVC(s) 4. New APF libraries 5. New linklist libraries 6. PPT modifications 7. Front-ending of existing SVCs 8. Console definition modifictions 9. Sub-system defintions ...and many other types of changes to system libraries or definitions. Each site will have standards about whether they allow such changes in-flight, or require an IPL. There are benefits with the IPL method. One is that you prove the system configuration. You might also wish to consider that installing on one system is fine, but then the product may need to be activated on another LPAR in the Sysplex. Often however, the system initialisation changes can be mode for the first install and then library updates can be performed for an update. Hope that helps. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: 16 September 2019 18:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] LPA - IPL or dynamic Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- 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: LPA - IPL or dynamic
Would have to understand where the modules you are referring to live and how they are used, etc. LPA content comes to mind. Take a quick look/read here. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieag100/iea3g1_Managing_dynamic_LPA_content.htm Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Monday, September 16, 2019 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LPA - IPL or dynamic Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- 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
LPA - IPL or dynamic
Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA
When a module is dynamically loaded into the LPA is the dataset name retained anywhere? No. Nor is it retained for modules loaded into PLPA or MLPA/FLPA (or private, for that matter, although of course those interfaces do not let you directly specify the data set name). 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
Dynamic LPA
When a module is dynamically loaded into the LPA is the dataset name retained anywhere? If so, where? I am asking because we want to issue a binder call to determine the LINKEDIT date and to do this we need the dataset name. Thank you in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Deleted modules in Dynamic LPA
When running the CDE chain, ECVTDLPF for the dynamic LPA queue is there any way to identify deleted modules? Modules that have been loaded and deleted many times have multiple CDE’s in the chain. It appears that IPCS can distinguish between current and deleted modules as IPCS LPAMAP shows all of the entries both current and deleted but IPCS FINDMOD just shows the current module. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSVQUERY Anomaly D LPA output diag column ?
On 6/9/2014 6:33 AM, MichealButz wrote: Would anyone know what the diag info and what the flags mean ? FLAGS MODULEENTRY PT LOAD PT LENGTHDIAG DFP USERMODDACEE 80C87000 00C87000 1310 02075EA8 Last I checked, the flags were fully documented with the message. If you find that is not the case, please file an RCF to get it corrected. Thanks, -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSVQUERY Anomaly D LPA output diag column ?
Would anyone know what the diag info and what the flags mean ? FLAGS MODULEENTRY PT LOAD PT LENGTHDIAG DFP USERMODDACEE 80C87000 00C87000 1310 02075EA8 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: Monday, June 09, 2014 7:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CSVQUERY Anomaly Did both but I still only get x'04' from attr3 Sent from my iPhone > On Jun 9, 2014, at 7:20 AM, Walt Farrell wrote: > >> On Mon, 9 Jun 2014 05:43:29 -0400, MichealButz wrote: >> >> It still is referenced by common below is my PROG01 entry >> >> LPA ADD MODNAME(USERMOD) DSNAME(USER.TEST.LOAD) FIXED > > So, did you add it via a SETPROG command or not? > > -- > Walt > > -- > 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: Same LPA library in LPALIST
It sounds like the OP has a user-owned SVC and wants to change the SVC module to a module that is in a "new" library. You would not typically add the whole library to LPA just to accomplish that (unless that new SVC module needs to be kept in synch with other modules in that library that will be accessed only after a new link/load/xctl/attach/csvquery to find the address). You could add the single module to LPA and use the SvcNumDec operand to identify which SVC table entry is to be updated. You could add the single module to LPA and use the SVCUPDTE assembler service to do the update. 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: Same LPA library in LPALIST
Tom Marchant wrote: >You are applying a fix to a running product. One of the elements is in >library that is in the LPA list. Is that correct? If so, you might have >bigger issues than the LPA library. Absolutely! >The LPA library is not used except at IPL time, so this may not be necessary. Except dynamic SVC, but I suppose the OP meant static SVC. >No, you can't add a library dynamically to LPALST. What do you think that >would mean? LPALST is read at IPL time to build the LPA. You can, however, >add modules to LPA **IF YOU KNOW WHAT YOU ARE DOING**. Correct. I hope the OP has a sandbox to practise his tricks... >It's not my dog. Also not my dogs too! If it were my dogs, I would grab a bottle of pentobarbital to get rid of it. ;-) (No, of course, I'm not that cruel! ;-D ) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Same LPA library in LPALIST
On Tue, 23 Jul 2013 17:01:05 +0530, Jake anderson wrote: >I am in a process of applying a fix to a product which eventually changes >the LPA library of the product. You are applying a fix to a running product. One of the elements is in library that is in the LPA list. Is that correct? If so, you might have bigger issues than the LPA library. >So as a backup I have overridden the DDDEF >by specifying a newly created LPA library(Copied from the existing one from >LPA queue). The LPA library is not used except at IPL time, so this may not be necessary. However, elements that are updated in other libraries may be picked up immediately and could cause problems. >Since Current LPA queue addresses SVC 254, for testing purpose can i add >the new ly updated LPA dynamically to LPALIST ? No, you can't add a library dynamically to LPALST. What do you think that would mean? LPALST is read at IPL time to build the LPA. You can, however, add modules to LPA **IF YOU KNOW WHAT YOU ARE DOING**. It's not my dog. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RES: Same LPA library in LPALIST
Actually you can update an entire library by issueing SETPROG LPA,ADD,DSN=,MASK=*, and then you update the SVC with SETPROG LPA,ADD,DSN=xxx,MODNAME=,SVCNUMDEC=254. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-2177 R: 42177 3-1402 Fax: +55 11 3684-4427 Agora é BRA. BRA de Brasil. BRA de Bradesco. Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de Staller, Allan Enviada em: terça-feira, 23 de julho de 2013 10:08 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: Same LPA library in LPALIST To modify LPALIST, an IPL is required. Are you saying this product is (updating/replacing) the user SVC 254? Or more than just the SVC? In general, you can replace LPA resident modules w/SETPROG LPA,ADD,MOD=lmodname,DSNAME=dsname . Works for 1 or 2modules, otherwise it gets quite cumbersome. I believe (from a quick reading of the manual (MVS SYSTEM COMMANDs - SETPROG LPA) you will need an additional operand (SVCNUMDEC=svcnum) to update the SVC table HTH, I am in a process of applying a fix to a product which eventually changes the LPA library of the product. So as a backup I have overridden the DDDEF by specifying a newly created LPA library(Copied from the existing one from LPA queue). Since Current LPA queue addresses SVC 254, for testing purpose can i add the new ly updated LPA dynamically to LPALIST ? Z/OS : 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICE...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Same LPA library in LPALIST
Hello, It is just updating SVC 254. Its like : JAKE.PROD.LPA is already in LPALIST, but due to a new maintenance I have overridden the LPA DDDEF with a copy of JAKE.PROD.LPA as : //DBLPA DD DSN=JAKE.PROD.LPA.NEW,DISP=SHR So, DYNAMIC update of JAKE.PROD.LPA.NEW will be feasible ? On Tue, Jul 23, 2013 at 6:37 PM, Staller, Allan wrote: > To modify LPALIST, an IPL is required. Are you saying this product is > (updating/replacing) the user SVC 254? Or more than just the SVC? > > In general, you can replace LPA resident modules w/SETPROG > LPA,ADD,MOD=lmodname,DSNAME=dsname . Works for 1 or 2modules, otherwise it > gets quite cumbersome. > > I believe (from a quick reading of the manual (MVS SYSTEM COMMANDs - > SETPROG LPA) you will need an additional operand (SVCNUMDEC=svcnum) to > update the SVC table > > HTH, > > > I am in a process of applying a fix to a product which eventually changes > the LPA library of the product. So as a backup I have overridden the DDDEF > by specifying a newly created LPA library(Copied from the existing one from > LPA queue). > > Since Current LPA queue addresses SVC 254, for testing purpose can i add > the new ly updated LPA dynamically to LPALIST ? > > Z/OS : 1.13 > > > -- > 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: Same LPA library in LPALIST
I would suggest a quick trip to the MVS manuals for SETPROG http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm. zos.r11.ieag100/setprog.htm Next, you need to be very careful when changing a module in LPA. Could cause an IPL. Do you have any tools like Tivoli (Omegamon), Mainview or other monitor? They typically have an LPAM type function. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Tuesday, July 23, 2013 4:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Same LPA library in LPALIST Hello All, I am in a process of applying a fix to a product which eventually changes the LPA library of the product. So as a backup I have overridden the DDDEF by specifying a newly created LPA library(Copied from the existing one from LPA queue). Since Current LPA queue addresses SVC 254, for testing purpose can i add the new ly updated LPA dynamically to LPALIST ? Z/OS : 1.13 Any Suggestions or advise is much appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Same LPA library in LPALIST
To modify LPALIST, an IPL is required. Are you saying this product is (updating/replacing) the user SVC 254? Or more than just the SVC? In general, you can replace LPA resident modules w/SETPROG LPA,ADD,MOD=lmodname,DSNAME=dsname . Works for 1 or 2modules, otherwise it gets quite cumbersome. I believe (from a quick reading of the manual (MVS SYSTEM COMMANDs - SETPROG LPA) you will need an additional operand (SVCNUMDEC=svcnum) to update the SVC table HTH, I am in a process of applying a fix to a product which eventually changes the LPA library of the product. So as a backup I have overridden the DDDEF by specifying a newly created LPA library(Copied from the existing one from LPA queue). Since Current LPA queue addresses SVC 254, for testing purpose can i add the new ly updated LPA dynamically to LPALIST ? Z/OS : 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Same LPA library in LPALIST
Hello All, I am in a process of applying a fix to a product which eventually changes the LPA library of the product. So as a backup I have overridden the DDDEF by specifying a newly created LPA library(Copied from the existing one from LPA queue). Since Current LPA queue addresses SVC 254, for testing purpose can i add the new ly updated LPA dynamically to LPALIST ? Z/OS : 1.13 Any Suggestions or advise is much appreciated. /Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
On Sun, 14 Jul 2013 17:19:09 -0400 Richard Verville wrote: :>John Gilmore->There is no need for further assertions that things :>that manifestly do work may not or for something less than clarity :>about, for example, the fact that AMODE(64) code is faster than :>AMODE(31) code.< :>Are you saying that AMODE(64) is faster than AMODE(31) ? If so, why would that be ? Depending on how the box is built, to handle tri-mode may require a check of addresses versus the AMODE on most instructions. There may be a preference to 64 to improve performance in products that are used for benchmarks. Of course, there may be 3 different engines -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
John Gilmore->There is no need for further assertions that things that manifestly do work may not or for something less than clarity about, for example, the fact that AMODE(64) code is faster than AMODE(31) code.< Are you saying that AMODE(64) is faster than AMODE(31) ? If so, why would that be ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
On 7/8/2013 5:55 AM, Kenneth Wilkerson wrote: ... most of the stuff I write is RMODE64. Wow! That's ambitious! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
Peter Relson's most recent post seems to me to strike the right note. That the PrOp makes a hardware feature available is a necessary but not a sufficient condition for its availability under an operating system, any operating system. (I know of one old proto-OS that effectively blocked all use of the System/360 SVC facility.) It is important that anyone who gets into trouble using a facility or technique that IBM has not said it supports not whine about it. Moreover, anyone who does use such a facility has an obligation to do more and more rigorous boundary testing than he might otherwise do. Much depends upon circumstances and judgment. Most statement-level languages, for example, omit to enforce some of the restrictions they impose explicitly. Exploiting such an omissis is, however, unwise. The next version of the language processor involved may well enforce some of them. This seems to be a situation much like the one we are discussing, but it is in fact a very different one. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
>I'm basing everything I'm doing on the Principles of Operations manual >(POM). The Z/Architecture is the final authority for any program even MVS. An interesting opinion. But I'd say "not overly relevant". Sure, you can consider the Principles of Operation to be the final authority for what the machine does. That document does not in any way define what the operating system supports. And when you do something not supported by the operating system, it is your risk to bear, if the operating system has chosen not to enforce other than by documentation (even lack of "we support it" documentation). Suppose, for example, you use "Wait" via SVC from an RMODE 64 routine. You might get into Wait just fine (although at this point the SVC FLIH would reject it, I believe, except for the abend SVC). But Wait does stuff based on the invoker's address and Wait is not cognizant of an address above 2G. There are other more subtle things that could come into play even for a PC-entered service that are related to the caller's address. You are betting that none of them happen or come into play, without having much way of validating if that is or is not true. Those might be functional things, or diagnostic things. 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: Dynamic LPA Services
Walt Farrell wrote: | Are you perhaps confusing AMODE and RMODE, | John? I am, I must suppose, confused about some things at my advanced age; but that is not one of them. There are two issues here that it is useful to disentangle. I execute code above the bar routinely; and I know of others who do so too. IBM's strictures are entirely reasonable. They come down to the notion that you are on your own if you do something that IBM is not yet ready to support. That said, the future of the mainframe, assuming hopefully that it has one, is above the bar. Moreover, in my now considerable experience with AMODE(64) code I have not found, systems services aside, any interesting differences between the behavior of such code above and below the bar. This morning, for example, I tested some extensions to an AMODE(64) table-search routine. As is my habit, I tested it for the 2^2 = 4 relevant situations: table and code below the bar, table below the bar and code above it, table above the bar and code below it, table above the bar and code above it. I expected none, and there were no behavioral differences. A little more candor about some of these things is now, I think, in order. IBM has provided us with what its lawyers call constructive notice of the things it is not yet prepared to fix if they malfunction or fail to function at all. This, as I have already said, is sensible and appropriate. There is no need for further assertions that things that manifestly do work may not or for something less than clarity about, for example, the fact that AMODE(64) code is faster than AMODE(31) code. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
I relocate all non-PC code into 31 bit storage. To the code being called, it appears as if it's RMODE31. I do call PC routines above the bar, but it would be trivial to relocate them as well if it became necessary. I trust the Z/Architecture to handle the PC linkage. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Thursday, July 11, 2013 9:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services On Thu, 11 Jul 2013 09:03:33 -0400, John Gilmore wrote: >As I read Kenneth Wilkerson's post he is arranging things so that an >RMODE(64) routine that needs system services unavailable to it as such >arranges to have a different, associated RMODE(31) routine request them >and make their results available to it. As I read it, that's not what Kenneth said, John. He said that he has an RMODE(31) stub that he uses as the address -of- the PC routine, and the stub then invokes the actual PC code that is RMODE(64). He specifically talked about using the system services from his RMODE(64) code, and if that's true then it's unsupported, as Peter mentioned. > >This scheme [or the alternative one in which an RMODE(31) routine hands >off functions to, or accesses data in, an RMODE(64) one] is entirely >viable and much used in IBM code. Are you perhaps confusing AMODE and RMODE, John? As far as I know, IBM does not make much use of RMODE(64) code. I believe the capability of RMODE(64) code was provided for DB2's use, and I suspect only DB2 is using it for much (though I have no real way of knowing, any more.) It is true that RMODE(31) routines are used often to handle AMODE(64) callers, of course. >In my own programming I >now often use AMODE(64) code in RMODE(31) routines to facilitate just >such exchanges. Right: AMODE(64) in RMODE(31) is just fine. But RMODE(64) code is rare, I believe, and has the restrictions that Peter mentioned. RMODE(64) support for code is documented to be for code that does not call system services. While system services may be documented to allow AMODE(64) callers, that does not mean that they will properly handle RMODE(64) callers. I presume IBM knows (or suspects) that some issues exist if RMODE(64) code were to call system services or they would not have made that restriction. But I suppose it is also possible that they are simply being cautious and avoiding a heavy testing and warranty expense by stating that restriction. -- Walt -- 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: Dynamic LPA Services
On Thu, 11 Jul 2013 09:03:33 -0400, John Gilmore wrote: >As I read Kenneth Wilkerson's post he is arranging things so that an >RMODE(64) routine that needs system services unavailable to it as such >arranges to have a different, associated RMODE(31) routine request >them and make their results available to it. As I read it, that's not what Kenneth said, John. He said that he has an RMODE(31) stub that he uses as the address -of- the PC routine, and the stub then invokes the actual PC code that is RMODE(64). He specifically talked about using the system services from his RMODE(64) code, and if that's true then it's unsupported, as Peter mentioned. > >This scheme [or the alternative one in which an RMODE(31) routine >hands off functions to, or accesses data in, an RMODE(64) one] is >entirely viable and much used in IBM code. Are you perhaps confusing AMODE and RMODE, John? As far as I know, IBM does not make much use of RMODE(64) code. I believe the capability of RMODE(64) code was provided for DB2's use, and I suspect only DB2 is using it for much (though I have no real way of knowing, any more.) It is true that RMODE(31) routines are used often to handle AMODE(64) callers, of course. >In my own programming I >now often use AMODE(64) code in RMODE(31) routines to facilitate just >such exchanges. Right: AMODE(64) in RMODE(31) is just fine. But RMODE(64) code is rare, I believe, and has the restrictions that Peter mentioned. RMODE(64) support for code is documented to be for code that does not call system services. While system services may be documented to allow AMODE(64) callers, that does not mean that they will properly handle RMODE(64) callers. I presume IBM knows (or suspects) that some issues exist if RMODE(64) code were to call system services or they would not have made that restriction. But I suppose it is also possible that they are simply being cautious and avoiding a heavy testing and warranty expense by stating that restriction. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
I'm basing everything I'm doing on the Principles of Operations manual (POM). The Z/Architecture is the final authority for any program even MVS. The linkage for PC instructions are handled by the linkage stack which fully supports 128 bit PSW and 64 bit registers. If it didn't, nothing that I'm doing would work. I've had STORAGE abends (B78 etc) and they get communicated to my RTM exit and the exit handles the 64 bit retry by retrying into a 31 bit stub that BSMs to the actual retry. It's important that I mention that even in PC calls, I insure that all parameters are below the bar. And if a problem ever did occur, I would simply start relocating PC calls below the bar as well. This methodology works for BLDL so I can't see why it wouldn't work for STORAGE. I've been running RMODE64 since shortly after 1.13 became available without incident related to RMODE64 except program bugs. All of this probably works because the RMODe64 programs define a 31 bit RTM exit and 31 bit retries. I understand your objection to LOAD with ADDR=. The fact that the code is not identified can be problematic. But the nucleus solves this problem by using load tables (CVT, SVT, SFT, etc) and provides a service, NUCLKUP. I have simply adopted that methodology; a load table with a RESOLVE command that is also PC intelligent. It's not difficult to extract the LTOR and resolve the entry tables. The POM describes the architecture very thoroughly. I actually don't use ADDR64=. During server initialization, I have to load the code to verify whether or not the code has changed. Since all of the code is self-relocating (no ESDs or RLDs), if it has changed, I simply MVCL it into the common memory object. At the end of initialization, I also DAT protect the code area so that essentially, except for the fact that it can't be identified, it's just like an LPA above the bar. If there were a way to identify RMODE64 code, I would use it. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, July 11, 2013 6:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services RMODE64: Perhaps you are not aware that z/OS provides support for RMODE 64 routines only when they call no system services. If that was your case, then great. But apparently it isn't since you mentioned STORAGE and ESTAEX and CSVQUERY which certainly do not document that they support RMODE 64 invocation. You are taking a risk. Is it worth it? Presumably you are using LOAD with ADDR64 rather than LOAD with ADDR. Perhaps I misread your original post, but I thought it said LOAD with ADDR. I still fully stand by the statement that lOAD with ADDR= to common storage should not be used for programs any longer. LOAD with ADDR64, it is true, has no dynamic LPA equivalent so to the extent you have a routine that properly qualifies, there can be benefit. 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: Dynamic LPA Services
As I read Kenneth Wilkerson's post he is arranging things so that an RMODE(64) routine that needs system services unavailable to it as such arranges to have a different, associated RMODE(31) routine request them and make their results available to it. This scheme [or the alternative one in which an RMODE(31) routine hands off functions to, or accesses data in, an RMODE(64) one] is entirely viable and much used in IBM code. In my own programming I now often use AMODE(64) code in RMODE(31) routines to facilitate just such exchanges. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
RMODE64: Perhaps you are not aware that z/OS provides support for RMODE 64 routines only when they call no system services. If that was your case, then great. But apparently it isn't since you mentioned STORAGE and ESTAEX and CSVQUERY which certainly do not document that they support RMODE 64 invocation. You are taking a risk. Is it worth it? Presumably you are using LOAD with ADDR64 rather than LOAD with ADDR. Perhaps I misread your original post, but I thought it said LOAD with ADDR. I still fully stand by the statement that lOAD with ADDR= to common storage should not be used for programs any longer. LOAD with ADDR64, it is true, has no dynamic LPA equivalent so to the extent you have a routine that properly qualifies, there can be benefit. 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: Dynamic LPA Services
>since most of the stuff I write is RMODE64. >Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do with PC routines. And it has a lot to do with PC routines sine the LPA is 24/31 bit storage. If you want to exploit RMODE64, you can't currently do that in the LPA. PC routines can be called from any amode, any Rmode and any environment (the new transaction environment excluded) except SACF 256 and 768. That is why PC routines are important. More than 2/3rds of the server (approximately 500K of code) executes in a common memory object. The code that does not is mostly involved in SVC screening, runs as IRBs, run as tasks in the server or are specialized services that make a lot of non-PC MVS service calls. Since most of the server including the API are designed to run in cross memory mode, there are no SVC calls. Since PC calls such as STORAGE, ESTAEX and CSVQUERY (which is all the services normally used by the server) are RMODE64 capable this presents no problem. Some of the API services branch call MVS services and even do I/O. Since all the code is ARCHLVL=2 and is self-relocating, I copy the guts (macro expansions) of these calls into a 31 bit work area enclosed in a BSM back to the RMODE64 code. My RTM exit recognizes abends in these relocated copies and report them accordingly. The 2 big issues were RTM exits and getting the PCAUTH to accept my 64 bit addresses. I got around these issues through a concept I call surrogation. I create a 31 bit stub program that contains the entry points to all the PC calls and their RTM exit (they all share the same RTM estaex or FRR exits). This code handles the redirection into the memory object. I could not find methods provided by MVS to do these things (I did not spend a whole lot of time searching). So I designed and wrote my own methods. I designed the server to run in RMODE64 from day 1 so when 1.13 was released, I was able (through a few macros and the surrogate program) to get many of the server programs above the bar in a single day. With time, I've moved most of the server including much of the UI above the bar. I even execute ISPF calls above the bar by replacing the CALL macro with a self-written macro. Again, my point is that I don't believe in designing servers to the lowest common denominator provided you are willing to write the code to fill in the gaps. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, July 09, 2013 6:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services >You know who owns it because its defined as a PC and therefore has an >entry table assigned to it. I suspect that every diagnostician in the world disagrees with you about using LOAD with ADDR=. It is true of course that you could navigate from the PC number to the entry table to the target address for the PC. But then you want to know what module is at that target address. Having a "name" that has been provided by the module owner (presumably one that follows the module owner's naming conventions) makes that easiest. The same is true if you blow up at address "x" and want to find out in what module "x" is. Using dynamic LPA for things in common makes that easier. And has no significant downside. >since most of the stuff I write is RMODE64. Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do with PC routines. >MVS is going to treat it as authorized simply because it's in the LPA. That means that it is accepted as the target of a LINK, LOAD, (etc) from an authorized requestor. It does not mean that it will get control in an authorized state from EXEC PGM=. That requires AC=1. >To say that you can't ever free a PC routine is untrue. Almost any >space switching PC will terminate as soon as the server that defined it >terminates. I carelessly omitted, but the thread had already established, that we were talking about non-space-switch PC's. >Certainly, any PC routine that is defined as non-space switching >system PC routine that can be called without any provided interface >probably cannot be freed. The only such "interface" that I can think of is one that increments a counter (or sets a flag if that suffices) before issuing the PC and freeing of the area is not allowed if the counter is non-0. Such counters/flags are notoriously problematic due to memterm considerations. >However, a new copy can be loaded and >redefined which is why I like reusable LXs. Everyone should like reusable LX's. But you still do have to get rid of the old one first so there's a window when neither is available. >In my book, PC routines are the only way to fly. I don't think anyone is disagreeing with you. I was only pointing out that LOAD with ADDR= is not the way to go. Peter Rels
Re: Dynamic LPA Services
A D6-22 is a linkage exception meaning the LX is not connected to the address space issuing the PC. For a system LX, this means the LX has not been connected by an ETCON, the LX has been disconnected by an ETDIS or ETDES, or the address space that connected the LX has terminated. For a non-system LX, it could mean the address space issuing the PC has not issued the ETCON to connect the non-system LX. If you do a SLIP COMP=0D6, you can use the IPCS Status display to list all the linkage tables in ascending LX order. Then you can visually whether the LX is connected or not. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Tuesday, July 09, 2013 3:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services You should be aware that ETDEF does not set a return code. It does inline instructions to build a single entry. The ETCRE/ETCON are the ones that make something happen. On Mon, 8 Jul 2013 22:28:59 GMT "esst...@juno.com" wrote: :>As the original Poster, I thank every one for there input. :>The various information provided has been excellent :>Thank You :>I am still getting the 0D6-022 Abend, and I am Not Understanding why. :> :>So Let me level set every one. :>I Am On a Z/oS 1.4 System :>I do not have LX Reuse on this system, I don't think that has anything to do with this issue. :> :>I use te CVT to determine LX Reuse. :> USING CVTMAP,R15 .INFORM ASSEMBLER :> L R15,X'10' .ADDRESS OF CVT :> TMCVTFLAG2,CVTALR.LX Reuse Available 01404522 :> BNO NO_LX_REUSE.NO EXISTANCE 01404622 :> :>I would like to understand the use of CR0 to determine this, if someone would post the code. :>. :>I am aware of Obtaining Storage in Common and Loading a routine into key 0 SP 241 or similar, I'm trying to gain a new skill by using LPA Dynamic Services. :> :>In a separate job I Dynamically Add a module to LPA using CSVDYLPA. :> :>Then I Start An Address Space and use CSVQUERY to obtain the entry Point Address of the Module I Added To LPA. :>The Entry Point Address returned from CSVQUERY is then used in an ETDEF SET macro that describes a Non Space Switching PC Routine. :> :>SET_ETD1 DS 0H 03340004 :> ETDEF TYPE=SET,ETEADR=ETD1,ROUTINE=(2),RAMODE=31, X03350004 :> STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO, X03360004 :> SASN=OLD,ASCMODE=PRIMARY, X03370004 :> EK=8,PKM=OR, XX03380004 :> AKM=(8,9),EKM=(8) 03390004 :>* 0344 :> STR15,XMSRESP Save Response Code 03410004 :> BRAS R14,CHKRESP Go Check Response Code In Reg-15 :> :>The Address Space has Not terminated. :> :>Now I want to submit a Job which invokes this Routine via a PC instruction. :>the PC Number is D601. :>Where D6 is The LX :>01 Is the Second Entry in the Entry Table. :>However when I issue the PC instruction I get an 0D6 Abend... :> :>Thank You Again for all Your comments. :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen 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 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: Dynamic LPA Services
>The point is that SLIP LPAMOD=and the IPCS WHERE subcommand >will not be able to identify your module by name. So when someone needs to refer to your module on a SLIP command, they will need to manually determine the address of your module in order to use use ADDRESS= (and the >address could change every time your product starts, and is likely to be different of each member of a sysplex). >As a z/OS diagnosis expert, I view that as a serviceability issue. Since a server address space is required to define the PCs, the server provides an operator command such as resolve. The customer issues RESOLVE,pgmname+disp and the system returns the address and the instruction at that address for verification. The address can then be cut and paste into a SLIP command. I have my own WHERE facility that is PC intelligent. My point is that you don't have to design severs to the lowest common denominator as long as you are willing to provide services to fill in the gap. The diagnostic capabilities that the server I write provide are much greater than what currently exists. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Tuesday, July 09, 2013 12:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services > You know who owns it because its defined as a PC and therefore has an entry > table assigned to it. Looking in the entry tables for a program is > just as > common a practice as looking for "identified" programs. So finding PC > routines just requires different methods. Besides, if this is a > stacking PC > which is the only type I use, the linkage stack has everything needed > to associate the call with the PC routine including the PC number. The point is that SLIP LPAMOD=and the IPCS WHERE subcommand will not be able to identify your module by name. So when someone needs to refer to your module on a SLIP command, they will need to manually determine the address of your module in order to use use ADDRESS= (and the address could change every time your product starts, and is likely to be different of each member of a sysplex). As a z/OS diagnosis expert, I view that as a serviceability issue. > To say that you can't ever free a PC routine is untrue. Almost any > space switching PC will terminate as soon as the server that defined > it terminates. So these can be released and refreshed as needed every > time the > server recycles. Certainly, there are many PC routines that can't be freed. > But if a PC routine is designed to be called as part of an API or UI, then > API/UI recovery can easily recover the error and report it as the > server terminating. Certainly, any PC routine that is defined as > non-space switching system PC routine that can be called without any > provided interface probably cannot be freed. However, a new copy can > be loaded and > redefined which is why I like reusable LXs. Consider the case where the storage formerly occupied by the freed PC routine has been reassigned by VSM, and now contains data that happens to look like a valid instruction stream. So now your "PC routine" is executing unintended code, with the authority of the user and your PC routine. What will cause your API/UI recovery to get control, and if it does get control, how will it "easily recover the error"? How will it detect and repair any damage which occurred due to the execution of the unintended instructions? Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Dynamic LPA Services
>You know who owns it because its defined as a PC and therefore has an >entry table assigned to it. I suspect that every diagnostician in the world disagrees with you about using LOAD with ADDR=. It is true of course that you could navigate from the PC number to the entry table to the target address for the PC. But then you want to know what module is at that target address. Having a "name" that has been provided by the module owner (presumably one that follows the module owner's naming conventions) makes that easiest. The same is true if you blow up at address "x" and want to find out in what module "x" is. Using dynamic LPA for things in common makes that easier. And has no significant downside. >since most of the stuff I write is RMODE64. Really? Perhaps you meant AMODE 64. But I'm not sure what that has to do with PC routines. >MVS is going to treat it as authorized simply because it's in the LPA. That means that it is accepted as the target of a LINK, LOAD, (etc) from an authorized requestor. It does not mean that it will get control in an authorized state from EXEC PGM=. That requires AC=1. >To say that you can't ever free a PC routine is untrue. Almost any space >switching PC will terminate as soon as the server that defined it >terminates. I carelessly omitted, but the thread had already established, that we were talking about non-space-switch PC's. >Certainly, any PC routine that is defined as non-space >switching system PC routine that can be called without any provided >interface probably cannot be freed. The only such "interface" that I can think of is one that increments a counter (or sets a flag if that suffices) before issuing the PC and freeing of the area is not allowed if the counter is non-0. Such counters/flags are notoriously problematic due to memterm considerations. >However, a new copy can be loaded and >redefined which is why I like reusable LXs. Everyone should like reusable LX's. But you still do have to get rid of the old one first so there's a window when neither is available. >In my book, PC routines are the only way to fly. I don't think anyone is disagreeing with you. I was only pointing out that LOAD with ADDR= is not the way to go. 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: Dynamic LPA Services
You should be aware that ETDEF does not set a return code. It does inline instructions to build a single entry. The ETCRE/ETCON are the ones that make something happen. On Mon, 8 Jul 2013 22:28:59 GMT "esst...@juno.com" wrote: :>As the original Poster, I thank every one for there input. :>The various information provided has been excellent :>Thank You :>I am still getting the 0D6-022 Abend, and I am Not Understanding why. :> :>So Let me level set every one. :>I Am On a Z/oS 1.4 System :>I do not have LX Reuse on this system, I don't think that has anything to do with this issue. :> :>I use te CVT to determine LX Reuse. :> USING CVTMAP,R15 .INFORM ASSEMBLER :> L R15,X'10' .ADDRESS OF CVT :> TMCVTFLAG2,CVTALR.LX Reuse Available 01404522 :> BNO NO_LX_REUSE.NO EXISTANCE 01404622 :> :>I would like to understand the use of CR0 to determine this, if someone would post the code. :>. :>I am aware of Obtaining Storage in Common and Loading a routine into key 0 SP 241 or similar, I'm trying to gain a new skill by using LPA Dynamic Services. :> :>In a separate job I Dynamically Add a module to LPA using CSVDYLPA. :> :>Then I Start An Address Space and use CSVQUERY to obtain the entry Point Address of the Module I Added To LPA. :>The Entry Point Address returned from CSVQUERY is then used in an ETDEF SET macro that describes a Non Space Switching PC Routine. :> :>SET_ETD1 DS 0H 03340004 :> ETDEF TYPE=SET,ETEADR=ETD1,ROUTINE=(2),RAMODE=31, X03350004 :> STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO, X03360004 :> SASN=OLD,ASCMODE=PRIMARY, X03370004 :> EK=8,PKM=OR, XX03380004 :> AKM=(8,9),EKM=(8) 03390004 :>* 0344 :> STR15,XMSRESP Save Response Code 03410004 :> BRAS R14,CHKRESP Go Check Response Code In Reg-15 :> :>The Address Space has Not terminated. :> :>Now I want to submit a Job which invokes this Routine via a PC instruction. :>the PC Number is D601. :>Where D6 is The LX :>01 Is the Second Entry in the Entry Table. :>However when I issue the PC instruction I get an 0D6 Abend... :> :>Thank You Again for all Your comments. :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
> You know who owns it because its defined as a PC and therefore has an entry > table assigned to it. Looking in the entry tables for a program is just as > common a practice as looking for "identified" programs. So finding PC > routines just requires different methods. Besides, if this is a stacking PC > which is the only type I use, the linkage stack has everything needed to > associate the call with the PC routine including the PC number. The point is that SLIP LPAMOD=and the IPCS WHERE subcommand will not be able to identify your module by name. So when someone needs to refer to your module on a SLIP command, they will need to manually determine the address of your module in order to use use ADDRESS= (and the address could change every time your product starts, and is likely to be different of each member of a sysplex). As a z/OS diagnosis expert, I view that as a serviceability issue. > To say that you can't ever free a PC routine is untrue. Almost any space > switching PC will terminate as soon as the server that defined it > terminates. So these can be released and refreshed as needed every time the > server recycles. Certainly, there are many PC routines that can't be freed. > But if a PC routine is designed to be called as part of an API or UI, then > API/UI recovery can easily recover the error and report it as the server > terminating. Certainly, any PC routine that is defined as non-space > switching system PC routine that can be called without any provided > interface probably cannot be freed. However, a new copy can be loaded and > redefined which is why I like reusable LXs. Consider the case where the storage formerly occupied by the freed PC routine has been reassigned by VSM, and now contains data that happens to look like a valid instruction stream. So now your "PC routine" is executing unintended code, with the authority of the user and your PC routine. What will cause your API/UI recovery to get control, and if it does get control, how will it "easily recover the error"? How will it detect and repair any damage which occurred due to the execution of the unintended instructions? Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
Control Register 0 bit 44 contains the system setting for LXRES as defined
in the POM in the chapter of control. I'm a Z/Architecture guy and I usually
go to the architecture for settings instead of z/OS. I'm also pretty sure LX
Reuse did not exist in 1.4 though I may be wrong. It was added sometime in
the 1.4 to 1.6 time frame.
In your description, I don't see any reference to LXRES, ETCRE or ETCON.
ETDEF only creates the entry table needed to define PCs. LXRES reserves an
LX (you probably need a system one) and returns a token. I assume that the
D6 LX was acquired via an LXRES and it's a system LX. ETCRE creates a
working copy of your entry tables in the PCAUTH address space and also
returns a token. ETCON connects your entries via the LXRES and ETCON tokens
to the address spaces that are allowed access to your PC routines. For
system LXs, that's every address space. The PC numbers start at LX00 and go
to LX## where 00 is assigned to the first entry in your entry table and ##
is the last entry up to 255. If you define space switch P{C more setup is
required. The Extended Addressability manual goes into all this.
Kenneth
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of esst...@juno.com
Sent: Monday, July 08, 2013 5:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dynamic LPA Services
As the original Poster, I thank every one for there input.
The various information provided has been excellent Thank You I am still
getting the 0D6-022 Abend, and I am Not Understanding why.
So Let me level set every one.
I Am On a Z/oS 1.4 System
I do not have LX Reuse on this system, I don't think that has anything to do
with this issue.
I use te CVT to determine LX Reuse.
USING CVTMAP,R15 .INFORM ASSEMBLER
L R15,X'10' .ADDRESS OF CVT
TMCVTFLAG2,CVTALR.LX Reuse Available
01404522
BNO NO_LX_REUSE.NO EXISTANCE
01404622
I would like to understand the use of CR0 to determine this, if someone
would post the code.
.
I am aware of Obtaining Storage in Common and Loading a routine into key 0
SP 241 or similar, I'm trying to gain a new skill by using LPA Dynamic
Services.
In a separate job I Dynamically Add a module to LPA using CSVDYLPA.
Then I Start An Address Space and use CSVQUERY to obtain the entry Point
Address of the Module I Added To LPA.
The Entry Point Address returned from CSVQUERY is then used in an ETDEF SET
macro that describes a Non Space Switching PC Routine.
SET_ETD1 DS 0H
03340004
ETDEF TYPE=SET,ETEADR=ETD1,ROUTINE=(2),RAMODE=31,
X03350004
STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO,
X03360004
SASN=OLD,ASCMODE=PRIMARY,
X03370004
EK=8,PKM=OR,
XX03380004
AKM=(8,9),EKM=(8)
03390004
*
0344
STR15,XMSRESP Save Response Code
03410004
BRAS R14,CHKRESP Go Check Response Code In Reg-15
The Address Space has Not terminated.
Now I want to submit a Job which invokes this Routine via a PC instruction.
the PC Number is D601.
Where D6 is The LX
01 Is the Second Entry in the Entry Table.
However when I issue the PC instruction I get an 0D6 Abend...
Thank You Again for all Your comments.
--
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
Dynamic LPA Services
As the original Poster, I thank every one for there input. The various information provided has been excellent Thank You I am still getting the 0D6-022 Abend, and I am Not Understanding why. So Let me level set every one. I Am On a Z/oS 1.4 System I do not have LX Reuse on this system, I don't think that has anything to do with this issue. I use te CVT to determine LX Reuse. USING CVTMAP,R15 .INFORM ASSEMBLER L R15,X'10' .ADDRESS OF CVT TMCVTFLAG2,CVTALR.LX Reuse Available 01404522 BNO NO_LX_REUSE.NO EXISTANCE 01404622 I would like to understand the use of CR0 to determine this, if someone would post the code. . I am aware of Obtaining Storage in Common and Loading a routine into key 0 SP 241 or similar, I'm trying to gain a new skill by using LPA Dynamic Services. In a separate job I Dynamically Add a module to LPA using CSVDYLPA. Then I Start An Address Space and use CSVQUERY to obtain the entry Point Address of the Module I Added To LPA. The Entry Point Address returned from CSVQUERY is then used in an ETDEF SET macro that describes a Non Space Switching PC Routine. SET_ETD1 DS 0H 03340004 ETDEF TYPE=SET,ETEADR=ETD1,ROUTINE=(2),RAMODE=31, X03350004 STATE=SUPERVISOR,PC=STACKING,SSWITCH=NO,X03360004 SASN=OLD,ASCMODE=PRIMARY, X03370004 EK=8,PKM=OR, XX03380004 AKM=(8,9),EKM=(8)03390004 * 0344 STR15,XMSRESP Save Response Code 03410004 BRAS R14,CHKRESP Go Check Response Code In Reg-15 The Address Space has Not terminated. Now I want to submit a Job which invokes this Routine via a PC instruction. the PC Number is D601. Where D6 is The LX 01 Is the Second Entry in the Entry Table. However when I issue the PC instruction I get an 0D6 Abend... Thank You Again for all Your comments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
In <003b01ce7b5d$f7113c80$e533b580$@austin.rr.com>, on 07/07/2013 at 05:04 PM, Kenneth Wilkerson said: >I don't know what you're trying to do but I would never define a PC >in the LPA for a lot of reasons. The most basic of these is that LPA >routines are callable by the EP=or EPLOC= parameter on LOAD, LINK, >XCTL and ATTACH services. LOAD does not call the module. >When called from these services the traditional linkage is >significantly different than PC linkage. If by "traditional linkage" you mean the API from EXEC PGM=, most module in the LPA don't support it. Try calling, e.g., IGC0001I, with that linkage (-; -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2<http://patriot.net/~shmuel> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
In <004d01ce7bda$769f9560$63dec020$@austin.rr.com>, on 07/08/2013 at 07:55 AM, Kenneth Wilkerson said: >And it doesn't matter what the AC= is for a LPA program. MVS is >going to treat it as authorized simply because it's in the LPA. Nonsense.See 21.3 Using APF to Restrict Access to System Functions in z/OS MVS Programming: Authorized Assembler Services Guide, SA22-7608-14. Could you be confusing authroized library with authorized program? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2<http://patriot.net/~shmuel> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
In <20130707.133109.2853...@webmail04.dca.untd.com>, on 07/07/2013 at 05:31 PM, "esst...@juno.com" said: >However after re-reading the description of CSVDYLPA, its not really >LPA, its more Common storage. What do you mean by "really LPA"? >So my question is - Should I be able to invoke a Dynamically Added >Module as a Non Space Switching PC Routine. Why not? Just be careful not to delete it prematurely. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2<http://patriot.net/~shmuel> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
Thank you Walt. I was remembering an issue incorrectly. I certainly am guilty of confusing how content supervision handles some aspects of authorization which is one reason I stick to PC routines. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Monday, July 08, 2013 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services On Mon, 8 Jul 2013 07:55:46 -0500, Kenneth Wilkerson wrote: >And it doesn't >matter what the AC= is for a LPA program. MVS is going to treat it as >authorized simply because it's in the LPA. I discovered that the hard way. > That's not true, Kenneth. MVS will certainly consider any LPA-resident module to have been loaded from (i.e., resident in) an APF-authorized library, but that is not related to the AC=0/1 setting. Being resident in an APF-authorized library simply means that the system will allow another program that is already running authorized (APF, system key, or supervisor state) to load the module, and this is true for both AC=0 and AC=1 modules. If the module is not in an APF-authorized library and an authorized program tries to load it in the normal way, the load will fail. If the module does have AC=1, and it's resident in an APF-authorized library, then IF the module in invoked as the jobstep program by the initiator (or in a small handful of other ways) then the new jobstep will gain APF-authorization and run APF-authorized. If you have an LPA-resident module that is AC=0, and you run it via EXEC PGM= it will NOT run APF-authorized. It needs AC=1 for that. Many people (including some IBMers, and some writers of documentation) seem confused by the distinctions between APF-authorized libraries, AC=1, and running APF-authorized. -- Walt -- 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: Dynamic LPA Services
On Mon, 8 Jul 2013 07:55:46 -0500, Kenneth Wilkerson wrote: >And it doesn't >matter what the AC= is for a LPA program. MVS is going to treat it as >authorized simply because it's in the LPA. I discovered that the hard way. > That's not true, Kenneth. MVS will certainly consider any LPA-resident module to have been loaded from (i.e., resident in) an APF-authorized library, but that is not related to the AC=0/1 setting. Being resident in an APF-authorized library simply means that the system will allow another program that is already running authorized (APF, system key, or supervisor state) to load the module, and this is true for both AC=0 and AC=1 modules. If the module is not in an APF-authorized library and an authorized program tries to load it in the normal way, the load will fail. If the module does have AC=1, and it's resident in an APF-authorized library, then IF the module in invoked as the jobstep program by the initiator (or in a small handful of other ways) then the new jobstep will gain APF-authorization and run APF-authorized. If you have an LPA-resident module that is AC=0, and you run it via EXEC PGM= it will NOT run APF-authorized. It needs AC=1 for that. Many people (including some IBMers, and some writers of documentation) seem confused by the distinctions between APF-authorized libraries, AC=1, and running APF-authorized. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
Chuck Arney wrote >Did your dynamic LPA replace a module that was already established as the >PC >routine? The book says you can't do that, as the PC linkage tables are >not >updated by the dynamic LPA service. If you are replacing a module >defined as >a PC you would have to remove the PC and redefine it with the >new module >address. I was not replacing an existing PC Routine. I dynamically added a new module to LPA Then I dynamically deleted It (to be sure I could remove it) And then dynamically Added it Again to LPA After that I started My Address Space, and it issues a CSVQUERY to obtain the Address Of this Dynamicly Added LPA Module. I used the address as input to the ETDEF SET macro. -- Original Message -- From: Chuck Arney To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 15:31:23 -0500 Did your dynamic LPA replace a module that was already established as the PC routine? The book says you can't do that, as the PC linkage tables are not updated by the dynamic LPA service. If you are replacing a module defined as a PC you would have to remove the PC and redefine it with the new module address. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Chuck Areny "It should work just fine Paul" Well I tend to agree, I seem to get the old 0D6-22 Abend when I try To PC to the routine. I first thought PC number was incorrect however I listed my PC Numbers and respective PC number is correct. Thats why I posted this question. Thanks For the Response, I will recheck the code. Paul D'Angelo -- Original Message -- From: Chuck Arney To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 14:12:34 -0500 It should work just fine Paul. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. -- 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: Dynamic LPA Services
You know who owns it because its defined as a PC and therefore has an entry table assigned to it. Looking in the entry tables for a program is just as common a practice as looking for "identified" programs. So finding PC routines just requires different methods. Besides, if this is a stacking PC which is the only type I use, the linkage stack has everything needed to associate the call with the PC routine including the PC number. I rarely use anything but PC routines anymore since most of the stuff I write is RMODE64. The IPCS status displays the entry tables for that reason. And it doesn't matter what the AC= is for a LPA program. MVS is going to treat it as authorized simply because it's in the LPA. I discovered that the hard way. To say that you can't ever free a PC routine is untrue. Almost any space switching PC will terminate as soon as the server that defined it terminates. So these can be released and refreshed as needed every time the server recycles. Certainly, there are many PC routines that can't be freed. But if a PC routine is designed to be called as part of an API or UI, then API/UI recovery can easily recover the error and report it as the server terminating. Certainly, any PC routine that is defined as non-space switching system PC routine that can be called without any provided interface probably cannot be freed. However, a new copy can be loaded and redefined which is why I like reusable LXs. In my book, PC routines are the only way to fly. They can be called in any amode, any rmode and any environment other than SACF 256 and 768 which are very rarely used. And there are as many ways to define and use them as they are people that define and use them. I was just making a suggestion. Peter is making another. I imagine Peter has trusted methods that work. I know that I do as well. If you're going to define a PC, I suggest you don't allow the old dogma to get in your way. Find the method that works for you. PC routines are where MVS has been headed for a long time. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Monday, July 08, 2013 6:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services 0D6 - 22: A linkage index (LX) translation exception occurred; the program interruption code is X'22'. This cannot have anything to do with the location of the target routine. Things added to dynamic LPA are part of LPA. They are built out of (E)CSA. What they are not part of are PLPA, MLPA, FLPA which are not built out of (E)CSA. The approach of using "directed load" is frowned upon. It does not buy anything and has detrimental RAS affects, since the storage area being used as the PC target is now not known by name and thus is harder for any diagnostician to determine who owns it. There is just about no reason any more to do LOAD with ADDR to CSA for code. P.S., do not use LOAD with GLOBAL=YES if your address space could ever terminate without wait-stating the system, as the system frees that storage upon such termination. It is true that someone "could" LINK to the name since there is a name, but that is never of concern to a properly written program. The LPA routine should not be marked as AC=1. By the way, there are extremely few cases where a PC routine can *ever* be freed without introducing a system integrity problem. Do you truly know (as opposed to just hope) that no one is within the routine at the time you want to free it? 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: Dynamic LPA Services
0D6 - 22: A linkage index (LX) translation exception occurred; the program interruption code is X'22'. This cannot have anything to do with the location of the target routine. Things added to dynamic LPA are part of LPA. They are built out of (E)CSA. What they are not part of are PLPA, MLPA, FLPA which are not built out of (E)CSA. The approach of using "directed load" is frowned upon. It does not buy anything and has detrimental RAS affects, since the storage area being used as the PC target is now not known by name and thus is harder for any diagnostician to determine who owns it. There is just about no reason any more to do LOAD with ADDR to CSA for code. P.S., do not use LOAD with GLOBAL=YES if your address space could ever terminate without wait-stating the system, as the system frees that storage upon such termination. It is true that someone "could" LINK to the name since there is a name, but that is never of concern to a properly written program. The LPA routine should not be marked as AC=1. By the way, there are extremely few cases where a PC routine can *ever* be freed without introducing a system integrity problem. Do you truly know (as opposed to just hope) that no one is within the routine at the time you want to free it? 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: Dynamic LPA Services
I don't know what you're trying to do but I would never define a PC in the LPA for a lot of reasons. The most basic of these is that LPA routines are callable by the EP=or EPLOC= parameter on LOAD, LINK, XCTL and ATTACH services. When called from these services the traditional linkage is significantly different than PC linkage. Of course, you might want to be callable by a LOAD, LINK, XCTL and ATTACH service which means you would have a separate entry point defined for the PC routine. I use a jump table at the start of a program to define multiple entry points. To define system level PC routine, I normally acquire a CSA control block that can be found by a system level name/token. Another approach is to use a word in the ECVT that has been assigned to you. I don't remember the procedure but a vendor can get one word in the ECVT assigned by IBM to that vendor. You may use another method. But regardless of the method used to anchor the control block, the small CSA control block would contain the EPA/Length and PC assignments. I always define reusable LXs, so I keep the LX number in there as well. I think reusable LXs are simpler but you have to check control register 0 to make sure the feature is available. I then acquire key 0 SP=241 (CSA non-fetch protected) storage and I do a LOAD ADDR= into that CSA storage. I can now define the PC. Each time you need to refresh the PC routine, you'll need to release the old storage, load a fresh copy and redefine the PC. If you use a reusable PC number, the PC number (low 32 bits) will remain the same (unless you change it) but a the sequence number (high 32 bits architecturally passed in r15) will be incremented by one. For that reason, I always use R15 as the PC register and I save the sequence number and PC number in a double word so I can load it into R15 and do a PC 0(R15). Since you're getting a D6-22 and you're sure the PC is defined, I suspect that the defining address space has terminated. MVS has to have an address space to own a resource. When you acquire an LX and define a range of PC routines, tables are created in real storage and are assigned to the defining address space. The PCAUTH server defines your PC tables in the private SQA of the PCAUTH address space. They are disconnected and released from real storage whenever the address space terminates. If you want PC routines to persist for the duration of an IPL, you need to schedule an SRB into a system address space to define the required PCs. The choice of system address space is yours. The non-space switch PC won't execute In the system address space. It will execute under the DU control blocks (SRB or TCB) in the address space of the caller. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chuck Arney Sent: Sunday, July 07, 2013 3:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Did your dynamic LPA replace a module that was already established as the PC routine? The book says you can't do that, as the PC linkage tables are not updated by the dynamic LPA service. If you are replacing a module defined as a PC you would have to remove the PC and redefine it with the new module address. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Chuck Areny "It should work just fine Paul" Well I tend to agree, I seem to get the old 0D6-22 Abend when I try To PC to the routine. I first thought PC number was incorrect however I listed my PC Numbers and respective PC number is correct. Thats why I posted this question. Thanks For the Response, I will recheck the code. Paul D'Angelo -- Original Message -- From: Chuck Arney To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 14:12:34 -0500 It should work just fine Paul. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --
Re: Dynamic LPA Services
Did your dynamic LPA replace a module that was already established as the PC routine? The book says you can't do that, as the PC linkage tables are not updated by the dynamic LPA service. If you are replacing a module defined as a PC you would have to remove the PC and redefine it with the new module address. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Chuck Areny "It should work just fine Paul" Well I tend to agree, I seem to get the old 0D6-22 Abend when I try To PC to the routine. I first thought PC number was incorrect however I listed my PC Numbers and respective PC number is correct. Thats why I posted this question. Thanks For the Response, I will recheck the code. Paul D'Angelo -- Original Message -- From: Chuck Arney To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 14:12:34 -0500 It should work just fine Paul. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. -- 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: Dynamic LPA Services
Chuck Areny "It should work just fine Paul" Well I tend to agree, I seem to get the old 0D6-22 Abend when I try To PC to the routine. I first thought PC number was incorrect however I listed my PC Numbers and respective PC number is correct. Thats why I posted this question. Thanks For the Response, I will recheck the code. Paul D'Angelo -- Original Message -- From: Chuck Arney To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 14:12:34 -0500 It should work just fine Paul. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. -- 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: Dynamic LPA Services
Bintamin, thanks for the response. I will recheck my code. Paul D'Angelo -- Original Message -- From: Binyamin Dissen To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic LPA Services Date: Sun, 7 Jul 2013 21:53:03 +0300 On Sun, 7 Jul 2013 17:31:09 GMT "esst...@juno.com" wrote: :>i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). :>Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. :>However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. :>So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. Common storage is commonly addressable, so it is the same as LPA in this respect. -- Binyamin Dissen 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 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: Dynamic LPA Services
It should work just fine Paul. Chuck Arney Arney Computer Systems -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esst...@juno.com Sent: Sunday, July 07, 2013 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamic LPA Services i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LPA Services
On Sun, 7 Jul 2013 17:31:09 GMT "esst...@juno.com" wrote: :>i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). :>Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. :>However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. :>So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. Common storage is commonly addressable, so it is the same as LPA in this respect. -- Binyamin Dissen 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dynamic LPA Services
i have been woking with the Dynamic LPA services of z/OS (CSVDYLPA). Im abel to add, delete, and invoke modules that were dynamically added to "LPA" using CSYDYLPA and CSVQUERY. However after re-reading the description of CSVDYLPA, its not really LPA, its more Common storage. So my question is - Should I be able to invoke a Dynamically Added Module as a Non Space Switching PC Routine. Any Suggestions would be helpfule... Paul D'Angelo - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
