Shmuel Metz (Seymour J.) wrote:
In <500e6b77.2090...@bcs.org.uk>, on 07/24/2012
at 10:31 AM, CM Poncelet <ponce...@bcs.org.uk> said:
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.
Address ISREDIT does not in general require quotes either. The quotes
are only needed because you want constants with special characters.
Had you wanted, e.g.,
Address ISREDIT F NEXT
then you wouldn't have needed quotes, assuming that you haven't
assigned values to F or NEXT.
Yes I know that. ADDRESS ISREDIT, on its own, is sufficient to cause all
commands that follow it to be interpreted as ISREDIT ones (without
quotes and without having to specify ADDRESS ISREDIT FIND NEXT etc. each
time) - until another ADDRESS <whatever> is found. But I do not normally
use ADDRESS except for IPCS: it is just as easy, and quicker, to put
strings in quotes. So I put quotes around ISREDITs (when writing in
REXX) and then pure REXX code without quotes.
So I assume that "ISPEXEC ..." is calling ISPEXEC directly, but
that "ISREDIT ..." is then calling ISREDIT likewise directly
No; Address ISPEXEC is calling ISPECEC directly and Address ISREDIT
... is calling ISREDIT directly. A statement containing only an
expression is evaluated and the result passed to the current
environment.
That is what I said, except that I use quotes instead of ADDRESS.
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?
By "IPCS call" and "ISREDIT call" do you mean expressions beginning
with IPCS or ISREDIT? If so, it's indirect. OTOH, if you mean
expressions recognized by IPCS or ISREDIT, then it's direct.
Address ISREDIT
ISREDIT foo /* indirect */
foo /* direct */
Yes, by IPCS call I mean expressions beginning with IPCS (unless ADDRESS
IPCS is coded beforehand, when the expressions that follow it are then
interpreted as IPCS ones - i.e. as 'direct' IPCS). Etc.
Meanwhile, REXX is a function-like sort of interpretative and
simplified PL/I
Don't confuse REXX syntax with the syntax of commands that REXX is
passing to an environment. From a REXX perspective, what it is passing
to TSO, ISPEXEC, ISREDIT or any other environment is an arbitrary
character string.
I mean pure REXX syntax is a function-like interpretative and simplified
form of PL/I - e.g., from memory, X= D2C(X2D(VAR)) is what I would call
pure REXX. I am not referring to REXX invoking other environments -
which requires either an ADDRESS (which I do not use) or quotes (which I
do use).
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).
Why do you believe that CLIST had any impact on the design of ISPF
panels?
That is not what I believe. I am pointing out that Clist and ISPF panels
come from a same 'era' in which ampersands were used to denote variables
- but without implying that one had a direct impact on the other. Two
people can speak a same language without necessarily having any impact
on each other - although it is more efficient to choose people who can
speak the same language if they are to interact with each other.
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.
No; there's a clash between the way ISPF works and your preconceptions
about how it works. From an ISPF and CLIST perspective, REXX is just a
consumer of strings; how it interprets those string is beyond the
scope of the scripting language.
I have no preconceptions about how ISPF works. I do not dispute that
REXX is just a consumer of strings. But from a CPU's perspective - ISPF,
Clist and REXX are just 'producers of strings' (of machine code,
ultimately), and how they build their strings or in what sequence they
are then 'presented' is irrelevant. The CPU executes whatever is in its
instruction cache. How the CPU interprets this machine code is beyond
the scope of even the machine code itself, because the CPU is
'hard-wired' to 'interpret' microcode. Hence the machine code can be
described as the 'old way' and Clist as the 'new way', or Clist as the
'old way' and REXX as the 'new way', or REXX as the 'old way' and mobile
phone apps (whatever they are) as the 'new way' etc. ad nauseam. But at
the 'atomic level', it is the microcode that makes things work.
but because they use different 'building blocks' that don't fit
together.
Actually, REXX and ISPF fit together quite well, but you have to
understand both.
I do understand both. I mean different 'building blocks' not fitting
together in a way similar to that of COBOL and Fortran, or assembler and
Forth, not 'fitting' together. But everything 'fits' together at the
machine code level if it hasn't done so 'higher up'. (BTW I have in the
past called Fortran from COBOL, just in case you want to lecture me on
that too.)
Meanwhile, I'm dropping out of this discussion topic.
Thanks for all your input and clarifications.
Cheers, Chris Poncelet
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
