Re: IBM error messages getting worse?
On Fri, 17 Jul 2009 18:32:29 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: 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? Frank, I suspect that the message is merely dated -- back when I went through undergraduate school, applications programmers wrote in Assembler and issued BLDLs directly, so they knew what a BLDL was and the error message made sense to them. Today, BLDLs are done umpteen layers below the applications and the message is no longer appropriate. MEMBER NOT FOUND would make more sense. Maybe its time to blow the dust off of messages such as these... W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Fri, 17 Jul 2009 18:32:29 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: 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? ... I think this is a pretty common example of an error message saying what rather than why. Maybe it was written by a coder that had no idea why the BLDL was issued or a developer who was just too close too close to the code. It's accurate but not helpful. But I doubt this is much more common now than in the past. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Wed, 15 Jul 2009 22:33:38 -0700, Ed Gould ps2...@yahoo.com wrote: ... Pat:I am not sure I agree , but I think that most USS messages are at best inscrutable. Since I'm one of those that gets anal over this use of USS, I'll object up front and you can not care starting now. More importantly, I'm not sure what messages you are referring to. The TCP/IP messages you mention below are standard MVS msgs, not Unix messages. (I agree that the Unix messages are indeed inscrutable.) Take TCP as an example most of the messages I had to look up at the time did not follow the IBM convention as to importance (W,I,E,C) and then they didn't set the condition code to match the message. The IBM convention as to importance (W,I,E,C) does not apply to console messages. As far as I know this has always been the case. For console messages I believe W is for a Wait State message, E is for an eventual response needed, and I'm not sure the other 2 are used at all. To the extent that the convention you refer to exists at all, I think it is for SYSOUT messages like from compilers, etc. I'm hard pressed to think of TCP/IP messages associated with condition codes so I assume you mean other USS messages. But last I knew there were 4 volumes of TCP/IP messages; there are a lot of both good and bad messages. I can't comment on the other messages you are referring to because I don't know which they are. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Thu, 16 Jul 2009 07:01:03 -0500, Chris Mason chrisma...@belgacom.net wrote: ... ideally USS messages are composed within the installation and so, if they are inscrutable, the person to whom to complain should be available with an in-organisation telephone call - assuming the original author hasn't been let go. ... I have to admit that USS messages cannot be looked up in a Messages and Codes manual, cannot (except for the default messages supplied by IBM) be the subject of PMRs, RCFs, etc. And they often ARE inscrutable. If Ed hadn't added his final disclaimer I would have had to agree with him. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Fri, 17 Jul 2009 02:53:26 -0500, Patrick O'Keefe patrick.oke...@wamu.net wrote: The IBM convention as to importance (W,I,E,C) does not apply to console messages. As far as I know this has always been the case. For console messages I believe W is for a Wait State message, E is for an eventual response needed, and I'm not sure the other 2 are used at all. To the extent that the convention you refer to exists at all, I think it is for SYSOUT messages like from compilers, etc. Patrick, its more than an IBM convention -- its an IBM Corporate Standard (which I own) C-S 3-7019-002 Message Format. Unfortunately, its confidential (I've tried several times to make it unconfidential and published, but to no avail). This standard applies to all messages on z architecture that are written to an operator's console (sorry, can't help you with the COBOL messages) and applies to z/OS, z/VSE and z/VM (sorry, not zTPF or zLinux). The standard describes what a message ID should look like (and othr things) and as you state W means wait state and we do use I and E (as well as A and D) but not C. There is a table in the standard relating each of these to the descriptor codes that are set (on z/OS). There are some best practices in terms of how to do message text (so that it won't flub up automation) and rules about the kinds of changes that can be made to a message without requiring that the message get a new message ID. As you know, I hang out on the System Automation user group on Yahoo and I've encouraged automation folk that have encountered messages that do not follow the conventions (such as command responses not setting the command response bit or descriptor code 5 so that they can be caught by a NetView PIPE) to submit PMRs to fix the message -- and if they get a hard time, to mention my name and the standard. I can't really help too much with poor English in messages (the standard doesn't address that) but be assured that when at least the z/OS folks consider new messages (or changes to an existing message), they will usually run it by me first. W. Kevin Kelley IBM POK Lab -- z/OS Core Technical Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
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... :-) Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
Ed I haven't been following this long-running thread but some some devil whispered in my ear to see what it was all about - mainly I expect because a long-running thread tends to drift off course and so I get curious as to where it may have wandered. I had got to the end just as my normally noisy grandson was enjoying having his nappy changed - he's back to being noisy again! Having digested this post I was able to reflect that, ideally USS messages are composed within the installation and so, if they are inscrutable, the person to whom to complain should be available with an in-organisation telephone call - assuming the original author hasn't been let go. However, I remember well a comment from a CE colleague in around 1977 or so regarding the supplied USS message 7: SESSION NOT BOUND.[1] What am I supposed to do with that he mused! Chris Mason [1] This did get improved but to something that only the techies could really handled: luname UNABLE TO ESTABLISH SESSION runame FAILED WITH SENSE sense. On Wed, 15 Jul 2009 22:33:38 -0700, Ed Gould ps2...@yahoo.com wrote: --- On Thu, 7/9/09, Patrick O'Keefe patrick.oke...@wamu.net wrote: From: Patrick O'Keefe patrick.oke...@wamu.net Subject: Re: IBM error messages getting worse? To: IBM-MAIN@bama.ua.edu Date: Thursday, July 9, 2009, 2:29 PM On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews d...@lists.duda.com wrote: I think you make a very good point. There have always been absolutely inscrutable MVS messages and there will probably be new ones. But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on if they are so bad as to be considered a defect. I don't think it is getting worse. Pat O'Keefe - Pat:I am not sure I agree , but I think that most USS messages are at best inscrutable. Take TCP as an example most of the messages I had to look up at the time did not follow the IBM convention as to importance (W,I,E,C) and then they didn't set the condition code to match the message. The condition code IMO was the worse and it looked to me like they threw the dice when it came to setting codes. Frankly I gave up and after reading the message in the manual 2 or 3 times and it still did not make sense I opened a PMR. I very rarely got anyplace with the PMR as the USS people live in the own universe separate from IBM. To me they decided to thumb their nose at the rest of IBM and said we are going to operate as we like to hell with IBM and their rules. I think the LE people weren't quite as bad, but they are up there. Do *NOT* get me going on COBOL messages. Their so called self describing messages must have been made up on a bad acid trip. In the past, say 1970 or so we can all agree that some messages like call your systems programmer were nightmares especially at 3AM and there was no IBM support to call back then. Since then (thanks to GUIDE anyway) we made the messages a MAJOR issue and I can still remember 1 GUIDE where the pubs people came into GUIDE and promised to do a better job. It actually did work, thank goodness. Messages actually started to mean something and they were reasonable english straightforward and it might take you a bit to understand the famous VSAM messages that gave you a bunch of possibilities at an answer if you could discern if it was a FC or other type of RC or whatever. If you read it carefully enough it did make sense (most of the time). That was about the time that (sorry I do not remember the name of the IBM product) but IBM shipped you a searchable database every month or so and you could play with search args to find something you couldn't make heads or tales out of. Of course now its IBMLINK (when it is up) and it functions the same and with reasonably more up to date issues than the once a month tape shipment. The pubs people might have lost their way as it seems in the late 80's (especially with USS) components (I DO NOT MEAN UNFORMATTED SYSTEM SERVICES so if anyone wants to get anal about the meaning I do not care. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Thursday, July 16, 2009 12:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM error messages getting worse? --- On Thu, 7/9/09, Patrick O'Keefe patrick.oke...@wamu.net wrote: From: Patrick O'Keefe patrick.oke...@wamu.net Subject: Re: IBM error messages getting worse? To: IBM-MAIN@bama.ua.edu Date: Thursday, July 9, 2009, 2:29 PM On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews=20 d...@lists.duda.com wrote: I think you make a very good point.=A0 There have always been absolutely inscrutable MVS messages and there will probably be new ones.=A0 But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on=20 if they are so bad as to be considered a defect.=A0 I don't think it is=20 getting worse. Pat O'Keefe=A0=20 - Pat:I am not sure I agree , but I think that most USS messages are at best = inscrutable. Take TCP as an example most of the messages I had to look up a= t the time did not follow the IBM convention as to importance (W,I,E,C) and= then they didn't set the condition code to match the message. The conditio= n code IMO was the worse and it looked to me like they threw the dice when = it came to setting codes. Frankly I gave up and after reading the message i= n the manual 2 or 3 times and it still did not make sense I opened a PMR. I= very rarely got anyplace with the PMR as the USS people live in the own = universe separate from IBM. To me they decided to thumb their nose at the r= est of IBM and said we are going to operate as we like to hell with IBM and= their rules. I think the LE people weren't quite as bad, but they are up there. Do *NOT*= get me going on COBOL messages. Their so called self describing messages m= ust have been made up on a bad acid trip. In the past, say 1970 or so we can all agree that some messages like call = your systems programmer were nightmares especially at 3AM and there was no= IBM support to call back then.=A0 Since then (thanks to GUIDE anyway) we made the messages a MAJOR issue and = I can still remember 1 GUIDE where the pubs people came into GUIDE and prom= ised to do a better job. It actually did work, thank goodness. Messages act= ually started to mean something and they were reasonable english straightfo= rward and it might take you a bit to understand the famous VSAM messages th= at gave you a bunch of possibilities at an answer if you could discern if i= t was a FC or other type of RC or whatever. If you read it carefully enough= it did make sense (most of the time). That was about the time that (sorry = I do not remember the name of the IBM product) but IBM shipped you a search= able database every month or so and you could play with search args to find= something you couldn't make heads or tales out of. Of course now its IBMLI= NK (when it is up) and it functions the same and with reasonably more up to= date issues than the once a month tape shipment. The pubs people might have lost their way as it seems in the late 80's (esp= ecially with USS) components (I DO NOT MEAN UNFORMATTED SYSTEM SERVICES so = if anyone wants to get anal about the meaning I do not care. Ed=A0=A0=0A=0A=0A -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
Steve I could say that IBM-MAIN posts were getting worse what with commenting before the quoted post(s) - much preferred by yours truly - or commenting after the quoted posts and maybe not having quoted lines preceded by greater than signs, it can be quite difficult to find the fresh text! Chris Mason On Thu, 16 Jul 2009 09:46:07 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Thursday, July 16, 2009 12:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM error messages getting worse? --- On Thu, 7/9/09, Patrick O'Keefe patrick.oke...@wamu.net wrote: From: Patrick O'Keefe patrick.oke...@wamu.net Subject: Re: IBM error messages getting worse? To: IBM-MAIN@bama.ua.edu Date: Thursday, July 9, 2009, 2:29 PM On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews=20 d...@lists.duda.com wrote: I think you make a very good point.=A0 There have always been absolutely inscrutable MVS messages and there will probably be new ones.=A0 But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on=20 if they are so bad as to be considered a defect.=A0 I don't think it is=20 getting worse. Pat O'Keefe=A0=20 - Pat:I am not sure I agree , but I think that most USS messages are at best = inscrutable. Take TCP as an example most of the messages I had to look up a= t the time did not follow the IBM convention as to importance (W,I,E,C) and= then they didn't set the condition code to match the message. The conditio= n code IMO was the worse and it looked to me like they threw the dice when = it came to setting codes. Frankly I gave up and after reading the message i= n the manual 2 or 3 times and it still did not make sense I opened a PMR. I= very rarely got anyplace with the PMR as the USS people live in the own = universe separate from IBM. To me they decided to thumb their nose at the r= est of IBM and said we are going to operate as we like to hell with IBM and= their rules. I think the LE people weren't quite as bad, but they are up there. Do *NOT*= get me going on COBOL messages. Their so called self describing messages m= ust have been made up on a bad acid trip. In the past, say 1970 or so we can all agree that some messages like call = your systems programmer were nightmares especially at 3AM and there was no= IBM support to call back then.=A0 Since then (thanks to GUIDE anyway) we made the messages a MAJOR issue and = I can still remember 1 GUIDE where the pubs people came into GUIDE and prom= ised to do a better job. It actually did work, thank goodness. Messages act= ually started to mean something and they were reasonable english straightfo= rward and it might take you a bit to understand the famous VSAM messages th= at gave you a bunch of possibilities at an answer if you could discern if i= t was a FC or other type of RC or whatever. If you read it carefully enough= it did make sense (most of the time). That was about the time that (sorry = I do not remember the name of the IBM product) but IBM shipped you a search= able database every month or so and you could play with search args to find= something you couldn't make heads or tales out of. Of course now its IBMLI= NK (when it is up) and it functions the same and with reasonably more up to= date issues than the once a month tape shipment. The pubs people might have lost their way as it seems in the late 80's (esp= ecially with USS) components (I DO NOT MEAN UNFORMATTED SYSTEM SERVICES so = if anyone wants to get anal about the meaning I do not care. Ed=A0=A0=0A=0A=0A -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
Sorry, that reply was the result of a comedy of errors. Suffice to say that having multiple displays and M/S deciding that it will take focus... Well it resulted in the focus changing to Outlook with the mouse over the wrong SEND button (I had more than one reply screen up)... And my thoughts, relative to this thread, and in particular to what Mr. David Andrews brought out, I decided weren't necessary. Working for an ISV, being in PWD, having worked at IBM and thinking about how absolutely wonderful the BPX/OE world is and the associated highly descriptive and meaningful messages -- well, I decided to keep those comments and opinions to myself. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Thursday, July 16, 2009 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM error messages getting worse? Steve I could say that IBM-MAIN posts were getting worse what with commenting before the quoted post(s) - much preferred by yours truly - or commenting after the quoted posts and maybe not having quoted lines preceded by greater than signs, it can be quite difficult to find the fresh text! Chris Mason SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
--- On Thu, 7/9/09, Patrick O'Keefe patrick.oke...@wamu.net wrote: From: Patrick O'Keefe patrick.oke...@wamu.net Subject: Re: IBM error messages getting worse? To: IBM-MAIN@bama.ua.edu Date: Thursday, July 9, 2009, 2:29 PM On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews d...@lists.duda.com wrote: I think you make a very good point. There have always been absolutely inscrutable MVS messages and there will probably be new ones. But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on if they are so bad as to be considered a defect. I don't think it is getting worse. Pat O'Keefe - Pat:I am not sure I agree , but I think that most USS messages are at best inscrutable. Take TCP as an example most of the messages I had to look up at the time did not follow the IBM convention as to importance (W,I,E,C) and then they didn't set the condition code to match the message. The condition code IMO was the worse and it looked to me like they threw the dice when it came to setting codes. Frankly I gave up and after reading the message in the manual 2 or 3 times and it still did not make sense I opened a PMR. I very rarely got anyplace with the PMR as the USS people live in the own universe separate from IBM. To me they decided to thumb their nose at the rest of IBM and said we are going to operate as we like to hell with IBM and their rules. I think the LE people weren't quite as bad, but they are up there. Do *NOT* get me going on COBOL messages. Their so called self describing messages must have been made up on a bad acid trip. In the past, say 1970 or so we can all agree that some messages like call your systems programmer were nightmares especially at 3AM and there was no IBM support to call back then. Since then (thanks to GUIDE anyway) we made the messages a MAJOR issue and I can still remember 1 GUIDE where the pubs people came into GUIDE and promised to do a better job. It actually did work, thank goodness. Messages actually started to mean something and they were reasonable english straightforward and it might take you a bit to understand the famous VSAM messages that gave you a bunch of possibilities at an answer if you could discern if it was a FC or other type of RC or whatever. If you read it carefully enough it did make sense (most of the time). That was about the time that (sorry I do not remember the name of the IBM product) but IBM shipped you a searchable database every month or so and you could play with search args to find something you couldn't make heads or tales out of. Of course now its IBMLINK (when it is up) and it functions the same and with reasonably more up to date issues than the once a month tape shipment. The pubs people might have lost their way as it seems in the late 80's (especially with USS) components (I DO NOT MEAN UNFORMATTED SYSTEM SERVICES so if anyone wants to get anal about the meaning I do not care. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
How about this one: 0ADR472E (009)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET SVS.RESZP1.OMVS.ROOT IN CATALOG CATALOG.TEST, 04 You'd think the volume was full. But in the end, I found out that the dataset name was already in use. And not the one listed, but the name I was trying to renunc to! Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville kenneth.kl...@kyfb.com 502-495-5000 x7011 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mattson Sent: Wednesday, July 08, 2009 5:33 PM To: IBM-MAIN@bama.ua.edu Subject: IBM error messages getting worse? Am I just getting more cranky as I age, or are IBM messages getting ever more obtuse? I just submitted a simple JCL error. Just put in a VOL=SER=XX where XX is a volume we do not have in our shop. Should be a simple error, with a simple IBM Message saying That VOLSER does not exist, or is not online (dummy). I would swear that used to be some such. But what I got was EDG8197I VOLUME HFS009 IS NOT DFSMSrmm MANAGED Here is the expanded JCL. so you might see that it is not talking about tape. and NO, F83D is not a tape unit address, it is the unit address of HFS000, and that was my typo. XXDASD DD DISP=OLD,UNIT=/U,VOL=SER=V IEFC653I SUBSTITUTION JCL - DISP=OLD,UNIT=/F83D,VOL=SER=HFS009 There are a number of other examples of this, but now I am going to start keeping track of them. This message is worse than useless, it misleads the unwary into thinking that RMM is involved in the problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Wed, 2009-07-08 at 17:33 -0400, John Mattson wrote: Am I just getting more cranky as I age, or are IBM messages getting ever more obtuse? I wouldn't say more obtuse. Remember this chestnut? IEB817I MEMBER NAME NOT FOUND IN NM DIRECTORY. STOWED WITH TTR. which meant: I added a new member to your PDS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Thu, 9 Jul 2009 08:21:22 -0400, David Andrews d...@lists.duda.com wrote: On Wed, 2009-07-08 at 17:33 -0400, John Mattson wrote: Am I just getting more cranky as I age, or are IBM messages getting ever more obtuse? I wouldn't say more obtuse. Remember this chestnut? IEB817I MEMBER NAME NOT FOUND IN NM DIRECTORY. STOWED WITH TTR. which meant: I added a new member to your PDS. I think you make a very good point. There have always been absolutely inscrutable MVS messages and there will probably be new ones. But there are many prefectly clear ones, too, and there is that message id you can look up, run searches on, submit RCFs on (if those still exist ... and are read), or even open PMRs on if they are so bad as to be considered a defect. I don't think it is getting worse. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
There have always been absolutely inscrutable MVS messages and there will probably be new ones. Can you say COBOL, boys and girls? These obscure ones are so 'self-documenting' that there is no reason to document them! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM error messages getting worse?
Am I just getting more cranky as I age, or are IBM messages getting ever more obtuse? I just submitted a simple JCL error. Just put in a VOL=SER=XX where XX is a volume we do not have in our shop. Should be a simple error, with a simple IBM Message saying That VOLSER does not exist, or is not online (dummy). I would swear that used to be some such. But what I got was EDG8197I VOLUME HFS009 IS NOT DFSMSrmm MANAGED Here is the expanded JCL. so you might see that it is not talking about tape. and NO, F83D is not a tape unit address, it is the unit address of HFS000, and that was my typo. XXDASD DD DISP=OLD,UNIT=/U,VOL=SER=V IEFC653I SUBSTITUTION JCL - DISP=OLD,UNIT=/F83D,VOL=SER=HFS009 There are a number of other examples of this, but now I am going to start keeping track of them. This message is worse than useless, it misleads the unwary into thinking that RMM is involved in the problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
