error: syntax error, unexpected Identifier, expecting AUTOMATIC or EXCLUSIVE or MANUAL

[Cathy Welsh]

Ok, when I try to compile the programs with -std=cobol85, I get different message, and bizarre, because it clearly shows the error is EXPECTING AUTOMATIC, EXCLUSIVE OR MANUAL, and the error message appears over and over, when it clearly shows LOCK MODE IS AUTOMATIC.

MSL/FILESZ.SEL:1: error: syntax error, unexpected Identifier, expecting AUTOMATIC or EXCLUSIVE or MANUAL
    1 >                LOCK MODE IS AUTOMATIC

Because I was supporting 4 differnt COBOL compilers at one time, we have all of the OS Specific files kept in a MSL directory, and these files are called the same thing on each OS, but the contents are different.

Again, this compiled fine on COBOL-77 on PDP-=11 back in the day, still compiles fine on VAX 5.1 which is VAX COBOL version Cobol-85, on MF Cobol 3.259 and on RHEL MF Visual COBOL version 5, patch 7.

I have attached the file that is used on MF cobol both version 3.259 and Visual COBOL 5.7.

[Simon Sobisch]

This one is tricky - the parser expects a lock mode there (and outputs the possible "tokens") but -std=cobol85 has none of the reserved words for that - because COBOL85 has no LOCK MODE at all (at least VAX COBOL77 and HP COBOL85 don't have that, IBM's MVS/OSVS documents that as an extension to COBOL85) [but has both LOCK and MODE reserved in general].

Patches welcome to post-process the messages to extend the token text with "(not reserved)" for the tokens that this applies to (which would be all in this case).
In theory we could also add a dialect configuration that checks the lock-mode support in general - this would return an error: LOCK MODE does not conform to COBOL 85 before the others.

You can see the effective list of reserved words also by cobc -std=cobol85 --list-reserved.

Note: you also won't have any of the intrinsic functions, because those were added in an amendment to COBOL85.

But as you've previously compiled with Visual COBOL - why not using -std=mf-strict (or the non-strict option if you don't need GnuCOBOL to tell you what doesn't work with MF and you don't have a problem with the reserved words from other dialects [as those are included in the non-strict ones - the standard ones are always strict])?

[Cathy Welsh]

It gave me more error messages with -std mf-strict and -std=mf.

Not sure why these routines have been use since 1982. No errors on any compiler just gnucobol.

I am away from the office right now, but will give you the details of compiling it with the other std settings when I return.

[Simon Sobisch]

Sounds like a good option to improve GnuCOBOL then :-)
Looking forward to your minimal examples.

Not sure why these routines have been use since 1982.

But these did not use LOCK MODE back then, did they?

[Cathy Welsh]

I do not have the copy of the PDP code any longer, but can provide you the examples of VAX-COBOL copy library, and the MF Cobol 3.259 and of course the RHEL version of COBOL. I just have to boot up the VAX.

These files have not been changed since 1990.
copy Library is MSL/FILESZ.SEL - same name on every machine, but because the library is MSL, this means that they are all Machine Specific Libraries, which means each compiler has different options:

Unix - MF COBOL 3.259 - file:

               LOCK MODE IS AUTOMATIC

RHEL MF Visual COBOL v 5 - Patch 7

               LOCK MODE IS AUTOMATIC

Vax COBOL - VMS v 5,1 - VAX COBOL version v4.1-29
The file is empty, one exists, but since it did not apply to VAX-COBOL, we just had an empty file

But the PDP-11 RTS-COBOL the File-control section file MSL/FILESZ.SEL were empty, but the RDLOCK.PD on the Reads were NOT empty on PDP and VAX, where they are empty on MFCOBOL. On PDP and VAX the RDLOCK.PD that was a copy library that was placed after every READ statement WITH LOCK, so the locking was dealt with on individual read statement, not on the FILE.

