Re: gnubol: Record delimiter clause and parse order

[Matthew Vanecek <linuxguy@directlink.net>]

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.
> 
> For me it doesn't matter how you would distinguish between these two formats but
> it matters really if you don't support both of them.
> 
> Regards,
> 
> Fred Mobach

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.

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.

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. :)

well, off t'fight the dragons,
-- 
Matthew Vanecek
Visit my Website at http://mysite.directlink.net/linuxguy
For answers type: perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
*****************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...

--
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.