Line Seq Open I-O & Rewrite

[Marty Winn]

I've been reading the discussions on this subject and I have been in hopes that it will be supported in v3.
However, today I downloaded a Windows 3.0 version from earlier this year and the 3.0 version I downloaded still doesn't allow this usage.

Here is what I downloaded to test on Windows while our tech folks get around to downloading an AIX 64 bit version.
https://www.arnoldtrembley.com/GC30r2793-BDB-rename-7z-to-exe.7z​

Our shop has lots of small control files that we use for rewriting a single record to create a next sequential invoice# or pick ticket#, etc. It was used on IBM OSVS and has been used on Micro Focus Server Express for the past several years without issue. These are all simple Line Seq files with no hex or special characters.

Is there an "official" stance on whether or not this feature will be supported in the final v3.0 (or 3.1, etc) ?

Thanks,
Marty

[Arnold Trembley]

Marty,
I programmed with IBM OS/VS COBOL for many years, and it did not support line sequential files at all. The IBM MVS operating system also had no support for line sequential files. They didn't exist in that environment.

But I'm pretty sure that a sequential file (binary sequential in GnuCOBOL) would allow OPEN for I-O and REWRITE. Could it be that a simple code change in your SELECT...ASSIGN statements would solve the problem?

Kind regards,

[Ralph Linkletter]

Marty this defintion is one of a fixed length record - can't be line sequential without CR/LF ( or whatever the termination character is in Linux)
"...Line Seq files with no hex or special characters."

Marty to effect a rewrite verb you must use a fixed length record. MF imposed this constraint as well. To achieve the same behavior using GnuCobol, Fujitsu Cobol, or MF - I use the simple technique below. The technique has the added benefit of not having to modify the existing MVS / zOS source Cobol programs.

Using MF and GnuCobol and MVS/zOS for control cards should be about the same.
Here is a typical definition of MVS/zOS control cards (SYSUT1) ported to MF.
In each case below, the ASSIGN TO clause expects the resolution of the SYSUT1 dataset name to be facilitated by a //SYSUT1 DD * in the JCL stream.
I have had success with GnuCobol behavior, being one and the same with MF and zOS, using this paradigm:
Compile GnuCobol programs with:
-fassign=ibm
add a SET SYSUT1 (or whatever the MVS / zOS ASSIGN TO clause indicates)= to the .BAT file
insure that the ASSIGN TO clause does not explicitly specify a Windows / Linux file name

SET SYSUT1=C:\IBZANIM\COBOL\EXAMPLE.COB
SET SYSUT2=C:\IBZANIM\COBOL\COPIED.COB

   INPUT-OUTPUT SECTION.
   FILE-CONTROL.
       SELECT SYSUT1 ASSIGN TO UT-S-SYSUT1
           FILE STATUS  IS SYSUT1-STATUS
          ORGANIZATION SEQUENTIAL.
       SELECT SYSUT2 ASSIGN TO UT-S-SYSUT2
           FILE STATUS  IS SYSUT2-STATUS
          ORGANIZATION SEQUENTIAL.
       SELECT INTRDR-FILE ASSIGN TO UT-S-SYSUT3
           FILE STATUS IS INTRDR-STATUS
          ORGANIZATION SEQUENTIAL.
       SELECT LIST-FILE ASSIGN TO UT-S-LISTDD
           FILE STATUS  IS LIST-FILE-STATUS
          ORGANIZATION SEQUENTIAL.
       SELECT GDG-FILE ASSIGN TO UT-S-SYSGDG
           FILE STATUS  IS GDG-FILE-STATUS
          ORGANIZATION SEQUENTIAL.
   DATA DIVISION.
   FILE SECTION.
   FD  SYSUT1
       RECORDING MODE IS F
       BLOCK CONTAINS 0 RECORDS
       RECORD CONTAINS 80 CHARACTERS.
   01  SYSUT1-BUFFER    PIC X(80).
   FD  SYSUT2
       RECORDING MODE IS F
       BLOCK CONTAINS 0 RECORDS
       RECORD CONTAINS 80 CHARACTERS.