When we decided to make the move to RHEL, it took me 18 months, to essentially re-test the programs, as it did not take me very long to make the necessary changes to run in 64-Bit mode, and a few Utility programs had to change, but for the most part, the programs ran, and we had no issues. other than the 3 months for MF COBOL support to have me put in the Environment Variable.

COBCONFIG=/data1/cdms/TLS/rts-config-signal-regime-28
this fixed the RHEL Scroll Region that worked on every other platform as is.

[Cathy Welsh]

I stand corrected, they did NOT use LOCK MODE back on VAX-COBOL or PDP=11 RSX Cobol, but the LOCK was either on the opening of the file, which we have a copy library of OPENEX.PD or OPENAL.ALL and on the READ statements RDLOCK.PD. but the MF COBOL from 1990 definitely did.

I had only tried COBOL85 because I was getting these errors on Mf-strict and MF, They are attached accordingly. Sorry about that.

[Simon Sobisch]

strict returns

LIB/COMPFI.SL:1: error: ASSIGN variable does not conform to Micro Focus COBOL
LIB/COMPFI.FN:1: error: continuation character expected
SRC/TEST.COB:17: error: ASSIGN variable does not conform to Micro Focus COBOL

The first and last are obviously errors (I've rechecked the MF docs, too); this will be fixed in the next version, for now please adjust the installed "mf-strict.conf" file (see cobc --info where COB_CONFIG_DIR is) as follows:

-assign-variable:           unconformable
+assign-variable:           ok

The other error is still puzzling. Can you please compile with cobc SRC/TEST.COB -std=mf -E > reproducer.i and upload that?

Note: your copybooks are not completely correct setup, for old compilers you use the VALUE OF ID (MSL/VALUE.FD containing what it currently does) , for newer environments like Micro Focus and GnuCOBOL you use ASSIGN TO.
(--> you want to have an empty VALUE.FD)

[Cathy Welsh]

I have not done the COB_CONFIG_DIR stuff yet, but with that last compile string you provided, I only got the 1 error about the continuation character.
I have attached the reproducer.i as requested.

[Simon Sobisch]

The interesting thing is that you can compile reproducer.i afterwards...
So this may be a work around until we can find the issue.

Did you find the time already to create a minimal reproducer for the continuation character error (to start just drop everything after the noted copybook, if it still occurs drop as much as possible before)?
As soon as we have that I'll reinspect where the problem is and how we can fix that.

[Cathy Welsh]

I removed the COMPFI.F from after column 72 on each line in the copy LIB/COMPFI.FN. It seems like it may not like the "??" in the COMP-FIL-PREFIX field.
This "??" exists for every Company CODE specific File in our system, which is about 100 Ffilenames all with corresponding "FN".
The FILSET.SUB program is not really looking for the ?? but looking at the last filler at the 05 level with the value of 052, to know where in the filename the COMPANY CODE needs to be replaced in the filename. We can't use a valid Number or LETTER because a company code may contain one of those, which is why it uses "??". We could potentially change this to another special character such as "@, ^, *" unless that would confuse something in C?

[Paul McNary]

Cathy
Sometimes I use a ~ character

[Cathy Welsh]

I will see if that makes a difference.

[Cathy Welsh]

Changing the value from "??" to "~~" made no difference, the same result with the same error. Thanks.

[Cathy Welsh]

I am not clear on what you want me to do? Do you want me to hard copy the contents of the copy library LIB/COMPFI.FN into the program, and not use the copy library, and not have it so close to the column 72 margin? Is this what it is erroring on, that it thinks that line does not have the line continuation characters in place???

I am not completely clear on what you need me to do. Sorry. Until I have more of an understanding on gnucobol and how it works, and where stuff is stored, it is going to take me some time. I have not had a chance to read all of the documentation, only a few areas. It is a lot to take in for someone who is NOT a C programmer.
I have not even gotten 1/3 of the way through the C for COBOL programmers book I bought to help me understand this whole process.

[Simon Sobisch]

I've asked for a minimal example, so just take your program, remove everything after the error, then as much before as possible to still have a valid program, then provide a zip/tarball with the reproducer (I guess 2 files, but maybe it doesn't even need a copybook).

