sequential file formats

I have noticed that every compiler/op sys seems to create a different
format for sequential files.  for instance, a COBOL program on the
mainframe will create a sequential file with a four byte header that
indicates length.  On microfocus on AIX, a COBOL program will create a
similar file but the with a special record as the first record that has
some additional information.

Does anyone know of a comprehensive list of all the different formats
that may be out there?

I will post small sample program that will create a two record
sequential file in hopes that some of you will run the program and
report back the format of the file that is produced.  A hex dump as a
post would be great.  if you can not hex dump on your selected
operating system, then email the output to theador@@@@gmail and I will
hex dump the file and post it.

Hopefully we can cover these combinations:
Fujitsu on UNIX
Fujitsu on WIndows
IBM on AIX
IBM on z/OS
MicroFocus on UNIX
MicroFocus on WIndows
AccuCOBOL
OpenCOBOL

Thanks to those who can help in this experiment,
Theador.

theador wrote:
> I have noticed that every compiler/op sys seems to create a different
> format for sequential files.

Should be: "... every programmer seems to create..."


for instance, a COBOL program on the
> mainframe will create a sequential file with a four byte header that
> indicates length.  On microfocus on AIX, a COBOL program will create a
> similar file but the with a special record as the first record that
> has some additional information.

And I can duplicate these on a PC.

On 24 Jul 2005 22:02:28 -0700, "theador" <Theador@gmail.com>
enlightened us:

>I have noticed that every compiler/op sys seems to create a different
>format for sequential files.  for instance, a COBOL program on the
>mainframe will create a sequential file with a four byte header that
>indicates length.  On microfocus on AIX, a COBOL program will create a
>similar file but the with a special record as the first record that has
>some additional information.
>

Have you noticed that a sequential file on the mainframe, whether
created by COBOL or some other language, can also not have a four byte
header and be fixed length?


>Does anyone know of a comprehensive list of all the different formats
>that may be out there?
>
>I will post small sample program that will create a two record
>sequential file in hopes that some of you will run the program and
>report back the format of the file that is produced.  A hex dump as a
>post would be great.  if you can not hex dump on your selected
>operating system, then email the output to theador@@@@gmail and I will
>hex dump the file and post it.
>
>Hopefully we can cover these combinations:
>Fujitsu on UNIX
>Fujitsu on WIndows
>IBM on AIX
>IBM on z/OS
>MicroFocus on UNIX
>MicroFocus on WIndows
>AccuCOBOL
>OpenCOBOL
>
>Thanks to those who can help in this experiment,
>Theador.

Regards,

////
(o o)
-oOO--(_)--OOo-


"The early bird may get the worm,
but the second mouse gets the cheese."
--Steven Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

here is the hexdump of the output file from open-cobol on debian intel
linux:

$ od -h output.dat
0000000 0014 0000 ffff ffff ffff ffff ffff ffff
0000020 ffff ffff ffff ffff 001e 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000
0000072

I think this is the same as mainframe cobol.

Ahhh, the fixlength sequential file.  I will write a different test
program and start a new topic if I need to determine the differences
between what programs compiled with different compilers output.  Thanks
for pointing that out.

Here is the test program that I am asking people with access to the
above machines to run and report a hex dump of the output file.  This
was compiled on open-cobol, so there may be different compile errors
that would have to be fixed on your platform. thx.

IDENTIFICATION   DIVISION.
PROGRAM-ID.      test1.

environment division.
input-output section.
file-control.
select AFILE assign to "output.dat"
organization is relative sequential
record key is big-record.

DATA  DIVISION.
FILE  SECTION.

fd AFILE
label records are standard
record varying from 1 to 50
depending on a-length
data record is a-file.

01 a-file.
05 big-record pic x(50).
WORKING-STORAGE  SECTION.

01 A-GRP.
05  A-ELE     PIC X(50).

01 A-LENGTH  COMP PIC S9(4).

PROCEDURE DIVISION.

OPEN OUTPUT AFILE.
MOVE ALL HIGH-VALUES to a-grp.
MOVE 20 TO A-LENGTH.
WRITE A-FILE FROM A-GRP.
MOVE ALL LOW-VALUES to a-grp.
MOVE 30 TO A-LENGTH.
WRITE A-FILE FROM A-GRP.
CLOSE AFILE.

STOP RUN.

Can you tell us WHY you want this information?  Almost (possibly all) vendor
s
provide documentation on their OWN 'file structures" (and often they also
include OPTIONS for file types).  As others have pointed out on (IBM - not a
ll -
mainframes) the "RDW" (record descriptor word) ONLY appears for variable len
gth
(RECFM=V) (or possibly spanned?) records.  For fixed length files this doesn
't
exist.  For BLOCKED files (again IBM mainframe) there is also a 4-byte "bloc
k
descriptor word" before each block of records.  As far as "print" output goe
s,
on IBM mainframes, you also need to check out the ADV compiler option and th
ere
are different syntax options that produce RECFM=FA vs RECFM=FM (ASA characte
rs
vs Machine characters)

