I would agree too, if it worked that way.
execload rexxtry exec x try exec
rc = 0 .............................................. REXXTRY on CMS
try
TRY lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
Go on - try a few... Enter 'exit' to end.
parse source s
......................................................... TRY on CMS
say s
CMS COMMAND TRY EXEC * TRY CMS
......................................................... TRY on CMS
-----Original Message-----
From: CMSTSO Pipelines Discussion List
[mailto:[email protected]] On Behalf Of Schuh, Richard
Sent: Monday, March 23, 2009 4:06 PM
To: [email protected]
Subject: Re: [CMS-PIPELINES] Suggestion: NAME default.
I agree with you, Mike. I have been known to EXECLOAD code under a
different name than that of the file.
Regards,
Richard Schuh
> -----Original Message-----
> From: CMSTSO Pipelines Discussion List
> [mailto:[email protected]] On Behalf Of Mike Walter
> Sent: Monday, March 23, 2009 12:33 PM
> To: [email protected]
> Subject: Re: Suggestion: NAME default.
>
> I can't think of a single reason not to love it as a built-in DEFAULT.
> But then, I'm not the author and have probably regressed from
> journeyman plumber to apprentice.
>
> OK, maybe one reason: I'd probably prefer (in your example)
> "ExecName" vs "UsedName". "ExecName" is the name of the file
> that may need fixing.
> Would anyone really need to care what abbreviation might have
> been used to call it?
>
> It sure does look like a great time-saver when something goes wrong!
>
> Mike Walter
> Hewitt Associates
> Any opinions expressed herein are mine alone and do not
> necessarily represent the opinions or policies of Hewitt Associates.
>
>
>
>
>
> "SPITZ, HOBART CTR DFAS" <[email protected]>
>
> Sent by: "CMSTSO Pipelines Discussion List"
> <[email protected]>
> 03/23/2009 12:01 PM
> Please respond to
> "CMSTSO Pipelines Discussion List" <[email protected]>
>
>
>
> To
> [email protected]
> cc
>
> Subject
> Suggestion: NAME default.
>
>
>
>
>
>
> Almost without exception, I code my pipe, callpipe, and
> addpipe commands in this form:
>
> "pipe (listerr end ? name"
> UsedName"."ExecType"."LineNo()")",
> ...
>
> Where UsedName is word 6 of parse source and ExecType is word 4:
>
> parse source OpSys CallType ExecName
> ExecType ExecRes UsedName Rest
>
> Lineno() is as follows:
>
> ...
>
> /*------------------------------------------------------------
> --------*/
> /* Return source statement number of caller.
> LINENO
> EXEC
> HS0508 */
>
> /*------------------------------------------------------------
> --------*/
> LineNo:
>
> trace n
>
> return sigl /*
> LINENO
> EXEC
> HS0507 */
>
> Thus, pipes error messages tell the module name, the module
> type and the line number of the command where the message was
> generated. It saves lots of time in debugging. Since
> nothing is hard-coded, we can move or copy code, or rename
> modules, and not have to worry about going back and changing
> names or line numbers.
>
> For the technique to work, you must code the options on every
> pipe/callpipe/addpipe, include lineno() in every program, and
> do the same parse source in each program.
>
> A few years ago I inherited a system of some 600 modules
> (about 50% Rexx). I don't think there was a single 'name' in
> any of the many pipes.
>
> Would it be feasible to support a name default, using REXX
> parse source and sigl information as above, on each
> pipe/callpipe/addpipe without a name option?
>
> Do anyone else like this idea?
>
> - Hobart
>
>
>
>
>
> 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.
>
