MVSFORUMS.com

[vattikonda]

We have a program that reads a file and writes about 50 files (QSAM) for downstream users. This abended in Production with 80A couple times and we cut down the buffers to use about 8M as a temporary solution.

As a permanent solution, I have compiled the program with Enterprise COBOL with DATA(31), RENT, AMODE(31) and RMODE(ANY) options that allowed QSAM buffers to be placed above the line (Resulted in cutting down below 16M region from 8.5M to 967K).

To cut down the runtimes, I added more buffers to few files using high I/O. At this point I noticed a very peculiar problem:

- 1 additional record is being written to a file for which the criteria is to have say 'XXX' at position 920. When I dump that record from input it doesnot have 'XXX' value. So should not have been written to output file????

Example code:
FD INPUT-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0.

01 MAX-REC PIC X(27990).

COPY XYZREC.
|
01 ABC-REC.
05 ABC-FIELD1 PIC X(15).
|
|
05 ABC-920-POS-FIELD PIC X(03).
|
PROCEDURE DIVISION.
|
|
READ INPUT-FILE
NOT AT END
MOVE XYZ-REC TO ABC-REC.
|
|
IF ABC-920-POS-FIELD = 'XXX'
WRITE OUT-REC FROM ABC-REC
END-IF.

- I was unable to recreate the issue using just one record on input or using 15 records prior to the record in question.

- The only time it occurs is when I run using full file.

*** After many test runs, I concluded that the issue is being caused due to BUFNO=30 on the input file. If I code BUFNO=29, it works just fine.

I am confused on this observation. The questions I have are:
- What negative impacts should one watchout when allocating more buffers to a file?
- Is there any limitation on the REGION use above the line with Enterprise COBOL running under LE?
- Since my program calls some other programs that run below the line (even though the entire problem code in question appears in the main program), is there any limitation?

It took 2 days and lot of frustation to arrive at this conclusion. Any help is greatly appreciated.

Thanks,
Giri

[kolusu]

Vattikonda,

For variable block file I would suggest a read with READ filename INTO layout. READ filename moves the file pointer in the buffer such that the data-record overlays the next file record

The INTO option causes a move of the data from the buffer to the variable/structure specified, applying normal MOVE rules.

Just change the read verb to READ INTO and hopefully you should not have a problem.Also try coding region=0M

Hope this helps....

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[vattikonda]

Bingo!!! Kolusu... you are the best. Thanks for suggesting the solution. It works.

Coding multiple 01 levels under FD will be considered as redefines of the area. Why did I get the unpredectible errors? What does BUFNO have to do with the error that I observed??? Because coding BUFNO=29 on the INPUT-FILE works, but if I code BUFNO=30, I get the additional record???

As far as region, my current usage is less than 1M below the line as I am forcing all my buffers to be allocated above the line.

Thanks a lot.
Giri

[kolusu]

Vattikonda,

Glad that solution worked out for you. bufno provides the buffer area to the program, and the read statement moves the file pointer in the buffer such that the data-record overlays the next file record.

with bufno=30 your read statement might be at a different file pointer in the file. Note that it is just not bufno=30 you will get unpredicted results. It may also occur for any other value depending on the no: of records in the input file.

Try coding bufno=3,6,10,15 and I am sure that you will get the same error as you are getting before.

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[mok]

Vattikonda,
Maybe you compiled your program with the NOAWO option. I solved an identical problem with AWO.
This is an extract from the Cobol 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.

Of course, Kolusu was right with the READ INTO.
Cheers