Excerpted from a message dated 01-13-99, Eddy Thilleman to Murray
Lesser:

Hi Eddy--

    I am not going to comment in detail with regard to your assumptions
as to the meanings of the PL/I terminology used in the little example I
posted in reply to your earlier request to compare PL/I with Pascal.
There is no way that you can learn PL/I (which is probably the richest
programming language available) from a few explanations in a Fido post.
Suffice it to say that some of your interpretations were correct, and
some were not.  However, I will comment on some of your queries that
might be of general interest.

ML> REXX was derived from PL/I in a manner similar to the way the
ML> original BASIC was derived from FORTRAN. 

ET>I don't know FORTRAN. BASIC is limited in its capabilities, because
  >it's invented for the beginner.

    Note that I said "original BASIC."  When MS put out the last useful
(IMO) version of BASIC (BASIC Professional Development System v 7.1) in
1990, it was a full-fledged application-development language, probably
second only to REXX as a suitable language for text manipulation, and
considerably more useful than C for data-processing applications.  It
included most of the control constructs that are in most modern
languages, and several very useful data-processing features (such as
ISAM) that are not. It would compile for either DOS or for 16-bit OS/2
(v 1.x).

ML> PL/I source code begins in column 2, 

ET>Why is that?

    Tradition, I suppose, left over from punched card days.  In FORTRAN,
column one was reserved to mark a comment line.  In PL/I, you can change
the allowable column limits to anything you want, with suitable
compile-time options.

ML> *process langlvl(saa2), limits(extname(31)), libs, not('^');

    The *process statements (starting in column 1 and appearing before
any other code) denote compile-time options.  The example shown uses
only a small subset of those available; a detailed explanation of them
would not be very useful.

ET>toupper: proc(infile) options (main noexecops);
  >does the infile stand for the input device (keyboard) ?

    This is the label showing the beginning of the process "toupper."
"Main" identifies it as the main procedure, and
"noexecops" says to pass
the entire "rest of the command line" to the variable
"infile."  The
contents of infile come from the keyboard (actually from the system)
only for MAIN procedures.  Otherwise, any input arguments are passed by
the calling program.

ML>     dcl infile char(100) var;

    DCL is an abbreviation for "DECLARE" and "var" is
an abbreviation
for "varying."  This tells the compiler that infile is a variable-length
string not more than 100 characters long.

ML>     dcl (From value('abcdefghijklmnopqrstuvwxyz'),
ML>          To value('ABCDEFGHIJKLMNOPQRSTUVWXYZ')) char(26);

ET>these two lines are the translation rules?

    Same as REXX.  The REXX translate function was lifted almost exactly
from PL/I (with a couple of additions).  Note that, since there is no
intervening semicolon, this is only one statement.  Both strings are
declared with "value" telling the compiler that they are constants, not
variables.

ET>If a newer version is out, does not mean that an older 
  >version suddenly magically stops working.

    IBM doesn't support previous versions of any of its language
processors (no more CSDs containing free bug fixes or language
upgrades).  The back version doesn't stop working.

ML> So, I will have to live with workarounds for any long-lived
ML> bugs I discover.

ET>Hopefully, these bugs are not fatal toe you. ;-)

    The chances of finding a "fatal" bug in PL/I at this late date is
pretty small :-).  I have only found one bug in PL/I for OS/2 thus far
(in 1996) and wrote a workaround for it before I reported it to IBM.  (I
have found it most useful to include the workaround with the bug report;
it is of great help to the bug-swatter.)  I was later told by a
long-term PL/I user that my bug had been in the language since mainframe
days, and everyone just lived with it!  By coincidence, a CSD for that
version of the compiler was in the making at the time, so the bug fix
was shipped the following month.  Actually, bugs in language processors
(compilers) are very rarely fatal (for a well-designed language) because
there are always several ways to accomplish the same task.  I am not so
sure that this statement applies to drag-and-drop "application
builders," but I don't use them.

    Regards,

        --Murray

___
 * MR/2 2.25 #120 * Stay alive!  Learn something new every day.

--- Maximus/2 2.02