On all (most?) environments where Micro Focus provides a compiler, there are
bunches and BUNCHES of things that can impact this, for example
- the RDW compiler directive "emulates" IBM mainframe RDW support
- RECORD SEQUENTIAL files are stored very differently from LINE SEQUENTIAL
files (either source code or directives can impact this) - and fixed vs vari
able
impacts this as well.

"traditionally" most Windows (and DOS? and OS/2?) compilers use "CR/LF" to
terminate "line sequential" files - while they ONLY use "LF" (as I recall) f
or
Unix and Linux systems.   How they handle "AFTER/BEFORE ADVANCING" (and the
older POSITIONING) and Report-Writer type files may also vary.

Again, tell us what you REALLY want to know and we may be able to give you
better information. If this is just a case of "I'm curious" then about your
SPECIFIC code example, then some people may be able to run it - but I don't
know.

P.S.  You may want to compile your program with a compiler that has ANSI or 
FIPS
"flagging" available (which I don't think Open-COBOL does) to at least get a
"Standard conforming" source code.  Without checking in detail, I think your
example (in another post) ignores:
A-/B-margin
Assign to shouldn't be a literal
no paragraph names
etc

You have
organization is relative sequential
record key is big-record.

which means that this is a RELATIVE file with access sequential - which is N
OT
what is "usually" meant be "sequential file" - but instead what is meant by 
a
"relative file".  (On an IBM mainframe, this would need to be pointing to a 
RRDS
VSAM file and NOT to a QSAM file).  SEQUENTIAL files do not have "keys".
"Keyed" files have (usually VERY different structures.  See for example the
Micro Focus INDXFORMAT - or something like that - I didn't check) directive)

--
Bill Klein
wmklein <at> ix.netcom.com
"theador" <Theador@gmail.com> wrote in message
news:1122264295.228797.240710@o13g2000cwo.googlegroups.com...
>I have noticed that every compiler/op sys seems to create a different
> format for sequential files.  for instance, a COBOL program on the
> mainframe will create a sequential file with a four byte header that
> indicates length.  On microfocus on AIX, a COBOL program will create a
> similar file but the with a special record as the first record that has
> some additional information.
>
> Does anyone know of a comprehensive list of all the different formats
> that may be out there?
>
> I will post small sample program that will create a two record
> sequential file in hopes that some of you will run the program and
> report back the format of the file that is produced.  A hex dump as a
> post would be great.  if you can not hex dump on your selected
> operating system, then email the output to theador@@@@gmail and I will
> hex dump the file and post it.
>
> Hopefully we can cover these combinations:
> Fujitsu on UNIX
> Fujitsu on WIndows
> IBM on AIX
> IBM on z/OS
> MicroFocus on UNIX
> MicroFocus on WIndows
> AccuCOBOL
> OpenCOBOL
>
> Thanks to those who can help in this experiment,
> Theador.
>

theador wrote:
>
> Here is the test program that I am asking people with access to the
> above machines to run and report a hex dump of the output file.  This
> was compiled on open-cobol, so there may be different compile errors
> that would have to be fixed on your platform. thx.
>
>        IDENTIFICATION   DIVISION.
>        PROGRAM-ID.      test1.
>
>        environment division.
>        input-output section.
>        file-control.
>        select AFILE assign to "output.dat"
>        organization is relative sequential
>        record key is big-record.
>


Surely a clarification is needed: "organization is relative" is not the
same as "organization is sequential"/a sequential file.   ???

PL

>> different format for sequential files.

>      select AFILE assign to "output.dat"
>       organization is relative sequential
>       record key is big-record.

That is _NOT_ a 'sequential file'. It is organization relative, access
sequential which is quite a different thing altogether.

You also cannot have RECORD KEY on relative or sequential so I am
surprised that it compiled.

>          fd AFILE
>          label records are standard
>          record varying from 1 to 50
>          depending on a-length
>          data record is a-file.

If you going to have variable records then there must be _some_
mechanism to indicate where the record ends on the disc and (possibly)
where the next one starts. This is often done with a header on the
record though I do know of other mechanisms that can be used.

Fixed length records may not need the record header or terminator.

>       01 a-file.
>          05 big-record pic x(50).

This should be a problem for the compiler too.  You have defined a
variable key (though this is complete nonsense anyway).

Thank you all for the feed back.  Yes, my program has problems as I am
not a COBOL expert and I was compiling on a substandard compiler
(open-cobol).  I am financially constrained, so I can not afford to buy
a commercial COBOL compiler.  My goal in this exercise is to get sample
data to test routines that convert sequential files between the various
formats.  I am writing the conversion routines in C (a language in
which I am proficient).

At this time I am not concerned about C-ISAM, VSAM, or LINE SEQUENTIAL
FILES.

Theador.