MVSFORUMS.com

William Collins · Supermod Joined: 03 Jun 2012 Posts: 437 Topics: 0

The content of the user-data will change/can be changed. Is that what you are asking?

Here is a description of the content:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzdg90/C.4.4#!

When you change something which affects any of that, the value will change. For instance, with your example of modifying one blank, the number of lines changed should be reflected in the user-data.

Note: Where the document refers to "packed decimal" it is not quite being straight with you. The format is actually Binary Coded Decimal. Looks like "packed decimal" but with no low-order sign half-byte.

Bear in mind that the ISPF statistics can just be cleared easily. What are you actually trying to do?

BobGilbert · Beginner Joined: 12 Sep 2006 Posts: 24 Topics: 10

semigeezer · Posted: Fri Dec 13, 2013 3:12 pm Post subject:

I would not rely on user data for *anything*.

They are easily changed by copies, ISPF utilities and services, utilities, macros and anything else that writes to the PDS. They are sort of 'defacto' owned by ISPF with an ISPF defined format, but that format is implemented by many products and library systems, sometimes incorrectly or, to be nice, differently.

TTRs could be fooled by opening an output DCB for "update in place" for a PDS (not a PDSE I guess). Or doing a compress-change-compress if the member is at the end of the PDS.

For audit, the only way to do this in my opinion is to read the contents of the members, generate an md5sum, SHA hash or something like that store it externally. Take that with a grain of salt... I never worked in a shop that formally audited source code for changes. But I did work on the ISPF code that implemented the statistics a few decades ago and even changed the format once myself (I forget why. I think I added a bit somewhere).
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.

William Collins · Supermod Joined: 03 Jun 2012 Posts: 437 Topics: 0

BobGilbert · Beginner Joined: 12 Sep 2006 Posts: 24 Topics: 10

Endevor does control its libraires, but people have been known to setup copy jobs via tempory production jobs, thus bypassing endevor. This for the most part will placate the auditors and show we are minotoring it. Taking these changes, matching to endevor packages, and onto a feed from service now will go a long way towards the retoric. Over the next year we have to pull apart RACF, it really is a mess!

What I did notice with IEHLIST is if the library is a load module the TTR always changes, but when a non loadlib is looked at the user data changes and the TTR is not touched, unless it is compresed of course.

I understand someone could open the PDS in a job, this is more of a monitoring exercise than anything.

For now I am past the IEHLIST (but down the road I can replace), I have a proc which runs against any PDS/PDS, generates the IEHLIST into a GDG by dataset name. Reads those GDGs into Superc and produced of file read into a SAS job writing out a file with the library name, the member name, the type of change(add modify delete). Next is to get listing out of endevor...this will be a challenge.