Line-sequential files vs. others...

Hi,

Just wanted to confirm a couple of things about "line-sequential"
file. Read in the z/os docs that it means a file with only printable
chars, with each record seperated by a newline.

It also mentioned that physical records would be of different sizes as
trailing spaces are chopped off. This means that if we have a copybook
with the last entry as say 10 FILLER X(5). Then if in one record we
had a string of 3 chars the remaining 2 spaces would not be wriiten to
the file ?
ALso this would only be valid for alphanumerics as numerics are right
aligned so u'd never get trailing spaces. How about an array ? does
this rule hold for all elements in the array (unlikely) and only for
the last cell in the array (inconsistent)?

Only printable chars means DISPLAY usage. What is a file which
contains numerics with COMP's and the DISPLAY stuff mixed up called ?
Are there sequential files of this format as well ?

Is there anyplace where one can get hold of some sample sequential
ebcdic data files along with their copybooks. These seem really hard
to come by as opposed to say xml's and their xsd's !

Thanks

Ed wrote:
> Hi,
>
> Just wanted to confirm a couple of things about "line-sequential"
> file. Read in the z/os docs that it means a file with only printable
> chars, with each record seperated by a newline.
>
> It also mentioned that physical records would be of different sizes as
> trailing spaces are chopped off. This means that if we have a copybook
> with the last entry as say 10 FILLER X(5). Then if in one record we
> had a string of 3 chars the remaining 2 spaces would not be wriiten to
> the file ?
> ALso this would only be valid for alphanumerics as numerics are right
> aligned so u'd never get trailing spaces. How about an array ? does
> this rule hold for all elements in the array (unlikely) and only for
> the last cell in the array (inconsistent)?
>
> Only printable chars means DISPLAY usage. What is a file which
> contains numerics with COMP's and the DISPLAY stuff mixed up called ?

Depends on the compiler. Usually it is called "Sequential" as opposed to
"Line Sequential"

> Are there sequential files of this format as well ?
>
> Is there anyplace where one can get hold of some sample sequential
> ebcdic data files along with their copybooks. These seem really hard
> to come by as opposed to say xml's and their xsd's !



You may be making this harder than it really is. Here's the drill:
1. Record is built in the FD whose record is defined to be length "x"
2. Pgm finds, in the whole record, "y" trailing spaces.
3. Pgm writes a record of "x-y" + 1 (or 2) bytes. [1=X'0D', 2=X'0D0A']

So a record defined to be 1000 bytes can be anything from 1 to 1002 bytes of
actual media space. Anything less than 1000 is blank-filled when the record
is read.

You can WRITE a record with COMP fields. You just won't be able to read it!

Here's why:

Eventually the read routine will encounter a COMP field that looks like
{CR/LF or NewLine} and terminate the data transfer. On a read, the pgm can't
tell the difference between data and control characters.

"JerryMouse" <nospam@bisusa.com> wrote in message
news:B-udnTUXB9URaYbcRVn-ow@giganews.com...
> Ed wrote: 
>
> Depends on the compiler. Usually it is called "Sequential" as opposed to
> "Line Sequential"
> 
>
>
>
> You may be making this harder than it really is. Here's the drill:
> 1. Record is built in the FD whose record is defined to be length "x"
> 2. Pgm finds, in the whole record, "y" trailing spaces.
> 3. Pgm writes a record of "x-y" + 1 (or 2) bytes. [1=X'0D', 2=X'0D0A']
>
> So a record defined to be 1000 bytes can be anything from 1 to 1002 bytes
of
> actual media space. Anything less than 1000 is blank-filled when the
record
> is read.
>
> You can WRITE a record with COMP fields. You just won't be able to read
it!
>
> Here's why:
>
> Eventually the read routine will encounter a COMP field that looks like
> {CR/LF or NewLine} and terminate the data transfer. On a read, the pgm
can't
> tell the difference between data and control characters.
>
>
Some systems (example: Microfocus on PC's) have extensions
for line sequential, but if you utilize these extensions, you lose
portability.

Eg, if you embed a control Z, it will likely not work elsewhere.

"Russell Styles" <rNwOsS0P2A0M2@comcast.net> wrote in message
news:uN6dnWju8f-a2YHcRVn-sg@giganews.com...
<snip>
>         Some systems (example: Microfocus on PC's) have extensions
> for line sequential, but if you utilize these extensions, you lose
> portability.
>
>     Eg, if you embed a control Z, it will likely not work elsewhere.
>
>

EVERY compiler that supports "explicitly defined" LINE SEQUENTIAL files is
providing an extension to every ANSI or ISO Standard (but NOT to the X/Open
COBOL Standard).

Therefore each and every compiler vendor can say what they want about
- embedded control characters
- trailing spaces
- etc

I would agree, however, that you are MOST likely to not run into "portabilit
y"
problems for LINE SEQUENTIAL files if:

A) you use only "display" (possibly DBCS, Unicode, whatever) data, i.e. only
data that passes an IF ALPHANUMERIC class test (unless you are also using
Unicode data)

B) You strip off any trailing spaces before writes

C) You do NOT use the REWRITE feature (that some compilers allow) - at least
 not
when changing record lengths

D) Make certain that you "expand" tabs your self (to spaces)



--
Bill Klein
wmklein <at> ix.netcom.com

"Russell Styles" <rNwOsS0P2A0M2@comcast.net> wrote in message
news:uN6dnWju8f-a2YHcRVn-sg@giganews.com...
<snip>
>         Some systems (example: Microfocus on PC's) have extensions
> for line sequential, but if you utilize these extensions, you lose
> portability.
>
>     Eg, if you embed a control Z, it will likely not work elsewhere.
>
>

EVERY compiler that supports "explicitly defined" LINE SEQUENTIAL files is
providing an extension to every ANSI or ISO Standard (but NOT to the X/Open
COBOL Standard).

Therefore each and every compiler vendor can say what they want about
- embedded control characters
- trailing spaces
- etc

I would agree, however, that you are MOST likely to not run into "portabilit
y"
problems for LINE SEQUENTIAL files if:

A) you use only "display" (possibly DBCS, Unicode, whatever) data, i.e. only
data that passes an IF ALPHANUMERIC class test (unless you are also using
Unicode data)

B) You strip off any trailing spaces before writes

C) You do NOT use the REWRITE feature (that some compilers allow) - at least
 not
when changing record lengths

D) Make certain that you "expand" tabs your self (to spaces)



--
Bill Klein
wmklein <at> ix.netcom.com