Note: If the control card files are already text files (CR/LF terminated) change the
ORGANIZATION SEQUENTIAL to ORGANIZATION LINE SEQUENTIAL (doing so precludes use of the rewrite verb - but you could still read the control cards) If the control cards are fixed length (MVS/zOS format) use ORGANIZATION SEQUENTIAL and insure that the PC file has an LRECL of 80 characters.

I have a test bucket of several hundred MVS / zOS Cobol programs that execute perfectly with the above paradigm.

If you need assistance with using GnuCobol in the same manner that y'all used MF simulation / emulation of MVS / zOS applications let me know via an email to: ralph.linkletter@winadc.com. I would be glad to help
Ralph

[Marty Winn]

Thanks Arnold and Ralph for your responses.
I'm making a list of differences that we encounter in order to come up with an effort estimate so the least the changes the better.

Arnold, the reason we went with Line Seq files for the MVS BSAM I-O files is because other, non-Cobol programs (PL/SQL in our case) also read these files, and they need the file to be standard (Unix AIX in our case). So when going to MF the Line Seq fit the bill perfectly.

Ralph, many thanks for the code that you use and I will look at that closely today.

I'm currently thinking that what might be a good choice for us is to use a technique that we have used many times with MF when trailing spaces needed to be maintained sending to other systems, and that is to define the file as Record Sequential with record length being one greater than the data portion of the record and setting the extra character as x'0a' which is the line termination character in Unix. I will test that today and report back. If this technique will allow the I-O Rewrite then at least we won't need to change the physical file structure and all the other non-Cobol programs won't be affected, and also we can slip the new GnuCOBOL programs in one at a time.

Thanks to all,
Marty

[Marty Winn]

I created GnuCOBOL v2.2 code for a work-around to test Record Sequential Open I-O & Rewrite and it worked fine using one of our control record formats. Not complicated changes, only tedious. Requires changing all record copy books in addition to program code, but the file physical structure can stay as is by changing the Cobol record length to +1 and explicitly adding the Unix line end char (x'0a') at the end of the record so it looks like a standard Unix file to the PL/SQL and other standard Unix programs. This will also allow us to activate one new GnuCOBOL program at a time during the conversion. Nothing complicated, but when all time added up for the numerous files, the conversion scenario effort estimate just grows a bit.

Thanks again to all,
Marty

[Simon Sobisch]

Nothing complicated, but when all time added up for the numerous files, the conversion scenario effort estimate just grows a bit.

You may get away with a simple sed or regex (or COBOL program) to do the change for you.
To the original question:

Is there an "official" stance on whether or not this feature will be supported in the final v3.0 (or 3.1, etc) ?

Yes: this was planned to be available with 3.1 rc1 (which is nearly finished) and was postponed to 3.2 (which is already work in progress, you can use its alpha-version [warning - recompilation of the COBOL programs needed with the rc-1!] currently from the "pangaea" branch).
The feature "line sequential REWRITE" is stable there (was included from the stable reportwriter-branch).
Expect 3.1rc1 in the next days, 3.2 beta in the next two months.

[Marty Winn]

Wonderful news Simon, many thanks for that update !!

At present it appears that my largest amount of changes required for MF to GnuCOBOL v2.2 are two things:

1) is the COPY requiring apostrophies in WS & File Sections, and I was very happy to find that this issue is corrected in Arnold's v3.0 Windows package from earlier this year (thank you Arnold).

2) is the "ON 1" that is so heavily used in our shop. Was it decided whether or not to try to implement this since it was found to be a valid documented feature in OSVS? I remember possible support was mentioned briefly. While this change seems trivial, it is a bit more for us since it is usually used multiple times within each program in our shop, so individualized changes will be required for each of the couple hundred uses. Again, not complicated, just tedious and slow considering it is in so many programs.

Thanks again to Simon and all,
Marty

[Simon Sobisch]

Was it decided whether or not to try to implement this since it was found to be a valid documented feature in OSVS?

It was decided that it is very likely to get in if a patch is provided. I'd argue that it would be likely less work and less error prone if your shop assignes someone to write that patch (I'll help [mainly direct] but not do the work in my free time).