Re: An SFS aid
Wasn't aware of this. What's the difference between IPL long and short? i -- Original Message -- Received: 11:00 PM COT, 02/25/2010 From: Phil Smith III li...@akphs.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid I'm trying to remember if there are CP commands besides IPL whose behavior varies depending on whether they're abbreviated or not; I can't think of any. Anyone? ..phsiii
Re: An SFS aid
IPL (no abbreviation and no operands) executes the last IPL. Abbreviate it, and you have to specify system name or device address at least. On Fri, Feb 26, 2010 at 9:48 PM, Ian S. Worthington ianworthing...@usa.netwrote: Wasn't aware of this. What's the difference between IPL long and short? i -- Original Message -- Received: 11:00 PM COT, 02/25/2010 From: Phil Smith III li...@akphs.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid I'm trying to remember if there are CP commands besides IPL whose behavior varies depending on whether they're abbreviated or not; I can't think of any. Anyone? ..phsiii
Re: An SFS aid
On 2/25/10 5:51 PM, Ian S. Worthington ianworthing...@usa.net wrote: -- Original Message -- Received: 05:24 PM COT, 02/25/2010 From: Alan Altmark alan_altm...@us.ibm.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid Abbreviations are for humans, not programmers. This 'ere programmer is human. Or at least I've been so programmed to believe. I'm not. -- db (who spent last night watching Life of Brian after a really awful trip to the dentist.) Is id Friday yeth?
Re: An SFS aid
-Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: February 26, 2010 12:34 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid On 2/25/10 5:51 PM, Ian S. Worthington ianworthing...@usa.net wrote: -- Original Message -- Received: 05:24 PM COT, 02/25/2010 From: Alan Altmark alan_altm...@us.ibm.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid Abbreviations are for humans, not programmers. This 'ere programmer is human. Or at least I've been so programmed to believe. I'm not. -- db (who spent last night watching Life of Brian after a really awful trip to the dentist.) Is id Friday yeth? See http://www.theregister.co.uk/2010/02/25/spanish_priest/ and then the comment: Anonymous Coward Nobody expects the Spanish prostitution! # Posted Thursday 25th February 2010 13:20 GMT Rest of comment deleted for obvious reasons once you read it! The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: An SFS aid
Phil Smith III wrote: Les Koehler wrote: The gory details escape me now, but we had a customer application at IGS that issued a *lot* of CP commands. Customers complained of poor response time so we consulted with Development and were advised that in that particular situation we should abbreviate CP commands for improved performance. We were doubtful but coded an old vs. new test and timed their performance (both Virtual and Elapsed) on our lightly loaded Customer Production cpu at 2am on a Sunday when we had a maintenance window and customers couldn't log on. The results confirmed what Development had said, so we retested on our highly loaded Dev system during prime time and the resulting difference was obvious. That was sometime long before my retirement in May 2004 and was a *very* unusual case. Generally, I would always use the fully spelled out CP command. Les, I know you well enough to trust your sincerity, but empiricism beats out memory any day. I just ran a test and the full command was consistently faster, trying various CP commands. So...color me skeptical. I'm trying to remember if there are CP commands besides IPL whose behavior varies depending on whether they're abbreviated or not; I can't think of any. Anyone? ...phsiii My admittedly faulty memory tells me it had something to do with querying spool files. Our offering, SHOWBBS, now withdrawn, used 'pooled' userids and 'spool servers'. One server got all the spool files for all the poolids and dealt them out to the other spool servers after hiding the pseudo-id in one of the extended attributes. This avoided the spool file per user limit that CP had. When the user logged on to SHOWBBS and was given one of the poolids, the central spool server was notified and it passed the pseudo-id and poolid to the other spool servers. They then queried their spool to find all the spool files belonging to the pseudo-id, retagged them for the poolid and transferred them to the user. When the user went to view his mail, our code had to do some trickery to make everything look 'normal' in the dialog the user saw. At logoff, all his spool files had to be redistributed to the spool servers. As you can see, all this required a lot of CP commands and *somewhere* in there we made the change that helped. It was a long time ago, so I won't recommend that trick anymore! Apologies for all the technical details. SHOWBBS was well accepted by customers and an interesting project to lead. The folks that originally developed it wrote some great Rexx code and the two contractors that took it over and I worked with, Will Rodgers and John Shaw (now deceased) were certainly Best of Breed! Les
Re: An SFS aid
I didn't want to start a war of words about a poor little Signal, but I cannot resist now. SIGNAL should be used only if you want to branch to a piece of code from which you will never come back. In other words, it should be reserved for *abnormal* changes in the flow of logic. Error handling is fine. Anything else and you are in danger of creating a dreaded spaghetti mess. As with all generalizations, including this one, yours is bad :-) There are places where signal is not bad. For example, I have an EXEC that acts as (a) an EXEC, (b) a Pipelines filter and (c) an XEDIT profile. Nothing that cannot be coded without SIGNAL. There is no pretense that the filter or the XEDIT profile will return to the initial line of code. Except if you use another Signal to achieve exactly that, which was the case in Ray's program. Signal to get to the proper section of code is perfectly good in this situation, in fact I contend that it is preferable to CALL. That's a matter of taste or, if you want, choice. In your case, if you have three big chunks of logic that don't mix well with each other, then maybe yes. But, I would still use different parameters for each mentioned environment and a mainline with three CALLs. In some cases, constructing a signal-less program results in more complicated, more difficult to read and understand code. I would prefer the more maintainable program over one that was pristine, without signals. I also prefer more maintenable program, but such a program shall be with as few signals as possible. This bit that signal (goto, branch, Etc,) should *never* be used is nonsense, an outgrowth of the misapplication of the Top-down Structured Programming concepts. I never said never. I clearly stated the exceptions. I also never mentioned goto nor branch. That is *your* generalisation. BTW, SIGNAL and GOTO are not exactly the same. SIGNAL terminates all constructs from within which it was executed irrespective of wether the target label is within the same construct or outside of it. Some languages allow GOTO to jump to any instruction in a program. In PL/I it is limited to active blocks and GO TO does not terminate a construct if the target label is within the same construct, so you can jump around the same DO loop without terminating it. You cannot do that with SIGNAL. Its nature of bringing you to the top level of nesting before it branches lends itself to usage in abnormal conditions only. In my eyes at least. People went wild over-modularizing programs. I supported (I was in field support for Amdahl at the time) one client that had modularized to the extent that each module consisted of no more than 5 (some were only 2) actual COBOL statements. The rest of each module was comprised of set-up and termination code. Each was compiled separately. Most were only called from a single program; many only called from one place in that program. He wondered why the system was using so much cpu time and running so slowly, saying, It wasn't that way before. When I asked, Before what?, we were able to quickly determine source of the problem. That's a horror story, and you can't score points with horror stories. :-) Extremes, exaggerations and overzealousness don't count in rational comparisons. Making too many small modules is, of course, counterproductive. In general, I will always vote for modular programming - one entry point with the defined set of parameters, clearly defined function, one exit point and when you complete the module, you know what that piece of code does and you can put it away after testing it. When you test a program full of GOTOs, you constantly test the same piece of code over and over only under constantly changing conditions. On the other hand, I have seen the worst of the worst. When I made the switch from application to systems programming, one lady was sent to me to see if I could help her with her dump. This was in 1969, the system was OS/360, the language, COBOL . I started following the code in the dump and found that I was flicking through the pages of her program in a wildly random way. I finally got her to admit that when she sent a program to keypunch, she made sure that the divisions were in their proper place and that the statements of all, with the exception of the Procedure Division, were in the proper order. She didn't bother sorting the PD. When the program came back from keypunch she started her process of compiling and testing, inserting GOTOs wherever necessary to make the instructions execute in the proper order, perhaps a logical (or illogical) sort. The program was large; the number of statements on a coding sheet, small. The number of GOTO statements was substantial. Another horror story which I obviously cannot take advantage of. :-) I'll just say that whenever I see a program full of GOTOs, I roll my eyes in despair. Last time I used GOTOs with joy was with HP-41 programmable calculator more than 30
Re: An SFS aid
I understand, Ray. I just tried to prevent those who read this list and who may be new to REXX from thinking that Signal is widely accepted in constructing loops. Ivica On Thu, Feb 25, 2010 at 5:30 AM, Mrohs, Ray ray.mr...@usdoj.gov wrote: My posting was the result of frustration with SFS. I wasn't thinking about perfect code structure. Frankly, at a certain age you care less about those things, as long as it works and the boss is happy. :-) But I understand your criticism. Ray -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Ivica Brodaric *Sent:* Wednesday, February 24, 2010 10:46 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: An SFS aid May I suggest that you also see call, return, do forever and leave in REXX manual? You can easily implement those in your program. Please don't use signal unless you are handling an error and/or about to leave the program. I hope I've put this nicely... Ivica
Re: An SFS aid
Ivica Brodaric wrote: I didn't want to start a war of words about a poor little Signal, but I cannot resist now. SIGNAL should be used only if you want to branch to a piece of code from which you will never come back. In other words, it should be reserved for *abnormal* changes in the flow of logic. Error handling is fine. Anything else and you are in danger of creating a dreaded spaghetti mess. snip Admittedly Ray's original post contained some less-than-optimal code, but it's short and not general-purpose. What's the point of excoriating him for it? We all (most of us) remember the GOTO-less programming fad. And we've all seen and heard horror stories in both directions. Neither applies to this example. Getting all hot and bothered over code this trivial seems, well, overwrought at best. Used carefully, SIGNAL can greatly *increase* readability. Richard's example of a single piece of code that gets called in multiple, wildly varying ways (EXEC, Pipes filter, XEDIT macro) is one. If I see (p-code): if pipes signal Pipes if xedit signal Xedit EXEC path I don't have to think about what happens after the Pipes or XEDIT processing is done -- as opposed to: if pipes call Pipes if xedit call Xedit if exec call Exec Even if (as seems likely) the next line is exit rc, I now have to think about how rc is set in each routine, etc. The same applies to one entry, one exit: this is more important in languages where memory management isn't automatic, but even then, going through torturous methods (while (0) comes to mind in C) doesn't always make for the most readable code. Another great use for SIGNAL (and one that your rules do admit to) is for error exits. I hate code like this: address command 'somecmd' if rc 0 then do say 'That was an error, rc='rc exit rc end Far better IMHO is: address command 'somecmd' if rc 0 then signal Error This keeps the mainline more compact and readable, and it's pretty clear to the reader that Hey, we're going somewhere to handle the error and we ain't comin' back! We now return you to the actual thread on SFS. ...phsiii
Re: An SFS aid
Ivica Brodaric wrote:
I didn't want to start a war of words about a poor little
Signal, but I cannot resist now. SIGNAL should be used only
if you want to branch to a piece of code from which you will
never come back. In other words, it should be reserved for
*abnormal* changes in the flow of logic. Error handling is
fine. Anything else and you are in danger of creating a
dreaded spaghetti mess.
OK, here's one for the benefit of the newbies in the crowd (wherever
they are). After looking at Chris Buelens' excellent version, I would
highly recommend it. Too bad its not just part of the z/VM distribution
so we don't have this hit and miss problem. The only advantage to my
program is that it is contained in a single exec FWIW.
Ray
-
/* Menu SFS activities so you don't have to remember */
/* all those commands.*/
/* Here are the file systems to manage. You can have up to 9. */
sfss = VMSYS: VMSYSU: VMSYSR: K8SYSU:
Do while 1
'VMFCLEAR'
say 'AccessQueryMaintenance'
say 'UseridSpaceCommands '
say '------'
do i = 1 to words(sfss)
sfs = justify(word(sfss,i),12)
sel1 = justify(i||'1',13)
sel2 = justify(i||'2',13)
sel3 = justify(i||'3',13)
say sfs sel1 sel2 sel3
end
say
say 'Make 2-digit selection:'
parse pull ans .
ans1 = substr(ans,1,1)
ans2 = substr(ans,2,1)
if ans1 1 | ans1 words(sfss) then exit
fs = word(sfss,ans1)
select
when ans2 = '1' then call Access
when ans2 = '2' then call Query
when ans2 = '3' then call Maint
otherwise leave
end
end
exit
Access:
'VMFCLEAR'
'pipe',
'CMS Q ENROLL USER FOR ALL' fs,
'| drop 1',
'| pad 12',
'| snake 6 1',
'| console'
say
say 'Type the userid to access:'
parse pull user .
'DIRL' fs||user||'.'
return
Query:
'VMFCLEAR'
'Q FILEPOOL MINIDISK' fs
say
say 'Press ENTER to continue.'
parse pull junk
return
Maint:
say 'Examples -'
say 'enroll user newuser' fs '(blocks '
say 'modify user {+/-} for curuser' fs
say
say 'Press ENTER to continue.'
parse pull junk
return
---
Re: An SFS aid
2010/2/25 Phil Smith III li...@akphs.com .. Another great use for SIGNAL (and one that your rules do admit to) is for error exits. I hate code like this: address command 'somecmd' if rc 0 then do say 'That was an error, rc='rc exit rc end Far better IMHO is: address command 'somecmd' if rc 0 then signal Error This keeps the mainline more compact and readable, and it's pretty clear to the reader that Hey, we're going somewhere to handle the error and we ain't comin' back! We now return you to the actual thread on SFS. ...phsiii I agree with the use Signal sometimes, in cases where one will not return, it is more clear indeed. But, the example above if rc0 then signal Error isn't very practical: you cannot pass parameters. So I have a Call to my errorexit: routine. The name of the called routine makes it clear to the reader that one will not return from there. if rc0 then call errExit rc,'Something was wrong','Please try again' ... ERREXIT: /* general errorexit routine */ parse upper source . . myname . do i=2 to arg() /* give errormessages (if any) */ say myname':' arg(i) end exit arg(1) I guess we devoted some chapter to it in our selfstudy Telecourse: http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1 -- Kris Buelens, IBM Belgium, VM customer support
Re: An SFS aid
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivica Brodaric Sent: Thursday, February 25, 2010 8:57 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid I didn't want to start a war of words about a poor little Signal, but I cannot resist now. SIGNAL should be used only if you want to branch to a piece of code from which you will never come back. In other words, it should be reserved for *abnormal* changes in the flow of logic. Error handling is fine. Anything else and you are in danger of creating a dreaded spaghetti mess. Or you are writing event driven code, where you want to normalize dispatch w/o impacting the performance of the code with the source scan time. Yes, it's a special case, but it is a valid programming technique. I tend to agree with you that signal gets overused, but thank heavens it's there. Adding similar function to Common LISP was a royal PITA. n db
Re: An SFS aid
On Thursday, 02/25/2010 at 10:09 EST, David Boyes dbo...@sinenomine.net wrote: I tend to agree with you that signal gets overused, but thank heavens it?s there. Adding similar function to Common LISP was a royal PITA. Each of us has a unique ability to mentally cache the logic flow of a program we are reviewing. Our individual programming styles represent a blending of what we have been taught with the dictates of our brains. Some people thrive on what I would perceive as chaos. I thrive on what my wife considers chaos. Nothing is Good or Bad, but thinking makes is so. Beauty is in the eye of the beholder. It's simple: If you write it and you write it poorly, your peers, heirs, and assigns will hate you. If you write it well, they may hate you anyway. So, hopefully we don't have to discuss any [more] of the reasons that SIGNAL/CALL should [not] be used or why one is better [worse] than the other, or what a fantastic [horrible] experience each of us [or someone we know] has had. Life's too short. Alan Altmark z/VM Development IBM Endicott
Re: An SFS aid
Unless there is a reason to handle a nonzero rc (e.g. error correction code, or special a special message), then Phil's simple example would be better handled with an existing rexx convention: Signal ON ERROR address command 'somecmd' ... then either leave Signal ON ERROR active - generally not a bad setting unless you are specifically planning to accept and handle nonzero return codes, or issue: Signal OFF ERROR. (Forgive the mixed-case emphasis - I prefer to emphasize the potential for logical path flow changes.) Signal ON ERROR (along with Signal ON SYNTAX, and Signal ON NOVALUE) will help identify failures in code that may otherwise require significant debugging. Actually, I seem to remember Phil suggesting them in the past? Rexx provides help when asked -- let it. Mike Walter Hewitt Associates 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 02/25/2010 09:06 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: An SFS aid 2010/2/25 Phil Smith III li...@akphs.com .. Another great use for SIGNAL (and one that your rules do admit to) is for error exits. I hate code like this: address command 'somecmd' if rc 0 then do say 'That was an error, rc='rc exit rc end Far better IMHO is: address command 'somecmd' if rc 0 then signal Error This keeps the mainline more compact and readable, and it's pretty clear to the reader that Hey, we're going somewhere to handle the error and we ain't comin' back! We now return you to the actual thread on SFS. ...phsiii I agree with the use Signal sometimes, in cases where one will not return, it is more clear indeed. But, the example above if rc0 then signal Error isn't very practical: you cannot pass parameters. So I have a Call to my errorexit: routine. The name of the called routine makes it clear to the reader that one will not return from there. if rc0 then call errExit rc,'Something was wrong','Please try again' ... ERREXIT: /* general errorexit routine */ parse upper source . . myname . do i=2 to arg() /* give errormessages (if any) */ say myname':' arg(i) end exit arg(1) I guess we devoted some chapter to it in our selfstudy Telecourse: http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1 -- 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.
Re: An SFS aid
Ray, much nicer. Three nits: 1) DO FOREVER is usually preferable to DO WHILE 1 for readability. 2) ADDRESS COMMAND is usually preferable to ensure consistent operation: you don't want things breaking because some user has a PIPE EXEC, for example. 3) Avoiding abbreviations is usually preferable for the same reason: you don't want it to break because some user has a Q MODULE on their disk. (If they have a QUERY MODULE on their disk, they're already confused by why it doesn't seem to get invoked -- that's just how the CMS search order works!) None of these are significant but since you're putting it out there as an educational exercise... ...phsiii
Re: An SFS aid
I hoped the readers would realize that my code snipped wasn't meant to have a real text, I wanted to illustrate what I can code. So, you begged for real examples, here from SFSULIST EXEC: if fpool='' then do 'QUERY FILEPOOL CURRENT(LIFO' parse pull . fpool . if fpool='NONE' then call ErrExit 5,'There is no default filepool',, 'Issue' Myname 'fpool',, 'or SET FILEPOOL fpooland 'myname end /* Is filepool available ? */ 'PIPE COMMAND CMDCALL QUERY LIMITS *' fpool '|VAR EMSG' if rc0 then call ErrExit rc,emsg The example also illustrates how to grab messages from commands that normally don't produce error messages when called under control of ADDRESS COMMAND (or PIPE's COMMAND stage): you insert CMDCALL before the command -- Kris Buelens, IBM Belgium, VM customer support 2010/2/25 Schuh, Richard rsc...@visa.com Regards, Richard Schuh -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Kris Buelens *Sent:* Thursday, February 25, 2010 7:06 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: An SFS aid I agree with the use Signal sometimes, in cases where one will not return, it is more clear indeed. But, the example above if rc0 then signal Error isn't very practical: you cannot pass parameters. So I have a Call to my errorexit: routine. The name of the called routine makes it clear to the reader that one will not return from there. It could have been signal errorx instead of a generic signal error where errorx knows the message to display. The variable rc is still available to it and can be included in the message. if rc0 then call errExit rc,'Something was wrong','Please try again' That message is too generic and not at all helpful. It defeats the purpose of the call. As stated above, the rc is still available to the error routine, even if signal is used.
Re: An SFS aid
Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Thursday, February 25, 2010 7:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid I agree with the use Signal sometimes, in cases where one will not return, it is more clear indeed. But, the example above if rc0 then signal Error isn't very practical: you cannot pass parameters. So I have a Call to my errorexit: routine. The name of the called routine makes it clear to the reader that one will not return from there. It could have been signal errorx instead of a generic signal error where errorx knows the message to display. The variable rc is still available to it and can be included in the message. if rc0 then call errExit rc,'Something was wrong','Please try again' That message is too generic and not at all helpful. It defeats the purpose of the call. As stated above, the rc is still available to the error routine, even if signal is used.
Re: An SFS aid
Expanding on what Phil said: - Always put Address Command at the top of an ordinary Rexx exec. - Quote and capitalize all commands to the underlying system. - Use the *full* CMS command - Direct CP commands to CP via: 'CP whatever' - Abbreviate CP commands that are inside of a loop to improve performance. Ditto in execs that get used a *lot* Unlike Phil, I think these *are* significant! They will save you hours of misery and much embarrassment. Les Phil Smith III wrote: Ray, much nicer. Three nits: 1) DO FOREVER is usually preferable to DO WHILE 1 for readability. 2) ADDRESS COMMAND is usually preferable to ensure consistent operation: you don't want things breaking because some user has a PIPE EXEC, for example. 3) Avoiding abbreviations is usually preferable for the same reason: you don't want it to break because some user has a Q MODULE on their disk. (If they have a QUERY MODULE on their disk, they're already confused by why it doesn't seem to get invoked -- that's just how the CMS search order works!) None of these are significant but since you're putting it out there as an educational exercise... ...phsiii
Re: An SFS aid
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler
Sent: Thursday, February 25, 2010 12:28 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: An SFS aid
Expanding on what Phil said:
- Always put Address Command at the top of an ordinary Rexx exec.
- Quote and capitalize all commands to the underlying system.
- Use the *full* CMS command
- Direct CP commands to CP via: 'CP whatever'
- Abbreviate CP commands that are inside of a loop to improve
performance. Ditto in execs that get used a *lot*
You left out that you must also precede an EXEC's name with the word EXEC
('EXEC execname ...').
Re: An SFS aid
Les Koehler wrote: - Abbreviate CP commands that are inside of a loop to improve performance. Ditto in execs that get used a *lot* That one I am curious about ! Why would an abbreviated CP command yield better performance than a fully spelled out CP command ? --Ivan
Re: An SFS aid
Schuh, Richard wrote:
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler
Sent: Thursday, February 25, 2010 12:28 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: An SFS aid
Expanding on what Phil said:
- Always put Address Command at the top of an ordinary Rexx exec.
- Quote and capitalize all commands to the underlying system.
- Use the *full* CMS command
- Direct CP commands to CP via: 'CP whatever'
- Abbreviate CP commands that are inside of a loop to improve
performance. Ditto in execs that get used a *lot*
You left out that you must also precede an EXEC's name with the word EXEC
('EXEC execname ...').
Yep, sure did!
Les
Re: An SFS aid
Because CP looks up abbreviations first. CMS looks up the fully qualified command first. Unless they changed the rules after I retired. Les Ivan Warren wrote: Les Koehler wrote: - Abbreviate CP commands that are inside of a loop to improve performance. Ditto in execs that get used a *lot* That one I am curious about ! Why would an abbreviated CP command yield better performance than a fully spelled out CP command ? --Ivan
Re: An SFS aid
On Thu, Feb 25, 2010 at 3:28 PM, Les Koehler vmr...@tampabay.rr.comwrote: Expanding on what Phil said: - Always put Address Command at the top of an ordinary Rexx exec. - Quote and capitalize all commands to the underlying system. - Use the *full* CMS command - Direct CP commands to CP via: 'CP whatever' - Abbreviate CP commands that are inside of a loop to improve performance. Ditto in execs that get used a *lot* Unlike Phil, I think these *are* significant! They will save you hours of misery and much embarrassment. Oh, I do think they're *very* significant! I guess I meant that they weren't major hits in his example, and that I wasn't trying to nitpick. I preach this in every Rexx presentation I give. Sorry to have given the wrong impression, and thanks for correcting it. However, abbreviate CP commands that are inside of a loop to improve performance strikes me as unlikely to be worth it: all it takes is one maintainer after you having to look up what an abbreviation means to have lost any potential savings. What are you trying to avoid? Page faults from PLISTs crossing page boundaries? A few cycles in CP parsing a string? ...phsiii
Re: An SFS aid
Guys, please realize what I put forth works for ME, and it is up to YOU to either use it, modify it, or throw it in the trash. As it stands, it works perfectly well for its limited intended purpose in my plain-jane VM admin environment. I usually don't shoot for elegant or proper when I want it quick and functional, so I apologize for that. You can hang stuff all over it all day long until it looks like the Elephant Man, and it won't work one bit better. Now if this were a scheduled production routine, or distributed to my 3000+ end users, or involved a few hundred lines of code, there would naturally be more optimization and checking built in. So in this case take it or leave it for what it is - just a quick and dirty admin construct that helps relieve over-taxed memory cells. Again, SFSLIST on the IBM downloads page is more polished and the one you want for prime-time use. Your critiques are well intended but I hope they don't dissuade others from posting their little tricks of the trade that we can all benefit from. Ray -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Thursday, February 25, 2010 3:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid Expanding on what Phil said: - Always put Address Command at the top of an ordinary Rexx exec. - Quote and capitalize all commands to the underlying system. - Use the *full* CMS command - Direct CP commands to CP via: 'CP whatever' - Abbreviate CP commands that are inside of a loop to improve performance. Ditto in execs that get used a *lot* Unlike Phil, I think these *are* significant! They will save you hours of misery and much embarrassment. Les Phil Smith III wrote: Ray, much nicer. Three nits: 1) DO FOREVER is usually preferable to DO WHILE 1 for readability. 2) ADDRESS COMMAND is usually preferable to ensure consistent operation: you don't want things breaking because some user has a PIPE EXEC, for example. 3) Avoiding abbreviations is usually preferable for the same reason: you don't want it to break because some user has a Q MODULE on their disk. (If they have a QUERY MODULE on their disk, they're already confused by why it doesn't seem to get invoked -- that's just how the CMS search order works!) None of these are significant but since you're putting it out there as an educational exercise... ...phsiii
Re: An SFS aid
On Thursday, 02/25/2010 at 05:03 EST, Ivan Warren i...@vmfacility.fr wrote: Basically, I believe HCPCFC (which is OCO.. Yuck !) simply looks at the length of the command passed, verifies it doesn't exceed the length of the command and then does an EX/CLC for the abbreviation for the command to check for a match - which means no difference in processing time between an abbreviation and a fully spelled out command. That how it was done in my time in DMKCFC anyways. My point it that I strongly believe there is no difference in CP processing time for an abbreviated CP command. Leaving specific instructions out of it, yes, that's how it works. Compare this to any readability issues - a second over a year of processing time compared to an hour by a human being trying to figure out why it's not the right command being issued ! And we DO change abbreviations sometimes. When we introduced the FOR command, it was necessary to change the abbreviation of FORWARD from FO to FORW. Always spell out your CMS and CP command names AND operands in order to avoid such gotchas. Abbreviations are for humans, not programmers. Alan Altmark z/VM Development IBM Endicott
Re: An SFS aid
Les Koehler wrote: Because CP looks up abbreviations first. CMS looks up the fully qualified command first. Unless they changed the rules after I retired. CP Commands in HCPCOM are pretty much in the form of a table that describes a string, a minimum abbreviation length and the entry point (and the class and some auxiliary stuff). Basically, I believe HCPCFC (which is OCO.. Yuck !) simply looks at the length of the command passed, verifies it doesn't exceed the length of the command and then does an EX/CLC for the abbreviation for the command to check for a match - which means no difference in processing time between an abbreviation and a fully spelled out command. That how it was done in my time in DMKCFC anyways. My point it that I strongly believe there is no difference in CP processing time for an abbreviated CP command. And even for those commands which have different abbreviations than a full command (or rather an abbreviated alias, like MSG vs MESSAGE), it probably amounts to just a few CPU cycles (probably less than 1% of the time just actually spent passing the command down from a VM to CP, etc..) Compare this to any readability issues - a second over a year of processing time compared to an hour by a human being trying to figure out why it's not the right command being issued ! . Now - while we are providing each other advices... Make sure while passing CP commands that you aren't abbreviating commands (or arguments) based on your CP privileges. For example : 'CP QUERY DASD' and 'CP QUERY VIRTUAL DASD' has the same effect on a class G virtual machine - but an entirely different meaning on a class B virtual machine ! Same for QUERY RDR == QUERY RDR * for class G, but not for class D, etc.. --Ivan
Re: An SFS aid
-- Original Message -- Received: 05:24 PM COT, 02/25/2010 From: Alan Altmark alan_altm...@us.ibm.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid Abbreviations are for humans, not programmers. This 'ere programmer is human. Or at least I've been so programmed to believe. i
Re: An SFS aid
Ian S. Worthington wrote: Abbreviations are for humans, not programmers. This 'ere programmer is human. Or at least I've been so programmed to believe. i /**/ say Sorry Ian S. Worthington (S. being abbreviated due to lack of information say however, I believe that programmers are a special class of human say beings that can do without resorting to puny abbreviation say say --Ivan (3 minutes to friday here.. oops - a little early)
Re: An SFS aid
Alan Altmark wrote: On Thursday, 02/25/2010 at 05:03 EST, Ivan Warren i...@vmfacility.fr wrote: Basically, I believe HCPCFC (which is OCO.. Yuck !) simply looks at the length of the command passed, verifies it doesn't exceed the length of the command and then does an EX/CLC for the abbreviation for the command to check for a match - which means no difference in processing time between an abbreviation and a fully spelled out command. That how it was done in my time in DMKCFC anyways. My point it that I strongly believe there is no difference in CP processing time for an abbreviated CP command. Leaving specific instructions out of it, yes, that's how it works. Compare this to any readability issues - a second over a year of processing time compared to an hour by a human being trying to figure out why it's not the right command being issued ! And we DO change abbreviations sometimes. When we introduced the FOR command, it was necessary to change the abbreviation of FORWARD from FO to FORW. Always spell out your CMS and CP command names AND operands in order to avoid such gotchas. Abbreviations are for humans, not programmers. Alan Altmark z/VM Development IBM Endicott The gory details escape me now, but we had a customer application at IGS that issued a *lot* of CP commands. Customers complained of poor response time so we consulted with Development and were advised that in that particular situation we should abbreviate CP commands for improved performance. We were doubtful but coded an old vs. new test and timed their performance (both Virtual and Elapsed) on our lightly loaded Customer Production cpu at 2am on a Sunday when we had a maintenance window and customers couldn't log on. The results confirmed what Development had said, so we retested on our highly loaded Dev system during prime time and the resulting difference was obvious. That was sometime long before my retirement in May 2004 and was a *very* unusual case. Generally, I would always use the fully spelled out CP command. Les
Re: An SFS aid
Les Koehler wrote: The gory details escape me now, but we had a customer application at IGS that issued a *lot* of CP commands. Customers complained of poor response time so we consulted with Development and were advised that in that particular situation we should abbreviate CP commands for improved performance. We were doubtful but coded an old vs. new test and timed their performance (both Virtual and Elapsed) on our lightly loaded Customer Production cpu at 2am on a Sunday when we had a maintenance window and customers couldn't log on. The results confirmed what Development had said, so we retested on our highly loaded Dev system during prime time and the resulting difference was obvious. That was sometime long before my retirement in May 2004 and was a *very* unusual case. Generally, I would always use the fully spelled out CP command. Les, I know you well enough to trust your sincerity, but empiricism beats out memory any day. I just ran a test and the full command was consistently faster, trying various CP commands. So...color me skeptical. I'm trying to remember if there are CP commands besides IPL whose behavior varies depending on whether they're abbreviated or not; I can't think of any. Anyone? ...phsiii
An SFS aid
I deal with SFS administration only rarely and I have trouble
remembering the fussy syntax for even the more common functions. I put
together this little REXX to help me along. It's by no means complete,
but maybe some people in the same situation will find it useful. Note
K8SYSU: is an example - replace with your own.
--
/* Menu SFS activities so you don't have to remember */
/* all those commands.*/
/* Here aree the file systems to manage. You can have up to 9. */
sfss = VMSYS: VMSYSU: VMSYSR: K8SYSU:
Top:
'VMFCLEAR'
say 'AccessQueryMaintenance'
say 'UseridSpaceCommands '
say '------'
do i = 1 to words(sfss)
sfs = justify(word(sfss,i),12)
sel1 = justify(i||'1',13)
sel2 = justify(i||'2',13)
sel3 = justify(i||'3',13)
say sfs sel1 sel2 sel3
end
say
say 'Make 2-digit selection:'
parse pull ans .
ans1 = substr(ans,1,1)
ans2 = substr(ans,2,1)
if ans1 1 | ans1 words(sfss) then exit
fs = word(sfss,ans1)
if ans2 = '1' then signal Access
if ans2 = '2' then signal Query
if ans2 = '3' then signal Maint
exit
Access:
'VMFCLEAR'
'pipe',
'CMS Q ENROLL USER FOR ALL' fs,
'| drop 1',
'| pad 12',
'| snake 6 1',
'| console'
say
say 'Type the userid to access:'
parse pull user .
'DIRL' fs||user||'.'
signal Top
Query:
'VMFCLEAR'
'Q FILEPOOL MINIDISK' fs
say
say 'Press ENTER to continue.'
parse pull junk
signal Top
Maint:
say 'Examples -'
say 'enroll user newuser' fs '(blocks '
say 'modify user {+/-} for curuser' fs
say
say 'Press ENTER to continue.'
parse pull junk
signal Top
Re: An SFS aid
Did you have a look at my SFSULIST package? My first impression is that you
almost do in linemode what I created in a FILELIST-like fashion:
http://www.vm.ibm.com/download/packages/descript.cgi?SFSULIST
2010/2/24 Mrohs, Ray ray.mr...@usdoj.gov
I deal with SFS administration only rarely and I have trouble
remembering the fussy syntax for even the more common functions. I put
together this little REXX to help me along. It's by no means complete,
but maybe some people in the same situation will find it useful. Note
K8SYSU: is an example - replace with your own.
--
/* Menu SFS activities so you don't have to remember */
/* all those commands.*/
/* Here aree the file systems to manage. You can have up to 9. */
sfss = VMSYS: VMSYSU: VMSYSR: K8SYSU:
Top:
'VMFCLEAR'
say 'AccessQueryMaintenance'
say 'UseridSpaceCommands '
say '------'
do i = 1 to words(sfss)
sfs = justify(word(sfss,i),12)
sel1 = justify(i||'1',13)
sel2 = justify(i||'2',13)
sel3 = justify(i||'3',13)
say sfs sel1 sel2 sel3
end
say
say 'Make 2-digit selection:'
parse pull ans .
ans1 = substr(ans,1,1)
ans2 = substr(ans,2,1)
if ans1 1 | ans1 words(sfss) then exit
fs = word(sfss,ans1)
if ans2 = '1' then signal Access
if ans2 = '2' then signal Query
if ans2 = '3' then signal Maint
exit
Access:
'VMFCLEAR'
'pipe',
'CMS Q ENROLL USER FOR ALL' fs,
'| drop 1',
'| pad 12',
'| snake 6 1',
'| console'
say
say 'Type the userid to access:'
parse pull user .
'DIRL' fs||user||'.'
signal Top
Query:
'VMFCLEAR'
'Q FILEPOOL MINIDISK' fs
say
say 'Press ENTER to continue.'
parse pull junk
signal Top
Maint:
say 'Examples -'
say 'enroll user newuser' fs '(blocks '
say 'modify user {+/-} for curuser' fs
say
say 'Press ENTER to continue.'
parse pull junk
signal Top
--
Kris Buelens,
IBM Belgium, VM customer support
Re: An SFS aid
I didn't but I'm looking at it now. It looks much more thorough. Thanks for pointing it out. Ray From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Wednesday, February 24, 2010 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid Did you have a look at my SFSULIST package? My first impression is that you almost do in linemode what I created in a FILELIST-like fashion: http://www.vm.ibm.com/download/packages/descript.cgi?SFSULIST -- Kris Buelens, IBM Belgium, VM customer support
Re: An SFS aid
As with all generalizations, including this one, yours is bad :-) There are places where signal is not bad. For example, I have an EXEC that acts as (a) an EXEC, (b) a Pipelines filter and (c) an XEDIT profile. There is no pretense that the filter or the XEDIT profile will return to the initial line of code. Signal to get to the proper section of code is perfectly good in this situation, in fact I contend that it is preferable to CALL. In some cases, constructing a signal-less program results in more complicated, more difficult to read and understand code. I would prefer the more maintainable program over one that was pristine, without signals. This bit that signal (goto, branch, Etc,) should never be used is nonsense, an outgrowth of the misapplication of the Top-down Structured Programming concepts. People went wild over-modularizing programs. I supported (I was in field support for Amdahl at the time) one client that had modularized to the extent that each module consisted of no more than 5 (some were only 2) actual COBOL statements. The rest of each module was comprised of set-up and termination code. Each was compiled separately. Most were only called from a single program; many only called from one place in that program. He wondered why the system was using so much cpu time and running so slowly, saying, It wasn't that way before. When I asked, Before what?, we were able to quickly determine source of the problem. On the other hand, I have seen the worst of the worst. When I made the switch from application to systems programming, one lady was sent to me to see if I could help her with her dump. This was in 1969, the system was OS/360, the language, COBOL . I started following the code in the dump and found that I was flicking through the pages of her program in a wildly random way. I finally got her to admit that when she sent a program to keypunch, she made sure that the divisions were in their proper place and that the statements of all, with the exception of the Procedure Division, were in the proper order. She didn't bother sorting the PD. When the program came back from keypunch she started her process of compiling and testing, inserting GOTOs wherever necessary to make the instructions execute in the proper order, perhaps a logical (or illogical) sort. The program was large; the number of statements on a coding sheet, small. The number of GOTO statements was substantial. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivica Brodaric Sent: Wednesday, February 24, 2010 7:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid May I suggest that you also see call, return, do forever and leave in REXX manual? You can easily implement those in your program. Please don't use signal unless you are handling an error and/or about to leave the program. I hope I've put this nicely... Ivica
Re: An SFS aid
My posting was the result of frustration with SFS. I wasn't thinking about perfect code structure. Frankly, at a certain age you care less about those things, as long as it works and the boss is happy. :-) But I understand your criticism. Ray From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivica Brodaric Sent: Wednesday, February 24, 2010 10:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid May I suggest that you also see call, return, do forever and leave in REXX manual? You can easily implement those in your program. Please don't use signal unless you are handling an error and/or about to leave the program. I hope I've put this nicely... Ivica
