I was searching for a way to display ISPF statistics since a flag is set if the last editor of a dataset was SCLM, and I found that you can do this in z/OS 1.13 but not in z/OS 1.12, which we have. But along the way I discovered that you can use SuperC from within the editor, via the command COMPare.
For the hell of it I tried to see if I could trip SuperC up by using at least one large dataset, and I think I have.
The primary dataset is this one, which has many thousands of lines, in which I show the first few and last few lines:
and the second dataset is this one, composed of just 3 lines (note that the PICs and rightmost numbers should line up in both datasets, and they are both PDSs with LRECL=80, and the comparison is on columns 1 to 72, which does not include the rightmost numbers):
Code:
********************************* Top of Data **********************************
01 DCLAGT-CFM. 00010000
10 AGT-NUMBER PIC X(7). 00020000
10 CFM-VALUE PIC X(4). 00030000
******************************** Bottom of Data ********************************
Now, the lines that SuperC says match are the first lines and the last two in both datasets, and you can see that is the case in the code copies, but it is much easier to do and see the comparisons using COMPare, which I initially did.
The primary dataset has 47999 lines, and using 3.12 I get the following:
Code:
***************************** Top of Data ******************************
ISRSUPC - MVS/PDF FILE/LINE/WORD/BYTE/SFOR COMPARE UTILITY- ISPF F
NEW: PWSX.L5JALTO.APTF2(A) OLD: PWSX.L
LINE COMPARE SUMMARY AND STATISTICS
3 NUMBER OF LINE MATCHES 47996 TOTAL CHANGES (PAIRED+N
0 REFORMATTED LINES 0 PAIRED CHANGES (REFM+PA
47996 NEW FILE LINE INSERTIONS 47996 NON-PAIRED INSERTS
0 OLD FILE LINE DELETIONS 0 NON-PAIRED DELETES
47999 NEW FILE LINES PROCESSED
3 OLD FILE LINES PROCESSED
**************************** Bottom of Data ****************************
If I then edit the primary dataset and add one more (non-matching) line (making 48000 lines) I get the following:
Code:
***************************** Top of Data ******************************
ISRSUPC - MVS/PDF FILE/LINE/WORD/BYTE/SFOR COMPARE UTILITY- ISPF F
NEW: PWSX.L5JALTO.APTF2(A) OLD: PWSX.L
LINE COMPARE SUMMARY AND STATISTICS
2 NUMBER OF LINE MATCHES 47998 TOTAL CHANGES (PAIRED+N
0 REFORMATTED LINES 1 PAIRED CHANGES (REFM+PA
47998 NEW FILE LINE INSERTIONS 47997 NON-PAIRED INSERTS
1 OLD FILE LINE DELETIONS 0 NON-PAIRED DELETES
48000 NEW FILE LINES PROCESSED
3 OLD FILE LINES PROCESSED
**************************** Bottom of Data ****************************
Only two matching lines!
Of course I didn't just happen upon this boundary number of 48000, it took a lot of submissions using COMPare to arrive at the number, and it is also easier to see which lines SuperC thinks are the matching ones using COMPare, and it is the first line and the last line in both datasets, so it now thinks that the penultimate lines do not match.
For those who have not seen the results of using COMPare, the following is what you get using COMPare, where you can see that the non-matching (inserted) lines are labelled - they're also in colour in ISPF, but not here in this forum's display!
Code:
****** ***************************** Top of Data ******************************
000011 01 DCLAGT-CFM.
.OAAAA 01 DCLAGT-CFM.
.OAAAB 01 DCLAGT-CFM.
.OAAAC 01 DCLAGT-CFM
.OAAAD 01 DCLAGT-CFM
Hence, I've invoked SuperC in two different ways and get the same results, but results that seem to be anomalous.(And note that I've reversed the roles of the datasets (making the smaller one the primary) but the same anomaly occurs.)
So, have I broken SuperC or what?
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
From three matches you've gone to two matchesandone paired change.
It may have something to do with the fact, if I remember correctly, that SuperC breaks down the compare into segments of 16K lines, so you may just have hit a borderline case.
Thanks for your replies.
Regarding the paired change, I must say that I overlooked that but still I venture to say that it is still not classified as a match though I don't know what it is, so, Prino, can you tell us what it is? My investigations were wholly using COMPare, and I only turned to 3.12 for confirmation, and the information returned by COMPare only indicates a match or no match, not a subtlety like a paired change (whatever that is - Prino ...).
As for Pedro's reply - you may have IBM on a hotline but I don't, and certainly don't know what a PMR is - a Personal Moan Report? Also, I guess I was hoping that, just as DFSORT developers join in the SORT forum, ISPF/SuperC developers might join in this forum, but perhaps not.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
I believe there is an option to save the SuperC compare listing that is used by the COMP command. It might give clues as to why COMP reclassifies lines compared to plain SuperC.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
ISPF/SuperC developers might join in this forum, but perhaps not.
As far as i know, ISPF/SuperC developers/support do not look for topics here.
A PMR is a Problem Management Request (kinda like a Help Des Ticket). I suspect that you (or the organization) does have a "hotline" to IBM Support. There may be a restriction as to exactly who may call IBM.
One of the things SuperC will attempt is to show where a line was "changed" - i.e. a "matched pair". Sometimes i believe it gets a bit confused
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
Quote:
you may have IBM on a hotline
When I have problems, I tell my sysprog and she who knows what to do.
It seems that you investigated pretty thoroughly and the concluded that something is amiss. I doubt any of us will spend as much time on this as you did. I do not think any ISPF developers monitor this forum. If you think it is broken, the only way it will get fixed is if you call IBM.
ISPF option 3.13 can accept processing option "DLREFM = Don't list reformatted lines. " Likewise, in the editor you can issue COMPARE with no parameters to get a control panel: select "Ignore Reformat Differences". My understanding is that if it is the same text but in different columns, it will not get flagged as a changed line. If you get different results from editor than from 3.13, it is likely because of some of those settings.
