Re: Description of the format of a SYSUDUMP
On Thu, 19 Sep 2019 01:54:50 +0100, CM Poncelet wrote: >The before/after addresses (on the LHS in the SYSUDUMP) show which >addresses of the excluded lines are "SAME AS ABOVE". > Yes, but the question is, if N lines are identified as excluded, does that mean the single previous line was repeated N times or that the previous N lines were repeated once? The former is rational, but is IBM constrained to be rational? >On 18/09/2019 21:48, Tony Harminc wrote: >> >> What I've wished for for decades is that if there is just one repeated >> line, they not do the "same as above" processing. The message saves no >> space and just distracts from the flow when reading. >> RFE? (I suspect there may be an argument against complicating such low-level system code. Although within my memory, SYSUDUMP stopped showing lower-case characters as dots. But that might have changed only a translate table.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
The before/after addresses (on the LHS in the SYSUDUMP) show which addresses of the excluded lines are "SAME AS ABOVE". CP On 18/09/2019 21:48, Tony Harminc wrote: > On Wed, 18 Sep 2019 at 13:40, Thomas David Rivers wrote: > >> My particular question is the >> >>LINES - SAME AS ABOVE >> >> in a memory dump. Does that mean the the single line (of 32-bytes) just >> before this line is copied as many times to fill in the space between >> and > Yes - quite definitely. > > What I've wished for for decades is that if there is just one repeated > line, they not do the "same as above" processing. The message saves no > space and just distracts from the flow when reading. > > Tony H. > > -- > 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: Description of the format of a SYSUDUMP
On Wed, 18 Sep 2019 16:48:18 -0400, Tony Harminc wrote: >> >>LINES - SAME AS ABOVE >> >> in a memory dump. Does that mean the the single line (of 32-bytes) just >> before this line is copied as many times to fill in the space between >> and > >Yes - quite definitely. > >What I've wished for for decades is that if there is just one repeated >line, they not do the "same as above" processing. The message saves no >space and just distracts from the flow when reading. > Gee, they'd need to buffer an additional line to implement that logic. (I know, it could be done with a one-bit flag. If they were so clever.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Description of the format of a SYSUDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Wednesday, September 18, 2019 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Description of the format of a SYSUDUMP On Wed, 18 Sep 2019 at 13:40, Thomas David Rivers wrote: > My particular question is the > >LINES - SAME AS ABOVE > > in a memory dump. Does that mean the the single line (of 32-bytes) > just before this line is copied as many times to fill in the space > between and Yes - quite definitely. What I've wished for for decades is that if there is just one repeated line, they not do the "same as above" processing. The message saves no space and just distracts from the flow when reading. Tony H. -- Tony, Could IBM have done this way back in the days of chain printers to speed up printing? Waiting for the chains to spin around just to print a bunch of zeros would take longer than printing "same as above". 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
Another IBM Mainframe bites the dust....
Hi All, After almost 40 years, OppenheimerFunds (now Invesco), have shut down our Mainframe. Not sure who’s keeping the list, but wanted to share the info. Thanks! BobL Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on LDAPSRV running on z/OS
We are doing the same. There was no LDAP server changes we needed to do to make this happen. My first guess would be your web front-end is uppercasing it before sending it to LDAP. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Tuesday, September 17, 2019 1:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Human data compaction (was: Description ... SYSUDUMP)
On Wed, 18 Sep 2019 16:48:18 -0400, Tony Harminc wrote: > >What I've wished for for decades is that if there is just one repeated >line, they not do the "same as above" processing. The message saves no >space and just distracts from the flow when reading. > As a novice at the sysop console I once entered D U 000-FFF then wished that the system performed some compaction of the DOES NOT EXIST lines. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
On Wed, 18 Sep 2019 15:36:14 -0400, Thomas David Rivers wrote: > >I guess I'm asking "what is the chunk of memory described in 'SAME AS >ABOVE'" ? > >Seems like a document somewhere might explain that definitively... ? > Was that the entirety of your question or just a representative example of several things that need further documentation? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
On Wed, 18 Sep 2019 at 13:40, Thomas David Rivers wrote: > My particular question is the > >LINES - SAME AS ABOVE > > in a memory dump. Does that mean the the single line (of 32-bytes) just > before this line is copied as many times to fill in the space between > and Yes - quite definitely. What I've wished for for decades is that if there is just one repeated line, they not do the "same as above" processing. The message saves no space and just distracts from the flow when reading. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
On Wed, 18 Sep 2019 15:03:38 -0500, Tom Marchant wrote: >On Wed, 18 Sep 2019 15:36:14 -0400, Thomas David Rivers wrote: > >>I guess I'm asking "what is the chunk of memory described in 'SAME AS >>ABOVE'" ? > >One line. 32 bytes. > >It is simply telling you that it has skipped printing lines that would contain >the same data content. > >It becomes obvious when you see a separate data area that shows one >line of data then several lines "same as above". > You could verify this by coding a simple program containing a data area defined as CL1024'start of area of spaces' and abend it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
On Wed, 18 Sep 2019 15:36:14 -0400, Thomas David Rivers wrote: >I guess I'm asking "what is the chunk of memory described in 'SAME AS >ABOVE'" ? One line. 32 bytes. It is simply telling you that it has skipped printing lines that would contain the same data content. It becomes obvious when you see a separate data area that shows one line of data then several lines "same as above". -- 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
I think I'm safe. Not nearly this volume and no dependency in SYS1.IMAGELIB > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Brian Westerman > Sent: Wednesday, September 18, 2019 1:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Considering Bypassing ERROR HOLD for OA58037 > > When you are only about 1/2 thorough the apar list, if you print more than > 1000 jobs before restarting VPSIP, it would abend, the jobs all needed to > use|need SYS1.IMAGELIB. Then when we got to #18 on the list, the site > could produce 84,000+ jobs (again all needed SYS1.IMAGELIB), before the > abend. Now with the next 3 apars, we appear to be able to print an > unlimited number of jobs, but we split VPSIP into two separate regions and > restart them both weekly just in case, but once we get the final 2 on, we will > probably try to go without restarting any more. > > BRian > > > On Tue, 17 Sep 2019 18:44:02 +, Gibney, Dave > wrote: > > >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=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ > >> b- > >> > Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp > >> 07SIADw0RnXZmcA=4Cib0hikGVj- > >> d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= > >> > >> 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 > > -- > 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: Description of the format of a SYSUDUMP
Gereldy wrote: Seems like I recall, at some point, a pretty precise document on the format of a SYSUDUMP - but I can't seem to find it now... if anyone remembers what that might be a pointer to that would be welcome. I guess I would describe it as the storage that would be shown in lines from to is the same as the storage just shown prior to line . Typically, all x'00's so rather than print many lines of x'00's from the dump, the LINES - is printed to inform the reader that there was a whole lot of nothin' going on for a while. That's the question though... is it just the preceeding line of 32 bytes repeated over any over, or is it the same as the entireity of the (-) bytes previosly described? I guess I'm asking "what is the chunk of memory described in 'SAME AS ABOVE'" ? Seems like a document somewhere might explain that definitively... ? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4
EDCDSECT has so many quirks it is almost useless without significant adjustments to the output. Many of the standard control blocks are defined in such a way in assembler that it is impossible to tell that they are address fields so EDCDSECT has no choice but to define them as "array of char [4]" or "array of char [8]". Don't even try to use the results from EDCDSECT for a 4-byte field with a one-byte flag area and a 3-byte address pointer. Don't ever expect a typedef of a structure instead of a plain structure to be output. Just because there is a tool doesn't always mean there is an effective tool. EDCDSECT might work just fine for application DSECT's with "normal" record-area data definitions (and I suspect that is its design point), but it is not too good at translating complex and often anachronisticly defined system control block fields. As I said in a prior reply, having PL/S ADATA of the control blocks (and documentation thereof) might permit a more robust translation to other languages. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Wednesday, September 18, 2019 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4 XLC has a DSECT conversion utility. Check the User's Guide. Many don't like its output (probably including Peter Relson), but it can be useful, maybe as a starting point. sas On Wed, Sep 18, 2019 at 1:26 PM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Hmm-m-m. Interesting idea, but I can see complex language-dependent > variable definition issues. Might be a real bear to implement in the > compilers in any shared-code-among-languages way. > > But again, "business" (profit) justification needed for IBM to devote > the resources. Maybe if they bought back fewer of their own shares to > prop up the share price they could afford a larger development staff . > . . yeah, right, like that's gonna happen. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Wednesday, September 18, 2019 12:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: I see a need for general conversion of mappings was Re: C > headers in z/OS 2.4 > > On Tue, 17 Sep 2019 22:49:10 -0300, Clark Morris wrote: > > >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. > > What if you could get the compilers to be able to process the > Assembler DSECTs? Would that be a better approach? > -- > > 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 > -- 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: ISPF panel variable
thank you for the info! Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Description of the format of a SYSUDUMP
When in a dump you see: Line 10 (as in it is all zeroes) Lines 11-20 SAME AS ABOVE that means the data in lines 11-20 are all zeroes, too. IBM did this to save paper (how many zeroes do you need to see?). It does not mean that the data was copied from Line 10. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4
XLC has a DSECT conversion utility. Check the User's Guide. Many don't like its output (probably including Peter Relson), but it can be useful, maybe as a starting point. sas On Wed, Sep 18, 2019 at 1:26 PM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Hmm-m-m. Interesting idea, but I can see complex language-dependent > variable definition issues. Might be a real bear to implement in the > compilers in any shared-code-among-languages way. > > But again, "business" (profit) justification needed for IBM to devote the > resources. Maybe if they bought back fewer of their own shares to prop up > the share price they could afford a larger development staff . . . yeah, > right, like that's gonna happen. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Tom Marchant > Sent: Wednesday, September 18, 2019 12:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: I see a need for general conversion of mappings was Re: C > headers in z/OS 2.4 > > On Tue, 17 Sep 2019 22:49:10 -0300, Clark Morris wrote: > > >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. > > What if you could get the compilers to be able to process the Assembler > DSECTs? Would that be a better approach? > -- > > 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 > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Description of the format of a SYSUDUMP
In times past it always meant the single line above. Jim Horne -Original Message- Well - I've been reading SYSUDUMPs for a long time, but I've never found a pretty precise description of the various pieces of the dump. The newer z/OS doc seems to just want to point you to IPCS, but I rather like just reading the dump. My particular question is the LINES - SAME AS ABOVE in a memory dump. Does that mean the the single line (of 32-bytes) just before this line is copied as many times to fill in the space between and , or does it mean that all of the previously described memory (for as many bytes as needed) is copied? (I think it has to mean that the single line above is copied (-)/32 times... but - I'm just checking.) Seems like I recall, at some point, a pretty precise document on the format of a SYSUDUMP - but I can't seem to find it now... if anyone remembers what that might be a pointer to that would be welcome. 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
Description of the format of a SYSUDUMP
Well - I've been reading SYSUDUMPs for a long time, but I've never found a pretty precise description of the various pieces of the dump. The newer z/OS doc seems to just want to point you to IPCS, but I rather like just reading the dump. My particular question is the LINES - SAME AS ABOVE in a memory dump. Does that mean the the single line (of 32-bytes) just before this line is copied as many times to fill in the space between and , or does it mean that all of the previously described memory (for as many bytes as needed) is copied? (I think it has to mean that the single line above is copied (-)/32 times... but - I'm just checking.) Seems like I recall, at some point, a pretty precise document on the format of a SYSUDUMP - but I can't seem to find it now... if anyone remembers what that might be a pointer to that would be welcome. - Many thanks! - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4
Hmm-m-m. Interesting idea, but I can see complex language-dependent variable definition issues. Might be a real bear to implement in the compilers in any shared-code-among-languages way. But again, "business" (profit) justification needed for IBM to devote the resources. Maybe if they bought back fewer of their own shares to prop up the share price they could afford a larger development staff . . . yeah, right, like that's gonna happen. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Wednesday, September 18, 2019 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4 On Tue, 17 Sep 2019 22:49:10 -0300, Clark Morris wrote: >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. What if you could get the compilers to be able to process the Assembler DSECTs? Would that be a better approach? -- 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: CA-1 migration to RMM
Thanks David On 9/18/19, 12:29 PMEDT, "IBM Mainframe Discussion List on behalf of Statler, David" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Try this: > > > >https://urldefense.com/v3/__http://www.redbooks.ibm.com/abstracts/sg246241.html__;!eeWmBe9sc1cuNw!Hz4oAdRGbXEnrq_gEzjfLtdQA9JhmQ4fIprpk5yXSXtUcfPQ9HhQ_izRq96kINmeEw$ > > > > >David > > > >-Original Message- > >From: IBM Mainframe Discussion List On Behalf Of >Nai, Dean > >Sent: Wednesday, September 18, 2019 11:25 AM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: CA-1 migration to RMM > > > >We are planning on migrating from CA-1 to RMM. Does anyone know where there >might be some good documentation, maybe a Redbook, or some scripts to help >with the migration. Thanks in advance. > > > >Dean Nai > > > > > > > > > >> > > > >-- > >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: CA-1 migration to RMM
Try this: http://www.redbooks.ibm.com/abstracts/sg246241.html David -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Wednesday, September 18, 2019 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CA-1 migration to RMM We are planning on migrating from CA-1 to RMM. Does anyone know where there might be some good documentation, maybe a Redbook, or some scripts to help with the migration. Thanks in advance. Dean Nai > -- 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
CA-1 migration to RMM
We are planning on migrating from CA-1 to RMM. Does anyone know where there might be some good documentation, maybe a Redbook, or some scripts to help with the migration. Thanks in advance. Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4
On Tue, 17 Sep 2019 22:49:10 -0300, Clark Morris wrote: >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. What if you could get the compilers to be able to process the Assembler DSECTs? Would that be a better approach? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF panel variable
in short, in the panel-1 body do vput xxx asis. next panel might need to do a vget in the init section, but usually if same applid, there is not need for that. ITschak On Wed, Sep 18, 2019 at 6:59 PM Bill Giannelli wrote: > I need to pass a variable (SSID) to a products ISPF panel. How do I pass > a variable form one panel to another? > thanks > Bill > > -- > 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
ISPF panel variable
I need to pass a variable (SSID) to a products ISPF panel. How do I pass a variable form one panel to another? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C headers thain z/OS 2.4
On 2019-09-18 11:31 PM, Seymour J Metz wrote: That's unfortunate, since PL/I is a much better language for such purposes. I suppose that the business case for Ada headers would be even worse. Sigh. Ada is a fine language. It comes down to popularity. There are even better languages for safety critical applications in use today https://www.rust-lang.org/ -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Tuesday, September 17, 2019 10:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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://secure-web.cisco.com/11v_88vV4bklk-5ZjhNVLQcJii6iwzPXQacehBGHDc3hRV89gyIMlR7GaJkGxmGbCjxZumo6-0c4Ux3B69tydtfDEZLRMYXJUOtsSk4t1bW4wGyTfODc5AchhektFYJRdE2dBt2a8vsKXYZ2lBPS1_oHCFENlKT-R6cDiJztW_u83x_Juhvlw6nkJKRfuKKO4IVAp3073psI4iiC3KaAuitto0Qlc1-Q5aAqQkMbHSiTi9QCIiN6ShBNwkD1_86xEWcu6bCaLyR6EsE9knD-Th4pS-h8gQIje_He37wRgaDhIEc4C7tHHCArjvxF8eL0RyRSHrQ6pN39nk0uxCwvoPAdzyekdwSpdubVU5unZnjID18oO8yyNgz5EFW-k8tQn/https%3A%2F%2Fgithub.com%2Fzowe%2Fzowe-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
Re: C headers in z/OS 2.4
On 2019-09-18 11:08 PM, Farley, Peter x23353 wrote: Agreed 100%, but in the meantime I'll take the control block translations if I can get them and write the callable service myself. Or guide the new hire who knows C to do it for me in Metal C and thereafter take ownership for maintenance down the road. You apps guys have so much utility code to do useful things it would be great if you could share it! It's not core business code so I don't see the problem with setting up a github repo for z/OS COBOL common code. Now that git is stable on z/OS you can have all your stuff in the file system and use Makefiles and/or the cob2 z/OS UNIX COBOL compiler to build your stuff. If it had legs it could event make it into Zowe at some point? An elite COBOL programmer like your Peter who also knows assembler could moderate the repo. Side question: The Wikipedia entry for "IBM PL/S" says this: "As the market for computers and software shifted away from IBM mainframes and MVS, IBM recanted and has offered the current versions of PL/S to selected customers (ISVs through the Developer Partner program.)" Is that still true? I thought I read (probably on this forum) that that offer was later rescinded? I don't think so. ISVs need a license to use PL/X and it's restricted for use only on LPARs with limited access. I don't know why as it's a programming language but yet again if IBM made it public they would have to support it which comes with a cost and risk. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Wednesday, September 18, 2019 10:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C headers in z/OS 2.4 You make a valid point but it comes down to IBM assigning resources (money) to where they can add the most value to the customer. I would argue that instead of publishing COBOL copybooks for control blocks a better API would be callable services to provide the required information, such as your JFCB example. On 2019-09-18 10:22 PM, Farley, Peter x23353 wrote: Why does everyone assume that having MACLIB/MODGEN headers in C (or any other language) is only for systems-level code and exits? There are quite a few business application programs and customer-specific utility programs out here that can and do use what you may consider "system" API's to satisfy business application needs, not system coding needs. A simple example would be using JFCB (via an assembler subroutine today) to retrieve DSNAME to store in business application records. Certainly that assembler subroutine is probably more future-proof if recoded in Metal C, but it isn't part of the operating system or used as a system exit. Don’t forget customer business application and utility program uses for these new versions of MACLIB/MODGEN data areas is all I am trying to say here. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Tuesday, September 17, 2019 10:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 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
Re: C headers thain z/OS 2.4
That's unfortunate, since PL/I is a much better language for such purposes. I suppose that the business case for Ada headers would be even worse. Sigh. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Tuesday, September 17, 2019 10:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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://secure-web.cisco.com/11v_88vV4bklk-5ZjhNVLQcJii6iwzPXQacehBGHDc3hRV89gyIMlR7GaJkGxmGbCjxZumo6-0c4Ux3B69tydtfDEZLRMYXJUOtsSk4t1bW4wGyTfODc5AchhektFYJRdE2dBt2a8vsKXYZ2lBPS1_oHCFENlKT-R6cDiJztW_u83x_Juhvlw6nkJKRfuKKO4IVAp3073psI4iiC3KaAuitto0Qlc1-Q5aAqQkMbHSiTi9QCIiN6ShBNwkD1_86xEWcu6bCaLyR6EsE9knD-Th4pS-h8gQIje_He37wRgaDhIEc4C7tHHCArjvxF8eL0RyRSHrQ6pN39nk0uxCwvoPAdzyekdwSpdubVU5unZnjID18oO8yyNgz5EFW-k8tQn/https%3A%2F%2Fgithub.com%2Fzowe%2Fzowe-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 > >
Re: C headers in z/OS 2.4
Agreed 100%, but in the meantime I'll take the control block translations if I can get them and write the callable service myself. Or guide the new hire who knows C to do it for me in Metal C and thereafter take ownership for maintenance down the road. Side question: The Wikipedia entry for "IBM PL/S" says this: "As the market for computers and software shifted away from IBM mainframes and MVS, IBM recanted and has offered the current versions of PL/S to selected customers (ISVs through the Developer Partner program.) " Is that still true? I thought I read (probably on this forum) that that offer was later rescinded? Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Wednesday, September 18, 2019 10:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C headers in z/OS 2.4 You make a valid point but it comes down to IBM assigning resources (money) to where they can add the most value to the customer. I would argue that instead of publishing COBOL copybooks for control blocks a better API would be callable services to provide the required information, such as your JFCB example. On 2019-09-18 10:22 PM, Farley, Peter x23353 wrote: > Why does everyone assume that having MACLIB/MODGEN headers in C (or any other > language) is only for systems-level code and exits? There are quite a few > business application programs and customer-specific utility programs out here > that can and do use what you may consider "system" API's to satisfy business > application needs, not system coding needs. A simple example would be using > JFCB (via an assembler subroutine today) to retrieve DSNAME to store in > business application records. Certainly that assembler subroutine is > probably more future-proof if recoded in Metal C, but it isn't part of the > operating system or used as a system exit. > > Don’t forget customer business application and utility program uses for these > new versions of MACLIB/MODGEN data areas is all I am trying to say here. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of David Crayford > Sent: Tuesday, September 17, 2019 10:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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 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
You make a valid point but it comes down to IBM assigning resources (money) to where they can add the most value to the customer. I would argue that instead of publishing COBOL copybooks for control blocks a better API would be callable services to provide the required information, such as your JFCB example. On 2019-09-18 10:22 PM, Farley, Peter x23353 wrote: Why does everyone assume that having MACLIB/MODGEN headers in C (or any other language) is only for systems-level code and exits? There are quite a few business application programs and customer-specific utility programs out here that can and do use what you may consider "system' API's to satisfy business application needs, not system coding needs. A simple example would be using JFCB (via an assembler subroutine today) to retrieve DSNAME to store in business application records. Certainly that assembler subroutine is probably more future-proof if recoded in Metal C, but it isn't part of the operating system or used as a system exit. Don’t forget customer business application and utility program uses for these new versions of MACLIB/MODGEN data areas is all I am trying to say here. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Tuesday, September 17, 2019 10:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 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 -- 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
Why does everyone assume that having MACLIB/MODGEN headers in C (or any other language) is only for systems-level code and exits? There are quite a few business application programs and customer-specific utility programs out here that can and do use what you may consider "system' API's to satisfy business application needs, not system coding needs. A simple example would be using JFCB (via an assembler subroutine today) to retrieve DSNAME to store in business application records. Certainly that assembler subroutine is probably more future-proof if recoded in Metal C, but it isn't part of the operating system or used as a system exit. Don’t forget customer business application and utility program uses for these new versions of MACLIB/MODGEN data areas is all I am trying to say here. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Tuesday, September 17, 2019 10:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 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: Question on LDAPSRV running on z/OS
This is a right place; RACF-L is more focused but smaller. Did you activate support for mixed-case passwords? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Pommier, Rex Sent: Tuesday, September 17, 2019 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAE Mystery
Thanks. That was big help. I needed to add the GLOBALSTOP option to ADYSET01. It's working now. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, September 18, 2019 7:59 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > We are SHARED DAE in our plex too, but I suspect it would be the same in a > non-shared configuration, but just on the one system. When I use IPCS option > 3.5 to modify an entry to Take the next dump, it appears that IPCS is issuing > a SETDAE=01, which stops DAE, and then turns around and issues a SET DAE=00 > to all systems in the plex. ADYSET00 in parmlib has the start parameters, and > ADYSET01 has the GLOBALSTOP command in it. Since you manually shut DAE down, > but then I assume you made your changes via IPCS, that it then restarted for > you. The TSU* address space in the snip below is my TSO session. I didn’t > cut/paste all of the log, as it routed the commands to all my systems in the > plex. > > NI000 TEC1 19261 07:52:34.47 TSU03158 0290 SET DAE=01 > N 000 TEC1 19261 07:52:34.48 0280 IEE252I MEMBER ADYSET01 FOUND IN > SYS1.PARMLIB > N 000 TEC1 19261 07:52:34.48 0281 IEF196I IGD104I SYS2.SYSPLEX.DAE > N 000 TEC1 19261 07:52:34.48 0281 IEF196I DDNAME=SYS5 > MR400 TEC1 19261 07:52:34.48 INTERNAL 0090 ADY015I DAE STOP > PROCESSING IS COMPLETE 244 > NI000 TEC1 19261 07:52:36.61 TSU03158 0290 ROUTE DEV1,SET DAE=00 > N 000 TEC1 19261 07:52:36.83 0281 IEF196I IGD103I SMS ALLOCATED TO > DDNAME SYS6 > MR400 TEC1 19261 07:52:36.84 INTERNAL 0090 ADY012I THE FOLLOWING DAE > OPTIONS ARE IN EFFECT: 247 > DR 247 0090 START > DR 247 0090 SVCDUMP = NOTIFY(3,30) MATCH UPDATE SUPPRESSALL > DR 247 0090 SYSMDUMP = MATCH UPDATE > DR 247 0090 RECORDS = 400 > DR 247 0090 DSN = SYS2.SYSPLEX.DAE > DR 247 0090 SHARE = DSN OPTIONS > ER 247 0090 GLOBAL = DSN OPTIONS > > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > Sent: Wednesday, September 18, 2019 7:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DAE Mystery > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > > Where would I look in the WLM ISPF application to check that? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, September 17, 2019 4:38 PM, Mike Schwab mike.a.sch...@gmail.com > wrote: > > > 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, Swiss-based encrypted email. > > > GPG Public Key - > > > https://api.protonmail.ch/pks/lookup?op=get=markjacobs@proton > > > mail.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 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
Re: DAE Mystery
Hmm, Thanks. I'll try it myself. One of our developers needed to delete a DAE entry, don't know how he did it. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, September 18, 2019 7:59 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > We are SHARED DAE in our plex too, but I suspect it would be the same in a > non-shared configuration, but just on the one system. When I use IPCS option > 3.5 to modify an entry to Take the next dump, it appears that IPCS is issuing > a SETDAE=01, which stops DAE, and then turns around and issues a SET DAE=00 > to all systems in the plex. ADYSET00 in parmlib has the start parameters, and > ADYSET01 has the GLOBALSTOP command in it. Since you manually shut DAE down, > but then I assume you made your changes via IPCS, that it then restarted for > you. The TSU* address space in the snip below is my TSO session. I didn’t > cut/paste all of the log, as it routed the commands to all my systems in the > plex. > > NI000 TEC1 19261 07:52:34.47 TSU03158 0290 SET DAE=01 > N 000 TEC1 19261 07:52:34.48 0280 IEE252I MEMBER ADYSET01 FOUND IN > SYS1.PARMLIB > N 000 TEC1 19261 07:52:34.48 0281 IEF196I IGD104I SYS2.SYSPLEX.DAE > N 000 TEC1 19261 07:52:34.48 0281 IEF196I DDNAME=SYS5 > MR400 TEC1 19261 07:52:34.48 INTERNAL 0090 ADY015I DAE STOP > PROCESSING IS COMPLETE 244 > NI000 TEC1 19261 07:52:36.61 TSU03158 0290 ROUTE DEV1,SET DAE=00 > N 000 TEC1 19261 07:52:36.83 0281 IEF196I IGD103I SMS ALLOCATED TO > DDNAME SYS6 > MR400 TEC1 19261 07:52:36.84 INTERNAL 0090 ADY012I THE FOLLOWING DAE > OPTIONS ARE IN EFFECT: 247 > DR 247 0090 START > DR 247 0090 SVCDUMP = NOTIFY(3,30) MATCH UPDATE SUPPRESSALL > DR 247 0090 SYSMDUMP = MATCH UPDATE > DR 247 0090 RECORDS = 400 > DR 247 0090 DSN = SYS2.SYSPLEX.DAE > DR 247 0090 SHARE = DSN OPTIONS > ER 247 0090 GLOBAL = DSN OPTIONS > > 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 IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > Sent: Wednesday, September 18, 2019 7:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DAE Mystery > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected > emails > > Where would I look in the WLM ISPF application to check that? > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, September 17, 2019 4:38 PM, Mike Schwab mike.a.sch...@gmail.com > wrote: > > > 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, Swiss-based encrypted email. > > > GPG Public Key - > > > https://api.protonmail.ch/pks/lookup?op=get=markjacobs@proton > > > mail.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 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
Re: DAE Mystery
We are SHARED DAE in our plex too, but I suspect it would be the same in a non-shared configuration, but just on the one system. When I use IPCS option 3.5 to modify an entry to Take the next dump, it appears that IPCS is issuing a SETDAE=01, which stops DAE, and then turns around and issues a SET DAE=00 to all systems in the plex. ADYSET00 in parmlib has the start parameters, and ADYSET01 has the GLOBALSTOP command in it. Since you manually shut DAE down, but then I assume you made your changes via IPCS, that it then restarted for you. The TSU* address space in the snip below is my TSO session. I didn’t cut/paste all of the log, as it routed the commands to all my systems in the plex. NI000 TEC1 19261 07:52:34.47 TSU03158 0290 SET DAE=01 N 000 TEC1 19261 07:52:34.48 0280 IEE252I MEMBER ADYSET01 FOUND IN SYS1.PARMLIB N 000 TEC1 19261 07:52:34.48 0281 IEF196I IGD104I SYS2.SYSPLEX.DAE N 000 TEC1 19261 07:52:34.48 0281 IEF196I DDNAME=SYS5 MR400 TEC1 19261 07:52:34.48 INTERNAL 0090 ADY015I DAE STOP PROCESSING IS COMPLETE 244 NI000 TEC1 19261 07:52:36.61 TSU03158 0290 ROUTE DEV1,SET DAE=00 N 000 TEC1 19261 07:52:36.83 0281 IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS6 MR400 TEC1 19261 07:52:36.84 INTERNAL 0090 ADY012I THE FOLLOWING DAE OPTIONS ARE IN EFFECT: 247 DR247 0090 START DR247 0090 SVCDUMP = NOTIFY(3,30) MATCH UPDATE SUPPRESSALL DR247 0090 SYSMDUMP = MATCH UPDATE DR247 0090 RECORDS = 400 DR247 0090 DSN = SYS2.SYSPLEX.DAE DR247 0090 SHARE= DSN OPTIONS ER247 0090 GLOBAL = DSN OPTIONS _ 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 Mark Jacobs Sent: Wednesday, September 18, 2019 7:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DAE Mystery **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Where would I look in the WLM ISPF application to check that? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, September 17, 2019 4:38 PM, Mike Schwab wrote: > 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, Swiss-based encrypted email. > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjacobs@proton > > mail.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
Re: DAE Mystery
Where would I look in the WLM ISPF application to check that? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, September 17, 2019 4:38 PM, Mike Schwab wrote: > 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, Swiss-based encrypted > > email. > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=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 -- 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 seems fair. If you don't have VPSIP, or don't use it to the extent that some of our clients do, then you are good to go. Brian On Tue, 17 Sep 2019 20:10:32 +, Gibney, Dave wrote: >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=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ >> > b- >> > >> Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp >> > 07SIADw0RnXZmcA=4Cib0hikGVj- >> > d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= >> > >> > 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
Re: Considering Bypassing ERROR HOLD for OA58037
You run into it when (for instance), VPSIP gets the 16e abend but won't come down. Unfortunately, we found it the 'hard" way by cancelling VPSIP only to have to IPL when IGC00020 went into a tight loop. It's still not completely fixed, but we know now not to let VPSIP get anywhere close to the limit before we recycle it. Brian -- 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 completely agree, when I apply maintenance, I ALWAYS create an entirely new target and dlib zone, and I keep the old one for at least a year. Brian On Tue, 17 Sep 2019 14:23:56 -0500, Tom Marchant wrote: >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
When you are only about 1/2 thorough the apar list, if you print more than 1000 jobs before restarting VPSIP, it would abend, the jobs all needed to use|need SYS1.IMAGELIB. Then when we got to #18 on the list, the site could produce 84,000+ jobs (again all needed SYS1.IMAGELIB), before the abend. Now with the next 3 apars, we appear to be able to print an unlimited number of jobs, but we split VPSIP into two separate regions and restart them both weekly just in case, but once we get the final 2 on, we will probably try to go without restarting any more. BRian On Tue, 17 Sep 2019 18:44:02 +, Gibney, Dave wrote: >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=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQ >> b- >> Je7sw=u9g8rUevBoyCPAdo5sWE9w=RfHnql3CpaS3KFsgCx5LqRORoZTp >> 07SIADw0RnXZmcA=4Cib0hikGVj- >> d0uZAk1aIUAIlm51FKWEuYtMho4Ehww= >> >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
