Very good point.
On Wed, Nov 6, 2019 at 12:39 AM Mike Schwab wrote: >Listcat output changes when fields need more digits. DCollect doesn't change. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Mike Schwab <mike.a.sch...@gmail.com> Sent: Wednesday, November 6, 2019 12:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: calculating data set size - compression concern Caution! This message was sent from outside your organization. Listcat output changes when fields need more digits. DCollect doesn't change. On Tue, Nov 5, 2019 at 11:20 PM Mike Hochee <mike.hoc...@aspg.com> wrote: > > I was unaware of both DCOLLECT as well as the compression related fields on > the LISTCAT output. Thanks much to Mike and Kolusu. We can use the LISTCAT > info immediately and the DCOLLECT down the road apiece. Appreciate your > timely help! > > Mike > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: Tuesday, November 5, 2019 11:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: calculating data set size - compression concern > > Caution! This message was sent from outside your organization. > > 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 <mike.hoc...@aspg.com> 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 lists...@listserv.ua.edu 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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
