Endevor Physical Security and VSAM/RLS.... Anyone got any advice?

[John Dueckman]

We are in the process of implementing VSAM/RLS. At the present time, the site makes extensive use of program-pathing for physical security rather than Endevor's alternate id. We have encountered strange access problems that disappear when VSAM/RLS is disabled, leading me to believe either the share options or the program-path(s) are incorrect.

 

Share options were set to (1,3) but I have read some sites indicating they use (2,3) instead.

 

Program-paths were not changed when VSAM/RLS was activated; should they have been?

 

We'll figure it out... but I thought I'd ask the greater Endevor community to find out what it's experience has been!

[Steve Blackett]

I thought the share options were ignored (if you figure out what RLS is doing - that kind of makes sense...).

When the STC takes a hit you can see "unusual problems" - obviously if you're running this type of stuff you'd make sure that kind of failure shouldn't happen!

 

Here's a link to a useful deck I found when first learning about it.

[John Dueckman]

Out of curiosity, do you use the AltID or program-pathing?

[Josef Thaler]

Hi John,

we use vsam-rls for Endevor ksds-datasets. Their SHR-options are set to SHR(2,3) (equals to "one updater AND many readers"). In the past, under lserv the SHR(1,3) had been used (equals "one updater OR many readers"). With VSAM/RLS+SHR(2,3) for Endevor there are currently no reported access- or consistency-problems, except for backup during nightshift, while a user is accessing Endevor, the spheres can not be quiesced for a consistent backup). To improve that, idea https://communities.ca.com/ideas/235726381 and maybe other ideas were submitted.

[John Dueckman]

Hi Josef!

 

Same question I asked Steve: Does your site use program-pathing or the Alternate ID for security?

[Josef Thaler]

AltId

[Josef Thaler]

Out of curiosity, what are the considerations to use program-pathing rather than AltId?

[John Dueckman]

In a few words? imho? "Do not do it". (or if someone HAS done it and it works.... well..... that's why I raised this thread! )....

 

With the AltID, you can give READ level access to everyone and CONTROL/UPDATE level access to the AltID and you are fine! There are reasons this is the preferred method of providing physical security with Endevor!

 

With program-pathing, it appears you need to give CONTROL/UPDATE level access to the catalog to everyone.

 

Per the issue and correspondence we had with IBM:

 

(Us):

The Endevor envt is a collection of libraries associated with multiple application states (test, prod, etc), and it also (unfortunately)  includes software-support-owned libraries. Users can search thru all environments, including the software test envt. the users only have READ access to the software envt clusters (users are not allowed to update software-owned datasets). Now it looks like a catalog entry update is required if the cluster is open in RLS mode. Can you tell me what specific update is done to the cluster entry ?

Does this mean READ access is insufficient if you access a cluster via RLS ?

(IBM):

We need to update the catalog for the RLS-IN-USE flag and the VVR for lock structure name and READ access is insufficient for this.

[HarpoIU]

Hi John,  I found the below info in the IBM Redbook – VSAM Demystified:

 

 

 

You open a VSAM cluster in RLS mode by either specifying this in your program ACB macro, or by using the RLS JCL keyword. Options are

 

*     RLS=NRI, No Read Integrity; the application will read every record, even records that are in use elsewhere

*     RLS=CR, Consistent Read; the application will put a share lock on the record while reading and will not read records that are held for update by another user.

*     RLS=CRE, Consistent Read Explicit; the application will hold a record it is reading until is issues a commit point. CRE only works with applications that log updates and use commits to manage transaction backout.

 

Sample JCL

 

//DDNAME DD DSN=dataset.name,DISP=SHR,RLS=CR

 

 

 

From  VSAM Demystified Redbook:

 

 

 

5.5.11 RLS rules

 

RLS enforces some rules when you have a data set open in RLS and non-RLS modes.

 

RLS OPEN rules

 

The RLS OPEN command has these restrictions concerning RLS:

 

_ RLS OPEN for input/output fails if the data set is already opened for non-RLS output.

 

_ RLS OPEN for input/output fails if the data set is already opened for non-RLS input, unless

 

the data set is defined as SHAREOPTION(2,x). The non-RLS reader does not have read

 

integrity.

 

_ RLS OPEN for output of a recoverable data set by a batch client fails.

 

_ RLS OPEN for a data set that is either quiesced or is quiescing fails (QUIESCE=YES in

 

catalog).

 

_ RLS OPEN for a VSAM data set that has not been assigned a CF cache by using the SMS

 

STORCLAS construct fails.

 

_ Empty KSDSs: RLS allows you to open an empty KSDS without first loading the data set.

 

In other modes (NSR, RLS), this process is not possible.

 

_ Positioning: RLS does not do implicit positioning to the beginning of the data set for SEQ

 

processing. An explicit POINT is required.