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 abbrev
-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" wrote:
> -- Original Message
On 2/25/10 5:51 PM, "Ian S. Worthington" wrote:
> -- Original Message --
> Received: 05:24 PM COT, 02/25/2010
> From: Alan Altmark
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: An SFS aid
>
>> Abbreviations are for humans, not programmers.
> This &
short?
>
> i
>
> -- Original Message --
> Received: 11:00 PM COT, 02/25/2010
> From: Phil Smith III
> 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 w
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
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: An SFS aid
> I'm trying to remember if there are CP commands besides
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
Alan Altmark wrote:
On Thursday, 02/25/2010 at 05:03 EST, Ivan Warren
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
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
-- Original Message --
Received: 05:24 PM COT, 02/25/2010
From: Alan Altmark
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
On Thursday, 02/25/2010 at 05:03 EST, Ivan Warren
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
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
u] 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
On Thu, Feb 25, 2010 at 3:28 PM, Les Koehler wrote:
>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'
>- Abbrevi
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*
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
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
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
>
> Exp
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 p
--
Kris Buelens,
IBM Belgium, VM customer support
2010/2/25 Schuh, Richard
>
>
>
> Regards,
> Richard Schuh
>
>
>
>
> --
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Kris Buelens
> *Sent:* Thursday,
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 some
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
t my employer's.
"Kris Buelens"
Sent by: "The IBM z/VM Operating System"
02/25/2010 09:06 AM
Please respond to
"The IBM z/VM Operating System"
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: An SFS aid
2010/2/25 Phil Smith III
..
Another great use for S
On Thursday, 02/25/2010 at 10:09 EST, David Boyes
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 revi
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. S
2010/2/25 Phil Smith III
..
> 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 'so
> 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
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 o
lto: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 "lea
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
fi
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", "
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
0 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.cg
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
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
> I deal with SFS administration only rarely and I have trouble
> r
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 - r
35 matches
Mail list logo
