https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idai200/recstr.htm IDCAMS DCOLLECT RECORD TYPE D 264(X'108') CHARACTER 8 DCDUDSIZ USER DATA SIZE (64 BIT UNSIGNED BINARY NUMBER) 272(X'110') CHARACTER 8 DCDCUDSZ COMPRESSED DATA SET SIZE (64 BIT UNSIGNED BINARY NUMBER) 280(X'118') BITSTRING 1... .... 2 DCDEXFLG DCDBDSZ COMPRESSION FLAGS (Not used for zEDC) DATA SIZES THAT ARE NOT VALID
RECORD TYPE M 72 (48) SIGNED 4 UMDSIZE MIGRATION COPY DATA SET SIZE IN KILOBYTES/MEGABYTES 196 (C4) SIGNED 4 UMRECSP RECALL SPACE ESTIMATE IN KILOBYTES On Tue, Nov 5, 2019 at 8:55 PM Michael Hochee <[email protected]> wrote: > > A couple months ago I was in the process of retrieving the size of a data set > on disk until I came across a flag in one or more DSCBs that indicate whether > or not the data set is compressed. This was the point at which I stopped > coding, concluding that it was probably not possible to come up with an > accurate uncompressed size if the data set resided on a SAN with compression > turned on. Is my thinking off-base here? (of course, I have no interest in > reading the file to determine the actual uncompressed length) > > Thanks, Mike > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
