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

Products

• HYPER-BUF VSAM Buffer Optimizer

Issue/Introduction

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

 

Environment

Release: HYPERB00200-11.5-HYPER-BUF-VSAM Buffer Optimizer
Component:

Resolution

This is actually a 2 part question.

Part 1

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 

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 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.