🚀 go-pugleaf

<Goodbye-come again>


I have encountered the following bug with the EQUEL/C parser.  It is in a
section of code where I wish to find the next sequence number from a
coded key field. The sequence number is the last two characters. I substring
the right two chars, coerce them to type integer, and then take the 
aggregate max (adding one to get the next sequence number).  Works fine
in QUEL on the INGRES monitor:

##	int seq
		.
		.
	Non-EQUEL-code
		.
		.
##		range of p is problem
##		retrieve (seq=1+max(int1(right(p.tr,2))))
		.
		.

But when pre-processed by eqc, produces:

{IIwrite("range of p=problem");IIsync(0);}{IIwrite("retrieve(seq=1+max(int1(right(p. ");IIwrite(
tr);IIwrite(" ,2))))");IIsetup();while(IIn_get(0)){IIn_ret(&seq,6);if(IIerrtest())continue;

NOTE that the retrieve is broken into 3 IIwrites.  This produces a:

2601 line1 Syntax error on ',', the correct syntax is:
     RETRIEVE [[INTO] relname] (target_list) [WHERE qual] [SORT[BY] attname1
       [:sortorder] {,attname2,[:sortorder]}]
     RETRIEVE UNIQUE (target_list) [WHERE qual] [SORT [BY]
[HIT RETURN]

when the program is run. Note the program does continue...but with seq == 0.
If I change the C program generated by eqc thus:

{IIwrite("range of p=problem");IIsync(0);}{IIwrite("retrieve(seq=1+max(int1(right(p.tr,2))))");
IIsetup();while(IIn_get(0)){IIn_ret(&seq,6);if(IIerrtest())continue;

changing the 3 IIwrites to one containing the whole retrieve, the program
predictably works. 

This is the first EQUEL bug I have run into in over a year of use (albeit
most on VMS).  My 'solution' is, to me unacceptable (what is the possible
value of an unreliable pre-processor).  Does RTI have a uucp node? Who
within ATT is laison?

M. Kenig ["Share and enjoy"],
ATT-IS (consultant), S. Plainfield
bell: (201) 668 3283
uucp: ...!abnjh!cbspt002