Re: gnubol: Record delimiter clause and parse order

[Fred Mobach <fred@mobach.nl>]

Matthew Vanecek wrote:

> Fred Mobach wrote:
> >
> > Matthew Vanecek wrote:
> >
> > > GNUCobol@ZName.com wrote:
> > >
> > > <<big snip>>
> > >
> > > I like the default delimiter idea, myself.  Makes life much easier.
> > > I've a bunch of sequential files here, but unfortunately I ftp'ed them
> > > down, which conveniently converts text files to the local format.
> > > Still, since they all came from the mainframe, and since they are all
> > > currently delimited by a "\n", I think it's safe to say that we can use
> > > "\n" as a delimiter, or maybe "\n" on *nix, and "\r\n" on systems that
> > > use "\r\n".
> >
> > I am very sorry but would like to disturb your save feeling. All you have said is
> > true for disc files but you forgot that tape files can use the older format with
> > the block- and recordlength fields.
>
>
> People still use tapes for reading and writing production files?? Just
> kidding--I'm sure somewhere they do...I've not actually *seen* one of
> course.  Particularly not in the non-mainframe environment.  But then, I
> haven't seen anything.`

Some of my customers run weekly their jobs to produce tapes on their
_Unix_ and
mainframe systems ;-). They use the tapes to exchange lots of megabytes
of data. They
produce 1600 bpi and 6250 bpi tapes.


> The problem I have is that if you ftp to the mainframe, say from your
> Linux box, and download a sequential file, when you open that sequential
> file, it's going to be delimited by \n.  If you do the same from
> Windows, it'll have "\r\n".  This caused no end of grief for me, when I
> still used both OS's, until I had to start ftp-ing between my windows
> and Linux box, too. :(  Samba for some reason just didn't do the
> translation properly at the time.

You're doing an ascii transfer, not a binary :-).


> Anyhow, I've never actually looked at a sequential file, on the
> mainframe, with a hex editor, so I'm in the dark as to what it's
> delimited by there.  All I know is that when you download them to your
> workstation, they are delimited by the appropriate character (\n or
> \r\n) for the OS, if you use ftp for transfer, and IIRC, tn3270 clients
> would do the same.  At least mine did (both x3270 and TN3270, AWA
> tcp3270).
>
> I'll have to dig up my IBM docs somehow, and see if they put in a
> description of the physical file format. MF handles whatever is
> appropriate for the OS it's running on--I'll have to run a test at work
> and see what's the difference in the way it writes sequential vs. line
> sequential, if there is one. As for tape devices and other none-dasd
> devices, I think we'll shove those off to the future.  I don't know
> about other countries, but in US, DASD is the much more common case,
> nowadays, on the mainframe, and I personally don't know anyone who uses
> tapes for non-backup purposes off the mainframe.  Not that it doesn't
> happen, I'm sure...Anyhow, that type of write would probably require an
> interface to the hardware driver, in which we could do whatever
> conversions necessary to put the records in the appropriate format.
> Stuffs for the future. :)

The variable record format on IBM EBCDIC tapes is :

+-----+---------------+----------------+-----+------------+
| BLF | record 1      | record 2       | ... | record n   |
|     |---------------|----------------|     |            |
|     | RLF | data    | RLF | data     |     | RLF | data |
+-----+---------------+----------------+-----+------------+

BLF (Block Length Field) consists of 4 bytes, the two bytes
at the left contains the 16 bit binary value of the block
length including the block length field. The other two bytes
are unused and contains binary zeroes.

RLF (Record Length Field) consists of 4 bytes, the two bytes
at the left contains the 16 bit binary value of the record
length including the record length field. The other two bytes
are unused and contains binary zeroes.

The format of the ASCII tapes differs. I will dig up the specs which I
have
already. If you have any question I would be pleased to help you.

Regards,

Fred Mobach


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.