Here's the clarification from IBM... (the field being referred to is UDATASIZ, which is where the restriction statement popped up)...
"Unfortunately that field is only valid for extended format VSAM and non-VSAM data sets, as it is maintained in the extended format cell. It was introduced primarily to be able to compare the compressed and uncompressed sizes of a compressed format data set. It probably would be beneficial to maintain this type of number for all data sets. However, it might be difficult to maintain accurately for sequential non-extended format data sets and we would also need to find a place to store it. In any case, hope this helps for now." HTH, Mike -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Sunday, May 17, 2020 2:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Caution! This message was sent from outside your organization. Thanks Mike. If CSI is in fact a potential solution I can pass that on. Meantime I will try to find out if the VSAM file being sent is already extended format or not. I have the impression from my co-worker that the record volume isn't sufficient to warrant extended format under current storage administration rules, but if extended format solves the requirement to determine file size it might be an acceptable exception to the storage admin rules. Please let us know if/when you get an answer. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Mike Hochee Sent: Saturday, May 16, 2020 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It does seem implausible, but who knows. It is all in the parsing and for now we can only really be sure that it means what it means. Therefore I emailed the DFSMS architect I spoke with and requested clarification. I will share when/if she responds. HTH, Mike -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, May 16, 2020 10:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Extended format (VSAM and non-VSAM) Or (Extended format VSAM) and (non-VSAM) ? The former is redundant or overly wordy: why not just say "extended format datasets"? The latter, OTOH, seems implausible to me. Why would they do all non-VSAM but only extended format VSAM? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Saturday, May 16, 2020 6:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? How do you parse "Restriction: This field is only valid for extended format VSAM and non-VSAM data sets."? Does that mean extended format VSAM and any format non-VSAM, or extended format VSAM extended format non-VSAM? ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Mike Hochee [mike.hoc...@aspg.com] Sent: Saturday, May 16, 2020 1:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Hi Peter, I came across a similar use case a couple times over the past year or so. Shifting priorities have prevented me from doing much with it, but while at the most recent SHARE in Fort Worth, I asked one of the DFSMS architects about it. She encouraged me to check out the CSI, specifically, fields UDATASIZ and COMUDSIZ. They appeared to satisfy my use case, although as others have mentioned there are a few restrictions especially for UDATASIZ. HTH, Mike -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Thursday, May 14, 2020 11:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Caution! This message was sent from outside your organization. This question came to me from a co-worker: Is there any API to get the byte file size of a non-VSAM, non-zFS, non-database file in z/OS? I.E., byte file size for plain sequential files? I am aware of the "old way" of reading the VTOC of a volume to get the various DSCB's that total up disk extents, but that gets complicated quickly for multi-volume files, and was never guaranteed to be accurate as to the actual byte count of data in the file except in the RECFM=FS/FBS case anyway. There is always the performance-killing option of just reading the whole file and totaling up the length of every record (or block depending on how you structure the reads), but no one would call that an API. As far as I know there is no such API in z/OS, and this is what I told my co-worker, but am I wrong? Is there an alternative of which I am not aware? TIA for your input. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
