What is the most efficient way to read and set file modification timestamps for MVS data sets and PDS members?

187 Views Asked by At

I am trying to access data set and member metadata in MVS and cannot find a mechanism for getting and setting modification times (OK, and RACF rules, but that's not important right now). One of our (many) goals is to reconcile timestamps in USS with an analogous value in MVS when files are deployed.

The obvious mechanism is to use LISTCAT from TSO, but that only shows creation year.day (so today is 19.294). It is horrifically slow when I have to scan thousands of files for recent modifications. I am working in a C environment, which has the ability to embed 360 assembler instructions. The z/OS C/C++ library standard calls, like fstat/stat do not support MVS files or PDS members.

There are hints in the PDS utility documentation that ISPF sometimes sets modification times in the user area of PDS directories and there are hints that DSCB format 1 is used, but we have not been able to verify this, and the field definitions for that format do not describe modification timestamps.

1

There are 1 best solutions below

0
On BEST ANSWER

As PDS members are part of a single dataset and why you are getting mixed inidcations is that nothing in the dataset itself definitively records such a timestamp.

By default a PDS does not have such a field on a per member basis. ISPF utilities utilise the user data field, which is part of the directory (a directory entry has information on a per member basis), to record this for PDS members that are edited/editable if and only if edited using ISPF or the ISPF API (as per LMMSTATS).

  • Note that the ISPF stats are not sacrosanct and take up directory space, they can be removed, for example, using ISPF option 3.5 (a common attempt to fix for D or E37 abends).

If SMF type 42 records are captured/recorded then this may be more indicative but still not all encompassing as it only records such information when STOW (update directory) is issued (explicitly or implicitly). Most programs that update, create or delete members should issue a STOW. However some utilities may not.

You may be interested in subtypes :-

20, 21, 24 and 25 (22 and 23 are DFSMS related).