As far as I know there are only two useful tricks CLIST can perform that REXX
can't. Well, maybe three:
1) WRITENR. So when I really need it, I use an external REXX exec named SAYNR
that does the same thing - by calling a CLIST that does a WRITENR. Works like
a champ, but I wouldn't want to try it inside a loop.
2) Interacting with subsystems. In CLIST you can issue FTP commands, for
example, evaluate the response and decide where to go from there; REXX handles
subsystems as batch, essentially.
3) Dunno whether you'd count this, but CLIST has a neat built-in functionality
for evaluating parms. I get around this by starting every REXX with a SELECT
statement that evaluates each space-delimited word in the arg list; it's more
complicated, but it means that in most cases I can enter arguments in any
order, which pleases me. Like this (to pick a complex example with many
possible arguments):
fnox=0; fall=0; acid=''; ddnfm=''; ddnto=''
arg args; do while args<>''; parse var args arg args; select
when arg='DBG' then trace 'I' /* trace mode */
when arg='NOX' then fnox=1 /* no-execute mode */
when abbrev('LISTALL',arg,5) then fall=1 /* turn on list-all mode */
when pos('.',arg)>0 then dsn=arg /* set the DSN */
when tgetacid(arg)=0 then acid=arg /* set the ACID */
when length(arg)<9 & ddnfm='' then ddnfm=arg /* from DD */
when length(arg)<9 & ddnto='' then ddnto=arg /* to DD */
otherwise call abend 'Unrecognized arg' arg; end; end
The only requirement here regarding argument order is that the From DD has to
be named before the To DD; everything else the operator can type in as it
happens to occur to him.
This makes my REXX execs a little messy up front, but gives me flexibility that
I value. And anyway I'm used to it now. Easily worth the extra trouble to get
access to the power REXX affords over CLIST. Too bad about #2, though.
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Give a man fire and he's warm for a day; set him on fire and he's warm for
the rest of his life. -found on the web */
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of CM Poncelet
Sent: Friday, March 20, 2020 20:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does anybody remember CLIST?
No, there is no problem with that. I assume you meant "EXECIO 1 DISKR
"ddn1" (STEM foo."
The problem happens e.g. if a variable X contains the names of other
variables, which in turn contain the names of yet other variables etc.
etc. which finally - with say names Z1 Z2 Z3 etc. - have values that
need to be accessed.
We can "VPUT X (and all the other variables' names) SHARED" and call an
external exec. It issues "VGET X SHARED" and then "VGET "X" SHARED". But
how does it then VGET the other variables and their values in such way
that they can be processed? The variable names can be VGET as data, but
REXX cannot use data - such as names Z1 Z2 Z3 etc. - as names of
variables (although INTERPRET *might* be able to fix that.)
Clist can allocate variable names dynamically, using &'s, and can then
use SYSSCAN to control how many &'s are interpreted. Its problem is it
cannot ADDRESS environments and cannot process binary data, which REXX can.
Cheers.
On 20/03/2020 04:22, Seymour J Metz wrote:
> I don't see the problem.
>
> /* REXX */
> parse arg upper ddn1 ddn2
> EXECIO DISKR ddn1 1 '(' STEM foo.
> do i=1 to foo.0
> say 'Line' i 'is' foo.i
> end
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
> CM Poncelet [ponce...@bcs.org.uk]
> Sent: Friday, March 20, 2020 12:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Does anybody remember CLIST?
>
> As mentioned above, EXECIO is part of TSO REXX.
>
> The problem is not EXECIO but with reading the records of a dataset
> assigned to an arbitrary DDNAME passed as a parm to REXX.
>
> Consider the folowing:
>
> //*********************************************************************
> //* NOTE: 'U' => TSO USERID(S); SPECIFY LIST OF USERIDS UNDER DESTIDS *
> //* ¯¯¯¯¯ 'C' -> CONSOLE; SPECIFY MASTER ETC. UNDER CONSIDS *
> //* *
> //* 04/01/95 CMP *
> //*********************************************************************
> //*
> //CLIST EXEC PGM=IKJEFT01,
> // REGION=512K,
> //* PARM='%TSOSEND DESTIDS SYSIN USERID' (DESTLIST=DESTIDS)
> // PARM='%TSOSEND CONSIDS SYSIN CONSOLE' (DESTLIST=CONSIDS)
> //*
> //SYSPROC DD DISP=SHR,DSN=<Clist dataset>
> //SYSTSIN DD DUMMY
> //SYSTSPRT DD SYSOUT=*
> //CONSIDS DD *
> <master console ID>
> //*
> //SYSIN DD * (all messages below are sent to the console)
> Dear MVS OPS,
>
> Could someone please start DMSAR on LPAR1 and LPAR2 so my job can
> restore datasets from pseudo-volume <whatever>? It's been waiting
> for 2 1/2 hours.
>
> Here's part of the joblog (jobname on LPAR1):
> 14.58.46 JOB15032 ---- <whenever> ----
> 14.58.46 JOB15032 <whatever>
> 14.58.46 JOB15032 <whatever>
> 16.00.08 JOB15032 MSG FROM OPER: '***********************************
> 16.00.08 JOB15032 MSG FROM OPER: '* THIS JOB IS BEING AUTOMATICALLY C
> 16.00.08 JOB15032 MSG FROM OPER: '* BEEN RUNNING IN A CLASS ID INITIA
> 16.00.08 JOB15032 MSG FROM OPER: '* CLASS ID INITIATORS ARE TO BE USE
> 16.00.09 JOB15032 MSG FROM OPER: '* JOBS. REFER TO SYSPROG.PRODUCTS($
> 16.00.09 JOB15032 MSG FROM OPER: '* INITIATOR CLASSES.
> 16.00.09 JOB15032 MSG FROM OPER: '***********************************
> <etc.....>
> 16.45.05 JOB15032 MSG FROM OPER: '***********************************
> 16.45.05 JOB15032 MSG FROM OPER: '* THIS JOB IS BEING AUTOMATICALLY C
> 16.45.05 JOB15032 MSG FROM OPER: '* BEEN RUNNING IN A CLASS ID INITIA
> 16.45.05 JOB15032 MSG FROM OPER: '* CLASS ID INITIATORS ARE TO BE USE
> 16.45.05 JOB15032 MSG FROM OPER: '* JOBS. REFER TO SYSPROG.PRODUCTS($
> 16.45.05 JOB15032 MSG FROM OPER: '* INITIATOR CLASSES.
>
> Thanks a lot.
>
> Chris
>
> /*
> //*
>
> Which is quicker - manually issuing 'oodles' of TSOSENDs (1 per message
> line) to the console, or sending all messages together via SYSIN?
>
> That's why I used Clist for that <grin>.
>
> Cheers, Chris Poncelet
>
>
>
> On 20/03/2020 00:51, Paul Gilmartin wrote:
>> On Fri, 20 Mar 2020 00:33:40 +0000, CM Poncelet wrote:
>>> ...
>>> BTW Some things can be done in Clist which cannot (well at least not
>>> easily) be done in REXX, e.g. opening/reading a dataset associated with
>>> a DDNAME passed as a parm to a Clist submitted as a batch TSO job via
>>> JCL ...
>>>
>> If EXECIO were part of Rexx, couldn't it be done with EXECIO?
>>
>>> ...
>>> SET MAXCC = 0
>>> OPENFILE &DESTLIST INPUT /* open DDNAME=&DESTLIST for reading */
>>> GETFILE &DESTLIST /* read the 1st record in DDNAME=&DESTLIST */
>>> DO I = 0 TO 99 WHILE &MAXCC = 0
>>> SET USER = &USREC
>>> SET J = &SYSINDEX(&STR( ),&USER,1)
>>> SET J = &J - 1
>>> SET USER = &SUBSTR(1:&J,&USER)
>>> SET SENDTO = &STR(&SENDTO&USER,)
>>> GETFILE &DESTLIST
>>> ENDO
>>> /* etc. etc. */
>>>
>> Grrr. The over-and-under test for completion is a treacherous
>> construct; a maintenance pitfall. In Rexx, I prefer LEAVE.
>>
>> -- gil
>>
>> ----------------------------------------------------------------------
>> 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
>
> ----------------------------------------------------------------------
> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
