To put it a different way. The IBM-supplied default ISR@PRIM-driven menu
system is/was a demo IVP dialog whose purpose was to show that ISPF
executed correctly on IBM hardware. Users were not required to use IBM's
default ISPF IVP dialog, either asis or customized, but could write
their own instead. Almost all users adopted the IBM-supplied default
ISPF dialog as standard. I did not but wrote my own ISPF/PDF dialog (in
1988). My dialog used my TSO commands (from my ISPTLIB) and my panels
(which parsed whatever was on the command line). No error occurred. The
only 'necessity' was that I get rid of IBM's default menu-driven ISPF
environment as I did not need to be reminded that '1' was for Browse,
'2' was for Edit, '3' was for Utilities, etc. I had no "problems" at all
with LIBDEFs. I did use 'different' APPLIDs (actually the same one, but
stacked), as shown in my panel's 'CMD(&CLIST &ZTRAIL) NEWAPPL(&ZAPPLID)
PASSLIB'. (The 'NEWAPPL' specifies the 'new' APPLID.) REXX can execute
in any MVS address space, both TSO/E and non-TSO/E.
BTW Was this thread not about 'Clist character string compare'? Enough
said, methinks.
Chris Poncelet
Jon Perryman wrote:
ADDRESS TSO is the default when a REXX exec is executed from ISPF or TSO It
usually is not needed.
TSOEXEC adds additional overhead in some cases (not all). In addition, it is a
command (not a REXX environment such as ADDRESS TSO).
"LISTA ST" will work fine without ADDRESS TSO is omitted. Did you actually try
it? I've used it for years and never coded ADDRESS TSO in any REXX except to switch back
after ADDRESSing another environment.
Using ADDRESS XXXX changes to environment XXXX. This is why you coding ADDRESS
ISREDIT allows you to use the edit commands without prefixing them with ISREDIT
OR ADDRESS ISREDIT.
As for parsing in your panel, why was it necessary? What error occurred that
makes it necessary?
If you are having problems with LIBDEF's being freed, then you can consider
using different APPLID's because ISPF libdef's are associated with the APPLID.
Jon Perryman.
________________________________
From: CM Poncelet <[email protected]>
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.
----------------------------------------------------------------------
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
