Shmuel Metz (Seymour J.) wrote:
In <500bf711.2040...@bcs.org.uk>, on 07/22/2012
at 01:50 PM, CM Poncelet <ponce...@bcs.org.uk> said:
Unless I misunderstand what you mean by 'CALL-like', REXX is
calling ISREDIT
No, REXX is calling ISPEXEC, which in turn is calling ISREDIT. To call
ISREDIT directly, change the operand of the ADDRESS statement and
change the command text accordingly, e.g.,
Address ISREDIT
"MACRO (MEM) NOPROCESS"
Address ISPEXEC
"CONTROL ERRORS RETURN"
Address ISREDIT
"SCAN OFF"
"F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE' "
"F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
"F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
"F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
or
Address ISREDIT "MACRO (MEM) NOPROCESS"
Address ISPEXEC "CONTROL ERRORS RETURN"
Address ISREDIT "SCAN OFF"
Address ISREDIT "F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE' "
Address ISREDIT "F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
Address ISREDIT "F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
Address ISREDIT "F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
OK. But I do not *have* to code "ISPEXEC CONTROL ERRORS RETURN". The
rest is mostly "ISREDIT ..." apart from pure REXX instructions which do
not need quotes around them. So I assume that "ISPEXEC ..." is calling
ISPEXEC directly, but that "ISREDIT ..." is then calling ISREDIT
likewise directly (because the "ISPEXEC CONTROL ERRORS RETURN" is not
strictly required). However, REXX could be implicitly calling ISPEXEC
and then routing ISREDIT calls through ISPEXEC. But on the other hand,
if REXX does an ADDRESS IPCS followed by an IPCS call - and then an
ADDRESS ISREDIT followed by one or more ISREDIT calls - does that imply
that IPCS is now calling ISREDIT, or is ISPEXEC still calling it? If you
have GTF'd it and seen it happen, fine - thanks.
I suspect that this is because edit macros were originally
written in Clist,
Perhaps, but could it not have been for consistency with panel
definitions?
... or with assembler SET and system variables, and JCL PROC parms etc.
But I have a feeling that this is 'barking up the wrong tree'. Panels
are associated with ISPF dialogs which, in turn, rely on the 'old'
standards (which include Clist as well as panels). Meanwhile, REXX is a
function-like sort of interpretative and simplified PL/I - in which '&'
means the Boolean 'AND' but not a variable; i.e. it is 3GL-like. So I
guess there is a clash between the 'old' way of prefixing variables with
&'s and the 'new' way of declaring them without &'s. But no matter how
these different 'cultures' are fitted together, they will clash at times
- not because Clist or panels or ISREDIT or REXX or anything else is 'to
blame', but because they use different 'building blocks' that don't fit
together. So whether it is Clist or panels - or anything else from the
'old block' that ISREDIT came from - it will squabble with things from
the 'new block'.
Apart from that, there are lots of things wrong with ISPF (starting
from ESA onwards and getting worse);
What changes made things worse, other than dropping certain
components?
Drop-down menus, and primary PFK13-24 switched to PFK01-12, in ESA? XA's
panel ISREDDE changed to ISREDDE2/3/4/5 in ESA ... with a notice saying
something like 'use of ISREDDE will result in a better performance of
the editor'? PANELID showing that only ISREDDE2/3/4/5 are used? Making
VIEW (with ISREDDE2/3/4/5) the default instead of BROWSE? Hard-coded
data in the ISPF machine code so that VPUTs and VGETs issued in panels
(to save/restore settings) are overridden by ISPF hard-coded ones?
'Press' PF1 today and 'press' F1 tomorrow? Hodie tibi sed cras mihi? Cui
bono? Taketh the wise in their own craftiness doth he? Excuse my dig,
but I would rather look up to Diogenes in his barrel than to a thief in
his mansion.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
