IBM Mainframe Forum

Is it acceptable practice to have a cobol program defined with 2 logical files pointed to the same physical file?

Here is a code snippet to show what I am doing. I'm reading the file sequentially and then doing a keyed lookup back into the file and then updating the record on the file being read sequentially.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT WDELVRY-FILE
ASSIGN TO SYS016-WDELVRY
ORGANIZATION IS INDEXED
ACCESS IS SEQUENTIAL
RECORD KEY IS WDELVRY-KEY
FILE STATUS IS WDELVRY-STATUS.

SELECT WDELVRY2-FILE
ASSIGN TO SYS017-WDELVRY
ORGANIZATION IS INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS WDELVRY2-KEY
FILE STATUS IS WDELVRY2-STATUS.

Yes, I've seen this done in the past. One thing to beware of is if the direct read needs a record in the same CI as the sequential record you're updating, you may have a lock issue.

Perhaps you can explain more about the task, and why you feel that is an approach to take? I wouldn't want to do this, nor discover it somewhere.

How many records? How many updates?

If nothing else, people are always going to be "suspicious" of your technique whenever there are problems related to the program.

If the update is within the same buffer, I don't know if "locking" or "buffer invalidation" (meaning more IO to refresh the buffer (or buffers)) is going to get you.

Plus, and it is a big plus, what if your program fails? You've just destroyed your input (at least it is no longer in the state it previously started at). Which means you need a backup.

If you need a backup, why not REPRO to a sequential data set, which you can then use as input to your program? It's process substantially faster than a VSAM KSDS being read sequentially, and you would then be free to update the data set on a single DD.

However, there's quite probably a better way to do the whole thing anyway, if you provide details.

Thanks for the response guys.

This is what we are trying to accomplish.

The WDELVRY file gets rebuilt every morning, creating a delivery schedule for the next 10 days.

The key to the file is STORE, DEPARTMENT and DATE.

Also on the WDELVRY file is a table that we want to populate with department and date combinations that exist on the file.

05  WDELVRY-KEY.            
    10  WDELVRY-STORE       
    10  WDELVRY-DEPARTMENT  
    10  WDELVRY-DELIVERY-DATE            

05  WDELVRY-FLEX-TABLE.                   
    10  WDELVRY-FLEX OCCURS 10 TIMES INDEXED BY WX2.
        15  WDELVRY-FLEX-DEPARTMENT      PIC X(10).
        15  WDELVRY-FLEX-DELIVERY-DATE   PIC 9(8). 
                           
So the flow of the program is this,
  read the WDELVRY file sequentially
     if the DEPARTMENT has a corresponding FLEX-DEPARTMENT (there is a map in working storage that defines this relationship)

                    subtract one from the DELIVERY-DATE
                         perform a keyed lookup into WDELVRY2 using STORE, FLEX-DEPARTMENT, NEW-DELIVERY-DATE
                             if a record is found
                                update the WDELVRY file FLEX TABLE
              end                                           

We haven't had any issues during testing with this program, but somebody raised a concern about possible issues down the road with using this technique.  I was curious to other peoples experience and opinion about it.

It may make sense to use your suggestion and REPRO to a sequential dataset.

 

Hello,

ShaunL wrote:...It may make sense to use your suggestion and REPRO to a sequential dataset. ... 

What Mr. Boyo meant was to write a sequential dataset from the COBOL program containing the updated record, which in turn can be input to another step which will perform an IDCAMS REPRO-REPLACE into the VSAM DS. This way until the REPRO step's execution, the integrity of the VSAM DS stays intact.

A few things to note here:
a. How many updates are going to happen per run, and whether the records being updated can be spread over large key-range difference: this will determine the IDCAMS REPRO execution time. If the number of records which are written is fairly small, then the IDCAMS REPRO will be relatively quick. Since the access in the COBOL program is sequential (and if this DS is all batch; majorly sequential access), you can look at increasing the CISIZE to get better performance.
b. In case there is a possibility of all records being updated, it is better to generate a fresh KSDS from the COBOL program itself, instead of repeating the all read, all insert/rewrite routine.

Lastly, possibility of a process-redesign can be explored; reason being, WDELVRY/WDELVRY2 both are interdependent (from what you've shown), which would mean that there would be a common logical checkpoint wherein if WDELVRY is being written then a corresponding update is being done on WDELVRY2. This can be integrated to build WDELVRY itself.

Hope this helps.