|
View previous topic :: View next topic
|
| Author |
Message |
elixir1986
New User
Joined: 10 Nov 2015
Posts: 45
Location: USA
|
|
|
|
Hi,
I am interested to know details about the historical/statistical details for members in a PDS. Please find below,
| Code: |
BROWSE JXXX.XXX.XXXX.XXXX Row 0000001 of 000XXXX
Command ===> Scroll ===> CSR
Name Prompt Size Init [b]Mod[/b] VV MM ID
|
What I know so far?
VV is the version that is controlled thru version control tool. Please correct me if necessary?
MM is the number of times there is an EDIT made in the member and saved.
Please confirm what is Mod?
Also, please confirm what is the co-relation between "Mod" & "VV MM"
Thanks for all your replies |
|
| Back to top |
|
 |
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2593
Location: Silicon Valley
|
|
|
|
From the help:
| Code: |
Number of lines in the current member that have
been added or changed (have a non-zero mod level) |
FYI. you need to experiment some, but the line number is changed for any lines that are edited. the line number will have a suffix that corresponds to the 'mod' level. |
|
| Back to top |
|
|
elixir1986
New User
Joined: 10 Nov 2015
Posts: 45
Location: USA
|
|
|
|
I tried to EDIT the member(change existing and add a new line). I am not sure about what is non-zero mod level.
After saving the change, I do not see any change in the Mod parameter, i.e. it is still "0" whereas the MM got incremented by 1 & no change in VV either. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
This is ISPF stats. Been around since the 1970s and SPF version 1. Version (VV) is sort of arbitrary. Starts at 1 and can be changed via 3.5. Mod (MM) updates with each use of the member; basically means nothing useful. MOD as in lines modified (or something like that) also seems - to me -- to be meaningless and useless. Several years ago I wrote a line mode command to list PDS members.
| Code: |
-MEMBER- --TTRC-- VV MM -IDATE- -IRECS- -MDATE- -MTIME-- -RECS- -USER-
ADDSTATS 0001010F 01.00 01SEP13 299 01SEP13 11:33:41 299 XXXXXX
ASTATS 0003010F 01.02 16MAY13 504 12JUL13 14:29:26 524 XXXXXX |
Notice I didn't format MOD, mostly because I wanted this to fit on a line and the extra 8 bytes (a blank and 7 digits to support extended stats) was too much. Partly it's related to my style. I don't use PDS for development because of the data management issues. Lots of saves, and all of us know what that means for data management. If I'm going to fiddle with ADDSTATS, for example, I copy it to sequential and update the sequential data set. When I'm done I delete the PDS member and start a new member by copying the sequential data set to the PDS. |
|
| Back to top |
|
|
elixir1986
New User
Joined: 10 Nov 2015
Posts: 45
Location: USA
|
|
|
|
I came to know that the MOD is related to version control tool at my shop.
Ex: Say I modified 500 lines and moved the element into PDS thru version control tool, MOD shall reflect 500.
My question still is - how does VERSION level number (VV) change? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| In my experience it must be changed manually. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2137
Location: USA
|
|
|
|
AFAIR the field MOD is maintained by ISPF only when member lines are numbered in standard manner?
First RENUM command fills all positions 73-80 with 'NNNN0001' where '0001' stands for "change counter", and increased by 1 after any change of every single line. Looks like MOD value is produced as sum of all 4-digit change counters of all lines. So, after some lines are deleted, the MOD value decreases in accordance with this sum!
I'm lazy to verify this. Agree that nowadays it is meaningless, and useless. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
From the ISPF User's Guide Volume 1 :
| Quote: |
VV.MM
Version number and modification level. The version number is set to 1 and
the modification level is set to 0 when the member is created. The
modification level is the number of times this version has been modified.
For example, 02.15 means version 2, modification 15.
If a member name is just an alternate name for another member, ALIAS
appears in this field. |
The VV changes when you (or someone working at your site) goes into the appropriate ISPF screen and manually updates the VV. It otherwise stays at 01 as the quote indicates. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| sergeyken wrote: |
AFAIR the field MOD is maintained by ISPF only when member lines are numbered in standard manner?
First RENUM command fills all positions 73-80 with 'NNNN0001' where '0001' stands for "change counter", and increased by 1 after any change of every single line. Looks like MOD value is produced as sum of all 4-digit change counters of all lines. So, after some lines are deleted, the MOD value decreases in accordance with this sum!
I'm lazy to verify this. Agree that nowadays it is meaningless, and useless. |
No. mm increases by 1 each time the member is edited. ISPF never reduces mm on its own. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2137
Location: USA
|
|
|
|
| steve-myers wrote: |
| No. mm increases by 1 each time the member is edited. ISPF never reduces mm on its own. |
We are talking about MOD, not about MM
1. Member created; STATS OFF - no MOD, no numbering
| Code: |
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1
--END-- |
2. STATS ON - MM set to 00, MOD set to 0
| Code: |
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.00 2017/08/31 08:56 5 5 0 #XYZ$
--END-- |
3. RENUM - MM set to 01, MOD not changed from 0
| Code: |
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
000100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00010000
000200 T SKELETON 00020000
000300 00030000
000400 SKELETON 00040000
000500 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00050000
****** **************************** Bottom of Data ****************************
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.01 2017/08/31 08:58 5 5 0 #XYZ$
--END-- |
4. Lines added - MOD changed to 2, MM changed to 02, and '02' assigned to each changed line
| Code: |
****** ***************************** Top of Data ******************************
000100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00010000
000200 T SKELETON 00020000
000210 . . . . . . NEW LINE . . . . . . . 00021002
000300 00030000
000310 . . . . . . NEW LINE AGAIN . . . . . . 00031002
000400 SKELETON 00040000
000500 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00050000
****** **************************** Bottom of Data ****************************
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.02 2017/08/31 09:00 7 5 2 #XYZ$
--END-- |
5. Lines changed - MOD changed to 3, MM changed to 03, and changed line marked with '03'
| Code: |
****** ***************************** Top of Data ******************************
000100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00010000
000200 T SKELETON 00020000
000210 . . . . . . NEW LINE . . . . . . . 00021002
000300 --------- THIS LINE CHANGED --------- 00030003
000310 . . . . . . NEW LINE AGAIN . . . . . . 00031002
000400 SKELETON 00040000
000500 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00050000
****** **************************** Bottom of Data ****************************
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.03 2017/08/31 09:02 7 5 3 #XYZ$
--END-- |
6. Lines deleted -> MOD reduced to 1, MM changed to 04
| Code: |
****** ***************************** Top of Data ******************************
000100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00010000
000200 T SKELETON 00020000
000300 --------- THIS LINE CHANGED --------- 00030003
000400 SKELETON 00040000
000500 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00050000
****** **************************** Bottom of Data ****************************
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.04 2017/08/31 09:03 5 5 1 #XYZ$
--END-- |
7. UNNUM-RENUM - all lines marked with '05', MM changed to 05, MOD set to 5
| Code: |
****** ***************************** Top of Data ******************************
000100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00010005
000200 T SKELETON 00020005
000300 --------- THIS LINE CHANGED --------- 00030005
000400 SKELETON 00040005
000500 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00050005
****** **************************** Bottom of Data ****************************
NAME RENAME LIB VV.MM CHANGED SIZE INIT MOD USERID
TESTMEM +SAVED 1 01.05 2017/08/31 09:16 5 5 5 #XYZ$
--END-- |
|
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| ISPF member statistics are totally useless, and every one of them can be set to whatever values you want them to be set to via the LMMSTATS function. I have text members with a creation date of 1978, (seven years before I started as a programmer) and PL/I source with a creation date of 2099-12-31. And about half my members have a userid that doesn't even exist on the systems I'm working on. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| prino wrote: |
| ISPF member statistics are totally useless, and every one of them can be set to whatever values you want them to be set to via the LMMSTATS function. I have text members with a creation date of 1978, (seven years before I started as a programmer) and PL/I source with a creation date of 2099-12-31. And about half my members have a userid that doesn't even exist on the systems I'm working on. |
True. As Prino says, it is all to easy to subvert them. VV MM and user can easily be altered via 3.5, and a half way intelligent programmer can subvert the remainder through a program. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1314
Location: Vilnius, Lithuania
|
|
|
|
| steve-myers wrote: |
| prino wrote: |
| ISPF member statistics are totally useless, and every one of them can be set to whatever values you want them to be set to via the LMMSTATS function. I have text members with a creation date of 1978, (seven years before I started as a programmer) and PL/I source with a creation date of 2099-12-31. And about half my members have a userid that doesn't even exist on the systems I'm working on. |
True. As Prino says, it is all to easy to subvert them. VV MM and user can easily be altered via 3.5, and a half way intelligent programmer can subvert the remainder through a program. |
Or just use the editor provided commands:
version 42
level 42
Sigh... |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
It is important to remember that member statistics are not a part of the z/OS file system. Member stats are stored in the so-called "user area" of a PDS directory. As the name implies, the contents and usage of the "user area" is up to the user of the data set, in this case ISPF. Other programs that update PDSes may use the "user area" for other purposes.
As Mark Twain might have said: "There are lies, damned lies, and member list statistics". |
|
| Back to top |
|
|
|
|
