search cancel

DCB information changes by PST dataset on INPUT DD in IEBCOPY


Article ID: 227474


Updated On:


Compress Data Compression for MVS


A PST dataset on INPUT DD of IEBCOPY by mistake.
The IEBCOPY job abended and the DCB ( RECFM and LRECL ) was changed.

Before IEBCOPY : FB 80 13680
After    IEBCOPY : VB 92 27998

Is it Compress design when a PST is set on input DD of IEBCOPY ?

//COPY1    EXEC PGM=IEBCOPY             
//SYSPRINT DD SYSOUT=*                  
//SYSUT2   DD DISP=(,CATLG),            
//         UNIT=3390,VOL=SER=vvvvvv,  
//         DCB=prefix.PST,        
//         SPACE=(TRK,(1,1),)           
//SYSIN    DD  DUMMY                    

The PST dataset has following attribute.

The job terminated with RC=8 and it was then noticed that the DCB attributes for the input file appeared to have been changed from RECFM=FB,LRECL=80,BLKSIZE=13680 to RECFM=VB,LRECL=92,BLKSIZE=27998.   This change can be seen via ISPF 3.2.

Did Compress change the DCB attributes?


Release : 5.5

Component : CA Compress Data Compression


In the above example the user who allocated data set prefix.PST specified DCB attributes of RECFM=FB,LRECL=80,BLKSIZE=13680. Behind the scenes however, Compressed changed the DCB attributes to RECFM=VB,LRECL=92,BLKSIZE=27998 to facilitate compressing the data set. Under normal circumstances prefix.PST appears to application programs and users to have the original DCB attributes.

Because the job above terminated erroneously and a compressed data set was involved, Compress saw a problem and, in the Compress control file record for prefix.PST turned on the INHIBIT setting. Now, with INHIBIT turned on, Compress bypasses Compress processing and also bypasses intercepting SVC 99 calls and, as a result an ISPF 3.2 display will show the actual, physical attributes of prefix.PST. It should be noted that the record format, LRECL and block size in the F1 DSCB for prefix.PST was not changed!  In this case, because prefix.PST was being used as input and was not changed in any way, the correct fix is to run Compress utility DEFXP001 ALTER with UNINHIBIT.

In other cases the circumstances that caused INHIBIT to be set must be investigated and the appropriate action taken.

The next step to perform would be to UNINHIBIT the file since the flag is now set in the CMPMVS table. The fix the abend and rerun the job. In this case use the correct program/utility.

//SUIIN DD *                                    
   ALTER PSDSN=dataset,UNINHIBIT       

It is in reality since it is supposed to be compressed in the table. The data was protected but the DCB attributes now reflect a compressed entry.