RE: [Cobolforgcc-devel] yacc/bison question

[William M. K. <wm...@ix...>]

FYI - even in the draft COBOL Standard "file-sharing/record-locking" is in
the Processor Dependent list.  Therefore, I would suggest (?) that it be
placed in the "later" category, and that any work on 200x features
concentrate on those features that are REQUIRED (at least first).

> -----Original Message-----
> From: cob...@li...
> [mailto:cob...@li...]On Behalf Of Tim
> Josling
> Sent: Sunday, June 10, 2001 9:42 PM
> To: cob...@li...
> Subject: Re: [Cobolforgcc-devel] yacc/bison question
>
>
> Matthew,
>
> Good to hear from you.
>
> There is no LOCK MODE in COBOL 85, so you can just omit it (for
> now). It is only in COBOL 2002.
>
> The problem appears to be due to the fact that the LOCK could be
> the start of a LOCK ON MULTIPLE or the start of a second
> occurrence of the LOCK MODE clause.
>
> You basically have the right answer. Function set_up_magic_tokens
> will need to be updated to change the first LOCK to a magic token
> like LOCK_magic_starts_whole_clause. The logic for this would be
> if it is not followed by ON, RECORD or RECORDS it must be the
> first one.
>
> If this makes no sense, please send me *all* the files.
>
> Are you in a position to do a copyright assignment to the free
> software foundation for this work. I will attach the files which
> explain it all. Without the assignments we will not be able to
> have the compiler incorporated into the official GCC. Please have
> a look.
>
> Tim Josling
>
> Matthew Vanecek wrote:
> >
> > Tim,
> > I was working on my file i/o grammar this weekend, and ran into some
> > issues with the LOCK MODE clause.  I've kinda got it figured out, but
> > I'm not certain that it's the correct way:
> >
> > I've got a clause:
> >
> > LOCK [MODE IS] {MANUAL | AUTOMATIC} [[WITH] LOCK ON {RECORD | RECORDS}]
> >
> > The two LOCKs were causing reduce/reduce errors.  I finally ended up
> > sticking a "LOCK_ON" token in cobctok.def to alleviate the ambiguity for
> > bison/yacc.  I'm a little worried about the kvalue, however.  I've set
> > it to "LOCK ON".  I'd like to figure out a way to delete that token, and
> > still not have any shift/reduce or reduce/reduce errors.
> >
> > Here's the relevant bit from my file.tpl:
> >
> > lock_mode_clause:
> > LOCK opt_mode opt_is manual_or_auto_kw opt_lock_on_clause {
> >         RSN($1, "Lock Mode not yet supported");
> > }
> > ;
> >
> > manual_or_auto_kw:
> > MANUAL
> > | AUTOMATIC
> > ;
> >
> > opt_lock_on_clause:
> > /* nothing */
> > | with_lock_on
> > ;
> >
> > with_lock_on:
> > opt_with lock_on
> > ;
> >
> > lock_on:
> > LOCK_ON record_or_records
> > ;
> >
> > record_or_records:
> > RECORD
> > | RECORDS
> > ;
> >
> > If I change the "LOCK_ON" to "LOCK ON", I get a reduce/reduce error.  I
> > would rather not have any errors, but I'm still a little dubious about a
> > "LOCK_ON" token.
> >
> > Thoughts?
> > --
> > Matthew Vanecek
> > 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...
> >
> >   -----------------------------------------------------------------
> >    Part 1.2Type: application/pgp-signature