I do not know what error would have occured if I had used 'ISPF option
6', but I suspect none - because "TSOEXEC LISTA ST" (in quotes) would
still be valid regardless of whether the "TSOEXEC" was required or not
(e.g. if it was implicit in TSO/E). The error would have occurred if I
had executed LISTA ST (without a preceding ADDRESS TSO) in REXX in an
ISPF environment, and I guess the error would then have been something
like 'unrecognized command'. But the same would be true for ISREDIT in
REXX. You can either code ADDRESS ISREDIT followed by the edit commands
e.g. FIND <string> (without ISREDIT or quotes), or not code ADDRESS
ISREDIT but code "ISREDIT <edit command etc.>" (in quotes) for each edit
command, as in e.g. "ISREDIT FIND <string>" etc.
All my panel did was parse anything on the command line (e.g. %ABCXYZ 25
MNO 2) and then return the 'translated' results to my Clist, which then
issued the e.g. ISPEXEC SELECT CMD(%ABCXYZ 25 MNO 2) NEWAPPL PASSLIB. It
could also have been invoked directly as TSO %ABCXYZ 25 MNO 2, or (from
option 6) as %ABCXYZ 25 MNO 2. The panel itself did not play any active
role besides parsing whatever was on the command line.
From the TSO READY prompt I invoked REXX to extract the DSNs from my
TSO PROC's DDNAMEs, then free its DDNAMEs and reallocate them with their
original DSNs but with my own datasets concatenated ahead. I issued a
TSOLIB ACT DATASET('<whatever DSN>') if necessary. My REXX then called
my 'dialog' Clist without displaying panel ISR@PRIM. I did not use
LIBDEFs, as the final LIBDEF <DDNAME> freed not only its own DSNs but
any other DYNALLOC'd DSNs on <DDNAME> too if PASSLIB was not specified,
and I did not want that to happen.
There are different ways of achieving the same result. E.g. LISTDSI
("<DDNAME> FILE") can be used to get DSNs from DDNAMEs instead of using
"LISTA ST", and e.g. "IEBCOPY" can be coded on its own instead of
ISPEXEC SELECT PGM(IEBCOPY) or CALL 'SYS1.LPALIB(IEBCOPY)' etc. So if I
had already written something in the 1980's and it still worked, I used it.
Chris Poncelet
Jon Perryman wrote:
What is the actual error that occurs if you don't use this ISPF panel?
I usually don't have a STEPLIB in my TSO proc and tend to use ISPEXEC LIBDEF if I need access to load modules. With PARMLIB(IKJTSO##) correctly configured, I've never needed TSOEXEC for XMIT. I don't know if STEPLIB with an unauthorized dataset would change that. I've used it REXX, CLIST and directly from ISPEXEC SELECT CMD
Jon Perryman.
________________________________
From: CM Poncelet <[email protected]>
To: [email protected]
Sent: Sunday, March 30, 2014 8:21 PM
Subject: Re: Clist character string compare
Well ... I did things in an 'unconventional' way - e.g. if any command
began with "%" it meant "invoke as Clist or REXX and with parms if any".
In my panel I had:
<etc.>
)PROC
<etc.>
&CLIST = TRUNC(&ZCMD,1) /* <--- here */
&ZCMD = TRUNC(&ZCMD,' ')
&ZTRAIL = .TRAIL
IF (&CLIST='%') /* <--- here */
&CLIST = &ZCMD
&ZCMD = 'CLIST' /* <--- here */
&ZCMDTEMP = TRANS( &ZCMD
<etc.>
*,*) /* <--- here */
&ZSEL = TRANS( &ZCMDTEMP
<etc.>
CLIST,'CMD(&CLIST &ZTRAIL) NEWAPPL(&ZAPPLID) PASSLIB'
/* <--- here */
<etc.>
*,'' )
)END
In my Clist I then had:
<etc.>
ISPEXEC SELECT &ZSEL
<etc.>
My Clist and REXX executed under ISPF and needed an ADDRESS TSO (or
TSOEXEC) for LISTA, SUBMIT, VERIFY, DELETE etc. (I started them from the
TSO READY prompt to bypass the ISPF primary menu panel.)
Apples & oranges indeed.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
