Topic
7 replies Latest Post - ‏2013-05-17T08:29:08Z by BillWoodger
BillWoodger
BillWoodger
83 Posts
ACCEPTED ANSWER

Pinned topic Enterprise COBOL, Compiler option AWO

‏2013-05-09T10:24:16Z |

This is a question from LinkedIn originally and related to V5.1.

Compiler option AWO does this, says the Programming Guide:

AWO
If you specify AWO, an implicit APPLY WRITE-ONLY clause is activated for all QSAM files in the program that have blocked variable-length records.

Further:

Optimizing buffer and device space
Use the APPLY WRITE-ONLY clause to make optimum use of buffer and device space when you create a sequential file with blocked variable-length records. With APPLY WRITE-ONLY specified, a buffer is truncated only when the next record does not fit in the unused portion of the buffer. Without APPLY WRITE-ONLY specified, a buffer is truncated when it does not have enough space for a maximum-size record.

The APPLY WRITE-ONLY clause has meaning only for sequential files that have variable-length records and are blocked. The AWO compiler option applies an implicit APPLY WRITE-ONLY clause to all eligible
files. The NOAWO compiler option has no effect on files that have the APPLY WRITE-ONLY clause specified. The APPLY WRITE-ONLY clause takes precedence over the NOAWO compiler option.
The APPLY-WRITE ONLY clause can cause input files to use a record area rather than process the data in the buffer. This use might affect the processing of both input files and output files.

 

The Language Reference:

APPLY WRITE-ONLY clause
The APPLY WRITE-ONLY clause optimizes buffer and device space allocation for files that have standard sequential organization, have variable-length records, and are blocked. If you specify this phrase, the buffer is truncated only when the space available in the buffer is smaller than the size of the next record. Otherwise, the buffer is truncated when the space remaining in the buffer is smaller than the maximum record size for the file.

Tom Ross on LinkedIn:

"AWO should only affect output, Apply WRITE Only."

There is some discussion here:

http://www.ibmmainframes.com/viewtopic.php?p=266678#266678

http://www.ibmmainframes.com/viewtopic.php?p=300099#300099

My concern re V5.1 is the potential that the "logic" of the word "write" may have been applied in a different way to previous versions.

If the behaviour is intrinsic to QSAM, then OK. If it is the compiler which is doing it, I hope that it is still doing it in V5.1, however actually "illogical" that may be.

The Performance Tuning guides recommend using AWO. From a "performance" point of view, all VB input QSAM files get an "extra move" of the input record, from buffer to input area. For "performance", specify APPLY WRITE ONLY for output files it is needed for, and don't use AWO.

In fact, since you can do things which "work" for an input file with AWO, but which don't with NOAWO, I'd go as far as to say "don't use AWO".

This is the outline program I "wrote" to test the behaviour of AWO on VB inputs. The key in this case is

MOVE ZERO TO  QSAM-I-ODO

Compile with AWO, no S0C4. Compile with NOAWO, S0C4.

 

       IDENTIFICATION DIVISION.
       PROGRAM-ID. STUBOPEN.
       ENVIRONMENT DIVISION.
                                                             
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
                                                             
            SELECT QSAM-INPUT
                 ASSIGN           TO QSAMI
              FILE STATUS IS W-QSAM-I-FILE-STATUS
              .
            SELECT QSAM-OUTPUT
                 ASSIGN           TO QSAMO
              FILE STATUS IS W-QSAM-O-FILE-STATUS
              .
                                                             
       DATA DIVISION.
       FILE SECTION.
       FD  QSAM-INPUT
            RECORDING MODE IS V
            BLOCK CONTAINS 0 RECORDS.
       01  QSAM-I-RECORD.
           05  QSAM-I-ODO                 COMP PIC S9(4).
           05  QSAM-I-BYTES.
             10  FILLER OCCURS 1 TO 100 TIMES
                 DEPENDING ON QSAM-I-ODO.
                 15  QSAM-I-BYTE        PIC X.
       FD  QSAM-OUTPUT
            RECORDING MODE IS V
            BLOCK CONTAINS 0 RECORDS.
       01  QSAM-O-RECORD.
           05  QSAM-O-ODO                 COMP PIC S9(4).
           05  QSAM-O-BYTES.
             10  FILLER OCCURS 1 TO 100 TIMES
                 DEPENDING ON QSAM-O-ODO.

                 15  QSAM-O-BYTE        PIC X.
                                                              
                                                              
       WORKING-STORAGE SECTION.
       01  W-WHEN-COMPILED                      PIC X(8)BX(8).
       01  W-QSAM-O-FILE-STATUS         PIC XX.
           88  W-QSAM-O-OK              VALUE ZERO.
       01  W-QSAM-I-FILE-STATUS         PIC XX.
           88  W-QSAM-I-OK              VALUE ZERO.
                                                              
       PROCEDURE DIVISION.
                                                              
           MOVE WHEN-COMPILED TO W-WHEN-COMPILED
           DISPLAY "STUBOPEN " W-WHEN-COMPILED
           DISPLAY W-WHEN-COMPILED
           MOVE ZERO TO  QSAM-I-ODO
                                                              
           OPEN INPUT QSAM-INPUT
           IF NOT W-QSAM-I-OK
               CALL 'FRED01'
           END-IF
           OPEN OUTPUT QSAM-OUTPUT
           IF NOT W-QSAM-O-OK
               CALL 'FRED02'
           END-IF
                                                              
           GOBACK
           .



 

