Paul Gilmartin wrote:
On Fri, 20 Jul 2012 07:31:09 +0100, CM Poncelet wrote:
I did explain that ISREDIT follows Clist rules when processing &'s, in
my earlier posting, methinks <grin>:
...
TSO Clist edit macros have been around long before REXX appeared (around
1989-90) and ISREDIT was meant to be called in Clist, not REXX.. So REXX
has to follow the Clist rules when calling ISREDIT - e.g. to process
data containing &'s.
Does this mean that if the same command string is issued to ISREDIT
from CLIST and from Rexx the effect will be identical, or not?
In most cases yes - unless there are ampersands in the string. In Clist,
3 &'s must be coded. But it seems like 2 &'s are enough in REXX (I have
not checked what happens if 3 &'s are coded in REXX).
I scarcely know CLIST. Is it even meaningful to discuss the command
string issued from CLIST to ISREDIT?
It is meaningful only when ISREDIT command strings issued from REXX do
not produce the expected 'REXX-like' results.
How old is the CALL interface from programming languages?
I do not know, but either it or something like it was around for
'executing' Clist from PL/I in the 1980's. However, it is more efficient
CPU-wise to call a load module from REXX/Clist (e.g. in a loop) and
perform whatever needs to be done by REXX/Clist in the calling
REXX/Clist code itself, rather than execute a load module first and have
it then call REXX/Clist for whatever it needs.
Same
question as earlier: Do identical command strings issued to ISREDIT
from CLIST and CALL have identical effect?
I would expect the ISREDIT effects of REXX/Clist v. ISPLINK calls to be
identical, because the command strings in the call are passed as data
constants.
How are ampersands
treated in commands passed via CALL?
If you are referring to ISPLINK, the ampersands would be passed together
with all the other characters in the string. The assembler (or compiler)
cannot interpret the meaning/purpose of the REXX/Clist strings to
convert them into efficient machine code. So it assembles/compiles its
own program code, which it recognizes, but leaves the REXX/Clist strings
as they are and passes them as data in the call.
As you imply Rexx is not
CLIST. Might it not have been better if the Rexx interface had been
specified as CALL-like rather than CLIST-like?
Unless I misunderstand what you mean by 'CALL-like', REXX is calling
ISREDIT - as the strings are enclosed in quotes (e.g. "ISREDIT FIND
<whatever>"). It is ISREDIT, not the REXX interface, which interprets an
ampersand-prefix as a variable (like Clist does). I suspect that this is
because edit macros were originally written in Clist, before REXX
appeared, and ISREDIT follows Clist rules because of that.
There is nothing wrong with ISPF itself.
That's a sweeping statement. Are you sure?
I meant it within the context of using 'FIND' in ISPF itself, instead of
via ISREDIT. If you copy/paste all the JCL PROC lines from the original
post (e.g. into a member of a PDS) and then, from the command line,
issue "FIND FIRST 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)'",
ISPF's EDIT will then position its cursor on the first line that
contains that string and also at the first character of that string; if
you hit RFIND, it will find the next occurrence etc.; ditto for all the
other FIND strings in the edit macro. If you then save that member and
BROWSE it, and repeat all the FINDs, ISPF's BROWSE will each time
position the cursor at the correct line and starting character of the
string. So ISPF is not itself causing the edit macro problems. If you
then write some REXX to "ALLOCATE FI(IN) DA('<whatever the DSN(member)
is>') SHR KEEP", "EXECIO * DISKR IN (STEM REC. FINIS)", then loop
through a 'SAY REC.*' to display the lines read in - and save/execute
this REXX - all the lines will be displayed exactly as they are in the
PDS member and with their ampersands etc. So REXX is not causing the
edit macro problems either. Therefore ISREDIT is causing them.
Apart from that, there are lots of things wrong with ISPF (starting from
ESA onwards and getting worse); but that is way 'off topic'.
Cheers.
-- gil
----------------------------------------------------------------------
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
