Subtract 1 from all the following record key after deleting a specific one - cobol

Question

i want to delete a specific item then subtract 1 from all the following item-id so it would look like something like this:
item-id item-name qty price
[01] Item 1 10 99
[02] Item 2 10 99
[03] Item 3 10 99
[04] Item 4 33 23
[05] Item 5 22 33
-Delete item-id 03
new output:
item-id item-name qty price
[01] Item 1 10 99
[02] Item 2 10 99
[03] Item 4 33 23
[04] Item 5 22 33
ive tried something like this the delete works correctly i just dont know how to subtract 1 from all the following item-id's
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INVENTORY
ASSIGN TO 'C:\Users\User\Desktop\FINALS\inventory.dat'
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS ITEM-ID.
FILE SECTION.
FD INVENTORY.
01 FILE-INVENTORY.
02 ITEM-ID PIC 9(2).
02 ITEM-NAME PIC X(25).
02 QTY PIC Z99.
02 PRICE PIC ZZZ9.00.
WORKING-STORAGE SECTION.
01 WS-INVENTORY.
02 WS-ID PIC 9(2).
02 WS-GA PIC X(25).
02 WS-QTY PIC 999.
02 WS-PRC PIC 9999.00.
01 WS-EOF PIC A(4).
PROCEDURE DIVISION.
DEL-ITEM.
OPEN I-O INVENTORY
DISPLAY " ENTER ID OF THE PRODUCT YOU WANT TO DELETE"
DISPLAY " ITEM ID: " WITH NO ADVANCING
ACCEPT ITEM-ID
MOVE ITEM-ID TO WS-ID
DELETE INVENTORY
INVALID KEY
DISPLAY "ITEM DOES NOT EXIST"
END-DELETE
MOVE WS-ID TO ITEM-ID
READ INVENTORY NEXT INTO WS-INVENTORY
NOT AT END PERFORM ID-CHECK UNTIL WS-EOF = 'TRUE'
AT END MOVE 'TRUE' TO WS-EOF
CLOSE INVENTORY
ID-CHECK.
SUBTRACT 1 FROM WS-ID GIVING ITEM-ID REWRITE FILE-INVENTORY.

Answer 1

When using DELETE to remove a record, the DELETE statement must be preceded by a successful READ statement. For example,
READ INVENTORY KEY ITEM-ID
INVALID KEY
SET some-error-condition TO TRUE
NOT INVALID KEY
DELETE INVENTORY
more tests for errors
END-DELETE
END-READ
After successfully deleting the record, a loop is needed to change the prime record key of the remaining records.
Note that when changing the prime record key, REWRITE cannot be used. For ACCESS MODE IS RANDOM, use something like the following as a more complete example,
01 WS-DELETE-KEY PIC 99.
01 WS-DELETE-STATUS PIC 9 VALUE 0.
88 RECORD-NOT-FOUND VALUE 1.
88 RECORD-DELETED VALUE 2.
88 DELETE-FAILED VALUE 3.
88 NO-MORE-RECORDS VALUE 4.
ACCEPT WS-DELETE-KEY
PERFORM DELETE-RECORD
IF RECORD-DELETED
ADD 1 TO WS-DELETE-KEY
PERFORM CHANGE-PRIMARY-KEY *> for the remaining records
VARYING WS-DELETE-KEY FROM WS-DELETE-KEY BY 1
UNTIL NO-MORE-RECORDS
END-PERFORM
END-IF
.
DELETE-RECORD.
MOVE WS-DELETE-KEY TO ITEM-ID
READ INVENTORY KEY ITEM-ID
INVALID KEY
SET RECORD-NOT-FOUND TO TRUE
NOT INVALID KEY
DELETE INVENTORY
INVALID KEY
SET DELETE-FAILED TO TRUE
NOT INVALID KEY
SET RECORD-DELETED TO TRUE
END-DELETE
END-READ
.
CHANGE-PRIMARY-KEY.
MOVE WS-DELETE-KEY TO ITEM-ID
READ INVENTORY KEY ITEM-ID
INVALID KEY
SET NO-MORE-RECORDS TO TRUE
NOT INVALID KEY
DELETE INVENTORY
SUBTRACT 1 FROM ITEM-ID
WRITE FILE-INVENTORY
END-READ
This assumes that all remaining records are sequentially numbered and that the failure to read a record means there are no more records.
It may be wise to add additional checks in CHANGE-PRIMARY-KEY for other errors after the DELETE and WRITE statements.
For ACCESS MODE IS DYNAMIC the code is similar but could use START and READ ... NEXT statements.

Answer 2

You probably shouldn't be doing this. It's almost always a bad idea to change a primary key, because it can result in undefined behavior, i.e. you could mess up any other programs that use that file, especially if they have it open concurrently. It also could create a race condition. To be totally safe, kill all other running processes that could be potentially accessing the file using OS SYSTEM calls, open the input file with a lock, open an output file, re-write the file with the new keys under a different name (skipping that record of course), close the output file, close the input file, delete the input file, then rename the output file to the original name. Then you can restart any processes that use it.
A primary key isn't meant to be a meaningful data value, if it is, it is a "smell" that perhaps you should rethink your schema design. If your goal is to read an index file sequentially, then open it with ACCESS IS SEQUENTIAL and READ NEXT RECORD. That way it won't matter what the explicit key values are, or if there are gaps. if you are reading it later with ACCESS IS RANDOM, just include an INVALID KEY clause in your read to handle the missing key. What if there is another index file that has the deleted record key saved in a field as a foreign key? If so, you have just created an orphan and blown your referential integrity.
As a matter of fact, before doing this, you need to know for sure that this is not the case, otherwise, you should delete any other index file records that reference this one as a cascade, or check any other files that might have this key as a foreign key, and not allow the delete if they do, assuming you are in full control of the schema. Cheers!