LongEx Mainframe Quarterly - February 2020
Over the past couple of years, we've been working with a client and our partners, CPT Global, to convert their CICS/VSAM files to RLS. Why? They were setting up a CICSPlex, and needed to open and update these files from more than one CICS region. Read the manuals, and RLS looks pretty easy. Change the storage class and FCT entries, and you're away. But of course, that's not what we found. In this first article of three, we summarize what we did, and why. In our second article, we talk about VSAM performance, and how we compared performance before and after our RLS conversion. In a third article next issue, we will talk about some of the issues and problems that we found. Part 1: ResearchOur first step was to understand how the application used VSAM. What files, how many, what usage. In our case, the client had over 800 VSAM files defined to CICS. But it wasn't that bad. 100 of these were paths to alternate indexes. Four were entries to datasets that did not exist. Looking at CICS usage statistics for a six-week period, another 152 weren't used, so our target list was smaller. These statistics also showed that some of these files were not updated within CICS. So, they didn't need to be converted to RLS, further reducing our list. 16 of these datasets were IAM. Our client didn't have the IAM component that emulates RLS, so these needed to be converted to VSAM. Our client also had some ESDS datasets, we talk more about these below. From this list, we created 'blocks' of datasets to be converted. We chose the lesser used datasets (and less important) datasets first, moving towards the highest used. We also researched what the applications did with these files. We found programs that opened and closed files within CICS. We found others that changed attributes of the files (between read-only and update). We found programs that inquired on the status of each file, and this affected processing. More on this in a moment. We also looked at applications accessing our VSAM datasets remotely via function shipping, and determined if they also needed to convert their definitions to RLS. We checked batch access to these VSAM datasets, and considered if these needed to be converted to RLS. We looked at backups, and any issues that may cause us problems. We also found that some batch jobs were opening and closing VSAM files. We talk about what we found here in the third article in this series. We were also concerned about performance. The Redpaper IBM CICS Performance Series: CICS and VSAM RLS, the 2015 Share presentation Getting the Most out of your VSAM Data Sets in CICS by Using RLS , and the IBM Support Pac CP13 were useful. These indicate that we may get a performance enhancement from VSAM RLS. Issue: Read IntegrityMany don't realise that VSAM LSR does not have read integrity. So, if a program PGM1 obtains a record for update (EXEC CICS READ FILE() UPDATE), another program PGM2 can continue to read that (old) record. If PGM1 updates the record, PGM2 will 'see' the new record, even before the syncpoint (i.e., the change is not committed). Because of this, we did not use read integrity in our RLS files: no real change from pre-RLS. Or in other words, all FCT entries specified READINTEG(UNCOMMITTED). Issue: ESDSIBM recommend that RLS not be used with ESDS files. And with good reason: performance will be degraded as users always try to get a lock for the 'next' empty record. Our client had a few ESDS files. We solved this in two ways:
Part 2: PreparationThere was a lot of preparation. Here's a summary:
Let's look at a couple of interesting issues we came across in our planning. Issue: SMS ClassesWe defined two DFSMS storage classes: one for normal use, and one used for files that were backed up using snapshot technology. All RLS storage classes shared coupling facility cache and lock structures. We defined four new data classes:
All RLS datasets were:
We considered using extended addressing for all files. However, we had programs that used the RBA address. These would continue to work until a doubleword was required for the RBA. We decided that we wanted notice of this (an abend), rather than just letting our programs use the wrong RBA without notice. Issue: Altering File StatusWe had a few CICS programs that would change file attributes. For example, files would periodically be disabled for batch processing, and then re-enabled. With RLS files open in multiple CICS regions, this needed to be done in all CICS regions: EXEC CICS SET FILE() isn't good enough. We solved this by using the CPSM API: EXEC CPSM. This was the first time we used these APIs, so there was the usually 'teething problems': security, teaching the applications how to use them, ensuring that all CICS regions (including development ones) were in a CICSPlex with a valid (and correct) CPSM scope. Every CICS region executed using the same RACF user ID. So theoretically, one application could close files in another application's region with EXEC CPSM. We spent a lot of time ensuring application knew what they were doing. We also added in code to all EXEC CPSM files that would check that the current CICS region is in any CPSM scope used. We had a similar issue in batch: batch jobs would close CICS files to do processing. These jobs used SDS CAFC. We changed these to use CPSM in batch (usually with a REXX). Issue: RLS QuiesceSo, we had CICS regions that opened our VSAM datasets in RLS mode. We had batch streams that would close these files, and then process them in non-RLS mode. We briefly considered changing these batch jobs to RLS-mode, but decided that this was too hard. There were a lot of batch programs and utilities, and changing them to RLS-mode didn't buy us much, but would have been a lot of work. Now, the 'normal' way of allowing a batch job to access an RLS dataset in non-RLS mode is to do an RLS quiesce. This can be done using the CPSM API, for example EXEC CPSM PERFORM SET ACTION QUIESCE. Then, when batch processing is completed, we could do an UNQUIESCE and everything would be fine. We had two issues with this:
Because of this, we chose to use the EXEC CPSM PERFORM SET OBJECT CLOSE to close the file to all CICS region, and EXEC CPSM PERFORM SET OBJECT OPEN to open them again. Part 3: ImplementationWe did this in waves: starting with a couple of files, and having waves of up to 60 files at times. Each wave was done like this:
This was obviously done while our application was still running in a single CICS region. Once completed, we could start the second CICS region to share these files. We were very concerned with performance. Our application used VSAM heavily, with some very high add/update rates. You'll have seen that we did performance checks throughout the process. We discuss how we did this in our partner article. ConclusionWasn't that simple, was it? I was surprised at the number of issues that had to be considered. Not just a simple change of storage class, and FCT change. But it didn't end there. We were very concerned about performance, and spent a lot of time monitoring performance as the files were converted to RLS. We cover this in more detail in our article Comparing CICS/VSAM Performance With and Without RLS We also found a few problems that we didn't expect as we moved to RLS. We will talk more about these in our follow-on article next issue. |
