Can you guaranty that there will never be a name that is used for both a member and a ddname?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Bob Bridges <robhbrid...@gmail.com> Sent: Friday, October 1, 2021 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I vs. JCL I would never have seen this in advance, but one advantage I found when switching to REXX is that I'm almost eliminated positional parms from my commands. In all but a few cases, the program can tell what it is by looking at it. Thus every user can enter the arguments in the order that seems most logical to him, or (in my case) in the order that occurs to me at the time. It's a small convenience, but I cherish it. The one exception that occurs to me just now is my LOC command, which I use to find a module in a DD concatenation of libraries. Like this: ==> tss loc modulenm sysproc SYSPROC XYZ.ISPF.GENERAL.CLIB.... SYSPROC XYZ.ISPF.COMBINED.V65.CLIB.... SYSPROC TTP.CAI.V44.CAICLIB.... Member MODULENM found in dataset TTP.CAI.V44.CAICLIB (#3in SYSPROC). ...and then starts that module in View. (This is a big help when programming in ISPF, among other things.) In this case LOC needs to know which is the module name and which the DD name, since they both look the same. ...But wait: An idea strikes. I already have a function DSDD that receives a string and returns a code telling whether the string represents a catalogued DS, an allocated DD, or both, or neither. So even LOC doesn't need these two args to be positional; it can look over the args, determine which DD(s) to search, and any other args are module names. Cool! I have work to do :). --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* ....if we consider the unblushing promises of reward and the staggering nature of the rewards promised in the Gospels, it would seem that our Lord finds our desires not too strong, but too weak. We are half-hearted creatures, fooling about with drink and sex and ambition when infinite joy is offered us, like an ignorant child who wants to go on making mud pies in a slum because he cannot imagine what is meant by the offer of a holiday at the sea. -from _The Weight of Glory_ by C S Lewis */ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Skip Robinson Sent: Thursday, September 30, 2021 22:37 Even a dead horse needs a tail. Parsing CLIST parms involves more than sorting out characters and delimiters. There are (my terminology) three kinds of parms. 1. Positional parms 2. Keyword switch parms 3, Keyword value parms Positional parms must come first in the order coded in the exec. Each variable is assigned whatever value the user has entered. Keyword switch parms must follow positional parms in any order. If the keyword is present, the variable is assigned the value that matches the variable name. 'Match' here means an unambiguous (sub)string. If the match is ambiguous, CLIST prompts for an unambiguous. Keyword value parms must also follow positional parms in any order, coded like this: keyword(value). Value can be anything. Keyword entered by the user must unambiguously match one coded in the CLIST, else CLIST prompts the user. So why the complexity? CLIST is very old, predating ISPF. Hence the user had to supply lots of data at execution time. This framework offers flexibility. --- On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges <robhbrid...@gmail.com> wrote: > I once wrote an external routine that can break a character string > into various individual parms and return them on the stack. It > correctly parses strings with quotes, parens and comment markers. > > But as you say, even I hardly ever use it. Most routines work > perfectly well with a string of one-word arguments, and if I don't > have to remember what order they come in and don’t have to label them, > anything more is almost never required. > > -----Original Message----- > From: Skip Robinson > Sent: Wednesday, September 29, 2021 18:06 > > ....one of the most powerful features of CLIST is the mechanism by > which parameters/options are passed by the user: positional or > keyword, required or optional, with system prompting. I once saw a > REXX routine that simulated the old command/CLIST parm processing. It > was very complicated and hardly worth the trouble IMHO. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
