Re: “It's absurd that on a multi-million $ computer, a user expects to allocate a 100GB file that is for their private use. It would be different if multiple users were accessing that file. This file would be far cheaper on a $5,000 computer and provide the same functionality.”
Not absurd when open-source downloads to implement a POC to try out the product ***ON z/OS*** can easily take at least tens of GB , and adding up enough of those multi-GB files will easily get you to 100GB. Not to mention the make/compile/build “temporary” space needed. More GB’s for sure. Re: “… someone didn't talk to the z/OS storage admin”, some storage admins are not that easy to talk to. Some seem to have the mindset that giving out or acquiring more storage for expanded programmer use takes money directly out of their pockets. And that’s if the storage admins work for the same company as the programmer. If they are “hired hands” who work for a facilities management firm, you have to get your company to tell them this is work that should be done or you get ignored because it isn’t in the contract. Not every shop has cooperative denizens or sharp-enough contract negotiators. Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jon Perryman Sent: Friday, August 4, 2023 6:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Features > On Sunday, July 30, 2023 at 08:23:54 PM PDT, Andrew Rowley > <and...@blackhillsoftware.com<mailto:and...@blackhillsoftware.com>> wrote: >> Whatever. We use automount, and the "space" wasted is way too trivial to >> worry about. > If it's trivial, you're probably not using actually using it. Unix people don't understand trivial for z/OS. z/OS files are littered with unused space in each block and at the end of the file. This can be very significant. In many cases, we consider a lot of wasted space trivial. There are a lot of things we consider trivial that is considered wasteful to Unix mentality (e.g. redundancy). A Unix file will never waste more than 4K. > A low end laptop has 250GB available. How much space should a z/OS user > be able to use (to do their job) before they have to make a special > request to the storage management group? 10GB? 100GB? Typical Unix mindset is "me" instead of "business needs". This same problem will exist in a properly configured Unix system that has set disk quotas. Just because most do not implement disk quotas doesn't make it right. It's absurd that on a multi-million $ computer, a user expects to allocate a 100GB file that is for their private use. It would be different if multiple users were accessing that file. This file would be far cheaper on a $5,000 computer and provide the same functionality. > Some of my testing runs to (temporarily) 100GB+ for input and output >files. I run it on the PC because the space isn't available on the > mainframe, but It would be nice to be able to run it on z/OS. If you get > a few users with usage spikes to 100GB the space might not be so trivial. What possible business benefit is there to running on z/OS instead of a PC when you are the only user of this file? If multiple users want to do similar things at the same time, then it's time to consider some coordination. >> gil answered that one... if you really have a good reason to go poking >> around in users' business. > HSM recalls are the big problem with that. And authorized_keys is the > sort of question where auditors might require you to be poking around in > users' business. If HSM recalls are a problem, then someone didn't talk to the z/OS storage admin. He's the one who has the knowledge and tools to handle extreme situations. z/OS is about RAS (Reliability, Availability and Serviceability). Consider the same situation on Unix where RAS is not a concern. You fill up a filesystem and disrupt every user on that system. -- 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
