How does CA Hyper-Buf process RLS (Record level Sharing) defined clusters?

Document ID : KB000046269
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:

How does CA Hyper-Buf process RLS (Record level Sharing) defined clusters?

Answer:

This is actually a 2 part question.

Part 1

RLS (record Level Sharing) can be very complicated.

CA HYPER-BUF is capable of handling RLS files, but some precautions must 
be taken: 

During  CA 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 CA HYPER-BUF manual: 

3.2.3 CICS: Restricting Buffering for the CICS Environment 
3.2.23 NSR: Restricting Conversion to Local Shared Resources 

Part 2

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 CA Hyper-Buf is not involved. CA Hyper-Buf will only intercept the OPEN, alter the buffers, and then return control back to IDCAMS. If there are any issues then CA Hyper-Buf would not be involved. CA Hyper-Buf does not read or write data.