Updated on 2013-05-16T22:56:45Z at 2013-05-16T22:56:45Z by BillWoodger
  • BillWoodger
    BillWoodger
    83 Posts
    ACCEPTED ANSWER

    Re: Enterprise Cobol, Compiler option AWO

    ‏2013-05-09T14:45:52Z  in response to BillWoodger

    The compiler allows APPLY WRITE ONLY to be used for QSAM, variable-length, blocked input. No diagnostic.

    The Language Reference does not forbid it:

    APPLY WRITE-ONLY clause
    The APPLY WRITE-ONLY clause optimizes buffer and device space allocation for files that have standard sequential organization, have variable-length records, and are blocked....

    but from the rest of the paragraph, you'd really assume it is for an output file :-)

    ...If you specify this phrase, the buffer is truncated only when the space available in the buffer is smaller than the size of the next record. Otherwise, the buffer is truncated when the space remaining in the buffer is smaller than the maximum record size for the file.

    And then the Programming Guide:

    The APPLY-WRITE ONLY clause can cause input files to use a record area rather than process the data in the buffer. This use might affect the processing of both input files and output files.

    The only way that APPLY WRITE-ONLY (the above typo is in the manual) itself can affect an input file, is by specifying it for an input file.

    So, it happens, works, people are doing it, backwards-compatability - confidently hope V5.1 does the same :-)

    • Tom.Ross
      Tom.Ross
      14 Posts
      ACCEPTED ANSWER

      Re: Enterprise Cobol, Compiler option AWO

      ‏2013-05-10T06:19:51Z  in response to BillWoodger

      Bill, as I said in LinkedIn, COBOL V5 will behave like COBOL V4 and earlier releases in every way that we know of.

      Getting a buffer area (that in your example changed the behavior of an incorrectly written program) can also happen

      with the Same Record Area clause.  In your example the error occurs without any I/I, so in fact, AWO did not affect input.

      It affected an illegal move into a record before there was a record.  COBOL V5 will behave the same way, not to worry!.

      • BillWoodger
        BillWoodger
        83 Posts
        ACCEPTED ANSWER

        Re: Enterprise Cobol, Compiler option AWO

        ‏2013-05-10T09:33:43Z  in response to Tom.Ross

        Thanks Tom.

        I shifted it here from LinkedIn at Dwayne's reply to my query about a "centralised" place to cover questions relating to V5.1.

        I'm very happy to have it confirmed that V5.1 will behave as V4 and earlier, even where something a little "unusual" might be allowed.

        APPLY WRITE-ONLY can, in error, but with no diagnostic message, and with nothing clear in the manual one way or the other, be used for a VB QSAM input file.

        If APPLY WRITE-ONLY is not specified for that file, but compiler option AWO is used, then the compiler forces the input file to be "apply write-only".

        The "write-only" processing itself cannot, of course, affect the processing of the input file (there is no decision about when a buffer will be "truncated"). However, a side-effect of the potential decision is that the FD "points to" a piece of "owned" storage, which is available from program start, rather than points to a "buffer" which is only available while the file is "open" (not available before OPEN or after CLOSE for the file).

        On the READ, the record must go from the actual "buffer", sitting somewhere, to the area of storage that the FD is pointing to. There is an APAR for a record consisting of only an RDW, and linked-to in one of the links I provided, which seems to confirm that this is the process.

        Without compiler option AWO, the FD points directly to the "buffer", so there is no intervening move of the data.

        The above means that, with a poorly-coded program that accesses the record area whilst the file is not open, NOAWO will have an S0C4, and AWO will not.

        In a correctly-coded program (at least with regards to the use of the input record area) there is an additional "overhead" of moving the data from buffer to record area, with AWO, which does not exist with NOAWO.

        The Tuning paper suggests specifying AWO, without mentioning that the, more significant, savings will be slightly offset by any VB QSAM inputs getting a little slower. My advice has been to use APPLY WRITE-ONLY for all output VB QSAM and to forget AWO altogether.

        Since I know that there are programs out there compiled with AWO that are using the "record area" whilst the file is not open, I am happy that those programs will continue to be "odd" but behave in the same manner under V5 as V4.

        • Tom.Ross
          Tom.Ross
          14 Posts
          ACCEPTED ANSWER

          Re: Enterprise Cobol, Compiler option AWO

          ‏2013-05-16T18:20:10Z  in response to BillWoodger

          We are (or will be) very clear in our Migration Guide, that migrating poorly coded programs could result in problems when moving to Enterprise COBOL V5.1

          Tom

          • BillWoodger
            BillWoodger
            83 Posts
            ACCEPTED ANSWER

            Re: Enterprise Cobol, Compiler option AWO

            ‏2013-05-16T23:16:35Z  in response to Tom.Ross

            There are two things:

            1) The poorly-coded programs (using data definitions related to an FD when a file is not in an OPEN state) which are compiled with AWO and which therefore do not get a S0C4.

            2) The plain old program which has one or more input QSAM VB and which is compiled with AWO. They have an additional transfer of data from the input buffer to a "record area" associated with the program. Otherwise, there is no difference to the processing when compiled with NOAWO.

            For the discussion as it applies to V5.1, the question is whether the behaviour of AWO continues to affect input QSAM VB in V5.1. If it does, then nothing changes.

            If V5.1 doesn't behave in the same way, not applying AWO to QSAM VB input files (which would not longer get a "record area" but rather a "pointer" to the input buffer), then in the case of 1) there will be abends for unchanged (but re-compiled) programs (revealing bad code in the programs) and in the case of 2) the programs will run additionally faster (one fewer transfer of the input data) but with no other effect.

            If I know of two places which are using AWO and abusing (one wittingly, although without full knowledge or understanding, the other with no intention to do so, it is just the way it is) the record-area, then there are likely a good few sites out there who will get S0C4s just on a re-compile. And who will then turn to IBM. And, unless the Migration Guide is specific, may claim "backwards compatibility" as they are otherwise faced with evaluating hundreds/thousands of programs with QSAM VB input files.

            Unfortunately it could well be years before I can get the answer myself :-)

            • Tom.Ross
              Tom.Ross
              14 Posts
              ACCEPTED ANSWER

              Re: Enterprise Cobol, Compiler option AWO

              ‏2013-05-17T00:17:50Z  in response to BillWoodger

              These poorly coded programs could break anytime in the future, I cannot say whether they will have problems with COBOL V5 for sure, I can just say that IBM does not support such coding.  We have implemented AWO just like we did in previous versions, but I cannot say that this will always work for your examples of bad programs.  Sorry, that is all we can say in public!  It is likely that these bad programs will not die after moving to COBOL V5 and will instead die some other day...

              Tom

              • BillWoodger
                BillWoodger
                83 Posts
                ACCEPTED ANSWER

                Re: Enterprise Cobol, Compiler option AWO

                ‏2013-05-17T08:29:08Z  in response to Tom.Ross

                Thanks Tom, I'm happy with that.

                The only "benefits" from the bad code are imagined ones, so no-one reading this topic should think otherwise.

                For input from a QSAM VB, only use data-items related to an FD when a file is "open" (after OPEN and before CLOSE) and when the last IO operation was a "successful" read (a record was returned).

                Seems simple and obvious, but some people have talked themselves into doing otherwise for "reasons" which are incorrect.

                This includes the following:

                01  FIRST-RECORD PIC X(1000).

                01  SECOND-RECORD PIC X(800).

                 

                In the PROCEDURE DIVISION

                 

                MOVE FIRST-RECORD TO W-RECORD

                IF W-RECORD-IS-SECOND

                    MOVE W-RECORD TO ....

                When data for SECOND-RECORD is present, and FIRST-RECORD is used, you either get 200 bytes of "unexpected" and "undetermined" value or your get a S0C4, depending on where you are "in the input buffer". This is shoddy, bad, awful, coding.

                This type of shoddy, bad, awful, coding can then be "patched up" by using compiler option AWO and the program will never get a S0C4 on that file.

                It remains shoddy, bad, awful, coding.

                The code should be corrected, AWO removed, and APPLY WRITE-ONLY used specifically for each QSAM VB output file.

                And don't even THINK of blaming the compiler (yes, that's what they did...) :-)