It looks like you're nearly there, so I can take that and focus on fixing it.

[Cathy Welsh]

I will work on this for you on Monday.
Have a nice weekend Simon.

[Cathy Welsh]

I stripped everything out except for defining the comp-fil and the error does not happen. Does this have something to do with the 2nd file definition, of the vdck-file-name. I am adding that part back to the program, so there are 2 files, and see if it happens again.
I have the stripped down program and the reproducer.i with just the 1 file, and it has no issue at all. Changing this test2 program to add the 2nd file and will forward that reproducer as well

[Cathy Welsh]

Results with 2 files contained, but very minimal, it breaks as before showing the COMP-FI continuation character, but this may be on the 2nd file.
When the test2.cob which only has just the compfi in the filename-table - the error does not happen, only when I add a 2nd file.
I have attached both the test3.cob and the reproducer.i
Since the files are so tiny, I did not bother to tarzip them.

[Anonymous]

LIB/COMPFI.FN:1: error: continuation character expected
This appears to be a bug in the pre-processor as it fails to reset the continuation flag.

BTW these short continuations appear to be unnecessary, and can be easily avoided by minor modifications to the source code.

[Cathy Welsh]

What you are calling minor modifications, will take me months to complete.
Everything compiles correctly on MicroFocus VISUAL Cobol 5.7, and Microfocus COBOL 3.259, and VAX-COBOL 4.1.
I have over 3800 programs, and not sure how many copy libraries with Continuations. I am the sole programmer, and just don't have that amount of time to essentially Re-Rewrite the company APP. I am the sole programmer, now for 15 years. Funny thing, the error actually is NOT on the COMPFI.FN, but on the 2nd file below that which also has a Continuation. When I removed the 2nd file, and stripped down the program to not perform anything really in the Procedure division, the program compiles fine, no error at all. This is only a problem when there are multiple continuation characters used.

[Anonymous]

The problem, bug, is caused by a series of copybooks and continuations long before 'COMPFI.FN'.

Identifying the exact cause without looking a that particular section of code will be difficult.

[Vincent (Bryan) Coen]

On 08/04/2024 23:18, noreply@sourceforge.net wrote:

The problem, bug, is caused by a series of copybooks and continuations
long before 'COMPFI.FN'.

Identifying the exact cause without looking a that particular section
of code will be difficult.

Suggest you compile the progr with cobc -x progname.cbl -T progname.prn

and look at progname.prn for a clue.

Hopefully it will appear.

[Cathy Welsh]

Here is the printout. the format of the continuation characters is correct. I removed the majority of the COPY LIBS, and it has nothing to do with too many COPY LIBS.
As I have mentioned, these same COPY LIBS for these Filenames, have not changed since 1982. They compile beautifully on VAX-COBOL, MF cobol v3.259, and MF Visual COBOL 5.07.

I provided the full PRN to this response. This is just a sample of 2 very
vague programs, that are copyrighted and owned 100% by CDMS.

[Mickey White]

would it compile correctly if you move the 2 to start in column 12 and not column 13?
000061 - 2.

[Cathy Welsh]

The entire source has been provided for Simon along with a reproducer.i
with and without the area that is causing the problem. It does not appear that the MSL/COMPFI.FN is the problem but the section after that. I will compile and provide a full listing to the group.
CDMS at one point supported 3 different COBOL compilers, for PDP-11, VAX-COBOL and MF COBOL for Xenix and Unix v3.259. the use of copy libraries was critical and made it easy to port the coding to the 3 different platforms. Today we still support 2 platforms, SCO Open Server 5.07v and Open Server 6.0V both on MF cobol 3.259 and RHEL on MF Visual COBOL 5.07 - soon V 9.06. These programs and copy libraries compile error free on 3 platforms, as we still compile and debug on the VAX-COBOL, best debugger I have ever used. The Copy libraries that start with MSL - means Machine Specific Library, these are unique per Compiler.
the LIB are the same on every compiler.
Should have that soon to the group.