HP3000-L Archives

March 2002, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tom Emerson <[log in to unmask]>
Reply To:
Tom Emerson <[log in to unmask]>
Date:
Wed, 6 Mar 2002 02:58:21 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
> -----Original Message-----
> From: Richard Barker
>
> Not knowing Cobol that well, wouldn't the display show the
> other character
> if it is in the variable, so when I'm displaying
> "'"card-type"'" and the
> program displays '@', shouldn't it show something else.

Actually, it may be displaying something else -- it's just that your
terminal is incapable of displaying it (not that this should worry you much,
but it can be a cause for confusion)

What it may actually be showing is either '@<null>' or '@<some character
between 128 & 255>'.  Nulls, in particalar, are often dropped by most
terminals [part of the reason WHY they are "null" characters has to do with
the fact that mechanical devices (teletypes) needed a "character" to be sent
that didn't actually print in order to allow the print-head to move back to
the left after a carraige-return...]  HP terminals, however, can be switched
into a "display everything humanly and inhumanly possible" mode that will
show "null" bytes as the letters "N" and "L" in the space of a single
character. (stacked one on top of the other, and offset a bit...)

hi-order characters (with binary values between 128 and 255) may or may not
display, as well as a few "control" characters (characters with binary
values of 1 through 31)  The "bell" character, in particular, doesn't
"display", but rather causes the terminal to make an unusual noise  (hard to
'see' when sent to a printer, especially if you aren't in the room at the
time... :)

About the only way to be certain that "what you typed" matches what you are
testing for is to use a debugger and look at the contents of memory in
hexadecimal form (or octal, if so inclined).  If you find the values "40 00"
listed, then you know the second byte is indeed a "null". (COBOL is
expecting the values "40 20" to "match" a single "@" character -- the
"space" is ignored)

I don't remember if it has been suggested on this thread or not, but have
you tried the "ACCEPT <varname> FREE" form of the Accept statement?  the
"free" modifier means "freeform", which should accept a single character and
blank-fill any remaining characters in the input variable

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2