REFORMAT REFVTOC should NOT delete VTOC-INDEX prior to a reply 'U' to message ICK508A

Regarding message ICK508A, we understand that a VTOC-INDEX would be built when the reply is ‘U'. However, it is not appropriate to delete the existing VTOC-INDEX before a user answers the message ICK508A.  We think that ICKDSF REFORMAT REFVTOC job should issue the message ICK508A to ask for deleting the current VTOC-INDEX and BUILDIX function. Now it directly deleted the VTOC-INDEX and then asks if a (new) VTOC-INDEX needs to be built. It's not a good design logic-wise.
 

The SYSPRINT of the ICKDSF joblog showed message 'ICK01520I THE VTOC-INDEX WAS DELETED' but it was NOT issued to console (SYSLOG). The fact is the VTOC-INDEX had been deleted when the message ICK508A was issued. Customer said it is not supposed to do it prior to a response to ICK508A.

The Console (SYSLOG) showed:

09.36.40 JOB06038 ---- FRIDAY,    22 NOV 2024 ----
09.36.40 JOB06038  IRR010I  USERID CA7      IS ASSIGNED TO THIS JOB.
09.36.40 JOB06038  ICH70001I CA7      LAST ACCESS AT 09:30:02 ON FRIDAY, NOVEMBER 22, 2024
09.36.40 JOB06038  $HASP373 OPSRFVTC STARTED - INIT B2   - CLASS Y        - SYS CHA1
09.36.40 JOB06038  IEF403I OPSRFVTC - STARTED - TIME=09.36.40
09.36.47 JOB06038  ICK502I   BUILDIX FUNCTION STARTED
09.36.47 JOB06038  IEC604I VTOC CONVERT ROUTINE ENTERED ON 4062,CHPB15,DOS,DEVMAN
09.36.47 JOB06038  ICK503I   4062 REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT
09.36.47 JOB06038  ICK504I   4062 VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED
09.36.47 JOB06038 *080 ICK508A   4062 SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T
09.40.38 JOB06038  R 80,T                                                                                                           
09.40.38 JOB06038  ICK510I   4062 BUILDIX REQUEST CANCELLED DUE TO OPERATOR ACTION

Here, CHPB15 was IXFORMAT but after this first job was run / cancelled at message ICK508A, it becomes OSFORMAT which is not acceptable to the customer. Why ICKDSF cannot go check first before proceeding to delete the VTOC-INDEX and then build a new one (only when customer replies a U) ? Shouldn't we return the disk with its original attributes / settings to customer when he/she decides not to continue with the REFORMAT REFVTOC request, for instance, before a volume backup / dump has been taken.

Let's take another scenario, there are two IXFORMAT disks VOLUME-A and VOLUME-B. It is supposed to REFORMAT REFVTOC VOLUME-B but somehow VOLUME-A was coded in the JCL. When the job is run and it is found that the incorrect volume is used, then the job is Terminated and rerun for VOLUME-B with success. What happened now is VOLUME-A becomes OSFORMAT. If the user is not aware of the change and does not rebuild a VTOC-INDEX, then VOLUME-A will be used with degraded VTOC-searching performance.

Best regards - Tom Wai (TLS - Hong Kong Software Premium Support team)