Re: gnubol: Record delimiter clause and parse order

[Tim Josling <tej@melbpc.org.au>]

Matthew,

Parsing
*******

Where there are many clauses, I would use something like this. 

select_clause:
SELECT optional_clause_opt assign_clause
select_sub_clause_rep_opt
;

_rep (obvious)
_opt (obvious)

select_sub_clause:
 access_mode_clause
|file_status_clause
|lock_mode_clause
|organization_clause
|padding_char_clause
|record_delim_clause
|reserve_area_clause
|sharing_clause
;

The benefit is that you get maximum recognition out of the parser
and if the clauses are out of order you don't get a dumb 'syntax
error' message.

You then have the option of accepting the clauses out of order or
doing a manual check. You would probably only do the manual check
only in pedantic mode, at which time you can put out a good
message.

Record Delimiter
****************

The record delimiter clause is optional, in ANSI 85. "Record
delimiter is standard-1" is only allowed for mag tapes. 

On the general question of the sequential formats I would suggest
that we do as the Romans do, which as far as I know (please
someone knowledgeable correct me on this).

- ORGANISATION IS SEQUENTIAL 
means that either it is fixed records with no delimiter or
variable records with some record prefix. Someone may be able to
tell us what is the format used by Merant or FJ. The IBM
mainframe format can be ignored for now. It is a horrible mess.

- ORGANISATION iS LINE-SEQUENTIAL
means that it is delimited by CRLF or CR or LF depending on the
platform (whatever fread regards as "\n"). This would be flagged
as an extension in pedantic mode and the keyword line-sequential
would be just another word in standard cobol-84 mode (see
cobctok.def).

I don't know why they did not use 'record delimiter is newline'
instead of inventing line-sequential, but they did.

Someone mentioned that fixed vs variable changes the filling of
the records. True.

Don't forget we have the option to ignore clauses that have no
meaning in our environment. Eg we can say memeory-size is
ignored, same for record-delimiter. This is important for running
code for other compilers.

Tim Josling

Matthew Vanecek wrote:
> 
> Tim,
> got a couple of questions.  The specs I have list RECORD DELIMITER as
> required for sequential file i/o.  Now, I've never used that clause in a
> program before, so input is welcome--with lack of other input, I'm gonna
> make it optional.
> 
> Also, for writing the parser, I'm a little vague as to how to make order
> not matter.  If I do something like:
> 
> select_clause_opt:
> /* nothing */
> | SELECT opt_optional_clause file_desc_name
> assign_clause
> opt_access_mode_clause
> opt_file_status_clause
> opt_lock_mode_clause
> opt_organization_clause
> opt_padding_char_clause
> opt_record_delim_clause
> opt_reserve_area_clause
> opt_sharing_clause
> ;
> 
> then it will expect to find the clauses in that order, when, of course,
> the order doesn't really matter.  I'm not expert enough w/yacc to know
> the workaround, so a hint would be very welcome (e.g., "look at
> this-n-such section of code" or whatever).
> 
> ciao,
> --
> 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.

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