1

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.

Randall Becker
  • 65
  • 3
  • Dates for MVS files are stored in the format 1 DSCB in the volume VTOC, documented in DFSMSdfp Advanced Services. Manipulating DSCBs is tricky and you can break a VTOC if you’re not careful. ISPF statistics are maintained in the PDS directory. It’s easier when using ISPF services, but that means you need to invoke ISPF with a SELECT PGM or CMD pointing to a Rexx script that invokes a program. As you are dealing with a deep level, I recommend using Metal C, which is designed to work with OS-level stuff by dropping to assembly, at the expense of not having a lot of stdlib routines. – zarchasmpgmr Oct 22 '19 at 00:46
  • Thank you. I will look down that path. – Randall Becker Oct 22 '19 at 18:16
  • We succeeded using REXX stream(file, 'C', 'QUERY REFDATE') to pull dates. However the resolution is only down to the day of year rather than seconds. I decided that depending on timestamps is not really a good plan, so we are going with a different design. Thanks for the help. – Randall Becker Oct 29 '19 at 20:28
  • You're welcome. Unfortunately, z/OS for classic data sets does not reflect time of update. – zarchasmpgmr Oct 29 '19 at 22:49

1 Answers1

1

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).

MikeT
  • 51,415
  • 16
  • 49
  • 68