Re: Separate SMPe environments for maintenance levels
I always use a single shared GLOBAL zone and multiple targets. It's much simpler to keep track of and the only problem I have ever run into is a site the IBM ran an audit on and they wanted to know why they had 8 LPARs but 24 target|dlib zones. Apparently IBM doesn't do it that way. Aside from that little episode it has worked out quite well, and it allows me a great deal of flexibility if I ever had to fall back to something. If you are short on DASD or TAPE, you probably wouldn't want to keep them all around. I try to keep 3 copies of everything if I can though. I also have all datasets cataloged to ** for the res and symbolics for the dlib volume(s) and secondary res (which I need for some sites), and take care to make sure I keep the IEASYMxx under control. I maintain a large number of sites in that way and I have no problems with them at all. I have a series of CLONE jobs that I run for each upgrade tath copy the packs, duplicate and update the DDDEFs, etc. but I think most people do that as well. The SMPe volume(s) which are normally SMS controlled (but not always) tend to get large, but controllable. As someone else mentioned, the naming conventions for the OMVS datasets is very important, and you need to have a way to identify them quickly and easily. They should have both the system identifier and the lpar identifier (unless they are shared) in the dataset name. You have 44 characters, and there is no reason to get stingy with using them. It is very important that you establish a method of operation and stick with it, and document, document, document (then document some more). Brian On Thu, 11 Jun 2020 15:57:41 +, Seymour J Metz wrote: >I would go for a shared GLOBAL and 3 TARGET/DLIB pairs. I would use REPORT >SYSMOD to help keep them in synch. Of course, often there are installation >standards in place as to maintenance methodology, and you can't change things >without getting the appropriate approval. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Bill Giannelli [billgianne...@gmail.com] >Sent: Thursday, June 11, 2020 11:38 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Separate SMPe environments for maintenance levels > >I want to setup separate SMPe environments, say 3 for different maintenance >levels. One matching production then 2 others for maintenance levels "coming >next". My question is, when I what to update my PROD environment with one of >the other maintenance levels, do I need to go thru receive, apply, accept that >I would have done in the "prior" SMPe environment? Or is there a quicker way >to "synch" up the 2 environments? >thanks >Bill > >-- >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: "Everyone wants to retire mainframes"
Long ago in a galaxy far away, there was a telephone company called Gong, Owned by Andromeda Telepath and Teleport. When a customer called in with an outage, they would go to the appropriate equipment, clean and reseat all of the contacts, and then test. They would then report back to the customer that they saw no sign of a problem. In some cases the answer is timing. Certainly running GTF is going to introduce some delays, and there are equivalent effects in other areas. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhbrid...@gmail.com] Sent: Friday, June 12, 2020 12:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" I used to imagine the poor mechanics listening skeptically to a young clueless driver saying "I swear, mister, it was making this awful noise just a minute ago...!" I wouldn't have believed her either. Then I started in end-user support. I have implicitly believed those stories ever since. I tell some hapless users that their machines saw me coming and immediately cleaned up their act. I'm mostly kidding, but how else to explain it when it happens so often? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The real art of conversation is not only to say the right thing in the right place, but to leave unsaid the wrong thing at the tempting moment. -Dorothy Nevill */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, June 11, 2020 13:30 My favorite is when someone is repeatedly getting an error, but when they call me over and without doing anything differently, the error magically goes away. I always said this was because the computer knows that I simply won't stand for such insubordination and it knows that I know where the off switch is. -- 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: "Everyone wants to retire mainframes"
I used to imagine the poor mechanics listening skeptically to a young clueless driver saying "I swear, mister, it was making this awful noise just a minute ago...!" I wouldn't have believed her either. Then I started in end-user support. I have implicitly believed those stories ever since. I tell some hapless users that their machines saw me coming and immediately cleaned up their act. I'm mostly kidding, but how else to explain it when it happens so often? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The real art of conversation is not only to say the right thing in the right place, but to leave unsaid the wrong thing at the tempting moment. -Dorothy Nevill */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, June 11, 2020 13:30 My favorite is when someone is repeatedly getting an error, but when they call me over and without doing anything differently, the error magically goes away. I always said this was because the computer knows that I simply won't stand for such insubordination and it knows that I know where the off switch is. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
Heck, I was a PL/1 bigot from the start. There are other languages I like, but I remember PL/1 with a kind of rosy glow - possibly because I never use it any more. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* I think everyone who chooses to stay out of politics (which is your right) should make a mental note of where they would draw the line and feel it necessary to get involved. Then ask yourself: Is it possible that point already arrived, but it happened too slowly to notice? -Chris Evans */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rupert Reynolds Sent: Thursday, June 11, 2020 19:17 I lost faith COBOL and finallly became a PL/1 biggot when I was told that ALTER GOTO was introduced to help support structured programmng :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I see bookkeeping issue to ensure that you IPL each LPAR from the correct volume and to ensure that you install serive in the correct zone, but what is the synchronization issue with rotating among a set of TARGET/DLIB zones and associated volumes? Oh, there is a detail that I left out; the HFS and zFS naming convention should be tied to the symbols set from the IPL volser. Cloning the target volumes without cloning the target zone means that you can't install service on it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Allan Staller [allan.stal...@hcl.com] Sent: Thursday, June 11, 2020 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels You still end up with a major syncing problem using either Shmuel's or my previous suggestion. I personally have 1 set of target zones and a "canned" job to build an new sysres from scratch using the SMP/E targets as the source. I am happy to share the JCL if you would like. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: And another APPLY difficulty - IEW2821W
Defining BPXROOT according to documentation allowed this PTF to go on clean. Thanks for the help talking it through, > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Thursday, June 11, 2020 1:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > Yes, I think that is your issue. > > Check BPXPRM00 for the SUPERUSER keyword. That userid has to exist, and > have UID 0 > > /** > **/ > /* */ > /* SUPERUSER is a 1 to 8-character name that must conform to the */ > /* restrictions for an MVS user ID. This user ID is assigned */ > /* to shell users when they enter the su command. This user ID */ > /* should be defined to the security product and have a UID of 0 */ > /* assigned to it.*/ > /* The default is SUPERUSER(BPXROOT). */ > /* */ > /** > **/ > SUPERUSER(BPXROOT) > > __ > ___ > 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: Thursday, June 11, 2020 3:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I think I have it. I had noticed this new Healthcheck with z/OS 2.3 and I > intended to address it shortly. > BPXH081I The following problem was found with the SUPERUSER parmlib > statement: > UserID is not defined to the security product. > > It hasn't caused me know problems in the past, probably been this way for > several releases. > > I bet this is my issue. Stay tuned, I need to decide the correct repair. And > check my other LPARs > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Carmen Vitullo > > Sent: Thursday, June 11, 2020 12:32 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: And another APPLY difficulty - IEW2821W > > > > I am leaning toward what David had suggested - only based on the > > binder message > > > > > > > > IEW2821W UID userid NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > > GETPWUID RETURNED REASON CODE reason AND RETURN CODE rc > > > > Explanation: The value specified for UID is not a TSO/E user name or > > z/OS UNIX user ID known to the system. > > > > System action: The binder will not attempt to set UID for SYSLMOD or > > any associated files (such as SYSDEFSD). > > > > User response: Ensure that UID was specified correctly. > > > > Source: Binder > > > > > > Carmen Vitullo > > > > - Original Message - > > > > From: "Dave Gibney" > > To: IBM-MAIN@LISTSERV.UA.EDU > > Sent: Thursday, June 11, 2020 2:14:46 PM > > Subject: Re: And another APPLY difficulty - IEW2821W > > > > Hate to admit it, but I have UID(0) on my id at this time. And, I do > > have READ to BPX.SUPERUSER. > > I don't see any ICH messages in the obvious places > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > On > > > Behalf Of Jousma, David > > > Sent: Thursday, June 11, 2020 12:10 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: And another APPLY difficulty - IEW2821W > > > > > > Are you permitted to BPX.SUPERUSER? Looks like you may not be? > > > > > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES > FUNCTION > > > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > > 00A3. > > > > > > > > > __ > > > ___ > > > 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: Thursday, June 11, 2020 2:57 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: And another APPLY difficulty - IEW2821W > > > > > > **CAUTION EXTERNAL EMAIL** > > > > > > **DO NOT open attachments or click on links from unknown senders or > > > unexpected emails** > > > > > > I am seeing this in the CAUSER report for an APPLY CHECK: > > > CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE > > CAUSES > > > > > > UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR > > MODULE > > > FSUMXTSM IN
Re: Goto Statements AND COBOL OPTIMIZATION
I lost faith COBOL and finallly became a PL/1 biggot when I was told that ALTER GOTO was introduced to help support structured programmng :-) Rupert On Thu, Jun 11, 2020, 01:07 Tom Ross wrote: > >The addition of EXIT PARAGRAPH > >and EXIT SECTION have eliminated most of the reasons for use of GO TO > >in COBOL. I would be interested in any corrections to my > >understanding by those responsible for the COBOL compiler. =20 > > I partially agree, Clark, but what really made it easy to get rid of GOTOs > in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM > CYCLE! > These were added to the Standard with COBOL 2014 and implemented by IBM in > Enterprise > COBOL for z/OS V5.2 > > Cheers, > TomR >> COBOL is the Language of the Future! << > > -- > 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
z114 retroactive height reduction (FC 9975) for transportation
Hi, A bit of a niche question maybe, but this list usually enjoys those! I need to move my z114, and sadly I don't have the possibility of inspecting it physically right now. I was wondering if anyone knows if it is possible to reduce the height of the z114? In the IMPP there is a FC 9975 which separates the top portion in the installation, but I have no idea if my individual has that feature. Looking at older pictures of the frame there appears to be a "cut" between the BPA and where the battery is supposed to be, so it looks like maybe removing the side panels, the door, and then one might be able to detach the top - but that's hard to say for sure on the pictures. Does anyone have any experience removing the top portion for transportation of a z114? Or similar experiences? Thanks, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
Whether or not your methodology involves copying libraries or zones, you have to be careful of everything. Every strategy has risks that you need to address. There is no need to re-receive anything. You should, however, frequently receive the HOLDATA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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: "Everyone wants to retire mainframes"
? GTF? Generalized Trace Facility? Is there another GTF in z/OS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursday, June 11, 2020 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" On Thu, 11 Jun 2020 17:47:46 +, Seymour J Metz wrote: >I call that the "GTF effect"; the problem never manifests when I have >diagnostic measures in place to capture failure data. > GTF? Generalized Trace Facility? A colleague once used the term "Heisenberg effect" for a performance monitor that reported that most of the CPU time was being spent in the performance monitor. And I struggled with a vendor compiler when my program arithmetic checked in optimized mode but produced the result I intended in debug mode. Vendor support told me (correctly) that the construct I (tried to) use was documented as "unpredictable". WAD? On Thu, 11 Jun 2020 17:51:13 +, Seymour J Metz wrote: >> DBD or PSB library. > >In a kinder, more gentle world, the message would tell you which. > I consider "either-or" messages irresponsible. Even in the case where a single test and BC instruction may detect significantly different errors. More likely, middleware fails to distinguish or preserve distinct reason codes supplied by the base level. The M Reason explanations are rife with "either or". -- 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: Messages & Codes (again; was: another APPLY difficulty)
Compartmentalization. Presumably the DFSMSdfp people don't talk to the OMVS people. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Thursday, June 11, 2020 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Messages & Codes (again; was: another APPLY difficulty) On Thu, 11 Jun 2020 18:57:12 +, Gibney, Dave wrote: > >The BINDER error is: >IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID >RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. >Likely due to this in the BINDER control statements: >SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > Just what the other thread was discussing. Sheesh! Why doesn't Binder (which evidently knows how to invoke UNIX Services) issue strerror() and display the message? -- 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: Separate SMPe environments for maintenance levels
There are several strategies. I'd advice you to use a symbol to select the default DB2. The key, however, is that whatever approach you use you think through and document all the issues. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels So this is for DB2 software. Distribution libraries are *.AD* Target libraries are *.SD*. So I would create a second target zone a define datasets and DDDEFs for say "*.target2.SD*" ? -- 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: And another APPLY difficulty - IEW2821W
Yes, I think that is your issue. Check BPXPRM00 for the SUPERUSER keyword. That userid has to exist, and have UID 0 // /* */ /* SUPERUSER is a 1 to 8-character name that must conform to the */ /* restrictions for an MVS user ID. This user ID is assigned */ /* to shell users when they enter the su command. This user ID */ /* should be defined to the security product and have a UID of 0 */ /* assigned to it.*/ /* The default is SUPERUSER(BPXROOT). */ /* */ // SUPERUSER(BPXROOT) _ 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: Thursday, June 11, 2020 3:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: And another APPLY difficulty - IEW2821W **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I think I have it. I had noticed this new Healthcheck with z/OS 2.3 and I intended to address it shortly. BPXH081I The following problem was found with the SUPERUSER parmlib statement: UserID is not defined to the security product. It hasn't caused me know problems in the past, probably been this way for several releases. I bet this is my issue. Stay tuned, I need to decide the correct repair. And check my other LPARs > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Carmen Vitullo > Sent: Thursday, June 11, 2020 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > I am leaning toward what David had suggested - only based on the > binder message > > > > IEW2821W UID userid NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE reason AND RETURN CODE rc > > Explanation: The value specified for UID is not a TSO/E user name or > z/OS UNIX user ID known to the system. > > System action: The binder will not attempt to set UID for SYSLMOD or > any associated files (such as SYSDEFSD). > > User response: Ensure that UID was specified correctly. > > Source: Binder > > > Carmen Vitullo > > - Original Message - > > From: "Dave Gibney" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, June 11, 2020 2:14:46 PM > Subject: Re: And another APPLY difficulty - IEW2821W > > Hate to admit it, but I have UID(0) on my id at this time. And, I do > have READ to BPX.SUPERUSER. > I don't see any ICH messages in the obvious places > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jousma, David > > Sent: Thursday, June 11, 2020 12:10 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: And another APPLY difficulty - IEW2821W > > > > Are you permitted to BPX.SUPERUSER? Looks like you may not be? > > > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > > > > __ > > ___ > > 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: Thursday, June 11, 2020 2:57 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: And another APPLY difficulty - IEW2821W > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > I am seeing this in the CAUSER report for an APPLY CHECK: > > CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE > CAUSES > > > > UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR > MODULE > > FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB LIBRARY. THE RETURN > CODE WAS > > 04. THE SEQUENCE NUMBER WAS 09. THE SYSPRINT FILE WAS > SMP4. > > The BINDER error is: > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > Likely due to this in the BINDER control statements: > > SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > > > > This is APPLYING maintenance to my new
Re: Goto Statements AND COBOL OPTIMIZATION
[Default] On 10 Jun 2020 17:14:25 -0700, in bit.listserv.ibm-main tmr...@stlvm20.vnet.ibm.com (Tom Ross) wrote: >>The addition of EXIT PARAGRAPH >>and EXIT SECTION have eliminated most of the reasons for use of GO TO >>in COBOL. I would be interested in any corrections to my >>understanding by those responsible for the COBOL compiler. =20 > >I partially agree, Clark, but what really made it easy to get rid of GOTOs >in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! >These were added to the Standard with COBOL 2014 and implemented by IBM in >Enterprise >COBOL for z/OS V5.2 I agree but the main question I was raising is whether if I have GO TO blow-up-paragraph where blow-up-paragraph is the last paragraph which has a CALL "ILBOABN0" or its LE equivalent followed by GOBACK as the last two statements will that disrupt PERFORM optimization? Starting with VS COBOL II release 4 I have PERFORMed blow-up-paragrraph to make sure that my program is fully optimized. Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >-- >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: SMF 71 long floating point fields
-Original Message- From: Barry Merrill Sent: Thursday, June 11, 2020 10:02 AM To: 'pr...@videotron.ca' Subject: RE: SMF 71 long floating point fields To SAS, they are straightforward RB8. fields with exponent and mantissa. SMF71AFB=80737.714286 RBCHAR=4513B61B6DB6DB6D SMF71AFB=80700.142857 RBCHAR=4513B3C249249249 SMF71AFB=80701.285714 RBCHAR=4513B3D492492492 SMF71AFB=80811.428571 RBCHAR=4513BAB6DB6DB6DB SMF71AFB=80817.571429 RBCHAR=4513BB1924924924 SMF71AFB=80786.714286 RBCHAR=4513B92B6DB6DB6D SMF71AFB=80867.857143 RBCHAR=4513BE3DB6DB6DB6 SMF71AFB=80680.428571 RBCHAR=4513B286DB6DB6DB SMF71AFB=80578.285714 RBCHAR=4513AC2492492492 SMF71AFB=80708.428571 RBCHAR=4513B446DB6DB6DB SMF71AFB=80688.714286 RBCHAR=4513B30B6DB6DB6D SMF71AFB=80779 RBCHAR=4513B8B0 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pierre Fichaud Sent: Wednesday, June 10, 2020 6:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF 71 long floating point fields There are many of them. I'm guessing these are hex floating point. Could someone confirm this or correct me ? Thanks, Pierre. -- 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: Separate SMPe environments for maintenance levels
So this is for DB2 software. Distribution libraries are *.AD* Target libraries are *.SD*. So I would create a second target zone a define datasets and DDDEFs for say "*.target2.SD*" ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Messages & Codes (again; was: another APPLY difficulty)
On Thu, 11 Jun 2020 18:57:12 +, Gibney, Dave wrote: > >The BINDER error is: >IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID >RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. >Likely due to this in the BINDER control statements: >SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > Just what the other thread was discussing. Sheesh! Why doesn't Binder (which evidently knows how to invoke UNIX Services) issue strerror() and display the message? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: And another APPLY difficulty - IEW2821W
I think I have it. I had noticed this new Healthcheck with z/OS 2.3 and I intended to address it shortly. BPXH081I The following problem was found with the SUPERUSER parmlib statement: UserID is not defined to the security product. It hasn't caused me know problems in the past, probably been this way for several releases. I bet this is my issue. Stay tuned, I need to decide the correct repair. And check my other LPARs > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Carmen Vitullo > Sent: Thursday, June 11, 2020 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > I am leaning toward what David had suggested - only based on the binder > message > > > > IEW2821W UID userid NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE reason AND RETURN CODE rc > > Explanation: The value specified for UID is not a TSO/E user name or z/OS > UNIX user ID known to the system. > > System action: The binder will not attempt to set UID for SYSLMOD or any > associated files (such as SYSDEFSD). > > User response: Ensure that UID was specified correctly. > > Source: Binder > > > Carmen Vitullo > > - Original Message - > > From: "Dave Gibney" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, June 11, 2020 2:14:46 PM > Subject: Re: And another APPLY difficulty - IEW2821W > > Hate to admit it, but I have UID(0) on my id at this time. And, I do have READ > to BPX.SUPERUSER. > I don't see any ICH messages in the obvious places > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jousma, David > > Sent: Thursday, June 11, 2020 12:10 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: And another APPLY difficulty - IEW2821W > > > > Are you permitted to BPX.SUPERUSER? Looks like you may not be? > > > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > > > > __ > > ___ > > 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: Thursday, June 11, 2020 2:57 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: And another APPLY difficulty - IEW2821W > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > I am seeing this in the CAUSER report for an APPLY CHECK: > > CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE > CAUSES > > > > UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR > MODULE > > FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB LIBRARY. THE RETURN > CODE WAS > > 04. THE SEQUENCE NUMBER WAS 09. THE SYSPRINT FILE WAS > SMP4. > > The BINDER error is: > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > Likely due to this in the BINDER control statements: > > SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > > > > This is APPLYING maintenance to my new z/OS 2.3 system which was from > > an archive Serverpac at RSU1909 > > > > FTR, here is part of SMPOUT: > > GIM42401I THE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC > > STATEMENT FOR GIMSMP: > > 'PROCESS=WAIT,CSI=ZOS23S.SMPE.GLOBAL.CSI'. > > SET BOUNDARY (MVST100) OPTIONS(ZOSOPT). > > GIM20501I SET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE > WAS 00. > > > > > > APPLY > > /* CHECK > > /* PTFS /* */ > > /* SELECT ( /* */ > > /* UA71506 > > /* ) /* */ > > SOURCEID ( /* */ > > RSU* HIPER PRP /* */ > > IBM* /* */ > > ) /* */ > > EXCLUDE ( /* */ > > Several PTFs that Skip wouldn't do this, that were needed to have a > > RC=0 APPLY CHECK :) > > > > ) /* */ > > /* COMPRESS(ALL) /* */ > > /* REDO /* */ > > RETRY(YES) > > BYPASS( > > HOLDSYSTEM > > HOLDUSER > > HOLDCLASS(UCLREL,ERRELL) > > /* HOLDERROR( ) > > /* IFREQ /* */ > > /* REQ /* */ > > /* PRE /* */ > > ) > > GROUPEXTEND(NOUSERMODS) /* */ > > > > Dave Gibney > > Information Technology Services > > Washington State University > > > > > > -- > > 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
Re: And another APPLY difficulty - IEW2821W
I am leaning toward what David had suggested - only based on the binder message IEW2821W UID userid NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID RETURNED REASON CODE reason AND RETURN CODE rc Explanation: The value specified for UID is not a TSO/E user name or z/OS UNIX user ID known to the system. System action: The binder will not attempt to set UID for SYSLMOD or any associated files (such as SYSDEFSD). User response: Ensure that UID was specified correctly. Source: Binder Carmen Vitullo - Original Message - From: "Dave Gibney" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, June 11, 2020 2:14:46 PM Subject: Re: And another APPLY difficulty - IEW2821W Hate to admit it, but I have UID(0) on my id at this time. And, I do have READ to BPX.SUPERUSER. I don't see any ICH messages in the obvious places > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Thursday, June 11, 2020 12:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > Are you permitted to BPX.SUPERUSER? Looks like you may not be? > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > __ > ___ > 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: Thursday, June 11, 2020 2:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: And another APPLY difficulty - IEW2821W > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I am seeing this in the CAUSER report for an APPLY CHECK: > CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE > CAUSES > > UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR > MODULE FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB > LIBRARY. THE RETURN CODE WAS 04. THE SEQUENCE > NUMBER WAS 09. THE SYSPRINT > FILE WAS SMP4. > The BINDER error is: > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > Likely due to this in the BINDER control statements: > SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > > This is APPLYING maintenance to my new z/OS 2.3 system which was from an > archive Serverpac at RSU1909 > > FTR, here is part of SMPOUT: > GIM42401I THE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC > STATEMENT FOR GIMSMP: > 'PROCESS=WAIT,CSI=ZOS23S.SMPE.GLOBAL.CSI'. > SET BOUNDARY (MVST100) OPTIONS(ZOSOPT). > GIM20501I SET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE > WAS 00. > > > APPLY > /* CHECK > /* PTFS /* */ > /* SELECT ( /* */ > /* UA71506 > /* ) /* */ > SOURCEID ( /* */ > RSU* HIPER PRP /* */ > IBM* /* */ > ) /* */ > EXCLUDE ( /* */ > Several PTFs that Skip wouldn't do this, that were needed to have a RC=0 > APPLY CHECK :) > > ) /* */ > /* COMPRESS(ALL) /* */ > /* REDO /* */ > RETRY(YES) > BYPASS( > HOLDSYSTEM > HOLDUSER > HOLDCLASS(UCLREL,ERRELL) > /* HOLDERROR( ) > /* IFREQ /* */ > /* REQ /* */ > /* PRE /* */ > ) > GROUPEXTEND(NOUSERMODS) /* */ > > Dave Gibney > Information Technology Services > Washington State University > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog solution - dead or live?
Depends on your definition. (Is a zombie dead or alive?) We've run Catalog Solution since Rocket was just gleam in someone's eye. We techs would love to convert to Catalog Recovery Plus. Rocket has offered incentives to covert. Our management doesn't seem to give a sh*t. CS is still supported. Reluctantly. I don't know that you could buy a new license today. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Tuesday, June 2, 2020 2:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Catalog solution - dead or live? CAUTION EXTERNAL EMAIL I am trying to figure if this product still alive. afaik it is now at Rocket, but they only list mainstar catalog recovery plus. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: And another APPLY difficulty - IEW2821W
Hate to admit it, but I have UID(0) on my id at this time. And, I do have READ to BPX.SUPERUSER. I don't see any ICH messages in the obvious places > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Thursday, June 11, 2020 12:10 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: And another APPLY difficulty - IEW2821W > > Are you permitted to BPX.SUPERUSER? Looks like you may not be? > > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > > __ > ___ > 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: Thursday, June 11, 2020 2:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: And another APPLY difficulty - IEW2821W > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > I am seeing this in the CAUSER report for an APPLY CHECK: > CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE > CAUSES > > UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR > MODULE FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB > LIBRARY. THE RETURN CODE WAS 04. THE > SEQUENCE > NUMBER WAS 09. THE SYSPRINT > FILE WAS SMP4. > The BINDER error is: > IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION > GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE > 00A3. > Likely due to this in the BINDER control statements: > SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) > > This is APPLYING maintenance to my new z/OS 2.3 system which was from an > archive Serverpac at RSU1909 > > FTR, here is part of SMPOUT: > GIM42401ITHE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC > STATEMENT FOR GIMSMP: > 'PROCESS=WAIT,CSI=ZOS23S.SMPE.GLOBAL.CSI'. > SET BOUNDARY (MVST100) OPTIONS(ZOSOPT). > GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE > WAS 00. > > > APPLY > /*CHECK > /*PTFS /* */ > /*SELECT ( /* */ > /* UA71506 > /*) /* */ > SOURCEID (/* */ > RSU* HIPER PRP /* */ > IBM* /* */ > )/* */ >EXCLUDE ( /* */ > Several PTFs that Skip wouldn't do this, that were needed to have a RC=0 > APPLY CHECK :) > >) /* */ >/*COMPRESS(ALL) /* */ >/*REDO /* */ > RETRY(YES) > BYPASS( > HOLDSYSTEM > HOLDUSER > HOLDCLASS(UCLREL,ERRELL) > /*HOLDERROR( ) > /* IFREQ /* */ > /* REQ /* */ > /* PRE /* */ >) > GROUPEXTEND(NOUSERMODS) /* */ > > Dave Gibney > Information Technology Services > Washington State University > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: And another APPLY difficulty - IEW2821W
Are you permitted to BPX.SUPERUSER? Looks like you may not be? IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE 00A3. _ 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: Thursday, June 11, 2020 2:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: And another APPLY difficulty - IEW2821W **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I am seeing this in the CAUSER report for an APPLY CHECK: CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE CAUSES UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR MODULE FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB LIBRARY. THE RETURN CODE WAS 04. THE SEQUENCE NUMBER WAS 09. THE SYSPRINT FILE WAS SMP4. The BINDER error is: IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE 00A3. Likely due to this in the BINDER control statements: SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) This is APPLYING maintenance to my new z/OS 2.3 system which was from an archive Serverpac at RSU1909 FTR, here is part of SMPOUT: GIM42401ITHE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC STATEMENT FOR GIMSMP: 'PROCESS=WAIT,CSI=ZOS23S.SMPE.GLOBAL.CSI'. SET BOUNDARY (MVST100) OPTIONS(ZOSOPT). GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00. APPLY /*CHECK /*PTFS /* */ /*SELECT ( /* */ /* UA71506 /*) /* */ SOURCEID (/* */ RSU* HIPER PRP /* */ IBM* /* */ )/* */ EXCLUDE ( /* */ Several PTFs that Skip wouldn't do this, that were needed to have a RC=0 APPLY CHECK :) ) /* */ /*COMPRESS(ALL) /* */ /*REDO /* */ RETRY(YES) BYPASS( HOLDSYSTEM HOLDUSER HOLDCLASS(UCLREL,ERRELL) /*HOLDERROR( ) /* IFREQ /* */ /* REQ /* */ /* PRE /* */ ) GROUPEXTEND(NOUSERMODS) /* */ Dave Gibney Information Technology Services Washington State University -- 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
And another APPLY difficulty - IEW2821W
I am seeing this in the CAUSER report for an APPLY CHECK: CAUSER FMID MESSAGE ID PAGE ERROR DESCRIPTION AND POSSIBLE CAUSES UJ01705 HOT77B0 GIM23911E 16 LINK-EDIT PROCESSING FAILED FOR MODULE FSUMXTSM IN LMOD FSUMSTSM IN THE SFSUMLIB LIBRARY. THE RETURN CODE WAS 04. THE SEQUENCE NUMBER WAS 09. THE SYSPRINT FILE WAS SMP4. The BINDER error is: IEW2821W DF39 UID 0 NOT PROCESSED. UNIX SYSTEM SERVICES FUNCTION GETPWUID RETURNED REASON CODE 0B4F0800 AND RETURN CODE 00A3. Likely due to this in the BINDER control statements: SETOPT PARM(PATHMODE(4,7,5,5),UID(0)) This is APPLYING maintenance to my new z/OS 2.3 system which was from an archive Serverpac at RSU1909 FTR, here is part of SMPOUT: GIM42401ITHE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC STATEMENT FOR GIMSMP: 'PROCESS=WAIT,CSI=ZOS23S.SMPE.GLOBAL.CSI'. SET BOUNDARY (MVST100) OPTIONS(ZOSOPT). GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00. APPLY /*CHECK /*PTFS /* */ /*SELECT ( /* */ /* UA71506 /*) /* */ SOURCEID (/* */ RSU* HIPER PRP /* */ IBM* /* */ )/* */ EXCLUDE ( /* */ Several PTFs that Skip wouldn't do this, that were needed to have a RC=0 APPLY CHECK :) ) /* */ /*COMPRESS(ALL) /* */ /*REDO /* */ RETRY(YES) BYPASS( HOLDSYSTEM HOLDUSER HOLDCLASS(UCLREL,ERRELL) /*HOLDERROR( ) /* IFREQ /* */ /* REQ /* */ /* PRE /* */ ) GROUPEXTEND(NOUSERMODS) /* */ Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
This list doesn't do attachments. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Giannelli > Sent: Thursday, June 11, 2020 11:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMPe Apply not working > > I attached the apply check and the nonapply list > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
really need to see more than just your apply control cards, and IIRC that APPLY PTFS for a new FMIND ( function ) will not apply the FMID you need unless you specify APPLY FORFMID. show the entire apply smpprts and smpout show the FMID received successfully also Carmen Vitullo - Original Message - From: "Bill Giannelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, June 11, 2020 1:29:26 PM Subject: Re: SMPe Apply not working APPLY PTFS BYPASS( HOLDSYSTEM(ACTION,AO,DB2BIND,DEP,DOC,IPL,MULTSYS)) GROUPEXTEND CHECK . -- 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: "Everyone wants to retire mainframes"
Apparently that world is not this world. From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Thursday, June 11, 2020 11:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" > DBD or PSB library. In a kinder, more gentle world, the message would tell you which. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Thursday, June 11, 2020 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Here are all of the possibly relevant parts from the JESMSGLG for a similar occurrence that I just caused. +*DFS0929I BLDL FAILED FOR MEMBER --ABCDEFG IEA995I SYMPTOM DUMP OUTPUT 830 USER COMPLETION CODE=0929 TIME=10.52.44 SEQ=18497 CPU= ASID=0038 PSW AT TIME OF ERROR 078D1000 9012762C ILC 2 INTC 0D ACTIVE MODULE ADDRESS=_1011A000 OFFSET=D62C NAME=DFSDLBL0 DATA AT PSW 10127626 - D234181F 0A0DD71C D200D200 GR 0: 1: 83A1 2: 7660 3: 84B0 4: 0005D060 5: 7658 6: 10126358 7: 0005D060 8: 00019928 9: 00019F68 A: B: 0001 C: 1011C048 D: 101260B0 E: 90127E9E F: 83A1 END OF SYMPTOM DUMP DFS627I IMS RTM CLEANUP ( EOT ) COMPLETE FOR JS DDADMP .PROC01 .STEP01 ,RC=00 IEF450I DDADMP STEP01 PROC01 - ABEND=S000 U0929 REASON= 832 There are no additional DDs beyond this and the standard JESJCL and JESYSMSG which have no additional relevant data. Of course if you look up the error in the manual it does provide slightly more useful information. DFS0929I BLDL FAILED FOR MEMBER -- member name Explanation ~~~ A BLDL was issued for the named member. The member was not found in the DBD or PSB library. System action ~ Abend 0929 is issued if batch DL/I was running. ACBGEN processing continues if the ACBGEN utility was being run. Programmer response ~~~ Correct the error in the appropriate library, and rerun the program. From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Wednesday, June 10, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" The problem with that message is not that it mentions BLDL, but that it fails to mention other relevant data. At a minimum, what was the ddname and what was the return code. Ideally I'd like secondary messages listing the libraries in the concatenation. A user ABEND without a message is hard to justify. Are you sure that it wasn't in the joblog? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Wednesday, June 10, 2020 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Here's a quote from a message I posted to this list in 2009: "I have a very basic one to complain about: DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ This really means that the specified PSB DDMPPSZ is not in the specified IMS library. Why can't it just say that? As an application programmer do I really need to know that BLDL means, well, whatever it means? Of course IMS has some that are even worse. Sometimes I just get something like: USER COMPLETION CODE= without any message at all. The first time I ran in to it it took me a heck of a time to figure out I need to look in the IMS manual to find out what the error was. For all I could tell it was a user application error, but I couldn't see what. Now all of the other developers on our VSE to z/OS conversion team just ask me what the errors are, because trying to find them in the manuals is too often too painful. Hopefully I'll get them trained some day! I've got to say, coming from VSE their error messages are, in general, much better. Of course as a developer I hate dealing with creating error messages for my own apps, so I can understand why IBM has such issues... :-)" Things have not improved much, if it all, in this regard in the last ten years. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, June 9, 2020 8:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Yep. We used to get a lot of errors for out of volumes in a storage groups, and the users would want us to add more volumes. For several calls I would point out that the data set had a very small primary and secondary space value. I would go through all the extents on one volume, then proceed through the rest, and run out volumes despite lots of space in the storage
Re: SMPe Apply not working
I attached the apply check and the nonapply list -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
APPLY PTFS BYPASS( HOLDSYSTEM(ACTION,AO,DB2BIND,DEP,DOC,IPL,MULTSYS)) GROUPEXTEND CHECK . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
Wrong Global zone specified? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMPe Apply not working [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I ran a GIMSUP download, unpack, receive which ran clean. I see the received ptfs in a LIST NOAPPLY. But when I run theAPPLY I get "NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY". What could I be doing wrong? thanks Bill -- 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
Re: Separate SMPe environments for maintenance levels
You still end up with a major syncing problem using either Shmuel's or my previous suggestion. I personally have 1 set of target zones and a "canned" job to build an new sysres from scratch using the SMP/E targets as the source. I am happy to share the JCL if you would like. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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
Re: Separate SMPe environments for maintenance levels
Not sure I remember the details. I worked with one ex-sysprog that cloned the SMP/E target environment to the sysres for documentation purposes (1980's.) ZoneCopy should do a lot of what you seem to be looking for. I (personally do not think that is the way to go. My suggestion is One global zone A set of target zones One Dlib zone. The apply/accept processing would need to be repeated for each target zone. Accept processing for all except the last target zone will need the NOPURGE (?) operand. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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
Re: "Everyone wants to retire mainframes"
On Thu, 11 Jun 2020 17:47:46 +, Seymour J Metz wrote: >I call that the "GTF effect"; the problem never manifests when I have >diagnostic measures in place to capture failure data. > GTF? Generalized Trace Facility? A colleague once used the term "Heisenberg effect" for a performance monitor that reported that most of the CPU time was being spent in the performance monitor. And I struggled with a vendor compiler when my program arithmetic checked in optimized mode but produced the result I intended in debug mode. Vendor support told me (correctly) that the construct I (tried to) use was documented as "unpredictable". WAD? On Thu, 11 Jun 2020 17:51:13 +, Seymour J Metz wrote: >> DBD or PSB library. > >In a kinder, more gentle world, the message would tell you which. > I consider "either-or" messages irresponsible. Even in the case where a single test and BC instruction may detect significantly different errors. More likely, middleware fails to distinguish or preserve distinct reason codes supplied by the base level. The M Reason explanations are rife with "either or". -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
Those are not the messages I would like to see 1) Provide the APPLY Statement in full. 2) Provide all messages from the APPLY Function from SMOUT DD statement This will help us see what the issues might be. Sometimes when you do an APPLY it is for the incorrect FMID or the wrong SREL. We would like to see something like this . APPLY . GROUP . PTFS . BYPASS ( . HOLDSYSTEM . ) . NOJCLINREPORT . RETRY ( YES ) . . . .GIM42001I THE FOLLOWING CONDITIONS FOR SYSMOD UI68880 WERE NOT SATISFIED, BUT . WERE IGNORED BECAUSE THE BYPASS OPERAND WAS SPECIFIED. PROCESSING . CONTINUES. .GIM35966I SYSTEM HOLD ACTION ORIGINATED BY SYSMOD UI68880 WAS BYPASSED. .GIM35966I SYSTEM HOLD DOC ORIGINATED BY SYSMOD UI68880 WAS BYPASSED. .GIM42001I THE FOLLOWING CONDITIONS FOR SYSMOD UI68931 WERE NOT SATISFIED, BUT . WERE IGNORED BECAUSE THE BYPASS OPERAND WAS SPECIFIED. PROCESSING . CONTINUES. Liette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPe Apply not working GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS1 FOR GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS2 FOR GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. GIM59606IDEQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF OEMPP.DB2.V12R02M0.GLOBAL.C GIM59607IDEQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS FOR -- 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: Messages & Codes (was Re: "Everyone wants to retire mainframes")
Nope! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, June 11, 2020 10:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Any message whose action is given as "contact your systems programmer" is just as bad. Has IBM finally gotten rid of all of those? -- Shmuel (Seymour J.) Metz https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3data=02%7C01%7Callan.staller%40HCL.COM%7C5d87b6ba82604e73cc9308d80e18af0c%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637274846480687573sdata=u4EfCy7ayukIXREJxmztud3J1hWr7ajxrlmgk56KWpc%3Dreserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Thursday, June 11, 2020 4:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") This pair of error messages was a design mistake: OS/2 !! Sys01475 OS/2 !! Sys02027 That's a case of national language considerations run amok. That was the only pair of messages you saw on your screen when you formatted a diskette with OS/2, left the diskette in the primary drive, and rebooted the typical PC of that era (that didn't automatically try to boot from another device when there was a diskette in the primary drive). A diskette's boot sector doesn't have much room, so the designers had to be concise. They wanted to include at least one error code, and they did. But then instead of some portion of the planet not understanding what happened, very nearly the entire planet didn't understand what happened. :-) A better design would have used a global message like this: OS/2 SYS01475: Diskette in Drive! That's exactly the same number of characters, assuming the new line was one character. (If not, the colon could have been omitted.) Yes, "Diskette in Drive!" is technically English, but even so it would have been much more broadly, globally understood than mystery error codes. Even this one would have been better: OS/2 SYS01475 Unbootable Diskette Or: SYS01475: Data Diskette in Drive! Pretty much anything with the word "Diskette" (the term IBM preferred instead of "Floppy") would have given users a clue. Even this: OS/2 !! Sys01475 No Boot Diskette - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.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 ::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: Separate SMPe environments for maintenance levels
On Thu, 11 Jun 2020 11:40:47 -0500, Bill Giannelli wrote: >So I've been reviewing the options you all have so kindly shares zonecopy, >zonemerge, zoneexportand it seems obvious you need to be careful of the >DDDEFs and renaming of datasets. If not careful you can really screw up and >overlay one environment. >While simplistic and perhaps slightly more work.I am wondering if one >"safe" way is to simply re-receive and re-apply the maintenance on the next >environment when needed? That does not make it any safer. Each target and distribution zone will still have to have the correct DDDEFs. JCL symbols can be your friend in setting up the jobs to do all of this. Test your process carefully. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
Ditto, I'd like to also see what was actually received, this is a new product IIRC, so did the FMID actually get received+PTF's ? show what actually got received would also help Carmen Vitullo - Original Message - From: "Dave Gibney" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, June 11, 2020 12:59:06 PM Subject: Re: SMPe Apply not working And the output from smpout and smprpt > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Binyamin Dissen > Sent: Thursday, June 11, 2020 10:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMPe Apply not working > > Show the APPLY statement. > > On Thu, 11 Jun 2020 12:27:00 -0500 Bill Giannelli > wrote: > > :>GIM59603I ENQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS1 FOR > :>GIM59603I ENQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS2 FOR > :>GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE > APPLY COMMAND. > :>GIM59606I DEQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF > OEMPP.DB2.V12R02M0.GLOBAL.C > :>GIM59607I DEQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS FOR > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > https://urldefense.com/v3/__http://www.dissensoftware.com__;!!JmPEgB > Y0HMszNaDT!_6uhGc5oLyFkX1gFM7UkUTszrVtcoM27lzV1NlHNZT4lVHciRQy > wMjC6ICRdqw$ > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Everyone wants to retire mainframes"
The telephone folks used to close tickets with CWT -- "cleared while testing." In other words, they could not reproduce. Another support favorite: Customer: You've got to help us. It's happening all the time. It's really killing us. We're dead in the water without a fix. Tech: Add a SYSUDUMP DD statement, reproduce the problem and send us the dump. Customer: Oh, well, we'll have to see. It's really hard to reproduce. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, June 11, 2020 10:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" At least in that case you can hopefully reproduce the error :) It's the one-time lost error messages that as a support person, you sometimes have to say, "Oh well" My favorite is when someone is repeatedly getting an error, but when they call me over and without doing anything differently, the error magically goes away. I always said this was because the computer knows that I simply won't stand for such insubordination and it knows that I know where the off switch is. On 6/11/2020 9:42 AM, Bob Bridges wrote: > My favorite is a marketing guy I was supporting. He called for my help with > some problem that had occurred - I don't remember what exactly, probably with > a DYL-280II program that he'd written with my help - and, as always, I asked > him what the error message had said. "Oh, it said some damn thing" he > retorted. > > I think he was laughing at himself as he said it, but he said it. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > -- 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: Separate SMPe environments for maintenance levels
If you stay current on HOLDDATA, which you should, then conditions will have changed between the two sequences. You are not actually recreating your tested maintenance environment into your production. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Giannelli > Sent: Thursday, June 11, 2020 9:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Separate SMPe environments for maintenance levels > > So I've been reviewing the options you all have so kindly shares zonecopy, > zonemerge, zoneexportand it seems obvious you need to be careful of > the DDDEFs and renaming of datasets. If not careful you can really screw up > and overlay one environment. > While simplistic and perhaps slightly more work.I am wondering if one > "safe" way is to simply re-receive and re-apply the maintenance on the next > environment when needed? > thanks > Bill > > -- > 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: SMPe Apply not working
And the output from smpout and smprpt > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Binyamin Dissen > Sent: Thursday, June 11, 2020 10:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMPe Apply not working > > Show the APPLY statement. > > On Thu, 11 Jun 2020 12:27:00 -0500 Bill Giannelli > wrote: > > :>GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS1 FOR > :>GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS2 FOR > :>GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE > APPLY COMMAND. > :>GIM59606IDEQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF > OEMPP.DB2.V12R02M0.GLOBAL.C > :>GIM59607IDEQ WAS SUCCESSFUL FOR SHARED USE OF > OEMPP.DB2.V12R02M0.SMPPTS FOR > :> > :>-- > :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Binyamin Dissen > https://urldefense.com/v3/__http://www.dissensoftware.com__;!!JmPEgB > Y0HMszNaDT!_6uhGc5oLyFkX1gFM7UkUTszrVtcoM27lzV1NlHNZT4lVHciRQy > wMjC6ICRdqw$ > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
Show the APPLY statement. On Thu, 11 Jun 2020 12:27:00 -0500 Bill Giannelli wrote: :>GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS1 FOR :>GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS2 FOR :>GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. :>GIM59606IDEQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF OEMPP.DB2.V12R02M0.GLOBAL.C :>GIM59607IDEQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS FOR :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Everyone wants to retire mainframes"
There's another factor in the Betamax vs. VHS struggle. I went into a department store to buy my first camcorder in the early 80s. I chose a Beta model. The sales guy said, "Most folks these days are buying VHS. You can only exchange tapes with the same technology. Pick out a VHS model. Take it home but don't open the box. Check with some friends and relatives to see what *they* have. If it's mostly Beta, then bring back the VHS and exchange it." I never went back. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: Tuesday, June 9, 2020 8:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [External] Re: "Everyone wants to retire mainframes" CAUTION EXTERNAL EMAIL On Tue, Jun 9, 2020 at 9:21 AM Lionel B Dyck wrote: > Y'all stop using logic and reason - this is an emotional issue that > the author and others are invested in and has nothing to do with IBM > effectively telling the world that the mainframe is dead based on all > the layoffs that have occurred over the last 20-25 years, or that IBM > continues to offload software development or outright sells IBM > software to other companies, or that IBM has bought into the Cloud and > has reduced their investment in developing z/OS, or . . . . > > And then there is the vast amounts of money to be made by replacing a > mainframe - I'm sure that those vendors offering those services only > have the best interests of the current mainframe users at heart. > > It's Beta vs VHS all over again > Beta lost due to marketing idiocy. It was superior to VHS, technically, but "overpriced" compared to VHS. So the consumer went with the inferior but more affordable VHS. You're right -- exactly like z/OS vs. Windows and zSeries vs. AMD/Intel. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Everyone wants to retire mainframes"
> DBD or PSB library. In a kinder, more gentle world, the message would tell you which. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Thursday, June 11, 2020 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Here are all of the possibly relevant parts from the JESMSGLG for a similar occurrence that I just caused. +*DFS0929I BLDL FAILED FOR MEMBER --ABCDEFG IEA995I SYMPTOM DUMP OUTPUT 830 USER COMPLETION CODE=0929 TIME=10.52.44 SEQ=18497 CPU= ASID=0038 PSW AT TIME OF ERROR 078D1000 9012762C ILC 2 INTC 0D ACTIVE MODULE ADDRESS=_1011A000 OFFSET=D62C NAME=DFSDLBL0 DATA AT PSW 10127626 - D234181F 0A0DD71C D200D200 GR 0: 1: 83A1 2: 7660 3: 84B0 4: 0005D060 5: 7658 6: 10126358 7: 0005D060 8: 00019928 9: 00019F68 A: B: 0001 C: 1011C048 D: 101260B0 E: 90127E9E F: 83A1 END OF SYMPTOM DUMP DFS627I IMS RTM CLEANUP ( EOT ) COMPLETE FOR JS DDADMP .PROC01 .STEP01 ,RC=00 IEF450I DDADMP STEP01 PROC01 - ABEND=S000 U0929 REASON= 832 There are no additional DDs beyond this and the standard JESJCL and JESYSMSG which have no additional relevant data. Of course if you look up the error in the manual it does provide slightly more useful information. DFS0929I BLDL FAILED FOR MEMBER -- member name Explanation ~~~ A BLDL was issued for the named member. The member was not found in the DBD or PSB library. System action ~ Abend 0929 is issued if batch DL/I was running. ACBGEN processing continues if the ACBGEN utility was being run. Programmer response ~~~ Correct the error in the appropriate library, and rerun the program. From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Wednesday, June 10, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" The problem with that message is not that it mentions BLDL, but that it fails to mention other relevant data. At a minimum, what was the ddname and what was the return code. Ideally I'd like secondary messages listing the libraries in the concatenation. A user ABEND without a message is hard to justify. Are you sure that it wasn't in the joblog? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Wednesday, June 10, 2020 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Here's a quote from a message I posted to this list in 2009: "I have a very basic one to complain about: DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ This really means that the specified PSB DDMPPSZ is not in the specified IMS library. Why can't it just say that? As an application programmer do I really need to know that BLDL means, well, whatever it means? Of course IMS has some that are even worse. Sometimes I just get something like: USER COMPLETION CODE= without any message at all. The first time I ran in to it it took me a heck of a time to figure out I need to look in the IMS manual to find out what the error was. For all I could tell it was a user application error, but I couldn't see what. Now all of the other developers on our VSE to z/OS conversion team just ask me what the errors are, because trying to find them in the manuals is too often too painful. Hopefully I'll get them trained some day! I've got to say, coming from VSE their error messages are, in general, much better. Of course as a developer I hate dealing with creating error messages for my own apps, so I can understand why IBM has such issues... :-)" Things have not improved much, if it all, in this regard in the last ten years. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, June 9, 2020 8:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Yep. We used to get a lot of errors for out of volumes in a storage groups, and the users would want us to add more volumes. For several calls I would point out that the data set had a very small primary and secondary space value. I would go through all the extents on one volume, then proceed through the rest, and run out volumes despite lots of space in the storage group. They didn't want to reallocate, so I suggested they migrate and recall the dataset. Then the existing space would be in 1 extent on 1 volume and plenty of extents and volumes to extend onto. The problem started going away after that. Would the new 1st
Re: "Everyone wants to retire mainframes"
I call that the "GTF effect"; the problem never manifests when I have diagnostic measures in place to capture failure data. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Thursday, June 11, 2020 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" At least in that case you can hopefully reproduce the error :) It's the one-time lost error messages that as a support person, you sometimes have to say, "Oh well" My favorite is when someone is repeatedly getting an error, but when they call me over and without doing anything differently, the error magically goes away. I always said this was because the computer knows that I simply won't stand for such insubordination and it knows that I know where the off switch is. On 6/11/2020 9:42 AM, Bob Bridges wrote: > My favorite is a marketing guy I was supporting. He called for my help with > some problem that had occurred - I don't remember what exactly, probably with > a DYL-280II program that he'd written with my help - and, as always, I asked > him what the error message had said. "Oh, it said some damn thing" he > retorted. > > I think he was laughing at himself as he said it, but he said it. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > -- 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: SMPe Apply not working
Maybe the Zone is set to an incorrect Zone. (i.e SET BDY(TZONE).) On 2020-06-11 13:17, Bill Giannelli wrote: I ran a GIMSUP download, unpack, receive which ran clean. I see the received ptfs in a LIST NOAPPLY. But when I run theAPPLY I get "NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY". What could I be doing wrong? thanks Bill -- 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: "Everyone wants to retire mainframes"
At least in that case you can hopefully reproduce the error :) It's the one-time lost error messages that as a support person, you sometimes have to say, "Oh well" My favorite is when someone is repeatedly getting an error, but when they call me over and without doing anything differently, the error magically goes away. I always said this was because the computer knows that I simply won't stand for such insubordination and it knows that I know where the off switch is. On 6/11/2020 9:42 AM, Bob Bridges wrote: My favorite is a marketing guy I was supporting. He called for my help with some problem that had occurred - I don't remember what exactly, probably with a DYL-280II program that he'd written with my help - and, as always, I asked him what the error message had said. "Oh, it said some damn thing" he retorted. I think he was laughing at himself as he said it, but he said it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Goto Statements AND COBOL OPTIMIZATION
Those were added w/ COBOL 2002, not 2014. Don't give yourself too much credit! From: IBM Mainframe Discussion List on behalf of Tom Ross Sent: Wednesday, June 10, 2020 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Goto Statements AND COBOL OPTIMIZATION >The addition of EXIT PARAGRAPH >and EXIT SECTION have eliminated most of the reasons for use of GO TO >in COBOL. I would be interested in any corrections to my >understanding by those responsible for the COBOL compiler. =20 I partially agree, Clark, but what really made it easy to get rid of GOTOs in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! These were added to the Standard with COBOL 2014 and implemented by IBM in Enterprise COBOL for z/OS V5.2 Cheers, TomR >> COBOL is the Language of the Future! << -- 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: SMPe Apply not working
GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS1 FOR GIM59603IENQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS2 FOR GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. GIM59606IDEQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF OEMPP.DB2.V12R02M0.GLOBAL.C GIM59607IDEQ WAS SUCCESSFUL FOR SHARED USE OF OEMPP.DB2.V12R02M0.SMPPTS FOR -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPe Apply not working
Show us the output. Possible there are some control cards that are needed or the PTFs do not match the SREL or FIMDs in your global zone. But the GIM Messages would be very helpful to see Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMPe Apply not working I ran a GIMSUP download, unpack, receive which ran clean. I see the received ptfs in a LIST NOAPPLY. But when I run theAPPLY I get "NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY". What could I be doing wrong? thanks Bill -- 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
SMPe Apply not working
I ran a GIMSUP download, unpack, receive which ran clean. I see the received ptfs in a LIST NOAPPLY. But when I run theAPPLY I get "NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY". What could I be doing wrong? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: "Everyone wants to retire mainframes"
My other favorite. We had someone call about an installation problem. The solution was rather involved so our support tech said "it is covered in detail in the Installation Manual" whereupon the customer guy said "oh, I don't have the manuals. Bob has the manuals. He's in charge of documentation. I'm just in charge of installation." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Bridges Sent: Thursday, June 11, 2020 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: "Everyone wants to retire mainframes" My favorite is a marketing guy I was supporting. He called for my help with some problem that had occurred - I don't remember what exactly, probably with a DYL-280II program that he'd written with my help - and, as always, I asked him what the error message had said. "Oh, it said some damn thing" he retorted. I think he was laughing at himself as he said it, but he said it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Everyone wants to retire mainframes"
Here are all of the possibly relevant parts from the JESMSGLG for a similar occurrence that I just caused. +*DFS0929I BLDL FAILED FOR MEMBER --ABCDEFG IEA995I SYMPTOM DUMP OUTPUT 830 USER COMPLETION CODE=0929 TIME=10.52.44 SEQ=18497 CPU= ASID=0038 PSW AT TIME OF ERROR 078D1000 9012762C ILC 2 INTC 0D ACTIVE MODULE ADDRESS=_1011A000 OFFSET=D62C NAME=DFSDLBL0 DATA AT PSW 10127626 - D234181F 0A0DD71C D200D200 GR 0: 1: 83A1 2: 7660 3: 84B0 4: 0005D060 5: 7658 6: 10126358 7: 0005D060 8: 00019928 9: 00019F68 A: B: 0001 C: 1011C048 D: 101260B0 E: 90127E9E F: 83A1 END OF SYMPTOM DUMP DFS627I IMS RTM CLEANUP ( EOT ) COMPLETE FOR JS DDADMP .PROC01 .STEP01 ,RC=00 IEF450I DDADMP STEP01 PROC01 - ABEND=S000 U0929 REASON= 832 There are no additional DDs beyond this and the standard JESJCL and JESYSMSG which have no additional relevant data. Of course if you look up the error in the manual it does provide slightly more useful information. DFS0929I BLDL FAILED FOR MEMBER -- member name Explanation ~~~ A BLDL was issued for the named member. The member was not found in the DBD or PSB library. System action ~ Abend 0929 is issued if batch DL/I was running. ACBGEN processing continues if the ACBGEN utility was being run. Programmer response ~~~ Correct the error in the appropriate library, and rerun the program. From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Wednesday, June 10, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" The problem with that message is not that it mentions BLDL, but that it fails to mention other relevant data. At a minimum, what was the ddname and what was the return code. Ideally I'd like secondary messages listing the libraries in the concatenation. A user ABEND without a message is hard to justify. Are you sure that it wasn't in the joblog? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Wednesday, June 10, 2020 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Here's a quote from a message I posted to this list in 2009: "I have a very basic one to complain about: DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ This really means that the specified PSB DDMPPSZ is not in the specified IMS library. Why can't it just say that? As an application programmer do I really need to know that BLDL means, well, whatever it means? Of course IMS has some that are even worse. Sometimes I just get something like: USER COMPLETION CODE= without any message at all. The first time I ran in to it it took me a heck of a time to figure out I need to look in the IMS manual to find out what the error was. For all I could tell it was a user application error, but I couldn't see what. Now all of the other developers on our VSE to z/OS conversion team just ask me what the errors are, because trying to find them in the manuals is too often too painful. Hopefully I'll get them trained some day! I've got to say, coming from VSE their error messages are, in general, much better. Of course as a developer I hate dealing with creating error messages for my own apps, so I can understand why IBM has such issues... :-)" Things have not improved much, if it all, in this regard in the last ten years. From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Tuesday, June 9, 2020 8:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "Everyone wants to retire mainframes" Yep. We used to get a lot of errors for out of volumes in a storage groups, and the users would want us to add more volumes. For several calls I would point out that the data set had a very small primary and secondary space value. I would go through all the extents on one volume, then proceed through the rest, and run out volumes despite lots of space in the storage group. They didn't want to reallocate, so I suggested they migrate and recall the dataset. Then the existing space would be in 1 extent on 1 volume and plenty of extents and volumes to extend onto. The problem started going away after that. Would the new 1st extent on the first volume from the recall become the default 1st allocation on subsequent volumes? On Wed, Jun 10, 2020 at 12:48 AM Seymour J Metz wrote: > > My pet peeve is the default for SPACE; "Absolute track not available" is not > a user friendly error message for forgetting to specify SPACE. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM
Re: SMF 71 long floating point fields
What does the first byte look like, typically? I'm guessing 4X hex. 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://mainframeperformancetopics.com 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: Pierre Fichaud To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/06/2020 00:12 Subject:[EXTERNAL] SMF 71 long floating point fields Sent by:IBM Mainframe Discussion List There are many of them. I'm guessing these are hex floating point. Could someone confirm this or correct me ? Thanks, Pierre. -- 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: "Everyone wants to retire mainframes"
My favorite is a marketing guy I was supporting. He called for my help with some problem that had occurred - I don't remember what exactly, probably with a DYL-280II program that he'd written with my help - and, as always, I asked him what the error message had said. "Oh, it said some damn thing" he retorted. I think he was laughing at himself as he said it, but he said it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* My aunt has rather selfishly suspended her production of chocolate cake because of the whole "broken hip" thing, leaving me to try to find a worthwhile substituteI purchased a box with a picture of a cake on it, but inside were all these so-called "ingredients" that, once I'd mixed them and baked them and put out the flames, tasted suspiciously like one of my mother's chocolate hockey pucks. -Bruce Cameron */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, June 11, 2020 11:26 ...as a guy who has been responsible for product management and a support desk, I used to run around the office yelling that our next product was only going to have one error message "AN ERROR OCCURRED" after yet another exchange like this: Tech: XYZ support, may I help you? Customer: Yes, XYZ blew up yesterday. Tech: Our apologies. What was the error message? Customer: Something about an error occurred. Tech: What was the exact message number? We could use that to troubleshoot the issue. Customer: I don't know. We already deleted the SYSOUT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I prefer to have a rotating list of TARGET/DLIB pairs, with symbols keyed to
the IPL volser. When I want to promote a configuration from, e.g., TEST to QA,
I just IPL.
Note that whatever methodology you you, there will be some bookkeeping
associated with it, and cutting corners can be fatal.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Jousma, David [01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 11, 2020 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Separate SMPe environments for maintenance levels
I do a similar process. One global zone for a z/os ver.rel, a "maintenance
zone", and then a target zone that matches every active SYSRES in my
environment. One DLIB zone.Maintenance is only actively applied to the
maintenance zone, and when ready to promote that level into use, I have a set
of standard cloning jobs that copies the actual sysres to the new SYSRES with
appropriate renameu (sysres volser is a part of ZFS container names), copy the
SMPE support datasets with renames, and SMPE ZONECOPY from the maintenance zone
to a new target zone named to match the sysres describes, and then appropriate
zone edits to change dddef volser's/pathnames to match the sysres.
This way, you are only every applying maintenance once, you have a target zone
that matches the running sysres in the event a fix needs to be applied, etc.
Accept processing only occurs AFTER the last system in my complex is running
that level of maintenance.
SET BDY () .
ZCOPY () INTO() .
SET BDY() .
ZEDIT DDDEF .
CHANGE VOLUME(,
) .
CHANGE PATH('/'*,
'/'*).
CHANGE DA(SMPE.,
SMPE.).
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
ENDZONEEDIT .
_
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
From: "Bill Giannelli"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 11, 2020 10:38:23 AM
Subject: Separate SMPe environments for maintenance levels
I want to setup separate SMPe environments, say 3 for different maintenance
levels. One matching production then 2 others for maintenance levels "coming
next". My question is, when I what to update my PROD environment with one of
the other maintenance levels, do I need to go thru receive, apply, accept that
I would have done in the "prior" SMPe environment? Or is there a quicker way to
"synch" up the 2 environments?
thanks
Bill
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I do a similar process. One global zone for a z/os ver.rel, a "maintenance
zone", and then a target zone that matches every active SYSRES in my
environment. One DLIB zone.Maintenance is only actively applied to the
maintenance zone, and when ready to promote that level into use, I have a set
of standard cloning jobs that copies the actual sysres to the new SYSRES with
appropriate renameu (sysres volser is a part of ZFS container names), copy the
SMPE support datasets with renames, and SMPE ZONECOPY from the maintenance zone
to a new target zone named to match the sysres describes, and then appropriate
zone edits to change dddef volser's/pathnames to match the sysres.
This way, you are only every applying maintenance once, you have a target zone
that matches the running sysres in the event a fix needs to be applied, etc.
Accept processing only occurs AFTER the last system in my complex is running
that level of maintenance.
SET BDY () .
ZCOPY () INTO() .
SET BDY() .
ZEDIT DDDEF .
CHANGE VOLUME(,
) .
CHANGE PATH('/'*,
'/'*).
CHANGE DA(SMPE.,
SMPE.).
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
ENDZONEEDIT .
_
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
From: "Bill Giannelli"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 11, 2020 10:38:23 AM
Subject: Separate SMPe environments for maintenance levels
I want to setup separate SMPe environments, say 3 for different maintenance
levels. One matching production then 2 others for maintenance levels "coming
next". My question is, when I what to update my PROD environment with one of
the other maintenance levels, do I need to go thru receive, apply, accept that
I would have done in the "prior" SMPe environment? Or is there a quicker way to
"synch" up the 2 environments?
thanks
Bill
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: Separate SMPe environments for maintenance levels
I would go for a shared GLOBAL and 3 TARGET/DLIB pairs. I would use REPORT SYSMOD to help keep them in synch. Of course, often there are installation standards in place as to maintenance methodology, and you can't change things without getting the appropriate approval. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Separate SMPe environments for maintenance levels I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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: Separate SMPe environments for maintenance levels
I've done something similar but with one global zone and 2 target zones, one for the current maint and one for the next maint - one DLIB zone, so one global, one receive, apply to tzone1 migrate, then receive more maint, accept, then apply to tzone2, something like that. if you want a totally separate SMP/E environment then you can possibly do a megezone or export import I know there are several folks that do what you are wanting to do currently. Carmen Vitullo - Original Message - From: "Bill Giannelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, June 11, 2020 10:38:23 AM Subject: Separate SMPe environments for maintenance levels I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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: [External] Re: "Everyone wants to retire mainframes"
Well, in the TSO environment there's a service to build messages from templates, plugging in variables. ISPF has similar services. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, June 11, 2020 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: "Everyone wants to retire mainframes" That's cool, the is/are and pluralization. I never bothered -- I have always gone with (s) as in "You have %d dog(s)" Yes, I really upped my error message game when I went from assembler to C++. Yes, you can do anything in assembler, but unless you have or devote time to developing macros such as you describe, you tend to end up with less user-friendly messages. With C/C++ there is no excuse. On the other hand, as a guy who has been responsible for product management and a support desk, I used to run around the office yelling that our next product was only going to have one error message "AN ERROR OCCURRED" after yet another exchange like this: Tech: XYZ support, may I help you? Customer: Yes, XYZ blew up yesterday. Tech: Our apologies. What was the error message? Customer: Something about an error occurred. Tech: What was the exact message number? We could use that to troubleshoot the issue. Customer: I don't know. We already deleted the SYSOUT. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Wednesday, June 10, 2020 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: "Everyone wants to retire mainframes" Things like numeric conversion and scooting text around are difficult in assembler, so I would tend to put that off until later [1]. Then one day I coded a macro and underlying subroutine so I could do something like this: #PRINTF SYSPRINT,'DFS0929I BLDL ON DDNAME %s FAILED with RC=%d FOR MEMBER %s',(DDNAME,(R15),MEMBER) ... and suddenly I was far more likely to include the extra details with the initial coding. I just looked at some doc for that old code and found this section, so I guess I was having some fun with various options to help display what I assume is correct English: .* PLURALIZER EXAMPLE (options P and A): .* .* #SPRINTF OUTBUF,'You have %pd dogs',NUMDOGS .* .* produces: You have 1 dog .* You have 2 dogs .* .* #SPRINTF OUTBUF,'There %ad dogs',NUMDOGS .* .* produces: There is 1 dog .* There are 2 dogs -- 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: Separate SMPe environments for maintenance levels
SMP/e ZONECOPY, UCLIN (to fix the DDDEFs), DFSMSDss to COPY and RENAME the Datasets On 2020-06-11 11:38, Bill Giannelli wrote: I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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
Separate SMPe environments for maintenance levels
I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: "Everyone wants to retire mainframes"
That's cool, the is/are and pluralization. I never bothered -- I have always gone with (s) as in "You have %d dog(s)" Yes, I really upped my error message game when I went from assembler to C++. Yes, you can do anything in assembler, but unless you have or devote time to developing macros such as you describe, you tend to end up with less user-friendly messages. With C/C++ there is no excuse. On the other hand, as a guy who has been responsible for product management and a support desk, I used to run around the office yelling that our next product was only going to have one error message "AN ERROR OCCURRED" after yet another exchange like this: Tech: XYZ support, may I help you? Customer: Yes, XYZ blew up yesterday. Tech: Our apologies. What was the error message? Customer: Something about an error occurred. Tech: What was the exact message number? We could use that to troubleshoot the issue. Customer: I don't know. We already deleted the SYSOUT. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Wednesday, June 10, 2020 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: "Everyone wants to retire mainframes" Things like numeric conversion and scooting text around are difficult in assembler, so I would tend to put that off until later [1]. Then one day I coded a macro and underlying subroutine so I could do something like this: #PRINTF SYSPRINT,'DFS0929I BLDL ON DDNAME %s FAILED with RC=%d FOR MEMBER %s',(DDNAME,(R15),MEMBER) ... and suddenly I was far more likely to include the extra details with the initial coding. I just looked at some doc for that old code and found this section, so I guess I was having some fun with various options to help display what I assume is correct English: .* PLURALIZER EXAMPLE (options P and A): .* .* #SPRINTF OUTBUF,'You have %pd dogs',NUMDOGS .* .* produces: You have 1 dog .* You have 2 dogs .* .* #SPRINTF OUTBUF,'There %ad dogs',NUMDOGS .* .* produces: There is 1 dog .* There are 2 dogs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")
Any message whose action is given as "contact your systems programmer" is just as bad. Has IBM finally gotten rid of all of those? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Thursday, June 11, 2020 4:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") This pair of error messages was a design mistake: OS/2 !! Sys01475 OS/2 !! Sys02027 That's a case of national language considerations run amok. That was the only pair of messages you saw on your screen when you formatted a diskette with OS/2, left the diskette in the primary drive, and rebooted the typical PC of that era (that didn't automatically try to boot from another device when there was a diskette in the primary drive). A diskette's boot sector doesn't have much room, so the designers had to be concise. They wanted to include at least one error code, and they did. But then instead of some portion of the planet not understanding what happened, very nearly the entire planet didn't understand what happened. :-) A better design would have used a global message like this: OS/2 SYS01475: Diskette in Drive! That's exactly the same number of characters, assuming the new line was one character. (If not, the colon could have been omitted.) Yes, "Diskette in Drive!" is technically English, but even so it would have been much more broadly, globally understood than mystery error codes. Even this one would have been better: OS/2 SYS01475 Unbootable Diskette Or: SYS01475: Data Diskette in Drive! Pretty much anything with the word "Diskette" (the term IBM preferred instead of "Floppy") would have given users a clue. Even this: OS/2 !! Sys01475 No Boot Diskette - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.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: Messages & Codes (was Re: "Everyone wants to retire mainframes")
When IBM started using pictures instead of text in their assembly instructions, I coinded the phrase "International icons: unintelligible in any language." The concept, of course, applies to software, not just to printed product assembly instruction, and indisputably not just IBM. BTW, would it hurt when the product assembly involves bolts and screws to specify how much torque to apply? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, June 11, 2020 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") You have to understand national politics: "we won't buy this product; the error messages are in English" [not French, Japanese, etc.] Even though you are of course right, "diskette in drive" is more understandable to the average French speaker than !! Sys01475 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, June 11, 2020 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") This pair of error messages was a design mistake: OS/2 !! Sys01475 OS/2 !! Sys02027 That's a case of national language considerations run amok. That was the only pair of messages you saw on your screen when you formatted a diskette with OS/2, left the diskette in the primary drive, and rebooted the typical PC of that era (that didn't automatically try to boot from another device when there was a diskette in the primary drive). A diskette's boot sector doesn't have much room, so the designers had to be concise. They wanted to include at least one error code, and they did. But then instead of some portion of the planet not understanding what happened, very nearly the entire planet didn't understand what happened. :-) A better design would have used a global message like this: OS/2 SYS01475: Diskette in Drive! That's exactly the same number of characters, assuming the new line was one character. (If not, the colon could have been omitted.) Yes, "Diskette in Drive!" is technically English, but even so it would have been much more broadly, globally understood than mystery error codes. -- 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: Messages & Codes (was Re: "Everyone wants to retire mainframes")
You have to understand national politics: "we won't buy this product; the error messages are in English" [not French, Japanese, etc.] Even though you are of course right, "diskette in drive" is more understandable to the average French speaker than !! Sys01475 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Thursday, June 11, 2020 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Messages & Codes (was Re: "Everyone wants to retire mainframes") This pair of error messages was a design mistake: OS/2 !! Sys01475 OS/2 !! Sys02027 That's a case of national language considerations run amok. That was the only pair of messages you saw on your screen when you formatted a diskette with OS/2, left the diskette in the primary drive, and rebooted the typical PC of that era (that didn't automatically try to boot from another device when there was a diskette in the primary drive). A diskette's boot sector doesn't have much room, so the designers had to be concise. They wanted to include at least one error code, and they did. But then instead of some portion of the planet not understanding what happened, very nearly the entire planet didn't understand what happened. :-) A better design would have used a global message like this: OS/2 SYS01475: Diskette in Drive! That's exactly the same number of characters, assuming the new line was one character. (If not, the colon could have been omitted.) Yes, "Diskette in Drive!" is technically English, but even so it would have been much more broadly, globally understood than mystery error codes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")
On Thu, 11 Jun 2020 16:42:02 +0800, Timothy Sipples wrote: >This pair of error messages was a design mistake: > >OS/2 !! Sys01475 >OS/2 !! Sys02027 > >That's a case of national language considerations run amok. ... > >A diskette's boot sector doesn't have much room, ... >:-) Please don't try to justify the inadequacy of z/OS messages by analogy with limitations imposed by the OS/2 boot sector size. It's a non sequitur. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Messages & Codes (was Re: "Everyone wants to retire mainframes")
This pair of error messages was a design mistake: OS/2 !! Sys01475 OS/2 !! Sys02027 That's a case of national language considerations run amok. That was the only pair of messages you saw on your screen when you formatted a diskette with OS/2, left the diskette in the primary drive, and rebooted the typical PC of that era (that didn't automatically try to boot from another device when there was a diskette in the primary drive). A diskette's boot sector doesn't have much room, so the designers had to be concise. They wanted to include at least one error code, and they did. But then instead of some portion of the planet not understanding what happened, very nearly the entire planet didn't understand what happened. :-) A better design would have used a global message like this: OS/2 SYS01475: Diskette in Drive! That's exactly the same number of characters, assuming the new line was one character. (If not, the colon could have been omitted.) Yes, "Diskette in Drive!" is technically English, but even so it would have been much more broadly, globally understood than mystery error codes. Even this one would have been better: OS/2 SYS01475 Unbootable Diskette Or: SYS01475: Data Diskette in Drive! Pretty much anything with the word "Diskette" (the term IBM preferred instead of "Floppy") would have given users a clue. Even this: OS/2 !! Sys01475 No Boot Diskette - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
