IBM Mainframe Forum

[huxianjun]

Hello

See if anyone could suggest a solution for following issue:
1. a new record is written into a VSAM file from one CICS Cobol program
2. Immediately the same record is read directly from the same VSAM file by full key from another assembly program

Then the issue encountered that the read by full key failed with RC 4 indicating RECORD NOT FOUND, my guess that the failure seems be caused by the assembly program is trying to read the record from the Buffer, while it's not being added in the Buffer when the new record is written by the CICS program!

Could anyone confirm if the above guess correct or not? If yes, is there a way to fix it without rewriting the assembly program to CICS program?

FYI the related codes from both the CICS & assembly programs:

Below is how the new record being written in the VSAM file (from the CICS Cobol program):
EXEC CICS WRITE
DATASET ('the-VSAM-file')
FROM (DBAL-MAST-RECORD-AREA)
LENGTH (WW-REC-LENGTH)
KEYLENGTH (WW-KEY-LENGTH)
RIDFLD (WS-REC-KEY)
END-EXEC.

Below is how the record being read by full key from the same VSAM file (from the assembly program):
GENCB BLK=RPL,
ACB=(R8),
AREA=RCDADR,
AREALEN=4,
ARG=(R9),
OPTCD=(KEY,DIR,LOC)
. . .
L R9,KEYADR /R9=> KEY VALUE
. . .
MODCB RPL=(R8),
ARG=(R9),
OPTCD=(KEQ,FKS,DIR,NSP)
. . .
GETVSAM DS 0H
GET RPL=(R8)
LTR R15,R15 /RETRIEVAL SUCCESSFUL?

Thanks, Roy

[Robert Sample]

If the VSAM data set is in an LSR pool, the buffer will NOT be written until the system needs to reuse that particular buffer. This could be seconds or minutes or hours, and that's the way LSR buffering works. If the data set is not in an LSR pool, the same behavior occurs but since there are fewer buffers involved the time period is (usually) less.

After writing the record, you can close / open the data set which will flush the buffers to disk. Or, you can investigate the various options for accessing VSAM data sets in Assembler -- there may be a way to read the data from buffers instead of the data set; but you'll need to do the research. If none of the Assembler options will work for you, and you cannot close / open the data set for any reason, then you will need to accept that you cannot read the record back immediately (and the time before you can read it will not be predictable).

[huxianjun]

Thanks Robert!

From your reply, you meant the new record written in the CICS program is still in the Buffer(if the VSAM data set is defined to use LSR) instead of being already output in the VSAM data set, and subsequently when the assembly program read the record, it actually try to read it from the VSAM data set instead of the Buffer, therefore RECORD NOT FOUND - if this is the case (mostly it is), my guess is completely wrong!

Question then: In following parameter codes in GENCB in the assembly program, 'LOC' is specified to use the I/O buffer for processing, does it mean to check/read the buffer first whenever read a record?
OPTCD=(KEY,DIR,LOC)

[Robert Sample]

Yes, a READ will attempt to read from the VSAM data set (the only "files" in z/OS are on tape or in Unix). And LSR buffers are left in memory until CICS needs one, so depending upon how many buffers are defined in that LSR pool and the I/O activity of the data sets in that LSR pool, it could be quite some time before the data actually is written to disk.

From the manual description, it appears that OPTCD=LOC may work for you. It is not clear from the manual whether the READ uses the buffer; it's worth a try.