Re: Reading in file containing Low Values doesn't work correctly
- From: "Richard" <riplin@xxxxxxxxxxxx>
- Date: 24 Jan 2007 14:02:03 -0800
On Jan 25, 9:33 am, "HeyBub" <heybubNOS...@xxxxxxxxx> wrote:
Richard wrote:
On Jan 25, 3:44 am, "HeyBub" <heybubNOS...@xxxxxxxxx>
Low-values doesn't really make sense in a LINE SEQUENTIAL file. I
wouldn't be surprised if the results were unpredictable.
The results are entirely predictable, but the prediction needs to be
based on what the appropriate manual states will occur.
In the case of MicroFocus the default behaviour is that when writing a
line sequential record it will be processed and all control characters
will be prefixed by a null (which is the default 'low-value'). On
reading, the null is used as a signal the the next character is a
control character that needs to be preserved. This allows a file to be
written and read that will contain control characters (eg tab, line
feed).
In the case in point the nulls are being seen as guard characters and
are dropped, except where two nulls in a row the second is retained.
To change this behaviour set the 'N' switch to off (-N).
Reading the manual makes the behaviour predictable.
Here's another prediction:
"Line-sequential files are files that reside in the hierarchical file system
(HFS) and that contain only printable characters and certain control
characters as data."
Note the "... only printable characters..." qualifier. Low-values is not
printable, nor is it a normal control character like TAB or Linefeed.
In fact there is a list of allowable control characters. The prediction
is that in those files in that system a null will never occur and tabs,
for example, will be passed to the program in the record area (as
specified in the manual).
http://publib.boulder.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic...
Why a file system (like the one you mention) would go to the trouble of
adding LV bytes only to remove them later is a mystery and evidence of
carrot eating. If the file system can detect a control character for the
purpose of preceeding it with a LV byte, why does it need the LV byte to
identify the very same character when it reads the file?
Yep, definite carrot eating.
Because, upon reading a line sequential file, certain control
characters, such as tab, line feed and carriage return will be
processed by the file system and will not be passed into the program.
tabs will be expanded and cr/lf will signal the end of record.
If it is required to have these characters passed from one program to
another then the low-values prefix acts as an escape character. The
low value will be dropped and the character following will be passed to
the program as data.
If that behaviour is unrequired then the 'N' switch can be turned off
by a command-line entry or an environment variable (COBSW=-N) or by the
program using called routines to change the setting (as specified in
the manual).
That is to say that 'low-values in line sequential files' may not make
sense on your system, but your system is not the whole world and they
may make sense on other systems.
As it happens I have no use for the nulls in that way and have always
had the N switch off, but that is the reason they are used.
.
- References:
- Reading in file containing Low Values doesn't work correctly
- From: Timofmars
- Re: Reading in file containing Low Values doesn't work correctly
- From: HeyBub
- Re: Reading in file containing Low Values doesn't work correctly
- From: Richard
- Re: Reading in file containing Low Values doesn't work correctly
- From: HeyBub
- Reading in file containing Low Values doesn't work correctly
- Prev by Date: Re: Reading in file containing Low Values doesn't work correctly
- Next by Date: Re: JCL, Cobol and "Call Parameters"
- Previous by thread: Re: Reading in file containing Low Values doesn't work correctly
- Next by thread: Re: Reading in file containing Low Values doesn't work correctly
- Index(es):
Relevant Pages
|
