IBM Mainframe Forum

[Bad Man]

Hi I have a user whose 4 files created on 10th October started to show a creation date of 15th Sept. They were all good till 13th October as per the client but something happened after that and they started to show a creation date of 15th Sept and also the data was from 15th Sept. I ran FDR jobs to find it was not migrated since it got created on 10th October 2012 and also ran reports using records 14 and 15 to find these datasets were all touched only with DISP=SHR and as input and even verified by viewing the job the same. I have contacted FDR and they say only I could have done it as no one else using Restore jobs and none have the authority. The client only got back to me on this after he recreated his lost datasets. Any directions / Help / Suggestion please.

[dick scherrer]

Hello,

Sounds like someone simply wrote over the Oct datasets with the Sept data.

This does not sound like an FDR problem. I would also not think this was a migration issue.

I suspect something unintentional has happened.

[Bad Man]

In that case will the SMF records not show the same? It always showed the FILE as input and DISP=SHR.

[BillyBoyo]

DASD "image restore"? Sounds unlikely..., but, according to the Client, something did it.

I don't like that "according to the Client". Did you see anything of this yourself? The person reporting it to you is a systems person, or what?

[Bad Man]

The clients are belonging and related to a particular application they are probably DB2 guys, I am frankly clueless on what could have happened as the customer has clearly told he didn't touch it and SMF reports prove the same he touched it only for input...this issue hasn't repeated this week though...Dick scherrer if someone did overwrite it I would think that person id will show in SMF reports but then you may be right...

[dick scherrer]

Hello,

DISP=SHR allows writing as well as reading the data . . .

I am frankly clueless on what could have happened as the customer has clearly told he didn't touch it

Well, someone/something did

Sounds like there may be a process the client uses(ed) that Does re-write things. Is the user able to restore prior files?

Is there any chance there was some kind of system problem that resulted in these datasets being restored (say an entire volume) so there might be no individual SMF footprints? Have you talked with your storage management people?

[Bad Man]

I am the Storage person. I have been able to get some SME's look too but their is nothing they could find either. User says he doesn't have that authority to restore stuffs.

Along with DISP=SHR it also said input will it be safe to say that it was not used for writing and just readin as it says just input in OPEN?

Select all

OBS   SYSTEM                  DSNAME                   JOB        DISP   VOLSER

   1    SDEV    XXXXX.RIVA.DLR.XREF.WE1       ITSSREFM   NEW    TSTAE9
   2    SDEV    XXXXX.RIVA.DLR.XREF.WE1       ITSSWE2    SHR    TSTAE9
   3    SDEV    XXXXX.RIVA.DLR.XREF.WE1       ITSSWE2    SHR    TSTAE9
   4    SDEV    XXXXX.RIVA.DLR.XREF.WE1       SPA01085   SHR    TSTAE9
   5    SDEV    XXXXX.RIVA.DLR.XREF.WE1       SPA01006   SHR    TSTAE9
   6    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS405006   SHR    TSTAE9
   7    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404085   SHR    TSTAE9
   8    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404020   SHR    TSTAE9
   9    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404009   SHR    TSTAE9
  10    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS40425    SHR    TSTAE9
  11    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS40559    SHR    TSTAE9
  12    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404079   SHR    TSTAE9
  13    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404047   SHR    TSTAE9
  14    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404235   SHR    TSTAE9
  15    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404051   SHR    TSTAE9
  16    SDEV    XXXXX.RIVA.DLR.XREF.WE1       P1064      SHR    TSTAE9
  17    SDEV    XXXXX.RIVA.DLR.XREF.WE1       ITSSREFM   NEW    TSTA7M
  18    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404009   SHR    TSTA7M
  19    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404020   SHR    TSTA7M
  20    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404085   SHR    TSTA7M
  21    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS40425    SHR    TSTA7M
  22    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404047   SHR    TSTA7M
  23    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404079   SHR    TSTA7M
  24    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404235   SHR    TSTA7M
  25    SDEV    XXXXX.RIVA.DLR.XREF.WE1       CS404051   SHR    TSTA7M

Select all

 OBS                OPENTIME     OPEN                   SMFTIME    EXCPCNT

   1   10NOV2012:03:33:01.27    OUTPUT    10NOV2012:03:33:08.60        6
   2   13NOV2012:04:34:39.21    INPUT     13NOV2012:04:34:39.59        1
   3   13NOV2012:04:50:52.93    INPUT     13NOV2012:04:50:53.20        1
   4   13NOV2012:08:55:44.96    INPUT     13NOV2012:08:55:45.22        5
   5   13NOV2012:09:43:50.66    INPUT     13NOV2012:09:43:50.92        5
   6   14NOV2012:08:15:57.60    INPUT     14NOV2012:08:15:57.85        5
   7   14NOV2012:08:26:38.95    INPUT     14NOV2012:08:26:39.46        5
   8   14NOV2012:08:27:57.61    INPUT     14NOV2012:08:27:57.88        1
   9   14NOV2012:08:43:55.89    INPUT     14NOV2012:08:43:56.20        1
  10   14NOV2012:08:47:01.33    INPUT     14NOV2012:08:47:01.54        1
  11   14NOV2012:08:47:06.16    INPUT     14NOV2012:08:47:06.46        5
  12   14NOV2012:08:47:12.00    INPUT     14NOV2012:08:47:12.28        1
  13   14NOV2012:08:51:43.98    INPUT     14NOV2012:08:51:44.28        1
  14   14NOV2012:08:56:29.32    INPUT     14NOV2012:08:56:29.97      369
  15   14NOV2012:08:57:42.95    INPUT     14NOV2012:08:57:43.13        1
  16   14NOV2012:10:56:10.81    INPUT     14NOV2012:10:56:14.21        1
  17   14NOV2012:11:04:30.66    OUTPUT    14NOV2012:11:04:31.31        6
  18   14NOV2012:11:57:18.65    INPUT     14NOV2012:11:57:18.89        1
  19   14NOV2012:12:12:30.70    INPUT     14NOV2012:12:12:31.27        1
  20   14NOV2012:12:16:31.07    INPUT     14NOV2012:12:16:31.70        5
  21   14NOV2012:12:24:53.95    INPUT     14NOV2012:12:24:54.37        1
  22   14NOV2012:12:25:36.16    INPUT     14NOV2012:12:25:36.38        1
  23   14NOV2012:12:26:15.29    INPUT     14NOV2012:12:26:15.96        1
  24   14NOV2012:12:34:24.64    INPUT     14NOV2012:12:34:25.59      370
  25   14NOV2012:12:34:29.36    INPUT     14NOV2012:12:34:29.59        1

Code'd

[Robert Sample]

Along with DISP=SHR it also said input will it be safe to say that it was not used for writing and just readin as it says just input in OPEN?

If you want to try an interesting experiment sometime, try running an IEBCOPY batch job doing a compress on a PDS, with DISP=SHR in the JCL. Warning: make completely certain that nobody else is using that PDS when your batch job executes! Once you have completed this experiment, you will have the answer to your question.

[enrico-sorichetti]

I am the Storage person.

then You should know that the jcl DISP has little/nothing to do with the I/O done on the dataset

[dick scherrer]

Hello,

I still have not figured out how a read/write/re-write would change the Create date . . .

Especially to an earlier date and affecting multiple files. . .

Wonder if someone meant to run a backup of these, but submitted a restore instead