Maybe this posting is superfluous, but I feel there is an underlying
misunderstanding regarding this problem with ampersands.
At least this ongoing discussion hints at that.
1. REXX does *nothing* special with ampersands (it treats it as any other
character - in data it is.).
2. ISPF as such has the ampersand as a variable identifying character. And
does, when it's appropriate, evaluate/substitute it.
3. CLIST *also* have the ampersand as variable char. And does *its* variable
substitution work.
4. You need to be aware of this - nothing more.
5. Personally I avoid using ampersands in edit commands such as FIND. It
simplifies the life.
6. If You must I suggest an initial change like (e g) "C '&' '§' all" and an
ending "C '§' '&' all". (And of course using the "§" in place of "&".)
7. An alternative to the variants of editing/searching a PDS member as ISPF
Edit and EXECIO the member is this:
ISREDIT "(LAST) = .ZL"
r.0 = last
Do i = 1 To r.0
ISREDIT '(R) = LINE' i
r.i = r
End
- Then You can work with the stem "r.". And if needed, do a "EX ALL" + "DEL
ALL X" + inserting the lines with e g "LINE_AFTER" etc.
Regards,
Thomas Berg
_______________________________________________________
Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För CM Poncelet
> Skickat: den 22 juli 2012 14:50
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: Re: REXX ISPF edit FIND failing
>
> 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 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
