More fundamentally, why the MVS designers didn't steal VAM from TSS, including VIPAM, and why the didn't steal the idea of a Reverse Compatibility Interface (RCI) allowing ACB access to PS and PO.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List on behalf of Farley, Peter Sent: Wednesday, March 26, 2025 6:12 PM To: [email protected] Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!) External Message: Use Caution Well, ECKD wasn’t a mistake when DASD arm movement and rotation speed were MUCH slower and bit density so much lower than today’s devices. Minimizing arm movement back then gave us dramatically positive application speed improvements. I never did understand the IBM politics that provided native FBA DASD (3310 and 3370) support in VM and VSE but not in MVS, so I agree with your original request to "... implement a z/OS native filesystem that lives on a raw FBA storage device". Complex to do? Yes, of course. Worth the investment? I say yes, but I am not IBM. They may be too focused on a qubit future to really care about z/OS (except of course it is the cash cow today . . . ). Peter P.S. -- Question out of pure curiosity: Do available vendor or IBM DASD systems provide 3370 emulation? In larger than the original physical size? Or are VM and VSE shops forced to use ECKD and 3390-54 like z/OS must do? From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Pew, Curtis G Sent: Wednesday, March 26, 2025 5:25 PM To: [email protected] Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!) On Mar 26, 2025, at 3:53 PM, Paul Gilmartin <mailto:[email protected]> wrote: (Am I missing whimsical intent?) What programs, utilities, facilities would you expect to exploit such a filesystem? Doesn't zFS already emulate a raw FBA storage device? Embed a z/OS native filesystem there. I was actually thinking of beginning to wean z/OS off ECKD DASD. As things stand today, all storage is native FBA, but for z/OS the storage subsystem has to emulate the 3390 (or even 3380) architecture. Then the linear VSAM dataset container file for a zFS filesystem has to emulate FBA back again. My idea is to eliminate the layers of emulation. Things that can already exploit zFS would have no trouble exploiting this. Also, programs that use QSAM or BSAM can in many cases run just fine using Unix files instead of MVS datasets. IBM should make that even easier, and provide more ways for other things to exploit Unix directories and files, instead of depending on a 60 year old storage architecture that seems to clearly have been a mistake from the start. -- 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
