Re: Can you update WLM via a batch program?
Having been in the same position as Jim, I asked practically the same question here, a couple of years back. Then, the basic answer was 'No', so I was highly pleased to see that some sort of progress had been made on this. I should have known better. IWMINSTL is a great starting point, but it's input is a series of ISPF(?) tables. How do you create those from scratch in the first place? Sean On Mon, 16 Sep 2019 at 23:39, Salva Carrasco wrote: > Check IWMINSTL at SYS1.SAMPLIB. > > -- > 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
Ip printway configuration PCOMM screen
Hi , This is about IP printway When I connect to port 524 of printway I get a screen saying connection status, host name , host type , printer , PDT file, CPI/LPI and best-fit scaling. Is this screen part of PCOMM print driver or IP printway printer driver ? Regards Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can you update WLM via a batch program?
Correction - the input is *probably* not ISPF tables (having cross-checked with other ISPTLIBs that I have available). Nevertheless, they are 'encoded' - not straight text... Sean On Tue, 17 Sep 2019 at 08:06, Sean Gleann wrote: > Having been in the same position as Jim, I asked practically the same > question here, a couple of years back. > Then, the basic answer was 'No', so I was highly pleased to see that some > sort of progress had been made on this. > I should have known better. > IWMINSTL is a great starting point, but it's input is a series of ISPF(?) > tables. > How do you create those from scratch in the first place? > > Sean > > On Mon, 16 Sep 2019 at 23:39, Salva Carrasco wrote: > >> Check IWMINSTL at SYS1.SAMPLIB. >> >> -- >> 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: Can you update WLM via a batch program?
XML perchance? If so there’s a lot one could do with that... :-) ... If the plane I was about to get on didn’t see me with my elbows (and knees) up round my ears I’d rustle up a proof of concept. :-) Cheers, Martin Sent from my iPad > On 17 Sep 2019, at 08:57, Sean Gleann wrote: > > Correction - the input is *probably* not ISPF tables (having cross-checked > with other ISPTLIBs that I have available). > Nevertheless, they are 'encoded' - not straight text... > > Sean > >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann wrote: >> >> Having been in the same position as Jim, I asked practically the same >> question here, a couple of years back. >> Then, the basic answer was 'No', so I was highly pleased to see that some >> sort of progress had been made on this. >> I should have known better. >> IWMINSTL is a great starting point, but it's input is a series of ISPF (?) >> tables. >> How do you create those from scratch in the first place? >> >> Sean >> >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco wrote: >>> >>> Check IWMINSTL at SYS1.SAMPLIB. >>> >>> -- >>> 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can you update WLM via a batch program?
I don't think so, Martin - but I'm not an XML expert by any means. If I examine any of the members in the PDS that is used for input to IWMINSTL, I don't see any of the & 'tag' pairs that I'd expect to see. The names of the members are the same as for the results of saving an existing WLM policy and using the 'ISPF tables' option (I'd forgotten that was an option - so I must backtrack on my previous 'correction'). There *is* an option to save in XML format, but nothing in the IWMINSTL member appears to refer to using XML format as input. Even so, to generate the input in either format requires an existing WLM policy to be accessed via the ISPF panels. It appears that creating a WLM policy from scratch in, well, 'plain English', is still not possible, unfortunately. Have a safe trip! Sean On Tue, 17 Sep 2019 at 11:00, Martin Packer wrote: > > XML perchance? > > If so there’s a lot one could do with that... :-) > > ... If the plane I was about to get on didn’t see me with my elbows (and > knees) up round my ears I’d rustle up a proof of concept. :-) > > Cheers, Martin > > Sent from my iPad > > > On 17 Sep 2019, at 08:57, Sean Gleann wrote: > > > > Correction - the input is *probably* not ISPF tables (having > cross-checked > > with other ISPTLIBs that I have available). > > Nevertheless, they are 'encoded' - not straight text... > > > > Sean > > > >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann > wrote: > >> > >> Having been in the same position as Jim, I asked practically the same > >> question here, a couple of years back. > >> Then, the basic answer was 'No', so I was highly pleased to see that > some > >> sort of progress had been made on this. > >> I should have known better. > >> IWMINSTL is a great starting point, but it's input is a series of ISPF > (?) > >> tables. > >> How do you create those from scratch in the first place? > >> > >> Sean > >> > >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco > wrote: > >>> > >>> Check IWMINSTL at SYS1.SAMPLIB. > >>> > >>> -- > >>> 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 > >Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > -- > 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: Can you update WLM via a batch program?
Thanks! But I believe you can load WLM XML into the app - and also into z/OSMF. (Yes, I'll admit I only ever parse the XML (with PHP) - having fixed up some breakage. But the point of unloading is reloading.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Sean Gleann To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/09/2019 11:31 Subject:Re: Can you update WLM via a batch program? Sent by:IBM Mainframe Discussion List I don't think so, Martin - but I'm not an XML expert by any means. If I examine any of the members in the PDS that is used for input to IWMINSTL, I don't see any of the & 'tag' pairs that I'd expect to see. The names of the members are the same as for the results of saving an existing WLM policy and using the 'ISPF tables' option (I'd forgotten that was an option - so I must backtrack on my previous 'correction'). There *is* an option to save in XML format, but nothing in the IWMINSTL member appears to refer to using XML format as input. Even so, to generate the input in either format requires an existing WLM policy to be accessed via the ISPF panels. It appears that creating a WLM policy from scratch in, well, 'plain English', is still not possible, unfortunately. Have a safe trip! Sean On Tue, 17 Sep 2019 at 11:00, Martin Packer wrote: > > XML perchance? > > If so there’s a lot one could do with that... :-) > > ... If the plane I was about to get on didn’t see me with my elbows (and > knees) up round my ears I’d rustle up a proof of concept. :-) > > Cheers, Martin > > Sent from my iPad > > > On 17 Sep 2019, at 08:57, Sean Gleann wrote: > > > > Correction - the input is *probably* not ISPF tables (having > cross-checked > > with other ISPTLIBs that I have available). > > Nevertheless, they are 'encoded' - not straight text... > > > > Sean > > > >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann > wrote: > >> > >> Having been in the same position as Jim, I asked practically the same > >> question here, a couple of years back. > >> Then, the basic answer was 'No', so I was highly pleased to see that > some > >> sort of progress had been made on this. > >> I should have known better. > >> IWMINSTL is a great starting point, but it's input is a series of ISPF > (?) > >> tables. > >> How do you create those from scratch in the first place? > >> > >> Sean > >> > >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco > wrote: > >>> > >>> Check IWMINSTL at SYS1.SAMPLIB. > >>> > >>> -- > >>> 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 > >Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > -- > 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Can you update WLM via a batch program?
Martin, The policy is indeed in XML, FB 80 with a block size of 27920 (not that block size should matter). Looking at the raw data, it looks to continue to the next line at 80 bites so I believe there are no carriage returns or line feeds anywhere - but I don't know XML, and I need to not just parse it out, but parse it back in to make it available to the ISPF app (and the couple data set) again. Any pointers you can share are appreciated, Jim Horne Mainframe Services jim.s.ho...@lowes.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Tuesday, September 17, 2019 6:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Can you update WLM via a batch program? *EXTERNAL SENDER* XML perchance? If so there’s a lot one could do with that... :-) ... If the plane I was about to get on didn’t see me with my elbows (and knees) up round my ears I’d rustle up a proof of concept. :-) Cheers, Martin Sent from my iPad > On 17 Sep 2019, at 08:57, Sean Gleann wrote: > > Correction - the input is *probably* not ISPF tables (having cross-checked > with other ISPTLIBs that I have available). > Nevertheless, they are 'encoded' - not straight text... > > Sean > >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann wrote: >> >> Having been in the same position as Jim, I asked practically the same >> question here, a couple of years back. >> Then, the basic answer was 'No', so I was highly pleased to see that some >> sort of progress had been made on this. >> I should have known better. >> IWMINSTL is a great starting point, but it's input is a series of >> ISPF (?) >> tables. >> How do you create those from scratch in the first place? >> >> Sean >> >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco wrote: >>> >>> Check IWMINSTL at SYS1.SAMPLIB. >>> >>> >>> -- 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confidential information such as plans, pictures and drawings and to assume all risk and liability for and indemnify Lowe's from any claims, losses or damages that may arise from the transmittal of documents or including non-confidential information in the body of an email transmittal. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can you update WLM via a batch program?
On Tue, 17 Sep 2019 11:53:35 +0100, Martin Packer wrote: >Thanks! > >But I believe you can load WLM XML into the app - and also into z/OSMF. > >(Yes, I'll admit I only ever parse the XML (with PHP) - having fixed up >some breakage. But the point of unloading is reloading.) Yes, the extracted XML is a bit annoyingly not quite valid XML, with some extraneous character between the XML elements, that seems to be different for everybody by the time it gets downloaded, presumably due to codepage differences. But in principle, it seems that one could change the XML (presumably being careful with those extraneous characters) and then simply re-import the XML from the panels. Not fully ideal, but better than nothing. However, I don't know that the XML file is meant to be a programming interface, so... I'm not sure whether I'd actually trust that. Seems like it should be a fine enough idea. But I'd check things closely the first few times at least. And I'd trust it more if it seemed to be valid XML. But at least from what I've seen by the time it gets downloaded, it's not quite so. Scott Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: Can you update WLM via a batch program?
Right. In Sublime Text I delete the newline chars that appear to get added. Then my PHP thinks this is valid XML. I do note two things: As was said by Scott, one can't count on this format. Getting it back into valid 80-byte might be tough. (The round trip through valid XML is necessary if a global search and replace is wanted.) And boy would I love a spelling corrector and consistency creator for WLM policies. This stuff shows up in RMF and hence in titles of some of my graphs. :-) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Horne, Jim - James S" To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/09/2019 11:59 Subject:Re: [EXTERNAL] Re: Can you update WLM via a batch program? Sent by:IBM Mainframe Discussion List Martin, The policy is indeed in XML, FB 80 with a block size of 27920 (not that block size should matter). Looking at the raw data, it looks to continue to the next line at 80 bites so I believe there are no carriage returns or line feeds anywhere - but I don't know XML, and I need to not just parse it out, but parse it back in to make it available to the ISPF app (and the couple data set) again. Any pointers you can share are appreciated, Jim Horne Mainframe Services jim.s.ho...@lowes.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Tuesday, September 17, 2019 6:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Can you update WLM via a batch program? *EXTERNAL SENDER* XML perchance? If so there’s a lot one could do with that... :-) ... If the plane I was about to get on didn’t see me with my elbows (and knees) up round my ears I’d rustle up a proof of concept. :-) Cheers, Martin Sent from my iPad > On 17 Sep 2019, at 08:57, Sean Gleann wrote: > > Correction - the input is *probably* not ISPF tables (having cross-checked > with other ISPTLIBs that I have available). > Nevertheless, they are 'encoded' - not straight text... > > Sean > >> On Tue, 17 Sep 2019 at 08:06, Sean Gleann wrote: >> >> Having been in the same position as Jim, I asked practically the same >> question here, a couple of years back. >> Then, the basic answer was 'No', so I was highly pleased to see that some >> sort of progress had been made on this. >> I should have known better. >> IWMINSTL is a great starting point, but it's input is a series of >> ISPF (?) >> tables. >> How do you create those from scratch in the first place? >> >> Sean >> >>> On Mon, 16 Sep 2019 at 23:39, Salva Carrasco wrote: >>> >>> Check IWMINSTL at SYS1.SAMPLIB. >>> >>> >>> -- 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN NOTICE: All information in and attached to the e-mails below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message electronic, paper, or otherwise. By transmitting documents via this email: Users, Customers, Suppliers and Vendors collectively acknowledge and agree the transmittal of information via email is voluntary, is offered as a convenience, and is not a secured method of communication; Not to transmit any payment information E.G. credit card, debit card, checking account, wire transfer information, passwords, or sensitive and personal information E.G. Driver's license, DOB, social security, or any other information the user wishes to remain confidential; To transmit only non-confide
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
Control block values that exempt 522 Timeouts
Hi, I understand that address spaces can be made exempt from 522 timeouts if there is a particular value in one of three control blocks. If I have it correct they are: 1) The JSTL is 86400 seconds (Comes from TIME=1440 on Job card?) 2) The ASCBTOFF bit in the ASCBRCTF is set 3) The SWTL contains the magic number x'0D286880' What can I learn from one or more of those values being set? For example, which z/OS or application components update those control blocks or cause them to be updated? Thanks in advance for any insight! Kind regards, Lindy P.S. I think I asked some years ago where they magic number x'0D286880' comes from. I forgot. I think it was historical, and maybe counted in timerons or something similar. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
C headers in z/OS 2.4
You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
Peter, A big thx, well done IBM. Scott On Tue, Sep 17, 2019 at 9:21 AM Peter Relson wrote: > You might have seen mention in the announce that z/OS 2.4 is shipping more > C headers. > > The eventual goal is to do the mappings in SYS1.MACLIB and many in > SYS1.MODGEN, particularly the ones that have programming interfaces. > z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core > elements produce. > > The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and > within the file system (in a new subdirectory, /usr/include/zos). > The name of the header is the same as the name of the maclib/modgen macro > (plus the ".h" suffix when in the file system). > > There is no explicit documentation for any of the header files, including > no list of what is being provided. They are expected to be analogous to > the existing maclib/modgen mappings and the documentation for those > maclib/modgen mappings applies (allowing for differences in syntax, of > course). Once you have access to a z/OS 2.4 system, you can look. Here is > the list of mappings that are not SMF being provided in 2.4: > csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp > iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc > iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp > iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt > iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb > ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa > ihasrb ihastcb ikjrb ikjtcb > > We do intend to document (this will make its way into the 2.4 publications > in some not too distant refresh) that the way to get the mappings for SMF > is to include header file ifacsmfr. Unlike assembler IFASMFR for which you > give it an operand that indicates which single SMF record type to expand, > ifacsmfr expands all the headers under its umbrella (and of course your > program will use whichever of the struct's it needs). In general, those > headers will be the analogs of the ones that IFASMFR makes available in > assembler. But note that a subsystem with its own SMF record in general > does not get expanded by IFASMFR and will not be expanded by ifacsmfr. > > We are looking for help in deciding which mappings/headers to do next. > Feel free to send me an email with your group's (or personal) > recommendations. > Mappings related to system exit routines seem like they might be of high > interest, in order to write the exit routine in metal C. > > Peter Relson > z/OS Core Technology Design > relson (at) us.ibm.com > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
Thank you @Peter for spearheading this. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, September 17, 2019 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C headers in z/OS 2.4 You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- 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: C headers in z/OS 2.4
Agreed! Good job Peter and it's great to see that it made it into the file system :) On 2019-09-17 10:09 PM, Charles Mills wrote: Thank you @Peter for spearheading this. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, September 17, 2019 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C headers in z/OS 2.4 You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- 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: C headers in z/OS 2.4
Thanks Peter! Quality stuff! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Control block values that exempt 522 Timeouts
Well, if that represents 24 hours then 2555 is 1 second. On Tue, Sep 17, 2019 at 8:09 AM Lindy Mayfield wrote: > > Hi, > > I understand that address spaces can be made exempt from 522 timeouts if > there is a particular value in one of three control blocks. If I have it > correct they are: > > 1) The JSTL is 86400 seconds (Comes from TIME=1440 on Job card?) > 2) The ASCBTOFF bit in the ASCBRCTF is set > 3) The SWTL contains the magic number x'0D286880' > > What can I learn from one or more of those values being set? For example, > which z/OS or application components update those control blocks or cause > them to be updated? > > Thanks in advance for any insight! > > Kind regards, > Lindy > > P.S. I think I asked some years ago where they magic number x'0D286880' > comes from. I forgot. I think it was historical, and maybe counted in > timerons or something similar. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
Peter Relson has given me permission to post a question I asked him privately and his answer to that question. Q: Will IBM make its tool chain for converting DSECT's to C headers available to customers? That would be a very welcome enhancement, especially if it is made part of the base system, or at least as part of the HLASM tool set (as is EDCDSECT today). Then customers with their own assembler DSECT's would be able to convert them to C headers in a supported way. A: I doubt that anyone would agree to provide as part of the product a parameter list mapping for a service for which a macro interface is provided. When a macro is provided, the interface to the service is the macro. You are expected to use that macro by whatever means is available to you. I'd have guessed that you have already created C headers of your own for these things. If so, why would you need "ours"? Unfortunately IBM cannot make the tool I mentioned available to anyone else, as the C header is built to correspond to the PL/X mapping and requires usage of the PL/X compiler. If you want to post your question about that, feel free to post both your question and my answer. Maybe some day IBM would consider making the PL/X compiler available to customers even if only for this specific purpose. Then it would be up to users to decide if they wanted to take their existing mappings, create a PL/X (or bilingual) analog, and then use that to create the C header. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Tuesday, September 17, 2019 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C headers in z/OS 2.4 You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
I'd rather have PL/I headers. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Tuesday, September 17, 2019 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C headers in z/OS 2.4 You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- 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: C headers in z/OS 2.4
On Tue, Sep 17, 2019 at 11:16 AM Seymour J Metz wrote: > I'd rather have PL/I headers. > Me too. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
The IBM C/C++ compiler ships with an assembler DSECT to C header conversion tool. Someone could readily write a similar tool for PL/I.CharlesSent from a mobile; please excuse the brevity. Original message From: John McKown Date: 9/17/19 5:29 PM (GMT+00:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C headers in z/OS 2.4 On Tue, Sep 17, 2019 at 11:16 AM Seymour J Metz wrote:> I'd rather have PL/I headers.>Me too.>> --> Shmuel (Seymour J.) Metz> http://mason.gmu.edu/~smetz3>--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: C headers in z/OS 2.4
On Tue, 17 Sep 2019 16:16:31 +, Seymour J Metz wrote: >I'd rather have PL/I headers. > Many macros contain PL/S alternatives. Are these PL/I compatible? From: Peter Relson Sent: Tuesday, September 17, 2019 9:20 AM >The eventual goal is to do the mappings in SYS1.MACLIB and many in >SYS1.MODGEN, particularly the ones that have programming interfaces. >z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core >elements produce. > Good. This relieves the need for customers and ISVs to generate these by filtering SYSPRINT or ASMADATA. To what extent can these be generated by filtering the PL/S alternative sections? >The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and >within the file system (in a new subdirectory, /usr/include/zos). >The name of the header is the same as the name of the maclib/modgen macro >(plus the ".h" suffix when in the file system). > Couldn't this duplication and its attendant maintenance and testing burden and risk be reduced by suitable use of the -I option or by making /usr/include/zos part of the conventional search order, perhaps in startup.mk? "I see everything twice" -- Catch-22 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
WRT your first question, I would say "somewhat compatible". There are enough
similarities to make rough translations possible, EXCEPT that many macros only
have this kind of PL/S expansion published:
(From DCBD macro in SYS1.MACLIB):
**/%DCBD: MACRO KEYS(DATASET_ORG,DEVICE_TYPE,BASED_VALUE);
* ANS('?' || MACLABEL || ' DCBDP ' || MACKEYS || ';') SKIP;
* %END DCBD;
And of course the source of the PL/S macro DCBDP is not supplied anywhere,
possibly to prevent MACLIB bloat from the size of the actual PL/S macro text.
Even macros that have explicit PL/S mappings in the published macro text have
macro-conditional logic that often depends on global PL/S macro variables being
set to some value or other, with no plain indication of where or how those
macro variables need to be set / generated, though sometimes their meaning and
values can be inferred from the assembler source.
OTOH a library of PL/S ADATA mappings that matched the PL/S macro expansions
might be more easily translated to multiple language header definitions (COBOL
anyone? Maybe Java or Python?) by a replacement utility for EDCDSECT, which has
not proven to be nearly as useful as intended. A potential business
opportunity for an interested and well-funded ISV who could afford the no doubt
substantial NDA cost of acquiring PL/S ADATA documentation.
Not gonna happen in our lifetimes of course, but it is an interesting thought.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Tuesday, September 17, 2019 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C headers in z/OS 2.4
On Tue, 17 Sep 2019 16:16:31 +, Seymour J Metz wrote:
>I'd rather have PL/I headers.
>
Many macros contain PL/S alternatives. Are these PL/I compatible?
From: Peter Relson
Sent: Tuesday, September 17, 2019 9:20 AM
>The eventual goal is to do the mappings in SYS1.MACLIB and many in
>SYS1.MODGEN, particularly the ones that have programming interfaces.
>z/OS 2.4 starts small, concentrating on the SMF records that the z/OS
>core elements produce.
>
Good. This relieves the need for customers and ISVs to generate these by
filtering SYSPRINT or ASMADATA. To what extent can these be generated by
filtering the PL/S alternative sections?
>The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and
>within the file system (in a new subdirectory, /usr/include/zos).
>The name of the header is the same as the name of the maclib/modgen
>macro (plus the ".h" suffix when in the file system).
>
Couldn't this duplication and its attendant maintenance and testing burden and
risk be reduced by suitable use of the -I option or by making /usr/include/zos
part of the conventional search order, perhaps in startup.mk?
"I see everything twice" -- Catch-22
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers in z/OS 2.4
PL/S has several extensions, so while most of the declare statements would map over easily, some would be more difficult. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, September 17, 2019 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C headers in z/OS 2.4 On Tue, 17 Sep 2019 16:16:31 +, Seymour J Metz wrote: >I'd rather have PL/I headers. > Many macros contain PL/S alternatives. Are these PL/I compatible? From: Peter Relson Sent: Tuesday, September 17, 2019 9:20 AM >The eventual goal is to do the mappings in SYS1.MACLIB and many in >SYS1.MODGEN, particularly the ones that have programming interfaces. >z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core >elements produce. > Good. This relieves the need for customers and ISVs to generate these by filtering SYSPRINT or ASMADATA. To what extent can these be generated by filtering the PL/S alternative sections? >The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and >within the file system (in a new subdirectory, /usr/include/zos). >The name of the header is the same as the name of the maclib/modgen macro >(plus the ".h" suffix when in the file system). > Couldn't this duplication and its attendant maintenance and testing burden and risk be reduced by suitable use of the -I option or by making /usr/include/zos part of the conventional search order, perhaps in startup.mk? "I see everything twice" -- Catch-22 -- gil -- 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: Considering Bypassing ERROR HOLD for OA58037
Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) LRS's > VPSIP product. If you are running VPSIP, like several of our sites, then you > are likely aware of the issues that this whole string of aparas has caused. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance&d=DwIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA&s=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww&e= > > If you are not using VPSIP then it probably won't effect you either way to > bypass the hold. > > Brian > > -- > 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: Considering Bypassing ERROR HOLD for OA58037
That is a LONG*** pe chain to restore/re-apply -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Tuesday, September 17, 2019 1:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Considering Bypassing ERROR HOLD for OA58037 Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) > LRS's VPSIP product. If you are running VPSIP, like several of our > sites, then you are likely aware of the issues that this whole string of > aparas has caused. > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-&data=02%7C01%7Callan > .staller%40HCL.COM%7C86f7d61528b346b4d1da08d73b9f2984%7C189de737c93a4f > 5a8b686f4ca9941912%7C0%7C1%7C637043427118885256&sdata=oli6MDONl2sj > 4xIwtOJ2Jkl5YzCyWwOJtfmqF2lpY7o%3D&reserved=0 > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance&d=DwIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA&s=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww&e= > > If you are not using VPSIP then it probably won't effect you either > way to bypass the hold. > > Brian > > -- > 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 ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DAE Mystery
I manually stopped DAE on all systems so someone could remove an entry from the shared DAE dataset. Shortly thereafter it started itself, and I can't figure out how or who/what did it. 14:31:35.18 *ROUTEOD 0290 T DAE=01 0290 IEE252I MEMBER ADYSET01 FOUND IN SYS1.DEVL.PARMLIB 0290 IEF196I IEF285I SYSP.DAESHARE 0290 IEF196I IEF285I VOL SER NOS= SYS023. *ROUTEOD 0090 ADY015I DAE STOP PROCESSING IS COMPLETE 794 . 14:33:20.77 INTERNAL 0090 ADY012I THE FOLLOWING DAE OPTIONS ARE IN EFFECT: 801 801 0090 START 801 0090 SVCDUMP = NOTIFY(3,30) MATCH UPDATE SUPPRESSALL 801 0090 SYSMDUMP = MATCH UPDATE 801 0090 RECORDS = 400 801 0090 DSN = SYSP.DAESHARE 801 0090 SHARE= DSN OPTIONS 801 0090 GLOBAL = DSN OPTIONS Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
Thank you, and also Dave Jousma who sent similar (same?) code privately. I suspect my MXG level (V2929) needs some updating before I can run it. I ordered 37.06 yesterday. Will install (or use the tricks to run mixed levels) today. I may try the techniques to run directly off of SMF and build PDB on the fly also. And, thank you for the offer, Andrew Rowley. But, we've already paid Barry and I don't like to do free trial stuff when I know I'll never be buying the product. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bruce Hewson > Sent: Monday, September 16, 2019 9:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > On Mon, 16 Sep 2019 23:15:40 +, Gibney, Dave > wrote: > > >Well, I did do this. But, I am not sure it was worth it. The > ZOSMIGV2R3_NEXT_VSM_USERKEYCOMM check only tells me what I > already knew. That I have some address spaces using user key common. I > had hoped it went further and identified them. I know one for sure. > > > >Yes, I do see the info on interpreting SMF30_UserKeyCsaUsage and > SMF30_UserKeyCadsUsage. So, I guess my next step is to see if my MXG > level has this support, or do I need to update (in part, or fully) MXG. > > > > I forget who I got this code from, one of the list members websites:- > > > // EXPORT SYMLIST=* > //* > // SET DATE='06/01/2019' <<== SET Search Date > // SET SYSN=SYS1 <<== SET SYSTEM NAME > // SET SMFID=PRD1 <<== SET SMF ID > - - - - - - - - - - - - - - - - - - 63 Line(s) not > Displayed > //SYSINDD *,SYMBOLS=EXECSYS > > %INCLUDE SOURCLIB(TYPE30,SMFINTRV); > > DATA LIMIT; >SET PDB.SMFINTRV ; >IF CPUTM NE . ; > IF SMF30_RAXFLAGS='00'X THEN DELETE; > IF SMF30_RAXFLAGS='40'X THEN DELETE; > IF SMF30_RAXFLAGS='80'X THEN DELETE; > /* 1000 = 80 = AUDIT ON */ > /* 1001 = 90 = CHANGE KEY*/ > /* 1010 = A0 = CADS USAGE*/ > /* 1011 = B0 = CADS+CHANGE KEY */ > /* 1100 = C0 = CSA USAGE */ > /* 1101 = D0 = CSA+CHANGE KEY*/ > /* 1110 = E0 = CSA+CADS */ > /* = F0 = CSA+CADS+CHANGEKEY*/ > IF SMF30_RAXFLAGS='90'X THEN USERKEY='CHGKEY' ; > IF SMF30_RAXFLAGS='A0'X THEN USERKEY='CADS' ; > IF SMF30_RAXFLAGS='B0'X THEN USERKEY='CADS+CHGKEY' ; > IF SMF30_RAXFLAGS='C0'X THEN USERKEY='CSA' ; > IF SMF30_RAXFLAGS='D0'X THEN USERKEY='CSA+CHGKEY' ; > IF SMF30_RAXFLAGS='E0'X THEN USERKEY='CSA+CADS' ; > IF SMF30_RAXFLAGS='F0'X THEN USERKEY='CSA+CADS+CHGKEY' ; >RUN; > > PROC MEANS DATA=LIMIT SUM NWAY MISSING NONOBS PRINT; > CLASS SYSTEM JOB PROGRAM SMF30_RAXFLAGS USERKEY; > VAR CPUTM; > OUTPUT OUT=POSTAV1(DROP=_TYPE_) SUM = GCPU ; > > OPTIONS LS=80 ; > > PROC PRINTTO FILE=USERKEY ; > > PROC PRINT DATA=POSTAV1; >TITLE1 ' ' ; >TITLE2 'SMF30_USERKEY &SYSN. &DATE.'; >ID SYSTEM PROGRAM SMF30_RAXFLAGS USERKEY ; >VAR JOB; >RUN; > /* > > -- > 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: Considering Bypassing ERROR HOLD for OA58037
I'm getting confused by this thread. I thought I recalled you had said the PTF you were bypassing was for S16E? All of those DEB Check PTF's are in support of the changes needed for OSPROTECT. And yes, we ran into the S16E issue on certain application datasets, only in a blue moon. Eventually, IBM got it all figured out, and the problem is fixed. I do recall they said they saw the problem in VPS, where VPS was opening/closing an IMAGELIB many times. But none of this had anything to do with USERKEY CSA.That’s an entirely different animal, and needs to be rectified before going V2.4. I suspect you won't have much luck backing these PTF's off because they reach out and touch a lot of different modules. The only real option would be if you have a known complete backup of the entire SMPE environment *before* the application of any of these PTF's. Incidentally, we do have UA95897 applied for over a year now, and have not run into the scenario that OA58037 describes. Seems like a pretty small window of problem, and even then, it was on a task/job that was being cancelled to begin with. I'd probably open ticket with IBM on that APAR, and ask an opinion (which they may not give). _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Tuesday, September 17, 2019 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Considering Bypassing ERROR HOLD for OA58037 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, I do run VPS/TCPIP Key Product Name --- 012 DRS 001 VPS 004 VPS/PCL 002 VPS/TCPIP z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with the error bypass. We don't have many printers, but they are all TCP/IP network attached. So far I've not experienced (or at least not noticed) any of the errors in the link. Since I found the Health Check disappointing, I could consider backing the bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA data also part of one or more of the PTFs in this chain? There were 27 that went on with the bypass and selecting UA94607. (And 31 others that had dependencies satisfied :) ) Only running them in the sandboxes for now. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Monday, September 16, 2019 9:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > That's part of a pretty long comedy of errors that apply to (mostly) > LRS's VPSIP product. If you are running VPSIP, like several of our > sites, then you are likely aware of the issues that this whole string of > aparas has caused. > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > 2Dfunction-2Dlist- > 2Dmaintenance&d=DwIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > b- > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=RfHnql3CpaS3KFsgCx5LqRORoZTp > 07SIADw0RnXZmcA&s=4Cib0hikGVj- > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww&e= > > If you are not using VPSIP then it probably won't effect you either > way to bypass the hold. > > Brian > > -- > 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 **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
On Tue, 17 Sep 2019 19:00:04 +, Jousma, David wrote: >I suspect you won't have much luck backing these PTF's off because they reach >out and touch a lot of different modules. The only real option would be if >you have a known complete backup of the entire SMPE environment *before* the >application of any of these PTF's. Another reason to always clone target zones before applying maintenance. Here is another possible way to restore the PTFs that I have considered, but haven't yet had a need to try. 1. Clone your distribution zone and relate the cloned zone to your target zone. 2. Accept everything that is keeping you from restoring the PTFs in your cloned zone. 3. Restore the PTFs. 4. Relate the target zone back to the original distribution zone. Actually, if I was doing it, I would clone both the target and distribution zones. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
Incidentally, we do have UA95897 applied for over a year now, and have not run into the scenario that OA58037 describes. Seems like a pretty small window of problem, and even then, it was on a task/job that was being cancelled to begin with. I'd probably open ticket with IBM on that APAR, and ask an opinion (which they may not give). The above is what IBM told me as well. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Considering Bypassing ERROR HOLD for OA58037
First, I consider many things. That doesn't mean I will ultimately decide to do them. If I consider further, I will of course start with RESTORE CHECK and evaluate the complexity, etc. Second, I ran ACCEPT for everything that would accept clean before I started this path. Applied all that was RSU* IBM*, or HIPER and not in error as a separate run before I did the bypass. So, I do a. Have back-ups of the state after ACCEPT and before APPLY(s) and b. It's a total of less that 100 PTFs total in the full difference between RSU1903 (prior and ACCEPTED state) and RSU1908 +error, now running in my sandboxes. But, before I do anything in the way of backing out or going forward I will look further into the likelihood of this actually adversely effecting my systems. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Tuesday, September 17, 2019 12:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > On Tue, 17 Sep 2019 19:00:04 +, Jousma, David > wrote: > > >I suspect you won't have much luck backing these PTF's off because they > reach out and touch a lot of different modules. The only real option would > be if you have a known complete backup of the entire SMPE environment > *before* the application of any of these PTF's. > > Another reason to always clone target zones before applying maintenance. > > Here is another possible way to restore the PTFs that I have considered, but > haven't yet had a need to try. > > 1. Clone your distribution zone and relate the cloned zone to your target > zone. > 2. Accept everything that is keeping you from restoring the PTFs in your > cloned zone. > 3. Restore the PTFs. > 4. Relate the target zone back to the original distribution zone. > > Actually, if I was doing it, I would clone both the target and distribution > zones. > > -- > Tom Marchant > > -- > 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: Considering Bypassing ERROR HOLD for OA58037
The only reason I considered the bypass was because the PE chain was preventing the APPLY of the PTFs to aid detecting and migrating from USERCSA. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Tuesday, September 17, 2019 12:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > I'm getting confused by this thread. I thought I recalled you had said the > PTF > you were bypassing was for S16E? All of those DEB Check PTF's are in > support of the changes needed for OSPROTECT. And yes, we ran into the > S16E issue on certain application datasets, only in a blue moon. Eventually, > IBM got it all figured out, and the problem is fixed. I do recall they said > they > saw the problem in VPS, where VPS was opening/closing an IMAGELIB many > times. > > But none of this had anything to do with USERKEY CSA.That’s an entirely > different animal, and needs to be rectified before going V2.4. > > I suspect you won't have much luck backing these PTF's off because they > reach out and touch a lot of different modules. The only real option would > be if you have a known complete backup of the entire SMPE environment > *before* the application of any of these PTF's. > > Incidentally, we do have UA95897 applied for over a year now, and have not > run into the scenario that OA58037 describes. Seems like a pretty small > window of problem, and even then, it was on a task/job that was being > cancelled to begin with. I'd probably open ticket with IBM on that APAR, and > ask an opinion (which they may not give). > > __ > ___ > Dave Jousma > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, > MI > 49546 > 616.653.8429 | fax: 616.653.2717 > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Tuesday, September 17, 2019 2:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Well, I do run VPS/TCPIP > Key Product Name > --- > 012 DRS > 001 VPS > 004 VPS/PCL > 002 VPS/TCPIP > > z/OS 2.1 at RSU1903 (RSU1908 included in the set that could come on with > the error bypass. > We don't have many printers, but they are all TCP/IP network attached. So > far I've not experienced (or at least not noticed) any of the errors in the > link. > > Since I found the Health Check disappointing, I could consider backing the > bypassed PTFs out. I haven't looked. Are the SMF fields with the USERCSA > data also part of one or more of the PTFs in this chain? There were 27 that > went on with the bypass and selecting UA94607. (And 31 others that had > dependencies satisfied :) ) > > Only running them in the sandboxes for now. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Brian Westerman > > Sent: Monday, September 16, 2019 9:22 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > > > That's part of a pretty long comedy of errors that apply to (mostly) > > LRS's VPSIP product. If you are running VPSIP, like several of our > > sites, then you are likely aware of the issues that this whole string of > > aparas > has caused. > > > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ibm.com_support_pages_debchk-2Ddeb-2Dlock-2Dnew- > > 2Dfunction-2Dlist- > > > 2Dmaintenance&d=DwIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > > b- > > > Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=RfHnql3CpaS3KFsgCx5LqRORoZTp > > 07SIADw0RnXZmcA&s=4Cib0hikGVj- > > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww&e= > > > > If you are not using VPSIP then it probably won't effect you either > > way to bypass the hold. > > > > Brian > > > > -- > > 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 **CAUTION > EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any > manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibi
Re: DAE Mystery
Automatic restart in your WLM? On Tue, Sep 17, 2019, 13:48 Mark Jacobs < 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > I manually stopped DAE on all systems so someone could remove an entry > from the shared DAE dataset. Shortly thereafter it started itself, and I > can't figure out how or who/what did it. > > 14:31:35.18 *ROUTEOD 0290 T DAE=01 > 0290 IEE252I MEMBER ADYSET01 FOUND IN SYS1.DEVL.PARMLIB > 0290 IEF196I IEF285I SYSP.DAESHARE > 0290 IEF196I IEF285I VOL SER NOS= SYS023. > *ROUTEOD 0090 ADY015I DAE STOP PROCESSING IS COMPLETE 794 > . > 14:33:20.77 INTERNAL 0090 ADY012I THE FOLLOWING DAE OPTIONS ARE IN > EFFECT: 801 > 801 0090 START > 801 0090 SVCDUMP = NOTIFY(3,30) MATCH UPDATE SUPPRESSALL > 801 0090 SYSMDUMP = MATCH UPDATE > 801 0090 RECORDS = 400 > 801 0090 DSN = SYSP.DAESHARE > 801 0090 SHARE= DSN OPTIONS > 801 0090 GLOBAL = DSN OPTIONS > > Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted > email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > -- > 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
Question on LDAPSRV running on z/OS
Cross-posted from RACF list because I'm getting desperate. Hello list, I hope this is the right place for this. We're using LDAPSRV running on z/OS 2.2 to take login requests from a browser front-end and authenticate them against RACF. We just implemented mixed case passwords last night and it appears that LDAP is converting the passwords it gets to upper case before sending them on to RACF for validation, so logons are failing for people who have changed their passwords with the mixed case support. Is there a parameter in the LDAP config files to pass passwords through LDAP as-is instead of upper-casing them or am I looking in the wrong place. LDAP is a black box to me. AFAIK, logons are still working just fine for those who haven't changed passwords, only those who have. TIA, Rex The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I see a need for general conversion of mappings was Re: C headers in z/OS 2.4
[Default] On 17 Sep 2019 06:20:49 -0700, in bit.listserv.ibm-main rel...@us.ibm.com (Peter Relson) wrote: >You might have seen mention in the announce that z/OS 2.4 is shipping more >C headers. > >The eventual goal is to do the mappings in SYS1.MACLIB and many in >SYS1.MODGEN, particularly the ones that have programming interfaces. >z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core >elements produce. This is nice but when I was still doing system type coding I wanted a tool that converts Assembler mappings to COBOL or PL1. If people currently in the field would push for getting the BIT, BINARY-Character, the true binary, IEEE binary and decimal floating point usages that are in the current COBOL standard, then these mappings would be even more valuable. One of the justifications for making the effort is that COBOL should be able to access all data types that can be stored in DB2. I write this as someone who has used COBOL to get program and data set usage from SMF data. Clark Morris > >The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and >within the file system (in a new subdirectory, /usr/include/zos). >The name of the header is the same as the name of the maclib/modgen macro >(plus the ".h" suffix when in the file system). > >There is no explicit documentation for any of the header files, including >no list of what is being provided. They are expected to be analogous to >the existing maclib/modgen mappings and the documentation for those >maclib/modgen mappings applies (allowing for differences in syntax, of >course). Once you have access to a z/OS 2.4 system, you can look. Here is >the list of mappings that are not SMF being provided in 2.4: >csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp >iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc >iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp >iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt >iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb >ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa >ihasrb ihastcb ikjrb ikjtcb > >We do intend to document (this will make its way into the 2.4 publications >in some not too distant refresh) that the way to get the mappings for SMF >is to include header file ifacsmfr. Unlike assembler IFASMFR for which you >give it an operand that indicates which single SMF record type to expand, >ifacsmfr expands all the headers under its umbrella (and of course your >program will use whichever of the struct's it needs). In general, those >headers will be the analogs of the ones that IFASMFR makes available in >assembler. But note that a subsystem with its own SMF record in general >does not get expanded by IFASMFR and will not be expanded by ifacsmfr. > >We are looking for help in deciding which mappings/headers to do next. >Feel free to send me an email with your group's (or personal) >recommendations. >Mappings related to system exit routines seem like they might be of high >interest, in order to write the exit routine in metal C. > >Peter Relson >z/OS Core Technology Design >relson (at) us.ibm.com > > >-- >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: C headers in z/OS 2.4
On 2019-09-18 12:16 AM, Seymour J Metz wrote: I'd rather have PL/I headers. I don't think IBM could justify doing any work for PL/I because there isn't a compelling requirement from customers or vendors to use PL/I for systems level code. On the other hand, Metal/C is taking off very quickly and is being used by vendors to write infrastructure and products. The company I work for only uses Metal/C for new code. Assembler and PL/X, while still very important, are legacy languages. Some products that were originally written in PL/X have started to use Metal/C for new code. The reason for this is obvious. Assembler and PL/X programmers are disappearing fast and attracting good young talent to replace them is difficult. We have some brilliant young engineers who are writing systems level code in C. Retaining them would be difficult if they had to work primarily in a legacy language. These guys all learn C at college so we just have to teach them z/OS. The smart ones pick it up quickly. We use Metal/C to write cross-memory servers, pc-ss, pc-cp, AR-mode stuff etc, etc. A lot of that code has been open sourced https://github.com/zowe/zowe-common-c -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Tuesday, September 17, 2019 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: C headers in z/OS 2.4 You might have seen mention in the announce that z/OS 2.4 is shipping more C headers. The eventual goal is to do the mappings in SYS1.MACLIB and many in SYS1.MODGEN, particularly the ones that have programming interfaces. z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core elements produce. The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and within the file system (in a new subdirectory, /usr/include/zos). The name of the header is the same as the name of the maclib/modgen macro (plus the ".h" suffix when in the file system). There is no explicit documentation for any of the header files, including no list of what is being provided. They are expected to be analogous to the existing maclib/modgen mappings and the documentation for those maclib/modgen mappings applies (allowing for differences in syntax, of course). Once you have access to a z/OS 2.4 system, you can look. Here is the list of mappings that are not SMF being provided in 2.4: csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa ihasrb ihastcb ikjrb ikjtcb We do intend to document (this will make its way into the 2.4 publications in some not too distant refresh) that the way to get the mappings for SMF is to include header file ifacsmfr. Unlike assembler IFASMFR for which you give it an operand that indicates which single SMF record type to expand, ifacsmfr expands all the headers under its umbrella (and of course your program will use whichever of the struct's it needs). In general, those headers will be the analogs of the ones that IFASMFR makes available in assembler. But note that a subsystem with its own SMF record in general does not get expanded by IFASMFR and will not be expanded by ifacsmfr. We are looking for help in deciding which mappings/headers to do next. Feel free to send me an email with your group's (or personal) recommendations. Mappings related to system exit routines seem like they might be of high interest, in order to write the exit routine in metal C. Peter Relson z/OS Core Technology Design relson (at) us.ibm.com -- 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: Considering Bypassing ERROR HOLD for OA58037
Hello Dave, yes you do need a newer level of MXG:- Change 36.188 Support for new Bit 4 of SMF30_RAXFLAGS and creation of BUILD005 these new bit-level variables with explanation in label BUIL3005 SMF30_RAXFLAG0='RAX0*USERKEY*COMMON*AUDIT*ENABLED?' VMAC30 SMF30_RAXFLAG1='RAX1*USERKEY*COMON*AUDIT*USAGE?' Oct 16, 2018 SMF30_RAXFLAG2='RAX2*USERKEY*CADS*USAGE?' SMF30_RAXFLAG3='RAX3*USERKEY*CHANGE*KEY*USAGE?' SMF30_RAXFLAG4='RAX4*USERKEY*RUCSA*USAGE?' that are added to TYPE30_4/TYPE30_5/TYPE30_6/TYPE30_V and PDB.STEPS for BUILDPDB (JES2) and BUILDPD3 (JES3). (Variable RAXFLAGS was added in MXG 35.09.) Thanks to MP Welch, Bank of America, USA. Change 36.175 Support for SMF 30 User Key CSA Audit Enhancements adds VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and Sep 28, 2018 the TYPE30_5 datasets. Change 35.212 (MXG 35.09+) Sep Feb 28, 2018 2017 made the code change but the change text was still Sep 20, 2018 a "Reserved Change" until Feb 28, 2018, but had the old 35.212 Change Number, so it was only in CHANGESS member. The IBM Record Change was made by APAR OA53355, but will only be needed thru z/OS 2.3, as User Key Common Storage usage support ends there. This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM. These APARs required no additional code changes: OA53434 Corrects IBM macros SMF30RPS,SMF30SDS lengths not field lengths so it has no impact on MXG. OA53289 Corrects value of SMF30HVR from zero to valid. OA45767 APAR that added the extra triplet caused OA53434 See Change 36.188 which added new bit-level variables. Change 35.212 Support for SMF 30 User Key CSA Audit Enhancements adds VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and Sep 28, 2017 the TYPE30_5 datasets. This code change has been in MXG Feb 28, 2018 35.09 and later, but this change text replaced previous "Reserved Change" on Feb 28, 2018. This field was added by APAR OA53355, but will only be needed thru z/OS 2.3, as User Key Common Storage usage support ends there. This is Health Check ZOSMIGV22R3_NEXT_VSM_USERKEYCOMM. These APARs required no additional code changes: OA53434 Corrects ASM DSECT Lengths, no MXG impact OA53289 Corrects value of SMF30HVR from zero to valid. OA45767 APAR that added the extra triplet caused OA53434 On Tue, 17 Sep 2019 18:58:50 +, Gibney, Dave wrote: >Thank you, and also Dave Jousma who sent similar (same?) code privately. >I suspect my MXG level (V2929) needs some updating before I can run it. I >ordered 37.06 yesterday. Will install (or use the tricks to run mixed levels) >today. >I may try the techniques to run directly off of SMF and build PDB on the fly >also. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
