Re: [Fwd: gnubol: Record delimiter clause and parse order]

[Matthew Vanecek <linuxguy@directlink.net>]

SXbastien DuclXroir wrote:
> 
> Just a few words about this :
> 
> Tim Josling a écrit :
> >
> > - fixed length = records stacked one after another, no record
> > header, no delimiter.
> 
> We use IBM Cobol for AIX (4.2.1 and 4.3.2), with both Variable an Fixed records.
> IBM implementation of the fixed length is :
> - no header
> - Unix-like end-of-line delimiter between each record,
> - this delimiter isn't included in the Cobol DCLLIB of the file (the programmer
> never see it),
> - CR/LF files give one empty record every two records (also true if exotic
> caracters - at least ASCII<32 - are included in the record),
> 
> I don't know MF Cobol, but the way IBM implements Fixed-length files permits the
> use of the producted files directly in Unix tools as sort, awk, grep, wc, etc.
> That's at least "useful".
> 
> Hope I understood part of this interesting thread...
>

Let me make sure I understand you right--when using "ORGANIZATION IS
SEQUENTIAL" on AIX, you get a file in which each record is on it's own
line (or rather, each record is seperated by "\n").  So, say, if your
record length is 50 bytes, you could open that file in a text editor
(emacs for the sane =P ), and you would be presented with umpteen
million lines, each line at 50 bytes?  According to the MF manual,
that's pretty much a description of LINE SEQUENTIAL--with the exception
that line sequential truncates trailing spaces.  In MF, if you use
"ORGANIZATION IS SEQUENTIAL", you will get one long line, consisting of
(in this example) umpteen million 50-byte long records, with no
delimiters.  x"0A" and x"0D0A" would not signify end-of-record in this
file, as it seems you imply it does on AIX (x"0A", anyhow).

The (free) draft standards (available at Merant's site), do not specify
a physical file layout that I can see.  Granted, there's 850 pages
there, but I couldn't find a reference to how sequential records are
delimited--only a definition of what sequential (and the other
organizations) is. Microfocus, however, is quite specific.  I managed to
snag a full set of manuals (wow, what a task!), for v3.2.  In the System
Reference, vol. 2, Appendix F, there is a very explicit description of
the different file formats  "ORGANIZATION IS SEQUENTIAL" refers to (on
all platforms--including Unix) a file in which fixed length records are
not delimited   LINE SEQUENTIAL refers to a file in which each record is
delimited by the appropriate character--x"0A" for Unix, x"0D0A" for
Windows, OS/2, and DOS.  That's the definition I think is wisest to
stick with.  Maybe somewhere down the road we can implement compile-time
flags to determine compiler compatibility (i.e., do we act like COBOL
II, or like MF, ...).  x"0A" and x"0D" are allowed in SEQENTIAL files,
of course--they just don't signal EOR.

Tim,
I was reading the draft, and I think that the reason MF uses LINE
SEQUENTIAL instead of RECORD DELIMITER is that RECORD DELIMITER is only
supposed to be use with variable length records.  

Speaking of which, I found a very nice breakdown of the variable length
format files, in the MF manuals.  Those things are really handy.  The
first 128 bytes is just file information, and a lot if will end up being
x"00", anyhow.  Each record is padded up to 3 spaces to occur on 4-byte
boundaries.  This includes the record header.  In the record header, the
first nibble describes the record's status (e.g., if it's a user record,
or a system record, or deleted, etc).  The most common case in
sequential files will be a user record (0100). The rest of the header
describes how long the record is.  I'm making a reasonably educated
guess that the minimum length per record is 8 bytes.  All padding is
done with x"00" (guess we won't be using buffered reading/writing--a la
fprintf--for this!).

Sorry for my verbosity, but every time someone brings up a new point, I
generally tend to find out 3 or 4 times more information than what I was
originally looking for. ;)

I'd like to get some feeling for what people think about using
read/write and/or fread/fwrite.  Since it's possible to have NULL
characters in a record, I don't think higher level buffered functions
will work--I ran into a similar problem reading globs from a database
field once--*printf corrupted the file and ceased writing at the first
NULL contained in the file.  I used fwrite in that case, but still,
opinions would be welcome (and yes, I know, we'd really have to keep an
eye on buffer overruns and the like, manually).

Well, Galaxy Quest is calling my name, so I'll ttyl,
-- 
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.