I think the real downside is cost of going to a new "platform", even tho it's still within z/OS. That means training, development/conversionj/implementation, testing, deployment, new operations procedures and training, maintenance, etc.
Add in the general problem of rewriting any software in its entirety.: - You can miss important/heavily-used features. - You can waste resources on new features that are not really needed or cost-effective. - You can introduce new bugs. - If you change the UI, the users will hate you, your guts, and every member of your family, because they will have to spend time learning something entirely new when they already knew the old system well. Don't do it!!! (Unless you really. really, really have to.) Second to that are the deficient string and file models: - There are separate techniques for processing text, on one hand, and binary data on the other. (z/OS, z/VM have no such requirement.) - Using the wrong technique can break data structures badly, as can inadvertent/erroneous embedding of binary data in text strings/files. (z/OS, z/VM have not such problem.) - One of *nix's most powerful features, piping, is crippled because most filters are text oriented and cannot process binary data. Dispatching is mostly at the discretion of the operating system. (Dispatching generally deterministic, ands streams can be split and rejoined, because record movement is generally defined.) - When processing text strings or files, having to scan for the string terminator or CR/LF, results in performance-killing working-set/cache flooding. (Pipelines processes records not characters, and unneeded pages/cache-lines never have to be staged in.) The *nix string and file models were great for slow PDP-11s and the like, but make no sense on modern hardware. Fixing the 44 character limit? Do-able: New control blocks, VTOC records, catalog entries, JCL parameters, etc. Much less painful than going to USS. Just my buck three eighty. (Pat R., are you out there?) OREXXMan JCL is the buggy whip of 21st century computing. We want Pipelines in the z/OS base. On Fri, May 11, 2018 at 10:06 AM, Charles Mills <[email protected]> wrote: > Oh for gosh sakes! Every operating system is different. There is no > eleventh commandment "filenames shall be 44 uppercase characters" that UNIX > violated. Tell him a foolish consistency is the hobgoblin of little minds. > Or that the inability to learn new things is a sign of old age. > > Or point out that z/OS is case-dependent. Don't think so? Try referencing > 'sys1.maclib'. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of John McKown > Sent: Friday, May 11, 2018 6:04 AM > To: [email protected] > Subject: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the > Devil? > > OK, I bet I got your attention on that {grin}. > > But, seriously, I am wondering what the "person in the trenches" thinks > about the increasing use of UNIX files and commands becoming more prevalent > on z/OS. I am basically asking because my manager absolutely despises UNIX > files. And hates the current maintenance processes from IBM and CA which > force him to use it. One of his reasons is the case sensitivity of the UNIX > file names. Of course, like most people in the world, his mind has been > corrupted by the case insensitivity of Windows. As well as the very > prevalent use of space characters in Windows file and directory names. This > case sensitivity of names may be another reason why new people, likewise > corrupted by Windows, will take an instant dislike for z/OS. OTOH, Linux > might find it minimally interesting. And maybe even quite interesting, if > IBM would adopt and maintain a port of the GNU infrastructure software. > > What I think, and I am likely stupid on this, is that the Apple HFS+ > approach might work. Just like, at present, when you create a zFS > filesystem, the default for filenames on an HFS+ filesystem are, like > Windows, case _in_sensitive. However, when an HFS+ filesystem is > initialized, it can be set as "case sensitive". This is done on a > filesystem-by-filesystem basis. What might be nice is to enhance(?) zFS so > that it can be made case _in_sensitive (reverse default of HFS+). This > might be very helpful for "naive" z/OS UNIX users. Put the ${HOME} > directory (usually /u) under automount and set the parameters so that when > automount creates & initializes a ${HOME} directory, it is > case-insensitive. And, of course, they should be a way to "flip the switch" > back an forth between case sensitivity and case insensitivity. Of course, > the "make insensitive" conversion will need to check & abort if there two > names in the same directory which are equivalent when case is ignored. I > would think this would be simple; check for possible problems and if none, > just flip the switch in some sort of "header" data area. Regardless of > case sensitivity or insensitivity, it should be case preserving, like > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
