View previous topic :: View next topic
|
Author |
Message |
kovur
New User
Joined: 15 Nov 2007 Posts: 36 Location: India
|
|
|
|
Does using the line command Z for compressing the PDS corrupt the dataset? |
|
Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007 Posts: 1399 Location: IL, USA
|
|
|
|
Then such command would have been fixed or removed....
because We often use the same....
Any specific issue you faced? |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
kovur wrote: |
Does using the line command Z for compressing the datasets, corrupt the datasets? |
What makes you ask that |
|
Back to top |
|
|
kovur
New User
Joined: 15 Nov 2007 Posts: 36 Location: India
|
|
|
|
I know that Z is used to compress the PDS.
But the problem I faced is strange.
I tried compressing one of my PDS's using Z, but the contents in the PDS, the members got corrupted.
After compression, some members have no data, some members have some other member's data, some have junk data and some jobs still have valid data.
I am really confused how this happened. Please advise |
|
Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007 Posts: 1399 Location: IL, USA
|
|
|
|
Quote: |
some have junk data |
What junk means here |
|
Back to top |
|
|
kovur
New User
Joined: 15 Nov 2007 Posts: 36 Location: India
|
|
|
|
Here I mean 'Junk' as some thing which is not required.
for example, in a jcl memeber, I see numbers. If the jcl member has 40 lines before compression, after compression I see some numbers with thousands of rows |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
If something went wrong during the compress (such as your TSO user id getting logged off), then yes the data set could be corrupted. Compression is physically moving members around in the PDS, and if the process does not complete normally (or if there is another job or task attempting to use the members at the same time), then you can wind up with a PDS that needs to be restored from back up. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
Were more then one user "using" PDS when you issue compress? |
|
Back to top |
|
|
kovur
New User
Joined: 15 Nov 2007 Posts: 36 Location: India
|
|
|
|
It is a shared dataset. I asked everyone not to access it. But somebody unknowingly might have accessed it.
not sure.
But, does this really matters? |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
Quote: |
But, does this really matters? |
Given the situation that your PDS is in, what do you think ? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
But, does this really matters? |
OK, the person is updating the PDS and overwrites some of the data -- and directory -- due to the compress going on at the same time. What are the odds of corruption? Pretty much 100% I'd say.
There is a reason compress jobs usually run with DISP=OLD. |
|
Back to top |
|
|
kovur
New User
Joined: 15 Nov 2007 Posts: 36 Location: India
|
|
|
|
People might be using 1 or 2 members of the pds. But how come almost 50% of the members were corrupted? The pds contains almost 12000 members and almost half of the members does not have valid data.
the following is the screen I got while compressing. EVERY MEMBER GOT OVERLAPPED WITH OTHER MEMBER.
Code: |
FCO520A ABCDEFGH OVERLAPS PREVIOUS MEMBER
FCO520A I218158E OVERLAPS PREVIOUS MEMBER
FCO520A GHFTJ105 OVERLAPS PREVIOUS MEMBER
FCO520A JKGLJ601 OVERLAPS PREVIOUS MEMBER
FCO520A HB7869MG OVERLAPS PREVIOUS MEMBER
FCO520A KHGFJ462 OVERLAPS PREVIOUS MEMBER
FCO520A GMCTJ202 OVERLAPS PREVIOUS MEMBER
FCO520A SRFLJ404 OVERLAPS PREVIOUS MEMBER
FCO520A JNSTART OVERLAPS PREVIOUS MEMBER
FCO520A TYPBJ511 OVERLAPS PREVIOUS MEMBER
FCO520A JRCDJ031 OVERLAPS PREVIOUS MEMBER
FCO520A TUMOCRE OVERLAPS PREVIOUS MEMBER
FCO520A IENEZT OVERLAPS PREVIOUS MEMBER
FCO520A IOPBJ753 OVERLAPS PREVIOUS MEMBER
FCO520A UECVJ703 OVERLAPS PREVIOUS MEMBER
FCO520A YRCVJ705 OVERLAPS PREVIOUS MEMBER
FCO520A IUFTJIN1 OVERLAPS PREVIOUS MEMBER
FCO520A OWFTJINX OVERLAPS PREVIOUS MEMBER
FCO520A PIFTJINY OVERLAPS PREVIOUS MEMBER
FCO520A YUFTJIN2 OVERLAPS PREVIOUS MEMBER
FCO520A URCBJDGB OVERLAPS PREVIOUS MEMBER
FCO520A UR4485AA OVERLAPS PREVIOUS MEMBER
FCO520A BH4485AA OVERLAPS PREVIOUS MEMBER
FCO520A UIFTJ106 OVERLAPS PREVIOUS MEMBER
FCO520A YTFTJ108 OVERLAPS PREVIOUS MEMBER
|
|
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Even when I'm 99.9% certain that I'm the only user of a PDS, I still use the following instead of Z:
Code: |
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
//XXXXXBIG JOB (XXX),'T. HEINZE - XXX-XXXX',
// CLASS=R,
// MSGCLASS=T,
// NOTIFY=&SYSUID,
// REGION=0M
//* ALLOCATE MORE SPACE TO A PARTITIONED DATA SET BY COPYING IT TO A
//* NEW NAME AND RENAMING IT BACK TO THE ORIGINAL. THIS JOB DOES NOT
//* DELETE THE OLD DATA SET, SO PLEASE DO IT MANUALLY.
// SET BLKSIZE=27920 <=== CHECK (MAX=27998)
// SET BLKSPRI=00120 (30 BLOCKS PER 3390 CYLINDER)
//* 1 ADDITIONAL BLOCK IS ALLOCATED FOR APPROX. EVERY 20 DIR. BLKS.
// SET BLKSSEC=00120
// SET DIRBLKS=08
//* C CURR 'DATA SET NAME'
// SET DSNME='CURR' <=== CHANGE
// SET RECFORMT=FB {F|FB|U}
// SET RECLNGTH=00080
//*
// IF (RC EQ 0000) THEN
//* DELETE THE OLD GUY, IF HE EXISTS.
//DELETE EXEC PGM=IEFBR14
//DD1 DD DSN=&DSNME..OLD,
// DISP=(MOD,DELETE,DELETE),
// SPACE=(TRK,0)
// ENDIF
//*
//*
// IF (RC EQ 0000) THEN
//* COPY THE OLD GUY TO THE NEW GUY.
//COPY EXEC PGM=IEBCOPY
//DDIN DD DSN=&DSNME,
// DISP=OLD
//DDOUT DD DSN=&DSNME..NEW,
// DISP=(NEW,CATLG,DELETE),
// LRECL=&RECLNGTH,
// RECFM=&RECFORMT
// SPACE=(&BLKSIZE,(&BLKSPRI,&BLKSSEC,&DIRBLKS))
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COPY OUTDD=DDOUT
INDD=DDIN
// ENDIF
//*
//*
// IF (RC EQ 0000) THEN
//* RENAME THE NEW GUY TO THE OLD GUY.
//RENAME EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER CURR -
NEWNAME(CURR.OLD)
ALTER CURR.NEW -
NEWNAME(CURR)
// ENDIF
//*
// |
|
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
This should not happen at all because if one person has a PDS open for write, the 2nd one will get a 213-50 (or is it -70) abend when they try to open it for write. Compressing a data set with DISP=SHR is safe and has been for 10 years or more since the introduction of that abend protection. The only way corruption might occur is if the job, your TSO id, abends while writing the directory or data, or if the same data set is shared between different systems and the ENQ mechanism, GRS, MIM, etc is not set up correctly. You might also be seeing a problem where the directory is cached and the cache has not been updated to reflect the new directory. That is common for load modules controlled by VLF, but it also happens with other datasets and systems. If there is a program that writes the PDS directory directly (not using STOW) using an old directory as a starting point that would be a disaster waiting to happen, but I can't imagine anyone would do that. |
|
Back to top |
|
|
|