How does Hyper-Buf process RLS (Record level Sharing) defined clusters?
This is actually a 2 part question.
RLS (record Level Sharing) can be very complicated.
HYPER-BUF is capable of handling RLS files, but some precautions must be taken:
During HYPER-BUF buffering on one System, a CICS region on another System could encounter an abend, if special algorithms for tuning CICS buffer space are not set. By coding one rule for any CICS partition, you can tune CICS to select optimum buffer space for online processing.
-- Please review the following sections of the HYPER-BUF manual:
CICS: Restricting Buffering for the CICS Environment
NSR: Restricting Conversion to Local Shared Resources
The normal Constraint table entries will be utilized to determine buffers to be set at IDCAMS OPEN.
There will be messages informing this type of allocation is being bypassed or not bypassed. Your MSGLEVEL= and STATS table entries will determine the messages to be provided in the job log.
Possible messages noting exclusions:
GVB102I ddname SKIPPED BECAUSE OF reason
GVB104I ddname level EXCLUDED
The datasets in question have in the DEFINE CLUSTER: LOG(UNDO) and in the JCL: RLS=NRI
RLS=NRI tells the application to grab a record and update it even though another application may be using it at the time The IBM manual calls this a "Dirty Read"
FRLOG(UNDO) tells us that CICS VR forward recovery is turned on and before and after images of the records are being written to the log.
IN BOTH of these cases Hyper-Buf is not involved. Hyper-Buf will only intercept the OPEN, alter the buffers, and then return control back to IDCAMS. If there are any issues then Hyper-Buf would not be involved.
Hyper-Buf does not read or write data.