Re: USS Features
> Andrew Rowley wrote: > It's not cents per GB cheap While I agree with everything you're saying, at the end of the day it's the storage sysprog's decision. As with any z/OS sysprog, they make decisions that programmers feel are abusive. People are arguing about passion. If this were a manager or a CEO's decision, would you argue the point with them? Right or wrong, we live with their decisions. Just because sysprogs aren't managers, doesn't mean that they shouldn't be considered the authority without the necessity of arguing every detail. If you came into a company as storage sysprog, would you on day 1 satisfy all storage requests on your new desk? My point is that you can't possibly assume that everything from you last employer is the same as your new employer. If after 10 days, you must take the disk space back, those people will be more angry than if you just denied their requests. On Tuesday, August 15, 2023 at 05:20:47 PM PDT, Andrew Rowley wrote: On 16/08/2023 6:17 am, Jon Perryman wrote: > This is absurd. Not all disk is cheap (e.g. GDPS). Not all data is valuable. > While a person may be expensive, not everything they do is of value to the > business and worth the hidden expenses. It's not cents per GB PC cheap, but it's not 1990s expensive either. If you have a meeting with a couple of people, schedule a change, get it approved, implement it... you could easily spend $1000 of people's time, not to mention add weeks to a project. How much disk space would that buy you, if you can avoid that cost and delay? The IBM RDP systems charge $10/month for 5GB of disk space, which seems expensive. But still, $1000 of meetings avoided will pay for 40GB of space for a year. What is the (ballpark) cost per GB on a real customer system? How much space is it worth to reduce the time spent managing it? > You can't be serious about being a storage admin. Every situation and company > are different. Questions must be asked. How do you not understand adding > 100GB to a filesystem has an impact on GDPS, HSM, backups, recovery and much > more. If you believe, everything is created equal, 100GB has the same impact > on a 10GB or 10TB filesystem. A file system may contain millions of Unix > files but its 1 MVS dataset. Recovery of a filesystem is risky at the best of > times but add 100GB increases the risks and may impact the nightly archival > time (1 Unix file change causes HSM to backup the entire filesystem). If as > you say, data is valuable, then the UNIX backup would be used. I could go on > but I expect this should be obvious. Whole filesystem backups are not very useful - really just a DR tool. What do you do if a user wants file(s) restored? Restore all their files from a point in time? Or restore the filesystem, mount it somewhere and manually copy files? The whole filesystem backup takes us back to the problems with individual filesystems. You are going to back up a user's whole filesystem, including all the freespace from the largest file they ever deleted, because they logged on and updated .sh_history? Or worse - can the filesystem change indicator tell the difference between a data update and a metadata (e.g. last accessed date) change? I'm not saying everything is equal, I'm just saying that freespace is a lot cheaper than managing a lack of freespace. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 16/08/2023 6:17 am, Jon Perryman wrote: This is absurd. Not all disk is cheap (e.g. GDPS). Not all data is valuable. While a person may be expensive, not everything they do is of value to the business and worth the hidden expenses. It's not cents per GB PC cheap, but it's not 1990s expensive either. If you have a meeting with a couple of people, schedule a change, get it approved, implement it... you could easily spend $1000 of people's time, not to mention add weeks to a project. How much disk space would that buy you, if you can avoid that cost and delay? The IBM RDP systems charge $10/month for 5GB of disk space, which seems expensive. But still, $1000 of meetings avoided will pay for 40GB of space for a year. What is the (ballpark) cost per GB on a real customer system? How much space is it worth to reduce the time spent managing it? You can't be serious about being a storage admin. Every situation and company are different. Questions must be asked. How do you not understand adding 100GB to a filesystem has an impact on GDPS, HSM, backups, recovery and much more. If you believe, everything is created equal, 100GB has the same impact on a 10GB or 10TB filesystem. A file system may contain millions of Unix files but its 1 MVS dataset. Recovery of a filesystem is risky at the best of times but add 100GB increases the risks and may impact the nightly archival time (1 Unix file change causes HSM to backup the entire filesystem). If as you say, data is valuable, then the UNIX backup would be used. I could go on but I expect this should be obvious. Whole filesystem backups are not very useful - really just a DR tool. What do you do if a user wants file(s) restored? Restore all their files from a point in time? Or restore the filesystem, mount it somewhere and manually copy files? The whole filesystem backup takes us back to the problems with individual filesystems. You are going to back up a user's whole filesystem, including all the freespace from the largest file they ever deleted, because they logged on and updated .sh_history? Or worse - can the filesystem change indicator tell the difference between a data update and a metadata (e.g. last accessed date) change? I'm not saying everything is equal, I'm just saying that freespace is a lot cheaper than managing a lack of freespace. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
HSM has been able to back up at the file level (and recover, of course) rather than an entire ZFS data set for some time now. On Tue, 15 Aug 2023 at 21:17, Jon Perryman wrote: > Andrew Rowley wrote: > > > Disk space is cheap. Data is valuable. People are expensive. > > > This is absurd. Not all disk is cheap (e.g. GDPS). Not all data is > valuable. While a person may be expensive, not everything they do is of > value to the business and worth the hidden expenses. > > > I started on MVS in 1991, so it's a bit late to tell me that. > > I've *been* the storage admin. > > You can't be serious about being a storage admin. Every situation and > company are different. Questions must be asked. How do you not understand > adding 100GB to a filesystem has an impact on GDPS, HSM, backups, recovery > and much more. If you believe, everything is created equal, 100GB has the > same impact on a 10GB or 10TB filesystem. A file system may contain > millions of Unix files but its 1 MVS dataset. Recovery of a filesystem is > risky at the best of times but add 100GB increases the risks and may impact > the nightly archival time (1 Unix file change causes HSM to backup the > entire filesystem). If as you say, data is valuable, then the UNIX backup > would be used. I could go on but I expect this should be obvious. > On Tuesday, August 15, 2023 at 03:40:26 AM PDT, Andrew Rowley < > and...@blackhillsoftware.com> wrote: > > On 15/08/2023 10:09 am, Jon Perryman wrote: > > This is z/OS with SYSPROGS, not Unix with sysadmins where programmers > have full control to define reasonable. You keep asking the wrong question. > Who (not what) determines reasonable. Right or wrong, it is their job, not > yours. If you can't give up control of sysprog duties, then z/OS is not the > OS for you. > > I started on MVS in 1991, so it's a bit late to tell me that. I've > *been* the storage admin. > > Without evidence to the contrary, its a good idea to assume the fact > that your colleagues are being paid means that they are doing work > valuable to the business, and it's not the storage admin's job to veto > it because it requires too much DASD space. > > Its the storage admin's job to make sure that other people are not > prevented from doing their work due to a lack of disk space. It's one of > those jobs where the better you do, the less people know you're there. > > Disk space is cheap. Data is valuable. People are expensive. Don't waste > expensive people time managing empty space. Spend your time looking > after the valuable data, and have enough free space that people don't > need to stop what they are doing and set up a meeting with the storage > admin group. > > -- > Andrew Rowley > Black Hill Software > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
I agree with Seymour that system z is not the same as PC but disagree that the problem is curiosity. The problem is with students not questioning what they are being taught. > Steve Thompson wrote: > How about the prestigious Schools telling their students that > COBOL is a dead or dying language? And indicating that Mainframes > are obsolete and not keeping up with technology? Those that can, do. Those that can't, teach. These teachers are afflicted with motivated reasoning. It's obvious these teachers are not making an informed statements about system z and z/OS. z/OS concepts continue to be implemented in Unix but go unnoticed (e.g. Google's equivalent to VSAM KSDS because database is overkill. How is it this did not make it into Unix file programming? Unix files have not changed in 40 years, yet z/OS files continue to evolve without impacting programmers. Maybe Cobol is dying, but they ignore why it may be important. Do accounting programmers need something far more complicated? Should Cobol programmers be encouraged to understand BTREE when they shouldn't use it on z/OS? How about all those other API's we use in Unix but are irrelevant in z/OS. On Tuesday, August 15, 2023 at 02:22:58 AM PDT, Seymour J Metz wrote: It's not a mainframe vs PC thing or a work place versus Academia thing, it's a general lack of curiousity and initiative. Lot's of people can't be bothered to learn anything that they can avoid learning. I have to partially disagree on theory: I believe that the failure to teach basic theory has caused a lot of problems. That said, I also believe that students should be exposed to several radically different languages along with the theory, but that it is misguided to concentrate on the language du jour. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Monday, August 14, 2023 4:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Features "Is it a non-west-coast specific mentality to ignore reality? Is COBOL bringing in top computer professionals because of the challenges it poses? " How about the prestigious Schools telling their students that COBOL is a dead or dying language? And indicating that Mainframes are obsolete and not keeping up with technology? I have relatives that have retired from a university (in the USofA) and one of them worked with Grad Students to help them get the computer lab time they needed, while also helping them get the resources they needed for any experiments and the like they needed to do involving IT. I also have a relative that retired in Germany from a school there, who had been teaching English to students from India. We won't get started on this, but I'm not making this stuff up. And they knew that I worked on mainframes. But when I told them that the language you say is dead is also an OO Language now. I told them about a few Standards put out for COBOL. They were astonished. Now granted, I know more about COBOL's pseudo OO abilities than I did back then. But that school got rid of their mainframe decades ago. And they had NO idea that the current IBM mainframes could run Java, c/C++, etc. They had no idea that the majority of their credit card transactions were being handled by a mainframe somewhere. They didn't know how many Banks, financial entities, Airlines, etc. ran their biz using obsolete mainframes making millions of obsolete dollars doing it. It is my opinion that the universities seem to be in their own Echo Chamber. And then to add insult to injury, they weren't (at that time) teaching any computer languages, they only taught theory. Say What!?! Yes, they only teach theory. So students have to learn a language on their own to get employed in IT. This is one of the top schools in the country. Not at Harvard's level, but something around Stanford's Level (speaking of Standford, they are the ones that destroyed the source for Wylbur when they migrated it to a non-mainframe environment). Then, I learned that several people from India that I had been working with had degrees, said that the school they went to in India only taught theory, they didn't teach any languages either!! It was no wonder that because I took care of the tool for getting compiles done, that they were using me for a help desk so I couldn't concentrate on things I needed to get done. The "compiler" had thrown an ABEND and I needed to fix it. The "compiler" was the utility for generating JCL to do their compiles. So it knew how to put together all the translators (CICS, DB2, IDMS, ProCOBOL, and all the linkedit stuff and DB2 BIND. The ABEND was the step after LINKEDIT which had failed with a non-zero CC. We had to put in these ABEND steps because they didn't bother to check if everything had worked before they
Re: USS Features
Andrew Rowley wrote: > Disk space is cheap. Data is valuable. People are expensive. This is absurd. Not all disk is cheap (e.g. GDPS). Not all data is valuable. While a person may be expensive, not everything they do is of value to the business and worth the hidden expenses. > I started on MVS in 1991, so it's a bit late to tell me that. > I've *been* the storage admin. You can't be serious about being a storage admin. Every situation and company are different. Questions must be asked. How do you not understand adding 100GB to a filesystem has an impact on GDPS, HSM, backups, recovery and much more. If you believe, everything is created equal, 100GB has the same impact on a 10GB or 10TB filesystem. A file system may contain millions of Unix files but its 1 MVS dataset. Recovery of a filesystem is risky at the best of times but add 100GB increases the risks and may impact the nightly archival time (1 Unix file change causes HSM to backup the entire filesystem). If as you say, data is valuable, then the UNIX backup would be used. I could go on but I expect this should be obvious. On Tuesday, August 15, 2023 at 03:40:26 AM PDT, Andrew Rowley wrote: On 15/08/2023 10:09 am, Jon Perryman wrote: > This is z/OS with SYSPROGS, not Unix with sysadmins where programmers have > full control to define reasonable. You keep asking the wrong question. Who > (not what) determines reasonable. Right or wrong, it is their job, not yours. > If you can't give up control of sysprog duties, then z/OS is not the OS for > you. I started on MVS in 1991, so it's a bit late to tell me that. I've *been* the storage admin. Without evidence to the contrary, its a good idea to assume the fact that your colleagues are being paid means that they are doing work valuable to the business, and it's not the storage admin's job to veto it because it requires too much DASD space. Its the storage admin's job to make sure that other people are not prevented from doing their work due to a lack of disk space. It's one of those jobs where the better you do, the less people know you're there. Disk space is cheap. Data is valuable. People are expensive. Don't waste expensive people time managing empty space. Spend your time looking after the valuable data, and have enough free space that people don't need to stop what they are doing and set up a meeting with the storage admin group. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 15/08/2023 10:09 am, Jon Perryman wrote: This is z/OS with SYSPROGS, not Unix with sysadmins where programmers have full control to define reasonable. You keep asking the wrong question. Who (not what) determines reasonable. Right or wrong, it is their job, not yours. If you can't give up control of sysprog duties, then z/OS is not the OS for you. I started on MVS in 1991, so it's a bit late to tell me that. I've *been* the storage admin. Without evidence to the contrary, its a good idea to assume the fact that your colleagues are being paid means that they are doing work valuable to the business, and it's not the storage admin's job to veto it because it requires too much DASD space. Its the storage admin's job to make sure that other people are not prevented from doing their work due to a lack of disk space. It's one of those jobs where the better you do, the less people know you're there. Disk space is cheap. Data is valuable. People are expensive. Don't waste expensive people time managing empty space. Spend your time looking after the valuable data, and have enough free space that people don't need to stop what they are doing and set up a meeting with the storage admin group. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
It's not a mainframe vs PC thing or a work place versus Academia thing, it's a general lack of curiousity and initiative. Lot's of people can't be bothered to learn anything that they can avoid learning. I have to partially disagree on theory: I believe that the failure to teach basic theory has caused a lot of problems. That said, I also believe that students should be exposed to several radically different languages along with the theory, but that it is misguided to concentrate on the language du jour. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Monday, August 14, 2023 4:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Features "Is it a non-west-coast specific mentality to ignore reality? Is COBOL bringing in top computer professionals because of the challenges it poses? " How about the prestigious Schools telling their students that COBOL is a dead or dying language? And indicating that Mainframes are obsolete and not keeping up with technology? I have relatives that have retired from a university (in the USofA) and one of them worked with Grad Students to help them get the computer lab time they needed, while also helping them get the resources they needed for any experiments and the like they needed to do involving IT. I also have a relative that retired in Germany from a school there, who had been teaching English to students from India. We won't get started on this, but I'm not making this stuff up. And they knew that I worked on mainframes. But when I told them that the language you say is dead is also an OO Language now. I told them about a few Standards put out for COBOL. They were astonished. Now granted, I know more about COBOL's pseudo OO abilities than I did back then. But that school got rid of their mainframe decades ago. And they had NO idea that the current IBM mainframes could run Java, c/C++, etc. They had no idea that the majority of their credit card transactions were being handled by a mainframe somewhere. They didn't know how many Banks, financial entities, Airlines, etc. ran their biz using obsolete mainframes making millions of obsolete dollars doing it. It is my opinion that the universities seem to be in their own Echo Chamber. And then to add insult to injury, they weren't (at that time) teaching any computer languages, they only taught theory. Say What!?! Yes, they only teach theory. So students have to learn a language on their own to get employed in IT. This is one of the top schools in the country. Not at Harvard's level, but something around Stanford's Level (speaking of Standford, they are the ones that destroyed the source for Wylbur when they migrated it to a non-mainframe environment). Then, I learned that several people from India that I had been working with had degrees, said that the school they went to in India only taught theory, they didn't teach any languages either!! It was no wonder that because I took care of the tool for getting compiles done, that they were using me for a help desk so I couldn't concentrate on things I needed to get done. The "compiler" had thrown an ABEND and I needed to fix it. The "compiler" was the utility for generating JCL to do their compiles. So it knew how to put together all the translators (CICS, DB2, IDMS, ProCOBOL, and all the linkedit stuff and DB2 BIND. The ABEND was the step after LINKEDIT which had failed with a non-zero CC. We had to put in these ABEND steps because they didn't bother to check if everything had worked before they'd run|reran their JOB to test the program. This is the level of people with degrees and a visa we are getting. That's my experience at one large insurance company. And you wonder about the recruiters that are also here with visas? Management wants to go cheap. They get what they pay for. Steve Thompson ps. Mainframes had color monitors in the mid-70s. Management didn't want to pay for them. Today mainframe is called Green screen. We had color before the PCs did. Just think about that. On 8/14/2023 3:41 PM, Jon Perryman wrote: > > On Monday, August 14, 2023 at 03:09:33 AM PDT, David Spiegel wrote: >> You said: "...Programmers leave z/OS for Unix in order to be in full control. >> I have not once heard any programmer leave for more control. >> Could this be a west-coast specific mentality? ... It would not be >> surprising. > Is it a non-west-coast specific mentality to ignore reality? Is cobol > bringing in top computer professionals because of the challenges it poses? > Who was it that convinced companies to switch from MVS to Unix because it is > superior? Do you consider Unix files superior when they haven't changed since > they were first conceived? Programmers flee to Unix because it offers r
Re: USS Features
> On Monday, August 14, 2023 at 04:18:31 PM PDT, Grant Taylor wrote: > How did the business learn that Kubernettes could meet business needs, > much less decide that is what the business wanted to do without first > testing / evaluating it? > That initial testing of Kubernettes is the very type of testing that I'm > talking about. In the IBM world, we don't look for solutions that don't have a problem. So you believe some random person should decide to look at a product and then find a problem that it can solve. Kubernettes proves why allowing random people is a waste of time and money. Businesses work from top down and the results will be ignored because it's not a priority. 2 man-weeks ($3,000) and z/OS ($5,000) with no benefit. Unix programmers have API's for everything. z/OS has hidden API's and concepts that the random programmer doesn't understand. They don't understand the important impact of a 200 CPU z machine and how Kubernettes can play an important role. They don't understand the role of multi-platforms. They may learn the container concept but won't understand the role that makes it important. They don't understand that they could have tested on an inexpensive PC. z/OS is about what the average person does not see. For example, why is JCL important? Why is JES2 important? Why is VSAM important? Unix programmers are dealing with simple OS concepts that do very little. Ask yourself, over the last 30 years, what has changed in reading / writing a simple file and how many pages are needed for documentation. z/OS is now up to 50 manuals yet the concepts for the average programmer has changed very little. On Monday, August 14, 2023 at 04:18:31 PM PDT, Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: On 8/14/23 4:30 PM, Jon Perryman wrote: > We don't ask people to follow blindly. Instead, we don't give them > another option. JCL, VSAM, availability to specific products and more > ensure you are choosing wisely. Kurbernettes containers, cloud and more > are implemented by sysprogs in a manner that meets the business needs. How did the business learn that Kubernettes could meet business needs, much less decide that is what the business wanted to do without first testing / evaluating it? That initial testing of Kubernettes is the very type of testing that I'm talking about. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> On Monday, August 14, 2023 at 03:36:47 PM PDT, Andrew Rowley > wrote: > where the storage admin has to be involved, but what is a reasonable value? This is z/OS with SYSPROGS, not Unix with sysadmins where programmers have full control to define reasonable. You keep asking the wrong question. Who (not what) determines reasonable. Right or wrong, it is their job, not yours. If you can't give up control of sysprog duties, then z/OS is not the OS for you. On Monday, August 14, 2023 at 03:36:47 PM PDT, Andrew Rowley wrote: On 14/08/2023 3:30 pm, Jon Perryman wrote: > > On Monday, August 7, 2023 at 04:33:24 PM PDT, Andrew Rowley > wrote: >> It comes back to the question I asked earlier - how much space is it >> reasonable to use *to do your job* before you have to get the storage >> admin involved? > Since you put it that way, I've got to say are you insane. The storage admin > based his decision on things called facts. He is responsible for storage and > his decision is final until his management tells him otherwise. I suggest you > inform your company CEO that all decisions must go through you. That was a question, not a decision. We all use space on the system, whether it be personal JCL libraries, sort work space, job output etc. If your manager says "Can you investigate this CICS problem from yesterday" and you want to analyze the SMF data, at what point do you need to ask the storage admin for space for sort work, data files etc? 100MB? 1GB? 100GB? I recognize that there has to be a limit where the storage admin has to be involved, but what is a reasonable value? Should it be different for a unix temporary file than for a sort work dataset? Maybe I decide the best way to investigate this problem is to generate JSON from the data and load it into Splunk. Is the disk space available? Or should I just download the CICS SMF data to the PC and process it there? Spool space, sort work space, user datasets - that space all comes from pools and when you delete the data the space is returned for use by other users. For some reason we set up a system for unix files where free space isn't automatically returned, and cannot be used by other users. This makes things unnecessarily difficult on the mainframe. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 8/14/23 4:30 PM, Jon Perryman wrote: We don't ask people to follow blindly. Instead, we don't give them another option. JCL, VSAM, availability to specific products and more ensure you are choosing wisely. Kurbernettes containers, cloud and more are implemented by sysprogs in a manner that meets the business needs. How did the business learn that Kubernettes could meet business needs, much less decide that is what the business wanted to do without first testing / evaluating it? That initial testing of Kubernettes is the very type of testing that I'm talking about. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 14/08/2023 3:30 pm, Jon Perryman wrote: > On Monday, August 7, 2023 at 04:33:24 PM PDT, Andrew Rowley wrote: It comes back to the question I asked earlier - how much space is it reasonable to use *to do your job* before you have to get the storage admin involved? Since you put it that way, I've got to say are you insane. The storage admin based his decision on things called facts. He is responsible for storage and his decision is final until his management tells him otherwise. I suggest you inform your company CEO that all decisions must go through you. That was a question, not a decision. We all use space on the system, whether it be personal JCL libraries, sort work space, job output etc. If your manager says "Can you investigate this CICS problem from yesterday" and you want to analyze the SMF data, at what point do you need to ask the storage admin for space for sort work, data files etc? 100MB? 1GB? 100GB? I recognize that there has to be a limit where the storage admin has to be involved, but what is a reasonable value? Should it be different for a unix temporary file than for a sort work dataset? Maybe I decide the best way to investigate this problem is to generate JSON from the data and load it into Splunk. Is the disk space available? Or should I just download the CICS SMF data to the PC and process it there? Spool space, sort work space, user datasets - that space all comes from pools and when you delete the data the space is returned for use by other users. For some reason we set up a system for unix files where free space isn't automatically returned, and cannot be used by other users. This makes things unnecessarily difficult on the mainframe. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
, I had boss or two in my first thirty years (not all by any means) who would occasionally say "Now, Bob, I want you to do this task, but I don't want you to write a program to do it - just do it". From this you would be justified in surmising that I like programming, and often write something to make the task go faster next time. When that happened I sometimes just did it, but other times I'd take a little extra time and figure out how to code it, maybe on my own time and maybe not. To some extent it is to this kind of calculated disobedience that I attribute what I am today, working for clients who ~value~ the tools I create for myself and others. I don't blame those old bosses for not being sure of the benefit. But I don't try too hard to feel guilty for making up my own mind about it, either. Nowadays I'm better off. When a PM said that to me a few years ago, I was in a position to tell him "With respect, I won't delegate that decision to you. You folks hired me to do the best job for you. This is my expertise; I'll decide whether it's better to write a utility for this or Just Do It." He and I fought a lot, but we respected each other too and we got a ton of work done for the client during that tumultuous time. Mostly, as you say, bosses ~like~ it when you expand your abilities. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* See everything. Overlook a great deal. Improve a little. -Pope John XXIII */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Monday, August 14, 2023 17:30 yearly performance review when they discuss advancement? Every manager I had discusses personal and job growth which included at least 1 self-improvement item. Do you feel the need to go behind their backs when there is something that you want to learn? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> On Monday, August 14, 2023 at 06:34:35 AM PDT, Grant Taylor wrote: >> On 8/14/23 12:54 AM, Jon Perryman wrote: >> You're confusing z/OS with Unix where all programmers are >> systems programmers who can do anything they want. > No, I'm not confusing z/OS with Unix. > I'm speaking agnosticly about any OS that will run on the platform; > z/OS, VM, z/TPF, or even Linux. Of course you are confusing z/OS mentality with UNIX mentality. Based on your expectations of z/OS, you come from the Unix world. In z/OS, we expect accounting programmers to expand their knowledge about accounting instead learning to make their programs perform better. There are sysprogs who monitor and solve performance problems. If you want more control over your life, then become a z/OS sysprog. > What is better for the business, discouraging people from learning Do you sleep during your yearly performance review when they discuss advancement? Every manager I had discusses personal and job growth which included at least 1 self-improvement item. Do you feel the need to go behind their backs when there is something that you want to learn? How much control do you need? > If anything the cost of the system implies that it will be more > difficult for newcomers to gain access to the platform to learn. What difficulty for a newcomer are you talking about? IBM has a free learning platform that is available for newcomers. If a newcomer is hired, then the company has a learning plan in place > What gives you the impression that any and all things to be investigated > don't go through the change approval board and don't have managerial support. Are you saying they were told you needed 100GB but they simply forgot to approve that as part of the request? > My experience is that these older DR systems gain some additional value > to the business if they are /also/ used to host sandbox VMs / LPARs. Are you saying that as a programmer, you were trained on the implications of using these DR systems? There are monthly hardware, software, personnel and facilities costs which is different for everyone. How is it that as a programmer, you know all about it? >> Programmers leave z/OS for Unix in order to be in full control. > I've never heard that before. > I question the veracity of the idea that everything is about control. How long are you willing to be a cobol programmer? If you never heard that, then you must have your head buried in the sand because it comes up every couple of years. >> Why do you think it's difficult to get z/OS programmers. > Would you rather have someone that blindly follows directions We don't ask people to follow blindly. Instead, we don't give them another option. JCL, VSAM, availability to specific products and more ensure you are choosing wisely. Kurbernettes containers, cloud and more are implemented by sysprogs in a manner that meets the business needs. > I can't think of a single instance that providing a test / sandbox / lab > instance has been a net negative. Are you a sysprog? You're not thinking hard enough. Are you dealing with a service provider or are you a service provider? Are you using provisioning or some other pricing schedule? You have to look for negatives to find them. > If you believe that proof of concepts are not necessary, I never made that claim. I do however question the wisdom of letting everyone do proof of concept for anything they desire. > Nothing about a what I'm advocating for negates, sidesteps, or > usurps change control or approval process. Stop using motivated reasoning. The storage admin gives you 100 bytes of storage but you want 100GB. You don't think his limit should apply to you and therefore don't consider this part of the approval process. You directly want to usurp the approval process otherwise we wouldn't be discussing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
Jon, maybe you didn't mean to but this is a bait-and-switch. You baited them with "...for more control". When Mr Spiegel questioned that and asked for specifics, you offered something else entirely: Unix is more challenging, and there was a claim that it's superior. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Realism demands that we face the good along with the bad. In spite of all reductionist theories of human motives, we heartily love mercy, gallantry, beauty, heroism and nobility. -Joseph Sobran, 1998 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Monday, August 14, 2023 15:42 Is cobol bringing in top computer professionals because of the challenges it poses? Who was it that convinced companies to switch from MVS to Unix because it is superior? Do you consider Unix files superior when they haven't changed since they were first conceived? Programmers flee to Unix because it offers real computer challenges instead of z/OS forcing them to focus on the business. > --- On Monday, August 14, 2023 at 03:09:33 AM PDT, David Spiegel wrote: > You said: "...Programmers leave z/OS for Unix in order to be in full > control. I have not once heard any programmer leave for more control. > Could this be a west-coast specific mentality? ... It would not be surprising. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
"Is it a non-west-coast specific mentality to ignore reality? Is COBOL bringing in top computer professionals because of the challenges it poses? " How about the prestigious Schools telling their students that COBOL is a dead or dying language? And indicating that Mainframes are obsolete and not keeping up with technology? I have relatives that have retired from a university (in the USofA) and one of them worked with Grad Students to help them get the computer lab time they needed, while also helping them get the resources they needed for any experiments and the like they needed to do involving IT. I also have a relative that retired in Germany from a school there, who had been teaching English to students from India. We won't get started on this, but I'm not making this stuff up. And they knew that I worked on mainframes. But when I told them that the language you say is dead is also an OO Language now. I told them about a few Standards put out for COBOL. They were astonished. Now granted, I know more about COBOL's pseudo OO abilities than I did back then. But that school got rid of their mainframe decades ago. And they had NO idea that the current IBM mainframes could run Java, c/C++, etc. They had no idea that the majority of their credit card transactions were being handled by a mainframe somewhere. They didn't know how many Banks, financial entities, Airlines, etc. ran their biz using obsolete mainframes making millions of obsolete dollars doing it. It is my opinion that the universities seem to be in their own Echo Chamber. And then to add insult to injury, they weren't (at that time) teaching any computer languages, they only taught theory. Say What!?! Yes, they only teach theory. So students have to learn a language on their own to get employed in IT. This is one of the top schools in the country. Not at Harvard's level, but something around Stanford's Level (speaking of Standford, they are the ones that destroyed the source for Wylbur when they migrated it to a non-mainframe environment). Then, I learned that several people from India that I had been working with had degrees, said that the school they went to in India only taught theory, they didn't teach any languages either!! It was no wonder that because I took care of the tool for getting compiles done, that they were using me for a help desk so I couldn't concentrate on things I needed to get done. The "compiler" had thrown an ABEND and I needed to fix it. The "compiler" was the utility for generating JCL to do their compiles. So it knew how to put together all the translators (CICS, DB2, IDMS, ProCOBOL, and all the linkedit stuff and DB2 BIND. The ABEND was the step after LINKEDIT which had failed with a non-zero CC. We had to put in these ABEND steps because they didn't bother to check if everything had worked before they'd run|reran their JOB to test the program. This is the level of people with degrees and a visa we are getting. That's my experience at one large insurance company. And you wonder about the recruiters that are also here with visas? Management wants to go cheap. They get what they pay for. Steve Thompson ps. Mainframes had color monitors in the mid-70s. Management didn't want to pay for them. Today mainframe is called Green screen. We had color before the PCs did. Just think about that. On 8/14/2023 3:41 PM, Jon Perryman wrote: > On Monday, August 14, 2023 at 03:09:33 AM PDT, David Spiegel wrote: You said: "...Programmers leave z/OS for Unix in order to be in full control. I have not once heard any programmer leave for more control. Could this be a west-coast specific mentality? ... It would not be surprising. Is it a non-west-coast specific mentality to ignore reality? Is cobol bringing in top computer professionals because of the challenges it poses? Who was it that convinced companies to switch from MVS to Unix because it is superior? Do you consider Unix files superior when they haven't changed since they were first conceived? Programmers flee to Unix because it offers real computer challenges instead of z/OS forcing them to focus on the business. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> On Monday, August 14, 2023 at 03:37:18 AM PDT, Lionel B Dyck > wrote: > I’ve never heard that before in my 50+ years I'm surprised that people don't hear about these skills gaps when they are mentioned every couple years. https://techchannel.com/Enterprise/10/2019/closing-cobol-programming-skills-gap On Monday, August 14, 2023 at 03:37:18 AM PDT, Lionel B Dyck wrote: I’ve never heard that before in my 50+ years. Lionel B. Dyck < Website: www.lbdsoftware.com Sent from my iPhone 12 Pro Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden > On Aug 14, 2023, at 5:09 AM, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi Jon, > You said: "...Programmers leave z/OS for Unix in order to be in full control. > Why do you think it's difficult to get z/OS programmers. ..." > I've been doing MVS Systems Programming for 40+ years and have not once > heard any programmer leave for more control. > Could this be a west-coast specific mentality? ... It would not be surprising. > > Regards, > David > >> On 2023-08-14 01:54, Jon Perryman wrote: >> > On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor wrote: >>> These statements cause me to pause. They seem somewhat antithetical to >>> welcoming and encouraging people to use the mainframe / z/OS. >> >>> Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? >> You're confusing z/OS with Unix where all programmers are systems >> programmers who can do anything they want. z/OS is NOT about be welcoming >> and encouraging. It's about what's best for the business. Your on a >> multi-million dollar computer shared by thousands. As a business programmer >> (not Unix sysprog), you're not qualified nor authorized to make these >> decisions. >> >> Programmers leave z/OS for Unix in order to be in full control. Why do you >> think it's difficult to get z/OS programmers. >> On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor >><023065957af1-dmarc-requ...@listserv.ua.edu> wrote: >>> On 8/7/23 9:56 AM, Jon Perryman wrote: >>> 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? >> These statements cause me to pause. They seem somewhat antithetical to >> welcoming and encouraging people to use the mainframe / z/OS. >> >> Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? >> >> Is there anything about z/OS that would cause you to worry about the >> security and stability of the system? >> >> Do you not trust a tiny VM / LPAR running a test instance of z/OS with >> absolutely minimal resources explicitly for such PoCs? >> >> I'd think that it would be a huge win for the platform to try to get >> more people to do things on it. >> >> No, not all PoCs are vital to the business. But I think that it's >> difficult to tell if any given PoC is vital until /after/ it has been >> tested. >> >> I suspect that there were people that thought that TCP/IP wasn't vital >> to the system back in SNA's heyday. Yet here we are 20+ years later and >> the idea of having any system without a TCP/IP stack is unthinkable. >> How long would TCP/IP for the mainframe have been delayed if someone >> didn't allow such a PoC until /after/ evidence showed that it was needed. >> >> I sincerely doubt that operators /needed/ to create programs that >> printed interesting things to printers after hours. But I suspect that >> many learned a thing or two about the system while doing so. >> >> I would sincerely hope that VM / LPAR could contain anything running in >> a tiny z/OS instance such that it couldn't be disruptive to the system. >> >> Or, if it was somehow disruptive to the system, that might be a good >> indicator that something needs to be tuned or a bug needs to be fixed >> thereby enhancing the larger mainframe z/OS / z/VM community. >> >> I think that encouraging people to do things on the mainframe / z/OS is >> a *GOOD* thing. >> >> >> >> Grant. . . . >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO
Re: USS Features
> On Monday, August 14, 2023 at 03:09:33 AM PDT, David Spiegel wrote: > You said: "...Programmers leave z/OS for Unix in order to be in full control. > I have not once heard any programmer leave for more control. > Could this be a west-coast specific mentality? ... It would not be surprising. Is it a non-west-coast specific mentality to ignore reality? Is cobol bringing in top computer professionals because of the challenges it poses? Who was it that convinced companies to switch from MVS to Unix because it is superior? Do you consider Unix files superior when they haven't changed since they were first conceived? Programmers flee to Unix because it offers real computer challenges instead of z/OS forcing them to focus on the business. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 8/14/23 12:54 AM, Jon Perryman wrote: You're confusing z/OS with Unix where all programmers are systems programmers who can do anything they want. No, I'm not confusing z/OS with Unix. I'm speaking agnosticly about any OS that will run on the platform; z/OS, VM, z/TPF, or even Linux. N.B. I don't consider USS/OMVS to be it's own independent OS. This is despite it being an integral and important z/OS sub-system. z/OS is NOT about be welcoming and encouraging. It's about what's best for the business. What is better for the business, discouraging people from learning $THING to the point that there is nobody to support and maintain it or providing a safe place for newcomers to learn $THING in a controlled safe location. I obviously think that a safe place is better. Ideally said safe place is also accompanied by access to more experienced people to help guide / tutor newer more junior people to make sure the newcomers do things safely. Your on a multi-million dollar computer shared by thousands. If anything the cost of the system implies that it will be more difficult for newcomers to gain access to the platform to learn. As such I think it's more important to provide a safe environment for people to learn. As a business programmer (not Unix sysprog), you're not qualified nor authorized to make these decisions. What gives you the impression that any and all things to be investigated don't go through the change approval board and don't have managerial support. Once upon a time Java, or more recently Node.JS, was considered new and toy software. Yet today, they are both critical. It's my understanding that many, but definitely not all, companies have multiple CECs, one (or more) newer for production, and one (or maybe more) older for DR. My experience is that these older DR systems gain some additional value to the business if they are /also/ used to host sandbox VMs / LPARs. Programmers leave z/OS for Unix in order to be in full control. I've never heard that before. I question the veracity of the idea that everything is about control. I think there is quite a bit that's about how to safely do tasks on the mainframe or z/OS in a way that utilizes it's unique capabilities not found on other platforms. Why do you think it's difficult to get z/OS programmers. Quite honestly, I think that the mainframe / z/OS is difficult for people to get access to in any capacity, and even more difficult for them to get access to a small safe sandbox environment for them to learn in. Would you rather have someone that blindly follows directions that have been written out for 30 years with zero understanding of what problems any mis-step may cause, or would you rather have someone that has been coming up through the ranks and has lots of experience with a procedure and has learned what each step of the procedure is for and who it impacts the overall process? I can't think of a single instance that providing a test / sandbox / lab instance has been a net negative. I can think of many instances where having a test / sandbox / lab instance to mimic production and test changes before applying the changes to production has improved understanding, identified problems in procedures, optimized the process, or generally helped the overall process in many different ways. If you believe that proof of concepts are not necessary, then please explain why a development system is needed as opposed to just making the changes in production directly. N.B. Nothing about a what I'm advocating for negates, sidesteps, or usurps change control or approval process. If anything I advocate for quite the opposite; work within and exercise the established process so that you understand it and are familiar with it. I firmly believe that the only way to identify problems in a process and make the process better is to use the process. I firmly believe that it's best to do this work in a non-production environment whenever possible. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
I’ve never heard that before in my 50+ years. Lionel B. Dyck < Website: www.lbdsoftware.com Sent from my iPhone 12 Pro Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden > On Aug 14, 2023, at 5:09 AM, David Spiegel > <0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > > Hi Jon, > You said: "...Programmers leave z/OS for Unix in order to be in full control. > Why do you think it's difficult to get z/OS programmers. ..." > I've been doing MVS Systems Programming for 40+ years and have not once > heard any programmer leave for more control. > Could this be a west-coast specific mentality? ... It would not be surprising. > > Regards, > David > >> On 2023-08-14 01:54, Jon Perryman wrote: >> > On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor wrote: >>> These statements cause me to pause. They seem somewhat antithetical to >>> welcoming and encouraging people to use the mainframe / z/OS. >> >>> Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? >> You're confusing z/OS with Unix where all programmers are systems >> programmers who can do anything they want. z/OS is NOT about be welcoming >> and encouraging. It's about what's best for the business. Your on a >> multi-million dollar computer shared by thousands. As a business programmer >> (not Unix sysprog), you're not qualified nor authorized to make these >> decisions. >> >> Programmers leave z/OS for Unix in order to be in full control. Why do you >> think it's difficult to get z/OS programmers. >> On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor >> <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: >>>On 8/7/23 9:56 AM, Jon Perryman wrote: >>> 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? >> These statements cause me to pause. They seem somewhat antithetical to >> welcoming and encouraging people to use the mainframe / z/OS. >> >> Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? >> >> Is there anything about z/OS that would cause you to worry about the >> security and stability of the system? >> >> Do you not trust a tiny VM / LPAR running a test instance of z/OS with >> absolutely minimal resources explicitly for such PoCs? >> >> I'd think that it would be a huge win for the platform to try to get >> more people to do things on it. >> >> No, not all PoCs are vital to the business. But I think that it's >> difficult to tell if any given PoC is vital until /after/ it has been >> tested. >> >> I suspect that there were people that thought that TCP/IP wasn't vital >> to the system back in SNA's heyday. Yet here we are 20+ years later and >> the idea of having any system without a TCP/IP stack is unthinkable. >> How long would TCP/IP for the mainframe have been delayed if someone >> didn't allow such a PoC until /after/ evidence showed that it was needed. >> >> I sincerely doubt that operators /needed/ to create programs that >> printed interesting things to printers after hours. But I suspect that >> many learned a thing or two about the system while doing so. >> >> I would sincerely hope that VM / LPAR could contain anything running in >> a tiny z/OS instance such that it couldn't be disruptive to the system. >> >> Or, if it was somehow disruptive to the system, that might be a good >> indicator that something needs to be tuned or a bug needs to be fixed >> thereby enhancing the larger mainframe z/OS / z/VM community. >> >> I think that encouraging people to do things on the mainframe / z/OS is >> a *GOOD* thing. >> >> >> >> Grant. . . . >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
Hi Jon, You said: "...Programmers leave z/OS for Unix in order to be in full control. Why do you think it's difficult to get z/OS programmers. ..." I've been doing MVS Systems Programming for 40+ years and have not once heard any programmer leave for more control. Could this be a west-coast specific mentality? ... It would not be surprising. Regards, David On 2023-08-14 01:54, Jon Perryman wrote: > On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor wrote: These statements cause me to pause. They seem somewhat antithetical to welcoming and encouraging people to use the mainframe / z/OS. Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? You're confusing z/OS with Unix where all programmers are systems programmers who can do anything they want. z/OS is NOT about be welcoming and encouraging. It's about what's best for the business. Your on a multi-million dollar computer shared by thousands. As a business programmer (not Unix sysprog), you're not qualified nor authorized to make these decisions. Programmers leave z/OS for Unix in order to be in full control. Why do you think it's difficult to get z/OS programmers. On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: On 8/7/23 9:56 AM, Jon Perryman wrote: 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? These statements cause me to pause. They seem somewhat antithetical to welcoming and encouraging people to use the mainframe / z/OS. Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? Is there anything about z/OS that would cause you to worry about the security and stability of the system? Do you not trust a tiny VM / LPAR running a test instance of z/OS with absolutely minimal resources explicitly for such PoCs? I'd think that it would be a huge win for the platform to try to get more people to do things on it. No, not all PoCs are vital to the business. But I think that it's difficult to tell if any given PoC is vital until /after/ it has been tested. I suspect that there were people that thought that TCP/IP wasn't vital to the system back in SNA's heyday. Yet here we are 20+ years later and the idea of having any system without a TCP/IP stack is unthinkable. How long would TCP/IP for the mainframe have been delayed if someone didn't allow such a PoC until /after/ evidence showed that it was needed. I sincerely doubt that operators /needed/ to create programs that printed interesting things to printers after hours. But I suspect that many learned a thing or two about the system while doing so. I would sincerely hope that VM / LPAR could contain anything running in a tiny z/OS instance such that it couldn't be disruptive to the system. Or, if it was somehow disruptive to the system, that might be a good indicator that something needs to be tuned or a bug needs to be fixed thereby enhancing the larger mainframe z/OS / z/VM community. I think that encouraging people to do things on the mainframe / z/OS is a *GOOD* thing. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor wrote: > These statements cause me to pause. They seem somewhat antithetical to > welcoming and encouraging people to use the mainframe / z/OS. > Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? You're confusing z/OS with Unix where all programmers are systems programmers who can do anything they want. z/OS is NOT about be welcoming and encouraging. It's about what's best for the business. Your on a multi-million dollar computer shared by thousands. As a business programmer (not Unix sysprog), you're not qualified nor authorized to make these decisions. Programmers leave z/OS for Unix in order to be in full control. Why do you think it's difficult to get z/OS programmers. On Saturday, August 12, 2023 at 06:04:55 PM PDT, Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: On 8/7/23 9:56 AM, Jon Perryman wrote: > 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? These statements cause me to pause. They seem somewhat antithetical to welcoming and encouraging people to use the mainframe / z/OS. Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? Is there anything about z/OS that would cause you to worry about the security and stability of the system? Do you not trust a tiny VM / LPAR running a test instance of z/OS with absolutely minimal resources explicitly for such PoCs? I'd think that it would be a huge win for the platform to try to get more people to do things on it. No, not all PoCs are vital to the business. But I think that it's difficult to tell if any given PoC is vital until /after/ it has been tested. I suspect that there were people that thought that TCP/IP wasn't vital to the system back in SNA's heyday. Yet here we are 20+ years later and the idea of having any system without a TCP/IP stack is unthinkable. How long would TCP/IP for the mainframe have been delayed if someone didn't allow such a PoC until /after/ evidence showed that it was needed. I sincerely doubt that operators /needed/ to create programs that printed interesting things to printers after hours. But I suspect that many learned a thing or two about the system while doing so. I would sincerely hope that VM / LPAR could contain anything running in a tiny z/OS instance such that it couldn't be disruptive to the system. Or, if it was somehow disruptive to the system, that might be a good indicator that something needs to be tuned or a bug needs to be fixed thereby enhancing the larger mainframe z/OS / z/VM community. I think that encouraging people to do things on the mainframe / z/OS is a *GOOD* thing. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> On Monday, August 7, 2023 at 04:33:24 PM PDT, Andrew Rowley > wrote: > It comes back to the question I asked earlier - how much space is it > reasonable to use *to do your job* before you have to get the storage > admin involved? Since you put it that way, I've got to say are you insane. The storage admin based his decision on things called facts. He is responsible for storage and his decision is final until his management tells him otherwise. I suggest you inform your company CEO that all decisions must go through you. On Monday, August 7, 2023 at 04:33:24 PM PDT, Andrew Rowley wrote: On 8/08/2023 12:56 am, Jon Perryman wrote: > 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. It comes back to the question I asked earlier - how much space is it reasonable to use *to do your job* before you have to get the storage admin involved? There can be good reasons to do it on z/OS, e.g. the source data is already on the system, data security on other platforms etc. There is some irony in the contradiction between "z/OS because of its I/O capabilities" and "100GB! Whoa! Be reasonable!" -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On 8/7/23 10:11 AM, Paul Gilmartin wrote: Instead of a home directory for each user with Documents, etc. subdirectories there's a global Documents directory with subdirectories for individual users. Which version of Windows are you talking about. Did something MASSIVELY change in Windows 11? For a *LONG* time it was C:\Documents and Settings\%UserName% for each user's home directory. At some point, I don't remember when, it became C:\Users\%UserName% for each user's home directory. I've not seen a version of Windows in 20 years that didn't have a dedicated home directory for each user where their files, documents, photos, etc. lived. Please share details about where you are seeing global document directory? That being said, I wouldn't be surprised if there was a -- as you say -- global directory that had sub-directories pointing into each user's directory as a convenience. But I would expect that users still had individual directories. C:\Global Documents\Bob -> C:\Users\Bob\Documents C:\Global Documents\Tom -> C:\Users\Tom\Documents C:\Global Pictures\Bob -> C:\Users\Bob\Pictures C:\Global Pictures\Tom -> C:\Users\Tom\Pictures C:\Users\Bob\Documents C:\Users\Bob\Pictures C:\Users\Tom\Documents C:\Users\Tom\Pictures -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 8/7/23 9:56 AM, Jon Perryman wrote: 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? These statements cause me to pause. They seem somewhat antithetical to welcoming and encouraging people to use the mainframe / z/OS. Why is it absurd to allow everyone to do a Proof Of Concept on z/OS? Is there anything about z/OS that would cause you to worry about the security and stability of the system? Do you not trust a tiny VM / LPAR running a test instance of z/OS with absolutely minimal resources explicitly for such PoCs? I'd think that it would be a huge win for the platform to try to get more people to do things on it. No, not all PoCs are vital to the business. But I think that it's difficult to tell if any given PoC is vital until /after/ it has been tested. I suspect that there were people that thought that TCP/IP wasn't vital to the system back in SNA's heyday. Yet here we are 20+ years later and the idea of having any system without a TCP/IP stack is unthinkable. How long would TCP/IP for the mainframe have been delayed if someone didn't allow such a PoC until /after/ evidence showed that it was needed. I sincerely doubt that operators /needed/ to create programs that printed interesting things to printers after hours. But I suspect that many learned a thing or two about the system while doing so. I would sincerely hope that VM / LPAR could contain anything running in a tiny z/OS instance such that it couldn't be disruptive to the system. Or, if it was somehow disruptive to the system, that might be a good indicator that something needs to be tuned or a bug needs to be fixed thereby enhancing the larger mainframe z/OS / z/VM community. I think that encouraging people to do things on the mainframe / z/OS is a *GOOD* thing. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
zfsadm shrink is faster and less disruptive. Nevertheless, shrinking is not automatic like growing is (can be). The fact that one can compress, decompress, encrypt, decrypt, grow, or shrink zfs files in-place and in-use implies to me that the zfs developers are pretty sharp. sas On Tue, Aug 8, 2023 at 9:34 AM Mike Schwab wrote: > If a user greatly reduces their file usage, you can create a new home > directory, copy the remaining files over, and release the old directory. > If it's a separate z/OS file system, you get the space back. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
If a user greatly reduces their file usage, you can create a new home directory, copy the remaining files over, and release the old directory. If it's a separate z/OS file system, you get the space back. On Tue, Aug 8, 2023, 07:11 Jack Zukt wrote: > As someone pointed out, it is only one more user file and I suppose that > you no not manage your space by restricting the number of user files. As it > has also been noticed, it can, and will be HSM migrated. > And when you delete a RACF userid the zfs file goes with all the others, > there is no USS directory to be located and deleted. > Never looked back after we implemented it a few years ago. > Best wishes > Jack > > > On Tue, Aug 8, 2023, 00:27 Andrew Rowley > wrote: > > > On 8/08/2023 12:37 am, Jon Perryman wrote: > > > Automount was created specifically to address some filesystem > > > blemishes. There's a problem they needed to solved and they allowed > > > people to continue without the use of automount. For those who choose > > > automount, they decided that with all its faults, it solved more > > > problems than it created. > > > > IBM didn't create automount. It was a standard unix thing before IBM did > > unix. IBM just came up with the idea of HSM migrating home directories > > as a use case. > > > > The primary problem with individual filesystems is that freespace > > doesn't get returned to the system. Deleted a file? The space still > > can't be used by someone else. If you accidentally fill up your > > filesystem, when you delete the file after all those "growing > > filesystem" messages: congratulations, you own the empty space. > > > > The secondary problem is that migrating filesystems makes file and > > directory level management impractical. > > > > # du --sh /home/* > > > > # find /home -size 2G > > > > Don't even think about it, unless you like HSM recalls. > > > > File level backup also gets complicated when filesystems are migrated. > > > > Pretty much all the problems that automounted individual filesystems are > > supposed to solve are actually a result of having individual > > filesystems. They don't have to be solved on other platforms because > > they didn't create them in the first place (or there is a better > > solution e.g. quotas). > > > > -- > > Andrew Rowley > > Black Hill Software > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
As someone pointed out, it is only one more user file and I suppose that you no not manage your space by restricting the number of user files. As it has also been noticed, it can, and will be HSM migrated. And when you delete a RACF userid the zfs file goes with all the others, there is no USS directory to be located and deleted. Never looked back after we implemented it a few years ago. Best wishes Jack On Tue, Aug 8, 2023, 00:27 Andrew Rowley wrote: > On 8/08/2023 12:37 am, Jon Perryman wrote: > > Automount was created specifically to address some filesystem > > blemishes. There's a problem they needed to solved and they allowed > > people to continue without the use of automount. For those who choose > > automount, they decided that with all its faults, it solved more > > problems than it created. > > IBM didn't create automount. It was a standard unix thing before IBM did > unix. IBM just came up with the idea of HSM migrating home directories > as a use case. > > The primary problem with individual filesystems is that freespace > doesn't get returned to the system. Deleted a file? The space still > can't be used by someone else. If you accidentally fill up your > filesystem, when you delete the file after all those "growing > filesystem" messages: congratulations, you own the empty space. > > The secondary problem is that migrating filesystems makes file and > directory level management impractical. > > # du --sh /home/* > > # find /home -size 2G > > Don't even think about it, unless you like HSM recalls. > > File level backup also gets complicated when filesystems are migrated. > > Pretty much all the problems that automounted individual filesystems are > supposed to solve are actually a result of having individual > filesystems. They don't have to be solved on other platforms because > they didn't create them in the first place (or there is a better > solution e.g. quotas). > > -- > Andrew Rowley > Black Hill Software > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 8/08/2023 12:56 am, Jon Perryman wrote: 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. It comes back to the question I asked earlier - how much space is it reasonable to use *to do your job* before you have to get the storage admin involved? There can be good reasons to do it on z/OS, e.g. the source data is already on the system, data security on other platforms etc. There is some irony in the contradiction between "z/OS because of its I/O capabilities" and "100GB! Whoa! Be reasonable!" -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On 8/08/2023 12:37 am, Jon Perryman wrote: Automount was created specifically to address some filesystem blemishes. There's a problem they needed to solved and they allowed people to continue without the use of automount. For those who choose automount, they decided that with all its faults, it solved more problems than it created. IBM didn't create automount. It was a standard unix thing before IBM did unix. IBM just came up with the idea of HSM migrating home directories as a use case. The primary problem with individual filesystems is that freespace doesn't get returned to the system. Deleted a file? The space still can't be used by someone else. If you accidentally fill up your filesystem, when you delete the file after all those "growing filesystem" messages: congratulations, you own the empty space. The secondary problem is that migrating filesystems makes file and directory level management impractical. # du --sh /home/* # find /home -size 2G Don't even think about it, unless you like HSM recalls. File level backup also gets complicated when filesystems are migrated. Pretty much all the problems that automounted individual filesystems are supposed to solve are actually a result of having individual filesystems. They don't have to be solved on other platforms because they didn't create them in the first place (or there is a better solution e.g. quotas). -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
We use automount with auto created ZFSs for each user. We set the size so it won’t grow beyond our settings. Works great. On Mon, Aug 7, 2023 at 7:57 AM Rick Troth wrote: > > However it is not reality show or beauty contest, rather I'd like to > see some real advantages of automount. > > Last week I learned of a peculiar use of automount in z/OS which is > different from my experience and which a storage admin might truly > dislike: auto-create a (possibly large, in any case yet another to > manage) USS filespace for each user. > Yuck. > So I get it that some find automount counter productive. > > My experience has always been quite different, whether with z/OS or > elsewhere. > The mounted objects are often sub-directories of a shared space > (advantage: NOT creating countless additional spaces to manage). > The mounted objects are called for on-demand (advantage: NOT requiring a > large table of filesystems to mount when the system starts). > > I was blown away the first time I ran 'df' on USS. So many things mounted! > And many of them were program products. As a long time Unix person and > sometime Unix admin, I do find program products to be excellent > candidates for their own mount point (whether also their own physical > space or shared). > Automounter could dramatically reduce the number of things needing mount > at boot time. > > My first experience with automounter was for user home directories (in > that case, always residing in shared spaces on the back end). > But that was the time of shared workstations: a users home dir was not > mounted until she signed on. > > Summary: YES, automount has some advantages, though no, it's not always > implemented elegantly. > > -- R; <>< > > > On 8/5/23 09:08, Radoslaw Skorupka wrote: > > W dniu 04.08.2023 o 22:04, Jon Perryman pisze: > >> > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka > >> wrote: > >> > >>> Regarding automount feature: IMHO it is less than useless. > >> While there is truth to what you say about automount, there are uses > >> where people find it useful because it provides features that some > >> customers need. Most notably, everything in a filesystem is randomly > >> placed within that filesystem without any controls. Ask a z/OS > >> storage admin if he could tolerate the same situation where all z/OS > >> datasets are placed randomly (no SMS nor disk esoterics). > > > > I asked storage admin (myself) and heard NO. Automount changes nothing > > to what you described (and what is IMHO disputable, but this is > > different thread). > > Oh, BTW: I met many other storage admins in my career. No one liked > > automount feature, usually they didn't express any opinion, but > > sometimes they complain on that. > > However it is not reality show or beauty contest, rather I'd like to > > see some real advantages of automount. > > > > > > > >> On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka > >> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > >> Regarding automount feature: IMHO it is less than useless. > >> - It require some effort to establish and manage (including storage > >> adm.) > >> - It wastes space, because even smallest empty home directory occupies > >> first extent of the ZFS/HFS. > >> - Space (extents) taken by some large files and then deleted is still > >> occupied by the user. > >> - Tools like find may omit currently unmounted directories, sometimes > >> making the search ineffective. > >> - I vaguely remember the z/OS Unix does not like excessive filesystems > >> being mounted. > >> - Automount/demount consume some resources. > >> - Last, but not least: I observed the are more active TSO users than USS > >> users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS > >> just out of curiosity. In case of automount yet another filesystem is > >> created. > >> > >> > >> From the other hand one can create common filesystems for all home > >> directories. > >> When needed it can be divided among multiple filesystems. > >> Users with large needs may have dedicated filesystems. > >> Empty user directory does not consume resources. Even "touched". > >> > >> > >> My €0.02 > > > > > > > > Regards > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Obviously it is not big deal. Yes, automount or not-automount is not the question (Hamlet). :-) It is just my opinion that automount require some setup and provide no value. And of course this is discussion forum, so I expect other opinions or arguments. This is kind of learning opportunity, which I appreciate. Regarding personal files - yes, it is not big deal, even for dozens of almost-empty filesystems multiplied by nn cylinders. Yes, DASD is quite cheap nowadays and we have a lot of. However when I take a time to consider minor deals, I see some disadvantages of automount and no advantages. With one exception: there are cases when a user wants his filesystem to be migrated. Migrated from system A to system B, etc. Important: it is not a migration of all the users. In that case it would be easier or quicker (for whom?) to use ADRDSSU dump/restore instead of pax. Note, I still consider automount and separate filesystems for every home dir vs common filesystem for home directories. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 07.08.2023 o 16:00, Steve Smith pisze: Every user on our system has dozens of "personal" files, ISPF-related, DDIR, etc. One more is no big deal. And if a user blows up their home filesystem, it's a minor issue (1 user), not a critical one (all users affected). I also do not want to manage space usage in the filesystems. I appreciate that you haven't continued the conflation of "automount" with what we're really talking about, which is individual home filesystems. Different systems have different requirements. If you think that a common user home filesystem is best for yours, fine. Nothing I've seen here has changed my view that automounted (with auto-create) individual filesystems is the best for us. sas On Mon, Aug 7, 2023 at 9:40 AM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Objection: I do not compare thousands of automounted filesystems to same thousands of permanently mounted same filesystems. Absolutely the opposite, I mean INSTEAD of thousands (I'd say dozens) automounted filesystems I'd like to have ONE or few permanently mounted filesystems. Caution: common filesystem does not mean common/shared home directory. In the filesystem I still can have thousands (dozens?) of separate user directiories. Just another mountpoint above the home dir. So, the mount time at the IPL will not be a problem. The same for mount table and parmlib member. Regarding mount table - I would bet it will be smaller. One (common) filesystem vs (few) dozens filesystems belonging to active users. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Mon, 7 Aug 2023 10:00:45 -0400, Steve Smith wrote: > >I appreciate that you haven't continued the conflation of "automount" with >what we're really talking about, which is individual home filesystems. > I can hardly imagine not having a private home directory. It hardly matters to me whether it's a separate filesystem -- performance and reliability are concerns for admins. Likewise it doesn't matter whether it appears at the second level above "/" or higher. Nur even the name. I knew one user who had his Solaris HOME defined in RACF as his MVS HOME, even though his TSO user ID was not the lowest qualifier in that path. RACF, HOME, "~" and getpwuid sort it all out. Our admins chose, wisely IMO, to replicate as our OMVS UIDs the older Solaris UIDs. Windows appears to take an orthogonal approach. Instead of a home directory for each user with Documents, etc. subdirectories there's a global Documents directory with subdirectories for individual users. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
> 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 <031df298a9da-dmarc-requ...@listserv.ua.edu> 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 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 > 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 inte
Re: Automount (was USS Features)
> On Monday, August 7, 2023 at 05:56:59 AM PDT, Rick Troth > wrote: > storage admin might truly dislike: auto-create a USS filespace for each user. Storage admins who don't like auto-create can create filespace by hand. Are you saying auto-create does not meet the needs for all? > automount has some advantages, though no, it's not always implemented > elegantly. Elegance is often not achievable when creating for something that already exists. IBM had few choices because of the faults of filesystem, Unix and z/OS. Automount was created specifically to address some filesystem blemishes. There's a problem they needed to solved and they allowed people to continue without the use of automount. For those who choose automount, they decided that with all its faults, it solved more problems than it created. This is true for all software whether it's Unix or z/OS. The solution to a problem usually changes the problem. On Monday, August 7, 2023 at 05:56:59 AM PDT, Rick Troth wrote: > However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. Last week I learned of a peculiar use of automount in z/OS which is different from my experience and which a storage admin might truly dislike: auto-create a (possibly large, in any case yet another to manage) USS filespace for each user. Yuck. So I get it that some find automount counter productive. My experience has always been quite different, whether with z/OS or elsewhere. The mounted objects are often sub-directories of a shared space (advantage: NOT creating countless additional spaces to manage). The mounted objects are called for on-demand (advantage: NOT requiring a large table of filesystems to mount when the system starts). I was blown away the first time I ran 'df' on USS. So many things mounted! And many of them were program products. As a long time Unix person and sometime Unix admin, I do find program products to be excellent candidates for their own mount point (whether also their own physical space or shared). Automounter could dramatically reduce the number of things needing mount at boot time. My first experience with automounter was for user home directories (in that case, always residing in shared spaces on the back end). But that was the time of shared workstations: a users home dir was not mounted until she signed on. Summary: YES, automount has some advantages, though no, it's not always implemented elegantly. -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Every user on our system has dozens of "personal" files, ISPF-related, DDIR, etc. One more is no big deal. And if a user blows up their home filesystem, it's a minor issue (1 user), not a critical one (all users affected). I also do not want to manage space usage in the filesystems. I appreciate that you haven't continued the conflation of "automount" with what we're really talking about, which is individual home filesystems. Different systems have different requirements. If you think that a common user home filesystem is best for yours, fine. Nothing I've seen here has changed my view that automounted (with auto-create) individual filesystems is the best for us. sas On Mon, Aug 7, 2023 at 9:40 AM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > Objection: I do not compare thousands of automounted filesystems to same > thousands of permanently mounted same filesystems. > Absolutely the opposite, I mean INSTEAD of thousands (I'd say dozens) > automounted filesystems I'd like to have ONE or few permanently mounted > filesystems. Caution: common filesystem does not mean common/shared home > directory. In the filesystem I still can have thousands (dozens?) of > separate user directiories. Just another mountpoint above the home dir. > > So, the mount time at the IPL will not be a problem. The same for mount > table and parmlib member. > Regarding mount table - I would bet it will be smaller. One (common) > filesystem vs (few) dozens filesystems belonging to active users. > > > > -- > Radoslaw Skorupka > Lodz, Poland > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Objection: I do not compare thousands of automounted filesystems to same thousands of permanently mounted same filesystems. Absolutely the opposite, I mean INSTEAD of thousands (I'd say dozens) automounted filesystems I'd like to have ONE or few permanently mounted filesystems. Caution: common filesystem does not mean common/shared home directory. In the filesystem I still can have thousands (dozens?) of separate user directiories. Just another mountpoint above the home dir. So, the mount time at the IPL will not be a problem. The same for mount table and parmlib member. Regarding mount table - I would bet it will be smaller. One (common) filesystem vs (few) dozens filesystems belonging to active users. -- Radoslaw Skorupka Lodz, Poland W dniu 07.08.2023 o 14:56, Rick Troth pisze: > However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. Last week I learned of a peculiar use of automount in z/OS which is different from my experience and which a storage admin might truly dislike: auto-create a (possibly large, in any case yet another to manage) USS filespace for each user. Yuck. So I get it that some find automount counter productive. My experience has always been quite different, whether with z/OS or elsewhere. The mounted objects are often sub-directories of a shared space (advantage: NOT creating countless additional spaces to manage). The mounted objects are called for on-demand (advantage: NOT requiring a large table of filesystems to mount when the system starts). I was blown away the first time I ran 'df' on USS. So many things mounted! And many of them were program products. As a long time Unix person and sometime Unix admin, I do find program products to be excellent candidates for their own mount point (whether also their own physical space or shared). Automounter could dramatically reduce the number of things needing mount at boot time. My first experience with automounter was for user home directories (in that case, always residing in shared spaces on the back end). But that was the time of shared workstations: a users home dir was not mounted until she signed on. Summary: YES, automount has some advantages, though no, it's not always implemented elegantly. -- R; <>< On 8/5/23 09:08, Radoslaw Skorupka wrote: W dniu 04.08.2023 o 22:04, Jon Perryman pisze: > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka wrote: Regarding automount feature: IMHO it is less than useless. While there is truth to what you say about automount, there are uses where people find it useful because it provides features that some customers need. Most notably, everything in a filesystem is randomly placed within that filesystem without any controls. Ask a z/OS storage admin if he could tolerate the same situation where all z/OS datasets are placed randomly (no SMS nor disk esoterics). I asked storage admin (myself) and heard NO. Automount changes nothing to what you described (and what is IMHO disputable, but this is different thread). Oh, BTW: I met many other storage admins in my career. No one liked automount feature, usually they didn't express any opinion, but sometimes they complain on that. However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
> However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. Last week I learned of a peculiar use of automount in z/OS which is different from my experience and which a storage admin might truly dislike: auto-create a (possibly large, in any case yet another to manage) USS filespace for each user. Yuck. So I get it that some find automount counter productive. My experience has always been quite different, whether with z/OS or elsewhere. The mounted objects are often sub-directories of a shared space (advantage: NOT creating countless additional spaces to manage). The mounted objects are called for on-demand (advantage: NOT requiring a large table of filesystems to mount when the system starts). I was blown away the first time I ran 'df' on USS. So many things mounted! And many of them were program products. As a long time Unix person and sometime Unix admin, I do find program products to be excellent candidates for their own mount point (whether also their own physical space or shared). Automounter could dramatically reduce the number of things needing mount at boot time. My first experience with automounter was for user home directories (in that case, always residing in shared spaces on the back end). But that was the time of shared workstations: a users home dir was not mounted until she signed on. Summary: YES, automount has some advantages, though no, it's not always implemented elegantly. -- R; <>< On 8/5/23 09:08, Radoslaw Skorupka wrote: W dniu 04.08.2023 o 22:04, Jon Perryman pisze: > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka wrote: Regarding automount feature: IMHO it is less than useless. While there is truth to what you say about automount, there are uses where people find it useful because it provides features that some customers need. Most notably, everything in a filesystem is randomly placed within that filesystem without any controls. Ask a z/OS storage admin if he could tolerate the same situation where all z/OS datasets are placed randomly (no SMS nor disk esoterics). I asked storage admin (myself) and heard NO. Automount changes nothing to what you described (and what is IMHO disputable, but this is different thread). Oh, BTW: I met many other storage admins in my career. No one liked automount feature, usually they didn't express any opinion, but sometimes they complain on that. However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Saturday, August 5, 2023 at 06:08:55 AM PDT, Radoslaw Skorupka wrote: > I asked storage admin (myself) and heard NO. Automount changes nothing > to what you described (and what is IMHO disputable, but this is > different thread). Clearly the storage admins you asked have never felt the pain of z/OS Unix filesystems because they are insignificant. Have him pretend he has a 100TB filesystem and ask him how he will restore your files. What tool will he use when the filesystem is full causing hundreds of users to fail? How will he migrate inactive z/OS Unix files to free up space? Is he willing to add an additional 10TB to the filesystem which will never be freed? When a storage admin doesn't want to fully understand z/OS Unix filesystems, what options do you think they have? While automount has problems, it gives storage admins a solution they can deal with in their world. They can ignore storage quotas and use extents to limit size. I'm not saying automount is a great solution but there are people who find it useful. z/OS Unix filesystems are not a great solution but we've learned to live with it's problems. How is automount any different? b -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
On Sat, 5 Aug 2023 15:08:31 +0200, Radoslaw Skorupka wrote: >... >However it is not reality show or beauty contest, rather I'd like to see >some real advantages of automount. > At one time our site had an open-system NFS client so users could access traditional MVS data sets on their desktops. Generic maps on both client and mainframe server, with HSM autorecall on server map. At some point a user (undisclosed, perhaps never identified) did a large wildcard query. I think it ran for multiple days with recalls filling up all storage packs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
W dniu 04.08.2023 o 22:04, Jon Perryman pisze: > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka wrote: Regarding automount feature: IMHO it is less than useless. While there is truth to what you say about automount, there are uses where people find it useful because it provides features that some customers need. Most notably, everything in a filesystem is randomly placed within that filesystem without any controls. Ask a z/OS storage admin if he could tolerate the same situation where all z/OS datasets are placed randomly (no SMS nor disk esoterics). I asked storage admin (myself) and heard NO. Automount changes nothing to what you described (and what is IMHO disputable, but this is different thread). Oh, BTW: I met many other storage admins in my career. No one liked automount feature, usually they didn't express any opinion, but sometimes they complain on that. However it is not reality show or beauty contest, rather I'd like to see some real advantages of automount. On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
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 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 > 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
Re: USS Features
> On Sunday, July 30, 2023 at 08:23:54 PM PDT, Andrew Rowley > 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
> On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka wrote: > Regarding automount feature: IMHO it is less than useless. While there is truth to what you say about automount, there are uses where people find it useful because it provides features that some customers need. Most notably, everything in a filesystem is randomly placed within that filesystem without any controls. Ask a z/OS storage admin if he could tolerate the same situation where all z/OS datasets are placed randomly (no SMS nor disk esoterics). On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 -- Radoslaw Skorupka Lodz, Poland W dniu 31.07.2023 o 17:08, Paul Gilmartin pisze: > On Mon, 31 Jul 2023 09:43:38 -0500, Grant Taylor wrote: > >> On 7/31/23 8:06 AM, Rick Troth wrote: >>> per-user automount does not necessarily waste space >> IMHO automount is completely independent of shared / separate per user >> disk space. >> >>> The thing which is mounted might be a sub-directory of a shared space. >> Agreed. >> > Wasn't true in the Bad Old Days, when the only thing that could be mounted > was an entire HFS content (or an NFS [sub]directory.) > > And I was dismayed that the MVS mount maps needed to differ between > MVS NFS server and client. Solaris was smarter: mount on the server > would look at the map, say, "Oh! That's me!" and mount the directory as local. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automount (was USS Features)
Regarding automount feature: IMHO it is less than useless. - It require some effort to establish and manage (including storage adm.) - It wastes space, because even smallest empty home directory occupies first extent of the ZFS/HFS. - Space (extents) taken by some large files and then deleted is still occupied by the user. - Tools like find may omit currently unmounted directories, sometimes making the search ineffective. - I vaguely remember the z/OS Unix does not like excessive filesystems being mounted. - Automount/demount consume some resources. - Last, but not least: I observed the are more active TSO users than USS users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS just out of curiosity. In case of automount yet another filesystem is created. From the other hand one can create common filesystems for all home directories. When needed it can be divided among multiple filesystems. Users with large needs may have dedicated filesystems. Empty user directory does not consume resources. Even "touched". My €0.02 -- Radoslaw Skorupka Lodz, Poland W dniu 31.07.2023 o 17:08, Paul Gilmartin pisze: On Mon, 31 Jul 2023 09:43:38 -0500, Grant Taylor wrote: On 7/31/23 8:06 AM, Rick Troth wrote: per-user automount does not necessarily waste space IMHO automount is completely independent of shared / separate per user disk space. The thing which is mounted might be a sub-directory of a shared space. Agreed. Wasn't true in the Bad Old Days, when the only thing that could be mounted was an entire HFS content (or an NFS [sub]directory.) And I was dismayed that the MVS mount maps needed to differ between MVS NFS server and client. Solaris was smarter: mount on the server would look at the map, say, "Oh! That's me!" and mount the directory as local. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On Mon, 31 Jul 2023 09:43:38 -0500, Grant Taylor wrote: >On 7/31/23 8:06 AM, Rick Troth wrote: >> per-user automount does not necessarily waste space > >IMHO automount is completely independent of shared / separate per user >disk space. > >> The thing which is mounted might be a sub-directory of a shared space. > >Agreed. > Wasn't true in the Bad Old Days, when the only thing that could be mounted was an entire HFS content (or an NFS [sub]directory.) And I was dismayed that the MVS mount maps needed to differ between MVS NFS server and client. Solaris was smarter: mount on the server would look at the map, say, "Oh! That's me!" and mount the directory as local. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 7/31/23 8:06 AM, Rick Troth wrote: per-user automount does not necessarily waste space IMHO automount is completely independent of shared / separate per user disk space. The thing which is mounted might be a sub-directory of a shared space. Agreed. Also, automount is not exclusively for user home directories. It's great for selected program products. ABSOLUTELY agreed. I've got nearly half a dozen auto-mounts on a number of systems, only one of which is the home directory. I've even got automount managing /boot on Linux. It doesn't need to be mounted all the time. If it's not mounted, it's a lot more difficult to get corrupted. N.B. automount doesn't protect against file access / deletion / modification as automounts design goal is to mount the necessary file system to enable said A/D/M. Much like RAID is not a backup. --- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
per-user automount does not necessarily waste space The thing which is mounted might be a sub-directory of a shared space. Also, automount is not exclusively for user home directories. It's great for selected program products. -- R; <>< On 7/30/23 23:46, Grant Taylor wrote: On 7/30/23 10:23 PM, Andrew Rowley wrote: 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? Please forgive the ignorant question, but does z/OS support quota in any way other than a hard file system limit? 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. I've seen a few quota systems capable of allowing users to go above a soft limit for an amount of time while still being bounded by an absolute hard limit. This soft limit allows users to burst for temporary things, usually for single digit number of hours or days. Once the user exceeds the time, their soft quota kicks in and behaves as if it's the hard limit. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 7/30/23 10:23 PM, Andrew Rowley wrote: 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? Please forgive the ignorant question, but does z/OS support quota in any way other than a hard file system limit? 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. I've seen a few quota systems capable of allowing users to go above a soft limit for an amount of time while still being bounded by an absolute hard limit. This soft limit allows users to burst for temporary things, usually for single digit number of hours or days. Once the user exceeds the time, their soft quota kicks in and behaves as if it's the hard limit. Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Features
On 31/07/2023 10:59 am, Steve Smith wrote: Whatever. We use automount, and the "space" wasted is way too trivial to worry about. And HSM can magically free up home filesystem zfs files that aren't used any more. If it's trivial, you're probably not using actually using it. 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? 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. 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. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
USS Features
On Sun, Jul 30, 2023 at 6:51 PM Andrew Rowley wrote: > On 30/07/2023 2:28 am, Jon Perryman wrote: > > ASK YOURSELF: Name the z/OS Unix feature that sort of fixes the > fundamental design flaw with Unix filesystems just described? > > > > I suspect most people won't think about each user having a unique > filesystem using automount to make their filesystem available. Typical Unix > uses one file system with all users having directories in the /user > directory. > > An automounted filesystem per user has always been a terrible idea. I > think it was given as an example of how you could use automount and > somehow morphed into a recommendation. (Other OSes can e.g. use > automount to mount a remote user filesystem via NFS). > > Reasons it's a bad idea: > > 1) Freespace in the filesystem is not shared between users. This means > that you need much more space than if there was one pool of freespace > shared between all. > Whatever. We use automount, and the "space" wasted is way too trivial to worry about. And HSM can magically free up home filesystem zfs files that aren't used any more. > > 2) It makes simple questions like e.g. "Which users have a > .ssh/authorized_keys file?" much harder to answer. > gil answered that one... if you really have a good reason to go poking around in users' business. > > A filesystem per user is basically equivalent to a SMS storage group and > catalog per user. You get isolation between users, but at the expense of > much more difficult management. > Now that you mention it, a catalog per user sounds like a great idea. I suppose it's the nature of our business, but we badly damage catalogs more often than I'd care to admit. We have a few expert Catalog Surgeons*, but the downtime and their time are an expense. The only issue I see is how that might affect CAS. *If my company would license Catalog Recovery+, we would only need to be Catalog Nurse Practitioners. > > -- > Andrew Rowley > Black Hill Software > > sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
