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
