AGILE! Never complete Any design before you crash and burn with eons of speculation. Just been involved in a similar debacle. At least I'm paid by the hour. Once more to the drawing board. We can share the crayons!
On Sat, May 16, 2020, 05:26 Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > As promised, I can now give you the reason my co-worker needs to get file > size information, since it is not particularly proprietary but just part of > a generic application design. Not commenting here (or seeking any comments > either! No flames please!) on whether it is a good or a bad design, just > relaying the general story to you. > > I was wrong in my statement that it was a batch COBOL need. My co-worker > told me today that the requirement is for a CICS COBOL program to pass the > file size for a dynamically configurable file name in a communications area > to a generalized CICS subroutine (written and maintained by another team) > that will send the file to a non-z/OS system. > > Apparently the contents and size of the files to be sent can change > independently of CICS activity during the business day. They are VSAM > files with fixed-length records, so if SHOWCB information can be > interrogated in CICS (possibly on an Open TCB) they should be able to > calculate a reasonably accurate file size from that info. > > Why the generalized send subroutine needs or wants file size information > is not in my co-worker's control. He was just told that it is a required > field in the communications area. I strongly suspect that any more detail > than that will be of a proprietary nature and thus not possible to discuss > publicly. > > Thanks again for all your comments and suggestions. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Farley, Peter x23353 > Sent: Thursday, May 14, 2020 4:41 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? > > EXTERNAL EMAIL > > Gentle listers, it's not that big a deal. As to why my co-worker wants > that information or what they think they need to do with it, I do not know > nor did I think to ask, as it was just phrased as "can I get this > information from a batch COBOL program?". And I did not have the luxury of > time to delve further into the subject as I have my own urgent priorities > to deal with. > > As to the intended use of the information, if my co-worker is permitted to > share that with me I'll share it here. > > In the meantime, my original question is answered: There is no easily > callable API (bar LISTDSI from Rexx, FSVO "easy") available to provide that > information for such files, as I surmised based on my own experience and as > I initially replied to my co-worker. > > Thank you. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Paul Gilmartin > Sent: Thursday, May 14, 2020 3:29 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? > > On Thu, 14 May 2020 18:52:09 +0000, Gerhard adam wrote: > > > > It is easy to say that a COBOL program needs to “know” this but it > is nonsense since there is nothing a COBOL program can do with this info. > > > It could print it in a report. > > I suspect cultural familiarity, the complement of a presentation I > attended circa 1980 where IBM was selling a then-innovative online > service. The presenter said the base subscription entitled the customer to > one megabyte of storage. Question from the > audience: > "How much is that in cylinders?" > > Of course, it depends. 1.75 cylinders. Someone with a different > background might have been familiar with 1.36 floppy disks. > > >If it turns out to really be necessary then a subroutine can be written > >(as it has been done for decades) to provide this information. If the > >question is simply to bitch about why z/OS does do this automatically > >via a call or something then the complaint is directed to the wrong > >group > > > Keep your data in zFS. Then "ls -l" gives the answer immediately. > > How readily can COBOL access zFS files. BPXWDYN should make it routine. > > -- > > 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 > > 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
