"Severe Error" While opening a Dataset in ISPF 3.4.

[mesripad]

Hi,

I am getting a "Severe Error" While opening a Dataset in ISPF 3.4. Any Help on this?

[enrico-sorichetti]

NO!
the info posted is insufficient.

[mesripad]

Let me try to explain you what I have done

I Ran a DFHCSDUP Job to extract a group from DFHCSD File, during I forgot to mention the member name in the Pds
Ex : cics.support.jcl(memname) - it is a PDS
Without memname I have submitted the job , After that when I tried to open the Pds . (Cics.support.jcl) in ISPF 3.4
i am getting "Severe Error" . I have saved most of the jobs in CICS.SUPPORT.JCL . all i need someone help to retrieve the Dataset with all the members in it.

Code: Select all

 DSLIST - Data Sets Matching CICS.SUPPORT                          Severe error
 Command ===>                                                  Scroll ===> CSR  
                                                                                
 Command - Enter "/" to select action                  Message           Volume 
 -------------------------------------------------------------------------------
          CICS.SUPPORT.EXTRACT.OUTPUT                                    MIGRAT2
          CICS.SUPPORT.EXTRACT.QUA1                                      MIGRAT2
          CICS.SUPPORT.EXTRACT.TRP1                                      MIGRAT2
          CICS.SUPPORT.EXTRACT.T707                                      MIGRAT2
          CICS.SUPPORT.EXTRACT.T707.TEST                                 MIGRAT2
 M        CICS.SUPPORT.JCL                                               SYSD01

[mesripad]

Severe Error.jpg

[enrico-sorichetti]

hit PF1 to see the long message
and get in touch with Your support

most probably You clobbered Your pds by overwriting the directory
Your pds will have to be recovered, and Your support will be happy to do it for You

[mesripad]

When i hit PF1 i see this message
Open, I/O, or BLDL error.

In Current utilization there is no Details about Directory Blocks.
Unfortunately there is no backups aswell for these volumes.

[enrico-sorichetti]

In Current utilization there is no Details about Directory Blocks.

it confirms my suspicion.

if no backups are available You will have to start everything over from scratch

[Anuj Dhawan]

Couple of thoughts. (Having no mainframes' access pushes you to the corner) -

I have not worked with DFHCSDUP, however, looking at the batch execution of it from the IBM manuals; the job should be like this (please share the job you have used, it might help us to help you):

Invoking DFHCSDUP as a batch program

Code: Select all

//CSDJOB  JOB  accounting info,name,MSGLEVEL=1
//STEP1   EXEC PGM=DFHCSDUP,REGION=0M,                                 
//             PARM='CSD(READWRITE),PAGESIZE(60),NOCOMPAT'
//STEPLIB DD   DSN=CICSTS53.CICS.SDFHLOAD,DISP=SHR
//DFHCSD   DD  DISP=SHR,DSN=CICSTS53.CICS.DFHCSD
//SECNDCSD DD  UNIT=SYSDA,DISP=SHR,DSN=CICSTS53.CICS.SECNDCSD          
//indd     DD  UNIT=SYSDA,DISP=SHR,DSN=extract.input.dataset           
//outdd    DD  UNIT=SYSDA,DISP=SHR,DSN=extract.output.dataset           
//* or                                                                 
//outdd    DD  SYSOUT=A                                                 
//SYSPRINT DD  SYSOUT=A
//SYSIN    DD  *
⋮
     DFHCSDUP commands                                                 
/*
//

[/url]

For your Job, if indd was a sequential file and outdd was supposed to be a PDS but given without a member name then as Enrico said, I think, you have very slim chances of getting the PDS back without a recent backup.


On a second thought, [username|#00AA00|bold|177]enrico-sorichetti[/username], please help me here (no mainframe access makes me dull in my responses):

If TA can add a dummy member by, say, IEBGENER. Don't you think it might help to repair the directory and might work in his favor?

Code: Select all

//SYSUT1   DD *
Some DUMMY Record
/*
//SYSUT2   DD DSN=the.corrupted.pds(DUMMY),DISP=OLD,
//          RECFM=FB,LRECL=80,SPACE=(?,?)

Be sure about the DCB parameters.

[enrico-sorichetti]

Hello Anuj
the sysut1/sysut2 trick helps for a DCB clobbering
( using a fb pds as target for a load module )
might be able to test it later , but I am pretty sure that it will not repair a broken directory

[Robert Sample]

IIRC, the PDS directory is stored in the first part of the data set. Hence, depending upon how long the overwriting data was, some or all of the PDS directory has been replaced. If the entire directory was not overwritten, it might be possible to recover the PDS members for which the directory entry still exists -- I'd probably try running PDS86 against it to see what, if anything, can be recovered.

This post again demonstrates the critical importance of backups of critical data sets. If you don't take backups, you're saying you don't care if the data set is destroyed. If no backups exist for the volumes, what about backups for the data set HLQ?