Re: Comments on DFSMS verbose messages?
In 3058465022590439.wa.wkkelleyoptonline@bama.ua.edu, on 05/10/2012 at 08:28 PM, W. Kevin Kelley wkkel...@optonline.net said: Based on the feedback that we had received from the ESP customers, the comments that I have received here were a surprise; I had expected the comments to have gone in other directions. Why? The comments here were that it should be under the control of the site; I doubt that any of the ESP customers would object. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/11/2012 8:47 AM, Shmuel Metz (Seymour J.) wrote: In3058465022590439.wa.wkkelleyoptonline@bama.ua.edu, on 05/10/2012 at 08:28 PM, W. Kevin Kelleywkkel...@optonline.net said: Based on the feedback that we had received from the ESP customers, the comments that I have received here were a surprise; I had expected the comments to have gone in other directions. Why? The comments here were that it should be under the control of the site; I doubt that any of the ESP customers would object. Precisely! Why on Earth would 'overreactive' ESP regressives wish to prevent me from getting the behavior I want so long as they are able to get the behavior THEY want? Perhaps some of them strive to be politicians... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
My suspicion would be that it got enable to shoot somebody's particular bug and maybe didn't get switched off for the GA release. a message dated 5/11/2012 4:30:15 P.M. Central Daylight Time, edja...@phoenixsoftware.com writes: getting the behavior I want so long as they are able to get the behavior THEY want? Perhaps some of them strive to be politicians... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Hey guys, lighten up. IBM went out of their way to discuss this with ESP customers who already had first hand experience with the effects of the change. I don't remember anyone beating the drum to retain verbose messages in syslog/operlog. After slogging through this thread, I still don't understand the hunger for yet more detritus in the common log. Our concern was never about sinking the ship under the weight of a few thousand more lines of data: it was the prospect of having to wade through ever more repetitive verbatim snippets of message manuals. That's all this is! Remember also that this is IBM's first venture into this arena. Today it's only O/C/E messages. The function could well be extended (no promises) to other components as well. Would we have to be able to selectively turn on or off each one according to everyone's particular druthers? Would it really be worth scarce development resources to establish yet another elaborate option facility to slice and dice all possible choices? Not for my $$. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ed Finnell efinnel...@aol.com To: IBM-MAIN@bama.ua.edu Date: 05/11/2012 02:43 PM Subject:Re: Comments on DFSMS verbose messages? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu My suspicion would be that it got enable to shoot somebody's particular bug and maybe didn't get switched off for the GA release. a message dated 5/11/2012 4:30:15 P.M. Central Daylight Time, edja...@phoenixsoftware.com writes: getting the behavior I want so long as they are able to get the behavior THEY want? Perhaps some of them strive to be politicians... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Yeah you'd think that this day and age some common options and corporate standards would kick in. f asid,verbose(on|off) would be useful to a number of components? In a message dated 5/11/2012 6:03:26 P.M. Central Daylight Time, jo.skip.robin...@sce.com writes: or off each one according to everyone's particular druthers? Would it really be worth scarce development resources to establish yet another elaborate option facility to slice and dice all possible choices? Not for my $$. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Ed, We do it with a debug=y or n, n= no messages unless a failure occurs, y= yes gives you verbose Scott ford www.identityforge.com On May 12, 2012, at 12:18 AM, Ed Finnell efinnel...@aol.com wrote: . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Mark, Based on the feedback that we had received from the ESP customers, the comments that I have received here were a surprise; I had expected the comments to have gone in other directions. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Mon, 7 May 2012 20:49:12 -0500, W. Kevin Kelley wkkel...@optonline.net wrote: Mark, I understand your frustration, and I can only suggest that you do what is appropriate for your customer. If you wish to open a formal complaint about what you view as a loss of function, that is of course your decision. The manner of delivery and the timeliness with which the support was delivered are result of a commitment that we made to the ESP customers. Please note that there was no z/OS Console Support involvement in the original DFSMS R13 support: it was unique to DFSMS; the current support is not. W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development Kevin, It's not a loss of function since I'm not even using it in production yet. However, if you / your employer's attitude is that it is now my issue to deal with and I need to take the ball and run with it as far as a complaint or new SHARE requirement or whatever the case may be, then what was your point in posting to IBM-MAIN to solicit feedback to begin with? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
In a6b9336cdb62bb46b9f8708e686a7ea00e924b4...@nrhmms8p02.uicnrh.dom, on 05/08/2012 at 12:05 PM, McKown, John john.mck...@healthmarkets.com said: Sort of. ? It does not set the AMODE of the currently executing program, true. Nor does it change the AMODE of the loaded program to that of the PSW. Don't confuse the value returned in R0 with the bits it sets in the CDE. Actually it returns the AMODE of the LOAD'ed module in GPR0. Correct. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
In 4fa956bd.6000...@trainersfriend.com, on 05/08/2012 at 11:24 AM, Steve Comstock st...@trainersfriend.com said: But if the AMODE of the loaded module is any, then the returned amode bits (in GPR0) are based on the AMODE of the invoker. True, but *not* the bits in the CDE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
In 4fa7ede9.2060...@trainersfriend.com, on 05/07/2012 at 09:44 AM, Steve Comstock st...@trainersfriend.com said: LOAD is a system service; it will set the bits to the AMODE of the program issuing the service call. Are you sure? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Sort of. It does not set the AMODE of the currently executing program, true. Actually it returns the AMODE of the LOAD'ed module in GPR0. Perhaps the OP was a bit loose in his phrasing. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9C0/ -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, May 08, 2012 9:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Comments on DFSMS verbose messages? In 4fa7ede9.2060...@trainersfriend.com, on 05/07/2012 at 09:44 AM, Steve Comstock st...@trainersfriend.com said: LOAD is a system service; it will set the bits to the AMODE of the program issuing the service call. Are you sure? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/8/2012 11:05 AM, McKown, John wrote: Sort of. It does not set the AMODE of the currently executing program, true. Actually it returns the AMODE of the LOAD'ed module in GPR0. Perhaps the OP was a bit loose in his phrasing. Quite. Sorry about that. Of course, LOAD doesn't set any PSW amode bits, since the service does not run the loaded module. But if the AMODE of the loaded module is any, then the returned amode bits (in GPR0) are based on the AMODE of the invoker. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9C0/ -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, May 08, 2012 9:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Comments on DFSMS verbose messages? In4fa7ede9.2060...@trainersfriend.com, on 05/07/2012 at 09:44 AM, Steve Comstockst...@trainersfriend.com said: LOAD is a system service; it will set the bits to the AMODE of the program issuing the service call. Are you sure? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; seehttp://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Sun, 6 May 2012 23:23:14 -0400, Robert A. Rosenberg wrote: The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). If I code AMODE-31 I can have problems with something that needs AMODE-24. There needs to be am AMODE (such as ALL) to say that all 3 AMODES (24/31/64) are supported. Errr... But when AMODE 128 happens, will ALL automatically include that, or will it once again have a counterintuitive meaning? Rather customers should be encouraged to use AMODE(24,31,64), but to use AMODE(ALL) only if they are prepared to accommodate any future extensions to addressing modes. AMODE(128) is perhaps unrealistic (nowadays, but 120-bit addressing is in the architecture of ZFS (I don't mean zFS)). But in the context of the original topic, the possibility of a new DFSMS message destination is realistic and should be taken into account. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Sun, 6 May 2012 23:23:14 -0400, Robert A. Rosenberg wrote: The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). Where does AMODE(ANY) mean both? Certainly not on the AMODE assembler instruction or in the binder. If I code AMODE-31 I can have problems with something that needs AMODE-24. yes. There needs to be am AMODE (such as ALL) to say that all 3 AMODES (24/31/64) are supported. That makes no sense. Addressing mode is set in the PSW and it tells the processor how to behave. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/7/2012 7:54 AM, Tom Marchant wrote:
On Sun, 6 May 2012 23:23:14 -0400, Robert A. Rosenberg wrote:
The problem is that before 64 AMODE you had 3 AMODE Choices -
24-Only, 31-Only, or BOTH 24 and 31 (ie: Any).
Where does AMODE(ANY) mean both? Certainly not on the
AMODE assembler instruction or in the binder.
AMODE ANY means the program will be given control in
the AMODE of its invoker and supports running in AMODE24
or AMODE31, whichever it's caller is currently running in.
And, yes, you can specify AMODE ANY in the Assembler and
in the binder.
In fact, the ASSEMBLER supports:
AMODE {24|31|64|ANY|ANY31|ANY64}
the Binder supports
AMODE {24|31|ANY|64|MIN}
If I code AMODE-31 I
can have problems with something that needs AMODE-24.
yes.
There needs to
be am AMODE (such as ALL) to say that all 3 AMODES (24/31/64) are
supported.
That makes no sense. Addressing mode is set in the PSW
and it tells the processor how to behave.
It does make sense, if you consider it as the required /
recommended / suggested initial AMODE, recognizing that
programs may change AMODE as they run.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Mon, 7 May 2012 08:09:45 -0600, Steve Comstock wrote: AMODE ANY means the program will be given control in the AMODE of its invoker and supports running in AMODE24 or AMODE31, whichever it's caller is currently running in. Of course this contradicts the conventional English notion of any in that it excludes AMODE64. Granted that conventional words may be overloaded with technical terms with specialized meaning, but such direct confrontation should be avoided. And, yes, you can specify AMODE ANY in the Assembler and in the binder. If Binder marks a load module AMODE(ANY), you say that ATTACH (e.g.) passes it control in the caller's AMODE, right? If a load module is marked AMODE(24) or AMODE(31), will ATTACH pass it control in that AMODE regardless of the caller's addressing mode? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/7/2012 8:25 AM, Paul Gilmartin wrote: On Mon, 7 May 2012 08:09:45 -0600, Steve Comstock wrote: AMODE ANY means the program will be given control in the AMODE of its invoker and supports running in AMODE24 or AMODE31, whichever it's caller is currently running in. Of course this contradicts the conventional English notion of any in that it excludes AMODE64. Granted that conventional words may be overloaded with technical terms with specialized meaning, but such direct confrontation should be avoided. It is what it is. And, yes, you can specify AMODE ANY in the Assembler and in the binder. If Binder marks a load module AMODE(ANY), you say that ATTACH (e.g.) passes it control in the caller's AMODE, right? If a load module is marked AMODE(24) or AMODE(31), will ATTACH pass it control in that AMODE regardless of the caller's addressing mode? -- gil ATTACH will pass control in the module's AMODE regardless of the current AMODE of the attacher. Perhaps more intriguing: each entry point in a load module / program object has its own AMODE specification. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Sun, 6 May 2012 20:03:43 -0500, W. Kevin Kelley wkkel...@optonline.net wrote: Mark, You are correct -- there is now no option to put the additional lines of explanation in the SYSLOG/OPERLOG. We reacted to what we heard from the ESP customers, and to quote you perhaps they overreacted. That is why I put the post out here, to hear what other people think. But a little late. Really... if the change wasn't made pre-GA (and documented) based on ESP feedback, I don't understand why the change was made now in the service stream without soliciting more feedback from other customers. So now what? Do I have to put a user hold on UA64502 to make sure it doesn't get applied in our normal maintenance procedures, or will it get marked PE via current HOLDDATA until something newer is available? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Mon, 7 May 2012 08:09:45 -0600, Steve Comstock wrote: On 5/7/2012 7:54 AM, Tom Marchant wrote: On Sun, 6 May 2012 23:23:14 -0400, Robert A. Rosenberg wrote: The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). Where does AMODE(ANY) mean both? Certainly not on the AMODE assembler instruction or in the binder. AMODE ANY means the program will be given control in the AMODE of its invoker No, it doesn't. Regardless of AMODE specification, a program that is invoked with BASR or BALR will get control in the AMODE of its caller. A program that is invoked with BASSM will have the AMODE set based upon the value of bits 32 and 63 in register 15 (assuming standard linkage conventions). When a load module that is marked AMODE ANY is LOADed, which way are these bits set in the entry point address? Of course, if a module that was assembled AMODE ANY is bound with another module that has its AMODE set to 24 or 31, the resulting load module will have its AMODE set to 24 or 31, respectively. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/7/2012 9:29 AM, Tom Marchant wrote: On Mon, 7 May 2012 08:09:45 -0600, Steve Comstock wrote: On 5/7/2012 7:54 AM, Tom Marchant wrote: On Sun, 6 May 2012 23:23:14 -0400, Robert A. Rosenberg wrote: The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). Where does AMODE(ANY) mean both? Certainly not on the AMODE assembler instruction or in the binder. AMODE ANY means the program will be given control in the AMODE of its invoker No, it doesn't. Regardless of AMODE specification, a program that is invoked with BASR or BALR will get control in the AMODE of its caller. Well, OK. I am talking about an invoker using system services LOAD / LINK / ATTACH / XCTL. A program that is invoked with BASSM will have the AMODE set based upon the value of bits 32 and 63 in register 15 (assuming standard linkage conventions). Yes, yes. When a load module that is marked AMODE ANY is LOADed, which way are these bits set in the entry point address? LOAD is a system service; it will set the bits to the AMODE of the program issuing the service call. Of course, if a module that was assembled AMODE ANY is bound with another module that has its AMODE set to 24 or 31, the resulting load module will have its AMODE set to 24 or 31, respectively. Unless you override it with binder control statements. You can, indeed, shoot yourself in the foot here, if you work at it. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
So far complaints on the new verbose behavior seem to have come from folks who are not yet running R13. The ESP customers who induced the change were already immersed in R13 and knew first hand how *useless* verbose messages are in syslog/operlog. Does everyone understand that verbose messages are nothing but chunks of prose lifted from the message manual? They are not sophisticated diagnostic guides that might provide unique insight into solving a particular abend. They just save you a trip to your favorite doc library. Over and over ad nauseam. These endlessly repetitive annotations clutter up syslog/operlog. Flotsam and jetsam that we can all live better with in a location closer to the actual problem. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: W. Kevin Kelley wkkel...@optonline.net To: IBM-MAIN@bama.ua.edu Date: 05/06/2012 06:04 PM Subject:Re: Comments on DFSMS verbose messages? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Mark, You are correct -- there is now no option to put the additional lines of explanation in the SYSLOG/OPERLOG. We reacted to what we heard from the ESP customers, and to quote you perhaps they overreacted. That is why I put the post out here, to hear what other people think. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Mon, 7 May 2012 09:45:23 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: So far complaints on the new verbose behavior seem to have come from folks who are not yet running R13. I am running it in 6 sandbox environments, but you are correct that it hasn't hit development nor production yet. I like what I see so far. The ESP customers who induced the change were already immersed in R13 and knew first hand how *useless* verbose messages are in syslog/operlog. Does everyone understand that verbose messages are nothing but chunks of prose lifted from the message manual? They are not sophisticated diagnostic guides that might provide unique insight into solving a particular abend. They just save you a trip to your favorite doc library. Over and over ad nauseam. These endlessly repetitive annotations clutter up syslog/operlog. Flotsam and jetsam that we can all live better with in a location closer to the actual problem. . See my previous post that had real life numbers on what I expect to see. Hardly a clutter compared to what is already in syslog/operalog. I asked for some of you ESP people who gave the initial feedback (or anyone else) for your real life numbers as to what you considered clutter. I haven't seen any responses yet. See the last paragraph of this post: https://bama.ua.edu/cgi-bin/wa?A2=ind1205L=ibm-mainD=1O=DT=0P=140934 -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
I asked for some of you ESP people who gave the initial feedback (or anyone else) for your real life numbers as to what you considered clutter. I haven't seen any responses yet. See the last paragraph of this post: Well, I agree with Mark. I think it's helpful, particularly as we have a lot of people who aren't that familiar with z/OS, and the cost is minimal. We installed 1.13 in production (such as it is here) in October 2011, and had an early version running 10-11 months before that. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Mark, I understand your frustration, and I can only suggest that you do what is appropriate for your customer. If you wish to open a formal complaint about what you view as a loss of function, that is of course your decision. The manner of delivery and the timeliness with which the support was delivered are result of a commitment that we made to the ESP customers. Please note that there was no z/OS Console Support involvement in the original DFSMS R13 support: it was unique to DFSMS; the current support is not. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
In of94172e54.f408defa-on852579f5.00781b99-852579f5.00789...@us.ibm.com, on 05/05/2012 at 05:56 PM, Peter Relson rel...@us.ibm.com said: Tongue in cheek: sorry for not being prescient enough in (approximately) 1977 to think that someone might ever need 64-bits worth of addressability. You didn't need to be prescient, just extrapolate long term trends. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Brian, If you are not receiving our Interface Change Notifications (ICNs), then we need to get that fixed. All of the automation venders that we interacted with were notified through that process and contacted me as a result. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Mark, You are correct -- there is now no option to put the additional lines of explanation in the SYSLOG/OPERLOG. We reacted to what we heard from the ESP customers, and to quote you perhaps they overreacted. That is why I put the post out here, to hear what other people think. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
At 17:56 -0400 on 05/05/2012, Peter Relson wrote about Re: Comments on DFSMS verbose messages?: Please avoid an absurdity such as AMODE(ANY), where ANY no longer means any, but instead any except 64. Tongue in cheek: sorry for not being prescient enough in (approximately) 1977 to think that someone might ever need 64-bits worth of addressability. It seems obvious now. No, really: I agree. And that is why those options are available in other forms now which I recommend that you use -- such as '31' instead of ANY in AMODE, or in the LOC parameters of STORAGE OBTAIN. We will never remove support for ANY. We can only encourage you to use better choices. The problem is that before 64 AMODE you had 3 AMODE Choices - 24-Only, 31-Only, or BOTH 24 and 31 (ie: Any). If I code AMODE-31 I can have problems with something that needs AMODE-24. There needs to be am AMODE (such as ALL) to say that all 3 AMODES (24/31/64) are supported. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Hi Kevin, In my shop, all of our support staff have access to view syslog/operlog , both the active and previous. W e would want to see the messaging in the syslog/operlog AND the joblog , but would want to have the ability to filter the verbose lines off of the console. This is not an effort on my par t to avoid looking up messages, but lean budgets have hit us hard, and we have lost a lot of staff. Those few of us who are left are happy for things that could save us time, especially when we are called to support a problem and have to do it on our own time. We are not at 1.13 yet and I have not seen examples of the messaging yet. Some of our customers use our central sysout repository, but our staff generally does not have access to the joblog there, except for the responsible application programmer, who would not be likely to be able use the information. Sysprogs do not have access to customer batch. For our customers who use a remote or off platform sysout respository, we have little or no access there . Thanks, Linda - Original Message - From: W. Kevin Kelley wkkel...@optonline.net To: IBM-MAIN@bama.ua.edu Sent: Thursday, May 3, 2012 6:46:29 PM Subject: Comments on DFSMS verbose messages? In z/OS R13, DFSMS changed approximately 400 of their rather cryptic IEC error messages to include additional lines of explanation. Feedback from R13 ESP customers indicated that the additional lines of explanation were appreciated for end-users but were not wanted in the SYSLOG/OPERLOG or on consoles. A suggestion was made that the additional lines of explanation be written only to the JOBLOG and not to other places that the message might go. z/OS OA37957 and DFSMS OA37505 provide the suggested support: the additional lines of explanation -- now referred to as verbose message lines -- are written only to the JOBLOG; they are not included with the message if it is written to the SYSLOG/OPERLOG or queued to a console. A new .MSGOPTION statement has been added to MPFLSTxx to allow you to enable or disable verbose message support at a system level: if the support is disabled (the default), the DFSMS error messages will not include additional lines of explanation; if the support is enabled, the DFSMS error messages will include the additional lines of explanation, but the verbose message lines will be written only to the JOBLOG. The DISPLAY MPF command response now displays the MSGOPTION enablement state. If verbose message support is enabled, the additional message lines are visible in MPF exits and are visible on the Subsystem Interface (SSI). The following control blocks have been modified to provide an indication if a verbose message line is present: WPL, WQE, CTXT and MDB. We have been in contact with the various automation venders and they are all aware of how to recognize verbose message lines. We expect that most venders will choose to ignore the verbose message lines. Any comments/criticisms/suggestions? 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Please avoid an absurdity such as AMODE(ANY), where ANY no longer means any, but instead any except 64. Tongue in cheek: sorry for not being prescient enough in (approximately) 1977 to think that someone might ever need 64-bits worth of addressability. It seems obvious now. No, really: I agree. And that is why those options are available in other forms now which I recommend that you use -- such as '31' instead of ANY in AMODE, or in the LOC parameters of STORAGE OBTAIN. We will never remove support for ANY. We can only encourage you to use better choices. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Hi, I realize you said that you contacted the Automation Software companies, but you didn't contact us. We have hundreds of sites running our automation software, and while we were aware of how to process and not process the verbose messages, we were never contacted from you (or anyone) to ask our opinion and you didn't even inform us it was going to happen until it already was shipped and by then we already knew about it from our own testing. We had to figure it out for ourselves and be able to handle it before IBM would even acknowledge the change. For the most part, from what I can see of the actual messages that are generated, the verbose messages are a huge waste of resources. I'm happy that IBM sets the default to NOT generate those messages. There are a great number of messages that could have been changed to provide more or better information, but providing information that should have stayed in the documentation (manuals) was (in my opinion) a bad decision and a waste of resources. I realize that CPUs are a lot faster than they have ever been, but using the resources on frivolous things like keeping people from having to look up a message by always printing the verbose text is silly. Most people have the manuals available to them electronically, and the ones who don't probably wouldn't be the one who is going to have to look up the message in the first place. Sorry for the rant, I was just very surprised by the way you presented the question which made it look like you consulted or even informed the automation software vendors before you planned to make the change. It's not like there are that many of us and you could have at least acknowledged the change when we asked about it instead of ignoring the question and (even worse) bringing the subject up on a public forum. Makes me feel all warm and fuzzy about my relationship with IBM. Brian Westerman Syzygy Incorporated -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
In 5625217423916820.wa.wkkelleyoptonline@bama.ua.edu, on 05/03/2012 at 08:46 PM, W. Kevin Kelley wkkel...@optonline.net said: Any comments/criticisms/suggestions? Suggestion: allow .MSGOPTION to enable writing the verbose message lines to SYSLOG/OPERLOG. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Thu, 3 May 2012 22:03:03 -0500, W. Kevin Kelley wkkel...@optonline.net wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? The DEVSUPxx external has been deprecated and replaced by the MPFLSTxx .MSGOPTION statement. What if you want the original behavior? I ask, because I like it. So you'd like the option of being able to have verbose message lines optionally go places other than JOBLOG? Yes, the syslog / operlog. As I mentioned in my last post, I often go to the syslog even before looking at a joblog and I'm sure the operations staff (operators, production control, job scheduling, etc.) do the same. It's really them I am more concerned about. I've lived without the long messages for a long time now. :-) It could also confuse them if a user calls and describes a message they see in their joblog that isn't in the syslog. Depending on the job, the operations person may not even be able to view the output in SDSF due to security restrictions. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Fri, 4 May 2012 03:57:24 -0500, Brian Westerman brian_wester...@syzygyinc.com wrote: I realize that CPUs are a lot faster than they have ever been, but using the resources on frivolous things like keeping people from having to look up a message by always printing the verbose text is silly. Most people have the manuals available to them electronically, and the ones who don't probably wouldn't be the one who is going to have to look up the message in the first place. This is sort of funny, because there have been so many rants on ibm-main about lack of good messages in z/OS unix (and some other areas) and here IBM is trying to take one of the strong points of our platform and make it better (optionally) and there are complaints by some. I realize that it isn't IEC* messages that get those rants though. I don't have access to quickref, and again, it isn't myself I am advocating for. It is the end users / operations staff. If the messages are right there in the joblog / syslog, no one has to look up a message anywhere. And right now I am at a shop with probably about 80-90% of the entire mainframe operations staff with 5 years or less of experience. Anyway, Brian brings up a slightly interesting point to me. Can the overhead even be measured on a normal system. I suppose if you generated a test case with thousands of B37s in a short period of time you could measure the difference. Did IBM do this in a lab? I still don't get the concern about some extra data being written to the syslog. For the person(s) who were concerned: Can you please tell me how many lines you used to write to syslog on avg. each day and then what the difference was when you turned on the verbose messages with 1.13? I don't have 1.13 in production yet, but I just looked at the syslog from a typical / medium sized production LPAR at my client. The syslog cut at midnight last night (24 hours) has about 450,000 lines in it.I think exactly 35 messages would have generated the verbose description.So a whopping ~ 200 extra lines of syslog would have been written - an increase of .04% to store that data wherever you store it. I did the same thing for a development LPAR since I expected to see more x37 abends. I found about 100 messages there out of about 350,000 or ~ .17%.But since most are production LPARs (and things like SAP and Websphere LPARs don't even run batch), overall for the environment I would expect the average increase to be more along the lines of .04%. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/3/2012 9:48 PM, W. Kevin Kelley wrote: In z/OS R13, DFSMS changed approximately 400 of their rather cryptic IEC error messages to include additional lines of explanation. Feedback from R13 ESP customers indicated that the additional lines of explanation were appreciated for end-users but were not wanted in the SYSLOG/OPERLOG or on consoles. A suggestion was made that the additional lines of explanation be written only to the JOBLOG and not to other places that the message might go. z/OS OA37957 and DFSMS OA37505 provide the suggested support: the additional lines of explanation -- now referred to as verbose message lines -- are written only to the JOBLOG; they are not included with the message if it is written to the SYSLOG/OPERLOG or queued to a console. A new .MSGOPTION statement has been added to MPFLSTxx to allow you to enable or disable verbose message support at a system level: if the support is disabled (the default), the DFSMS error messages will not include additional lines of explanation; if the support is enabled, the DFSMS error messages will include the additional lines of explanation, but the verbose message lines will be written only to the JOBLOG. The DISPLAY MPF command response now displays the MSGOPTION enablement state. If verbose message support is enabled, the additional message lines are visible in MPF exits and are visible on the Subsystem Interface (SSI). The following control blocks have been modified to provide an indication if a verbose message line is present: WPL, WQE, CTXT and MDB. We have been in contact with the various automation venders and they are all aware of how to recognize verbose message lines. We expect that most venders will choose to ignore the verbose message lines. Any comments/criticisms/suggestions? W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development Kevin, These messages are a good idea, so please don't be deterred in your efforts to bring this technology to other components. This technology will save thousands, perhaps millions of man hours around the world spent looking up common error messages, when simple explanations in the joblog can tell you exactly what's wrong. This will be a huge productivity boost. You and others spent a lot of time describing these messages at the TDM and in other forums, so notifications were available for vendors in PartnerWorld, members of SHARE attending the closed meetings, etc. I'm not sure what else you can do to get the word out. I think the MPFLST option should be something like JOBLOG, SYSLOG, or BOTH. That should satisfy the needs of all parties. My choice would be BOTH. Thanks again for this enhancement. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/3/2012 7:15 PM, Mark Zelden wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it. I also like the current behavior. Job logs come and go, but the system log is forever. ESP for z/OS 1.13 began in late spring 2011. Some of the participants probably overreacted. People don't like change. The release went GA in September 2011. Many shops have already migrated and many more are doing so. There was no 'blood in the streets'. I can't recall hearing or reading any negative mention of this new functionality until Kevin's post. When I first read the ICN (Interface Change Notification) about this new 'verbose' message support, I thought This is much ado about nothing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
I was in the ESP and joined the follow-on conversations about the increased message traffic. The concern was not about a weightier syslog/operlog, but about the even denser weed patch that one has to wade through in syslog/operlog in order to troubleshoot some other totally unrelated problem. How many times do 'we' have to slog through the same explanation of essentially the mundane error? The verbose explanation does not tell a sysprog anything more useful than the ancient and venerable message itself: error code, return code, data set name, volume. Why would a sysprog need anything more than that? I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@bama.ua.edu Date: 05/04/2012 08:43 AM Subject:Re: Comments on DFSMS verbose messages? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 5/3/2012 7:15 PM, Mark Zelden wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it. I also like the current behavior. Job logs come and go, but the system log is forever. ESP for z/OS 1.13 began in late spring 2011. Some of the participants probably overreacted. People don't like change. The release went GA in September 2011. Many shops have already migrated and many more are doing so. There was no 'blood in the streets'. I can't recall hearing or reading any negative mention of this new functionality until Kevin's post. When I first read the ICN (Interface Change Notification) about this new 'verbose' message support, I thought This is much ado about nothing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
I would love some software, preferable hosted on z/OS, which could do a context sensitive search of the syslog/operlog. Along with a __good__ repository. There may be such a thing already. I would know because we are a dying shop. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Skip Robinson Sent: Friday, May 04, 2012 10:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Comments on DFSMS verbose messages? I was in the ESP and joined the follow-on conversations about the increased message traffic. The concern was not about a weightier syslog/operlog, but about the even denser weed patch that one has to wade through in syslog/operlog in order to troubleshoot some other totally unrelated problem. How many times do 'we' have to slog through the same explanation of essentially the mundane error? The verbose explanation does not tell a sysprog anything more useful than the ancient and venerable message itself: error code, return code, data set name, volume. Why would a sysprog need anything more than that? I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@bama.ua.edu Date: 05/04/2012 08:43 AM Subject:Re: Comments on DFSMS verbose messages? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 5/3/2012 7:15 PM, Mark Zelden wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it. I also like the current behavior. Job logs come and go, but the system log is forever. ESP for z/OS 1.13 began in late spring 2011. Some of the participants probably overreacted. People don't like change. The release went GA in September 2011. Many shops have already migrated and many more are doing so. There was no 'blood in the streets'. I can't recall hearing or reading any negative mention of this new functionality until Kevin's post. When I first read the ICN (Interface Change Notification) about this new 'verbose' message support, I thought This is much ado about nothing. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Fri, 4 May 2012 08:56:38 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? Because unless I misread Kevin's post, it didn't sound like syslog/operlog was even an option. That is the part I'm complaining about. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Fri, 4 May 2012 08:42:37 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: On 5/3/2012 7:15 PM, Mark Zelden wrote: If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it. I also like the current behavior. Job logs come and go, but the system log is forever. ESP for z/OS 1.13 began in late spring 2011. Some of the participants probably overreacted. People don't like change. That was my first thought also. The release went GA in September 2011. Many shops have already migrated and many more are doing so. Right... I will be starting production migration in about a month and it will continue throughout the summer (about 25 prod / devl LPARs). My migration plan already includes updating DEVSUPxx. Now depending upon where I am at with maintenance, I may have to account for this the change being made mid-stream in my migration. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/4/2012 8:56 AM, Skip Robinson wrote: I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? You misunderstood. With the new design, the messages will NEVER appear on syslog/operlog. This is the complaint. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On 5/4/2012 7:52 AM, Thomas Conley wrote: I think the MPFLST option should be something like JOBLOG, SYSLOG, or BOTH. That should satisfy the needs of all parties. My choice would be BOTH. Thanks again for this enhancement. I like this idea. However, I would caution against the use of the word 'BOTH' since that would preclude a third verbose message destination being added in the future. I would suggest a simple list of possible verbose message destinations. Currently, the list would support zero, one or two destinations. Perhaps keyword=SYSLOG, keyword=JOBLOG, and keyword=(SYSLOG,JOBLOG) or some such... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Touche. Since I don't want verbosity in my syslog/operlog, I failed to notice the consequence for those who might. The original intent of explanatory messages was to assist the programmer or production control person or whoever has responsibility for fixing the problem to better understand the failure. If a job owner cannot get access to joblog after the fact, that would seem to be a problem inviting operational reform, not functional changes in z/OS. BTW in ESP conversations on this topic, I suggested that another candidate for explanatory messages might be the menagerie of x78/x0A failures that I can never keep straight: get vs. free, private vs. common, above vs. below, etc. I can use all the help I can get. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@bama.ua.edu Date: 05/04/2012 10:05 AM Subject:Re: Comments on DFSMS verbose messages? Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 5/4/2012 8:56 AM, Skip Robinson wrote: I like the solution. The installation can turn verbose on or off globally. The new 'filter' allows us to direct long explanations to just the programmer--my preference--or to syslog/operlog. Why complain about 'too much control'? You misunderstood. With the new design, the messages will NEVER appear on syslog/operlog. This is the complaint. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Fri, 4 May 2012 10:12:30 -0700, Edward Jaffe wrote: On 5/4/2012 7:52 AM, Thomas Conley wrote: I think the MPFLST option should be something like JOBLOG, SYSLOG, or BOTH. That should satisfy the needs of all parties. I like this idea. However, I would caution against the use of the word 'BOTH' since that would preclude a third verbose message destination being added in the future. I would suggest a simple list of possible verbose message destinations. Currently, the list would support zero, one or two destinations. Perhaps keyword=SYSLOG, keyword=JOBLOG, and keyword=(SYSLOG,JOBLOG) or some such... Indeed. Please avoid an absurdity such as AMODE(ANY), where ANY no longer means any, but instead any except 64. If you must supply ANY as a shorthand, put users on notice that future new destinations shall be added to ANY. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Looks like some words got repeated when my message got posted. 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
On Thu, 3 May 2012 20:46:29 -0500, W. Kevin Kelley wkkel...@optonline.net wrote: In z/OS R13, DFSMS changed approximately 400 of their rather cryptic IEC error messages to include additional lines of explanation. Feedback from R13 ESP customers indicated that the additional lines of explanation were appreciated for end-users but were not wanted in the SYSLOG/OPERLOG or on consoles. A suggestion was made that the additional lines of explanation be written only to the JOBLOG and not to other places that the message might go. z/OS OA37957 and DFSMS OA37505 provide the suggested support: the additional lines of explanation -- now referred to as verbose message lines -- are written only to the JOBLOG; they are not included with the message if it is written to the SYSLOG/OPERLOG or queued to a console. A new .MSGOPTION statement has been added to MPFLSTxx to allow you to enable or disable verbose message support at a system level: if the support is disabled (the default), the DFSMS error messages will not include additional lines of explanation; if the support is enabled, the DFSMS error messages will include the additional lines of explanation, but the verbose message lines will be written only to the JOBLOG. The DISPLAY MPF command response now displays the MSGOPTION enablement state. If verbose message support is enabled, the additional message lines are visible in MPF exits and are visible on the Subsystem Interface (SSI). The following control blocks have been modified to provide an indication if a verbose message line is present: WPL, WQE, CTXT and MDB. We have been in contact with the various automation venders and they are all aware of how to recognize verbose message lines. We expect that most venders will choose to ignore the verbose message lines. Any comments/criticisms/suggestions? W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development This sort of surprises me. Were the people giving feedback worried about the few extra bytes in the syslog/operlog when these messages were written? Obviously they agree the messages are useful for the end user or operations if they still wanted them in the joblog. If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? What if you want the original behavior? I ask, because I like it.Typically as a sysprog, I look at the syslog or operlog to get a better picture of what was happening at the time of an error (as opposed to an end user or programmer who may not have syslog access). Also,sometimes it's just easier to look at the syslog if the joblog has been sent of to some sysout archival product. My client has mixture of different products that do this in different sysplexes / monoplexes and some are more cumbersome to use than others. I'm also thinking of a situation I was just contacted about yesterday with an FTP issue on a pre 1.13 system where I thought the verbose messages in the syslog would have helped operations (thus preventing a call to me).There is no joblog they could have looked at easily since I'm pretty sure the message was generated from a BPXAS address space (it may have been purged as soon as the unix pid terminated). Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Mark, The concern was about the clutter that the additional message lines would cause. Also, the same explanation lines are repeated in each instance of the error message, so there would be a lot of redundancy. If the new MPFLSTxx option has it disabled by default or enables the verbose messages, what purpose does the OCE_ABEND_DESCRIP=YES serve in DEVSUPxx? The DEVSUPxx external has been deprecated and replaced by the MPFLSTxx .MSGOPTION statement. What if you want the original behavior? I ask, because I like it. So you'd like the option of being able to have verbose message lines optionally go places other than JOBLOG? 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: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
At 22:03 -0500 on 05/03/2012, W. Kevin Kelley wrote about Re: Comments on DFSMS verbose messages?: The concern was about the clutter that the additional message lines would cause. Also, the same explanation lines are repeated in each instance of the error message, so there would be a lot of redundancy. If the extra lines are pure boilerplate and not id and value then why not have a database where you can plug in the message number and display the added text? I have a vague memory of being able to do this. It might have just been the ability to look the message up online in the Messages and Codes Manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
My organization is on the ESP program. We also requested a 'non-verbose' option. The extra messages are essentially a verbatim copy of the explanatory text in the messages manual(s). Which resulted in messages that weren't just a few extra lines, but often a dozen or many more lines. What we were hoping for was a reduced set of messages. An option to have something between the more detailed explanation in the messages manual and the original cryptic (to non-technical people) message, that made common sense. IEC030I B37??? You may not have allocated enough DASD space (refer to messages manual for more detail). IEC031I D37??? You may not have specified enough DASD space or any secondary space allocation (refer to...). IEC032I E37??? You may have run out of directory blocks or DASD space in a PDS (refer to...) Ant. Northern Territory Government (Australia) Ant. Thompson Senior Systems Programmer Data Centre Services Department of Business and Employment Northern Territory Government of Australia GPO Box 2391, Darwin NT 0801 N (08) 8999 7035 (08) 8999 7493 ( anthony.thomp...@nt.gov.au DBE -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of W. Kevin Kelley Sent: Friday, 4 May 2012 11:16 AM To: IBM-MAIN@bama.ua.edu Subject: Comments on DFSMS verbose messages? In z/OS R13, DFSMS changed approximately 400 of their rather cryptic IEC error messages to include additional lines of explanation. Feedback from R13 ESP customers indicated that the additional lines of explanation were appreciated for end-users but were not wanted in the SYSLOG/OPERLOG or on consoles. A suggestion was made that the additional lines of explanation be written only to the JOBLOG and not to other places that the message might go. z/OS OA37957 and DFSMS OA37505 provide the suggested support: the additional lines of explanation -- now referred to as verbose message lines -- are written only to the JOBLOG; they are not included with the message if it is written to the SYSLOG/OPERLOG or queued to a console. A new .MSGOPTION statement has been added to MPFLSTxx to allow you to enable or disable verbose message support at a system level: if the support is disabled (the default), the DFSMS error messages will not include additional lines of explanation; if the support is enabled, the DFSMS error messages will include the additional lines of explanation, but the verbose message lines will be written only to the JOBLOG. The DISPLAY MPF command response now displays the MSGOPTION enablement state. If verbose message support is enabled, the additional message lines are visible in MPF exits and are visible on the Subsystem Interface (SSI). The following control blocks have been modified to provide an indication if a verbose message line is present: WPL, WQE, CTXT and MDB. We have been in contact with the various automation venders and they are all aware of how to recognize verbose message lines. We expect that most venders will choose to ignore the verbose message lines. Any comments/criticisms/suggestions? 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Comments on DFSMS verbose messages?
Quickref from Chicago-Soft. I imagine there are other similar products, but this is the one I commonly encounter. Ant. Northern Territory Government of Australia -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Friday, 4 May 2012 1:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Comments on DFSMS verbose messages? At 22:03 -0500 on 05/03/2012, W. Kevin Kelley wrote about Re: Comments on DFSMS verbose messages?: The concern was about the clutter that the additional message lines would cause. Also, the same explanation lines are repeated in each instance of the error message, so there would be a lot of redundancy. If the extra lines are pure boilerplate and not id and value then why not have a database where you can plug in the message number and display the added text? I have a vague memory of being able to do this. It might have just been the ability to look the message up online in the Messages and Codes Manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
