Hi David--

    Yesterday, I posted a message (I think this subject) complaining
about two idiosyncrasies in my Personal Edition of release 1.1 corrected
to CSD#7.  The first was a complaint about the compiler not recognizing
a PRN in the TITLE attribute when opening a file for printed output,
thus requiring an OS/2 DD:PRINTER=PRN line.  Forget that one; it was
pilot error!  I was using TITLE('PRN') instead of TITLE('/PRN').  Wonder
how many reported bugs are pilot error?

   The second complaint, that the compiler couldn't recognize
zero-length input lines when reading an ASCII file until it had read one
or more lines having some content, is not pilot error.  I figured out an
easier manual workaround than the one I mentioned yesterday:  Pick up
the file in a text editor.  If the first line is blank (zero length),
insert a  character, and save the file under a slightly different
name.  This one works fine; all the rest of the initially zero-length
lines are read as if they were single character lines having an  as
the only character.  But is still is a nuisance!

    I think this omission of the initial blank lines when reading an
ASCII file is a real bug (or else a design decision!).  I am using the
title page of Ray Gwinn's VMODEM.TXT (comes with SIO) for my test case
(the first actual text comes on line 24).  One way to check without
using up lots of paper is to look at the accepted input, unchanged,
using SYSPRINT redirected to a file.  I have also tried DISPLAYing one
input line at a time (no other output) in both hex and text, pressing a
key to get the next line, so I can almost see what is going on.  (I read
the original "text" file in hex using SYMDEB, left over from MASM 4, for
comparison.)  If you have time, and can confirm the symptoms with the
Professional Edition compiler, I will send the "bug" in to Carolyn at
Team PL/I Support; if it is in release 1.1, CS#7, it probably is still
in release 1.2.  Perhaps the powers that be have a convincing argument
that it is a feature, not a bug!

    I had the bright idea of reading in the file as a record file, with
2-byte records, testing the input to see if it was '0D0A'X, and, if so,
print a blank line and go on to the next.  If not, go into the same
routine I have been using, which would make the next line on the paper
the first line of the text with anything on it.  Unfortunately, while a
logically excellent workaround in theory, I spent all morning trying to
implement it, with no success.  How do I read an ASCII text file
(produced, say, by a text editor) as a set of fixed-length records?  As
near as I can tell, the language won't read fixed-length record files
unless they were written as such by a PL/I program :-(.  Any help will
be greatly appreciated.

    All-in-all, it has been an interesting, if somewhat frustrating,
learning experience.  I think I'll continue to use my REXX version for
reproducing shareware "manuals."  But this is a good start on my
eventual utility for listing source code (centered horizontally on the
page, with or without line numbers or headings, as desired).  After all,
there is always _something_ in the fist line of my source code, and if
there isn't, I don't want to see it on the listing!

    Slight change in subject:  I sent a message to Carolyn (she should
find it in her e-mail file tomorrow) asking if release 1.2 allows
stand-alone executables. If so, it might even be worth the money to me.
The next query is to see if you get hard-copy docs with the upgrade, and
whether or not the employee (retiree, in my case) discount works for the
upgrade.  As you see, I am talking myself into spending all that money!

    Best regards,

          --Murray

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

--- Maximus/2 2.02