We know Gilmartin considers UNIX elegant so he is a lost cause but it's sad that he's bringing others to the dark side. He often gives UNIX examples that he feels are at the forefront of technology when in reality there are z/OS solutions that work as well or even better. Case in point is the CP command to merge files. A simple exec to alloc the files and merge them can easily be created. How often do you merge files? If anyone considered this a requirement, they would have created the solution in less than a minute. So a newbie knows intuitively that CP is copy and help is -?.
z/OS certainly has it's problems and we are willing to admit it. z/OS may have a petina but UNIX / Linux has been rusting over time and some don't even recognize those problems. E.g. The CLOUD came into existence because UNIX was not able to solve basic problems so it came up with a way hide them. Instead of solving major limitations, it simply redefines them as non-problems. I am actually an advocate for both operating systems but I realize they both have their limitations. As for showing that z/OS is not as bad as some would make it out, here are some of the issues the cloud has addressed but not truly resolved: 1. Disk full: * Cloud: Some disk manufacturers have implementations that work well but they exist more as NFS than as a local filesystem and they are still not in heavy use. Other implementations simply use Unix filesystems but they require more disk space than is needed. * UNIX: Applications often do bizarre things with disk full. Admin's usually find out there is a problem from user reporting the problem. Adding a disk immediately won't solve the problem because the file system must be copied. Adding a mountpoint doesn't help. Admin must search / delete files to free space. Increasing the file system size requires the sceduling of down time (it's not just adding space). * z/OS: Applications will die but we can have automation to add disks to a storage group in a matter of seconds. We can easily steal disks from our test systems in an emergency where we don't have sufficient extra's. We have HSM to migrate seldom used files to tape. Admins can change the migration interval. 2. CPU busy. * Cloud: There are a few implementations to spread workload (e.g. SOA). They all are the same basic principle but with different standards. They all basically send a request and wait for a response. It still exists within the restrictions of UNIX. * UNIX: Can't dynamically add a cpu without reboot. Loosely coupled. Can't offload workload without purpose built applications (E.g. Peoplesoft and SAP). * z/OS: We have WLM to prioritize workload. CPU's can be dynamically added (IBM often has spares in the box that can be quickly purchased). Our systems are tightly coupled thru sysplex. IMS, CICS, TSO and batch can easily be spread on any / all systems within the sysplex. 3. Networking: * Cloud: Same as UNIX. * UNIX: TCP/IP was not publicly available until the 70's. Prior to that, simple communications were available. * z/OS: SNA existed long before TCP/IP was available. SNA was a robust, reliable and secure communications methodology. Once TCP was became available, we had the same situation as Betamax versus VHS. TCP won. 4. Data recovery: * Cloud: Cross your fingers and hope that your cloud provider is taking sufficient precautions. * UNIX: Backup and recovery utilities exist but an admin is often required to perform recovery. In addition, recovery is often an interactive process (start request / mount tape then repeat). * z/OS: HSM, DSM, FDR and other products exist. HSM allows user's to issue multiple HRECOVER commands which are queued to the server and you wait for notification of completion. It's been too long for me to remember the other products but I suspect they work as well. I could list more if necessary but that would be a waste of time. z/OS improvements often go unnoticed. They are often embedded and transparent to most users of the system. Granted that IBM does detrimental actions that overshadow the advantages of z/OS. I too think their user base would increase if they weren't so restrictive. This dinosaur hasn't died yet and probably won't in the near future. Jon Perryman. >________________________________ > From: Dana Mitchell <[email protected]> >To: [email protected] >Sent: Tuesday, November 5, 2013 7:01 AM >Subject: Re: Aging Sysprogs = Aging Farmers > > >On Tue, 5 Nov 2013 08:13:14 -0600, Paul Gilmartin <[email protected]> wrote: > >>It's far less encrusted with the patina of antiquity. Much of OS/360 >>made sense in the resource-constrained batch environment in which >>it originated. Nowadays, its residue is a requirement for compatibility; >>an enormous burden for novices. >> >>-- gil >> > >+1 gil! exactly! > >I've long thought that z/OS needed a good dose of modernization and overhaul >to come kicking and screaming onto the hardware of the 21st century.... Does >anyone use FLPA any more? > > >On Tue, 5 Nov 2013 20:32:38 +0800, David Crayford <[email protected]> wrote: >> >>Indeed! It's and old story isn't it? If youngster's don't have easy >>access to a platform they will not be interested in it. They can install >>Linux on a cheap PC and hack away to their hearts content. >>IBM really do need to wake up and start providing either emulation or >>cheap virtual machines to as many universities as they can reach. >> > >This is the exact same problem facing the IBM i community, no cheap/free >option for experimentation and exploration. IBM should make available a free >download of IBM z/OS emlated to run on a PC just for this purpose. On second >thought, that would highlight all the 'encrusted patina of antiquity' and >probably send the 20-somethings running for the hills! > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
