False jobname IBMOSVS2 returned by Disk Backup and Restore LISTD

Products

• Disk Backup and Restore - MVS

Issue/Introduction

The Disk command LISTD can be used to list a set of files that were archived, in order to find out which JOB created those files.

Sometimes it can happen that in the LISTD command output, the job that created the file is set to IBMOSVS2, even if there isn't any job with that jobname that could have created the file.

Why this value and how to correctly manage it in Disk  

Environment

Release : 

Component : Disk Backup and Restore

Resolution

In general, the literal 'IBMOSVS2' is copied from the DS1SYSCD field in the VTOC. To maintain the actual jobname of the job that created the file in this field it will be necessary to install the DISKOS SVC. 

Here the link in the documentation:

Install the Disk SVC

...Decide whether the Disk SVC maintains the job name or the accounting code. Then, update the source code in member ADSOPJBN provided in the CCUWSAMP library to reflect your selection. The default is to keep the creating JOBNAME. If this is appropriate, skip to substep 3....

so the default SVC keeps the creating JOBNAME.

Now, IBMOSVS2 is the IBM default jobname for data sets that are created but not  opened.  The field is not used by IBM.  Once they are updated with a jobname, if the SVC is installed, it will update the field and put in the jobname.

But there are some observations to take into consideration: 

1.  The data set would need to go through OPEN processing in order for the Disk SVC to do any updates or changes.  So depending on how the data set is allocated (created), it might be possible to see an update after the allocation and nothing later.      
2. If this dataset is allocated using a batch IEFBR14 , it is never opened/used , so this field contains IBMOSVS2 instead f the batch jobname that created it . So Non-VSAM data sets that are allocated but never opened will also not be updated.
3. the VSAM datasets would be affected by the IDATMSTP exit if they go through OPEN, not by the DISK SVC. In fact VSAM data sets do not have the FMT1 updated as they are bypassed by the Disk SVC. So the DS1SYSCD field in the FORMAT 1 DSCB for VSAM components is not  maintained by DISK. It still shows the default value of IBMOSVS2 . 
4. HFS data sets show as VSAM so the Disk SVC would not be used.  The only updates would be done by IDATMSTP.

This could explain why in the LISTD output, the jobname IBMOSVS2 is present for some datasets only.