On Jun 28, 2005, at 2:11 PM, Shmuel Metz (Seymour J.) wrote:
In <[EMAIL PROTECTED]>, on 06/28/2005
at 08:48 AM, Joe Zitzelberger <[EMAIL PROTECTED]> said:
While column 50 might look blank iff you are using a printed listing
(a rarity in the days of syntax highlighting editors
Editors? It doesn't exist in the source file, so the editor doesn't
see it.
and a waste of trees)
The term "listing" also includes DASD files with A or M carriage
control. Have they stopped translating out nondisplayable characters?
ISPF will offer a note line to the effect of "nondisplayable data,
blah, blah, find p'.', blah, blah'. PC editors tend to offer a
little square box.
Again, this only applies if you view your listing as a DASD file.
Printed listings will lose that data.
the surrounding columns would have something like:
Move 'a 0d 2 ic$k34 d pd e,x d' to DFHEI1234
Why would you get the error message for alphanumeric text? I don't see
a SI or SO there.
That is what the translator, with the given options would insert.
One of those blank-looking columns in the alphanumeric literal is
going to be the problem.
This is the problem we have been discussing. A translator inserted a
literal that contained a shift char. The compiler was confused
because it didn't expect shift chars and tossed out a message. The
listing looks something like:
* Exec product
* some command
* End-Exec
*Inserted by translator
Move 'alpha literal with SO embeded' to DFH1234
IGYPS1234-E A shift-out char was found in column 50 without a
matching shift-in. The literal was accepted as written.
IGYPS1235-E A DBCS literal was not properly continued. A delimiter
in column 72 was assumed.
Call 'DFHiface' using field, field, field, field
Somehow, some people think that these messages are not self-
documenting and completely obvious given the context in which they
are used.
The newer, supported and recommended, translator options would have
created something like:
Move x'01020304050e0f' to DFHEI1234
Where the use of a hex literal fixes the problem of the shift-in/
shift-out being taken, er, literally.
That should be enough for anyone to realize it is a translator
problem.
It would if the compiler were complaining about one of those
characters.
That is what the compiler was complaining about. As Bill K. has
pointed out, you can see the translator lines in your source
listing. You can see the column puts the error somewhere inside the
alphanumeric literal. Turning hex viewing on in ones editor will
show you the SI or SO in that column/line of your listing.
What more could anyone want in a message manual?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
