> On Friday, August 4, 2023 at 04:00:19 PM PDT, Farley, Peter wrote:
> 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.
It's absurd to allow everyone to do Proof Of Concept on z/OS. Are all POC vital
to the business? Are POCs disruptive to the business? "me" mentality ignores
the impact on everyone else. In this case, you're saying the storage admin is
not impacted when clearly that's not the case.
On Friday, August 4, 2023 at 04:00:19 PM PDT, Farley, Peter
<[email protected]> wrote:
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 <[email protected]> On Behalf Of Jon
Perryman
Sent: Friday, August 4, 2023 6:30 PM
To: [email protected]
Subject: Re: USS Features
> On Sunday, July 30, 2023 at 08:23:54 PM PDT, Andrew Rowley
> <[email protected]<mailto:[email protected]>> 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 [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
