I think I have seen it work for DSNTYPE=LARGE instead of extended format. Aren't CA Datacom files bdam? I say that because.. last time i interacted with Datacom it was only able to use DSNTYPE=LARGE.
Rob Schramm On Thu, Oct 25, 2018, 11:18 PM Farley, Peter x23353 < [email protected]> wrote: > My personal experience converting two old BDAM-based systems in the past > (one for an ISV product, one for a user application), is that converting to > use RRDS is relatively easy (SMOP), gives you much better control of error > conditions, and performs as well or better even in extreme conditions if > you make intelligent use of BLSR or SMB to use local caching of buffers. > Memory is (relatively) cheap, so make the most use of it that you can. > > And RRDS can be both extended (> 4Gb file size) and compressed saving much > disk space, but YMMV depending on the volume of I/O you need to sustain. > Compression isn't free, though it seems to be quite inexpensive (in CPU > time) these days, at least on relatively current hardware. > > And RRDS is supported in z/VSE as well, making the code more portable if > you need that option. > > HTH > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Frank M. Ramaekers > Sent: Wednesday, October 24, 2018 2:22 PM > To: [email protected] > Subject: z/OS BDAM question > > EXTERNAL EMAIL > > I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT > want to know if BDAM can be larger than 65535 tracks. Is this limitation > per extent or entire file size. > > From the z/VSE LISTSERV: > I believe it is 65K tracks per extent with a maximum of 255 extents for > BDAM, but I can't find any doc to verify that right now. > > -- > > > 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
