Most likely someone waking up from a long nap and looking at digests instead of e-mail.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, November 10, 2010 12:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How to determine SYSRES Are my posts not getting through, is the list not sending everything on the same day it is sent, or are members responding to old posts before reading all the way through the posts to see if there are already corrections? OK, so I had a "bad day" on 4 Nov 2010 when I posted that erroneous piece of code. Richard Schuh replied within minutes, pointing out a different problem. I responded by re-posting with Richard's fine suggestion in a slightly different way. Then on 9 Nov Alan Ackerman said what I had posted originally back on 4 Nov would not work for the reasons of the variable usage. That was true, but since a different solution had been posted late 4 Nov I did not elaborate on the variable problem back then. Earlier today 10 Nov, I explained why the use of the variable had "seemed" to work when I actually did test it before the erroneous post back early on 4 Nov. Hasn't this particular horse been beaten to death for long enough by now? Can we claim it dead and buried? The red blush on my cheeks faded over a week ago, c'mon already - give me a break! :-( Dale Smith's post on this subject is an altogether better solution anyway. One should expect that critical DASD volume information that was used during an IPL would be displayed as a documentary I-level message during IPL anyway. Some of this is already displayed, but a clean, concise display of the volsers and rdev of the sysres, checkpoint, warmstart, directory, parm disk, and the cylinder extents of each (even the sysres since it could be a 2nd level system) would be useful diagnostic information in the console log at a later date. Some of that is already available in various messages (displayed as they are discovered), but a single set of messages, perhaps in response to a command would be useful when things go bump in the dark. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. "Kris Buelens" <kris.buel...@gmail.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 11/10/2010 01:37 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: How to determine SYSRES This pipe below can never work as the author apparently expected, whatever the piper might implement 'PIPE CP Q ALLOC ALL' , '| TAKE LAST 1' , '| CONSOLE' , '| SPECS W6 1' , '| VAR sysres' , '| CP QUERY CPOWNED' , '| PICK W2 == /'sysres'/' , '| SPECS W2-* 1' , '| CONSOLE' Just think a bit. It is a REXX EXEC, so REXX is reading the source lines, and replaces all variables by their contents (or the uppercased variable name). In the case above: only 'sysres' is outside the quotes and replaced by whatever value it has at that time. All lines (but the last) end with a , so REXX joins it to the presvious string with 1 blnk in between. When REXX built this long string (from the 9 source lines), it sees it is not an assigment, not an IF, .... So it passes the string to the current "address" (those that know me a bit know that I tell it should better be COMMAND). So the CMS command processor starts the PIPE command, and it gets this long string to handle. PIPE simply cannot know that part of the PICK parameters ever were a runtime variable. And, there is even a second error: the second CP stage. It will first pass QUERY CPOWNED as command to CP, and then the records it finds in its input stream. In this case the 6th word of the last line of Q ALLOC. I guess your IPL volser is not labeled LOGOFF ... you would have been very surprised ... -- Kris Buelens, IBM Belgium, VM customer support ________________________________ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
