Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Tue, 15 May 2018 11:50:40 -0400, Phil Smith III wrote: > >>Would you submit or vote for an RFE that LOAD/LINK/ATTACH, BLDL, ... >>be made case-insensitive? > >Yes. > I won't vote for it, but please keep this list updated on how it plays out. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Perhaps unclear; I meant "not inspired" in the context of MS/PC-DOS, which sprang from QDOS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Timothy Sipples Sent: Tuesday, May 15, 2018 2:40 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? Seymour Metz wrote: >SCP was certainly inspired by CP/M, but m$ was not. I don't think that's a fair characterization. Microsoft was *deeply* "inspired" by CP/M, per the historical record. In fact, Microsoft was a CP/M licensee and sold CP/M as part of the Microsoft SoftCard for Apple II computers. I'd say that qualifies as "inspired." The Microsoft SoftCard plugged into one of the slots in an Apple II (or successor, such as the popular Apple //e), and it contained a Zilog Z80 microprocessor to run CP/M plus some "glue" logic to wed the card (and operating system) to the Apple II underneath. According to Wikipedia, Microsoft co-founder Paul Allen had the original idea to "port" CP/M to the Apple II. Tim Patterson at Seattle Computer Products (SCP) developed the original SoftCard prototype, and, later, Bill Gates and Don Burtis joined Tim Patterson in finishing the product. The SoftCard was Microsoft's top revenue source in 1980, and it became the #1 most popular CP/M platform. Radoslaw Skorupka wrote: >CP/M was very similar to any DOS version. The most >important (IMHO) exception was lack of directories. 86-DOS, MS-DOS, and PC-DOS did not have subdirectories either when initially released. It wasn't until Version 2.0 (March 8, 1983, along with the IBM PC/XT) that MS-DOS and PC-DOS got subdirectories, inspired by Microsoft's Xenix (UNIX) endeavors. CP/M 2.2 (released sometime in 1979) did not include subdirectories as such but did include 16 numbered user areas, i.e. a fixed number of pre-named subdirectories one level deep. This feature was a direct lift from MP/M. MS-DOS/PC-DOS Version 1.x didn't have any analogous feature. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
> Are you suggesting that there are codepoints that appear in multiple pages >but map differently If Gil is, then he's correct. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Phil Smith III Sent: Tuesday, May 15, 2018 11:50 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? Gil wrote: >OK. I'll try. Simplicity of specification. Simplicity of implementation. >Filenames are strings. Different strings should refer to different files. Categorical imperative there. Seems…circular. >Consistency. With Binder it's easy enough to create a load module: >CASE(M) > >NAME FooBar(R) >Should //STEP EXEC PGM=FOOBAR invoke that program? Why not" >How about //STEP EXEC PGM='FooBar'? Why not? How about >TSO: EXEC *(FooBar)? Binder? I’m talking Unix going back 45 years, not USS. But yes, I’d expect them to invoke the same program. >Would you submit or vote for an RFE that LOAD/LINK/ATTACH, BLDL, ... >be made case-insensitive? Yes. >Why not? I suspect you supplied the answer: >>So it fits the definition of "tradition": The same stupid old way we've >>always done it! >> >"Stupid" indeed. And z/OS is worse than most for inconsistency. Some >interfaces are case-sensitive; others enforce case-insensitivity. Absolutely z/OS is horrible in this regard. So? >And ethnic diversity. Should files named in Cyrillic, Greek, ... be treated >in a case-insensitive fashion? Imagine the implementation complexity >and documentation complexity. Should it be locale-sensitive? Should >Cyrillic filenames be case-insensitive in the Russia locale and Latin >filenames be case sensitive? And vice-versa in a Latin locale? Well, going back to the early days of Unix, I don’t think any of this mattered, so it’s not a defense for the design. But why would case-sensitivity need to change across locales? >Suppose another language is newly added to the Unicode CECP. Should >characters previously considered distinct suddenly be considered equivalent >because they are upper-lower case pairs? >(Don't be Anglocentric in your answer.) Are you suggesting that there are codepoints that appear in multiple pages but map differently—so “a” and “O” might be the upper/lowercase versions of the same character in Blezerbian? I respectfully disbelieve that. >Others have argued here that the filesystem should ignore diacritical marks. >But a Hispanophone sees "año" and "ano" as two very different nouns and >would probably not approve of using them interchangably as a filename. Those are different characters. Unicode folding is an entirely different issue, I think. >Peter Relson, among others, has written here of "invalid" names, implying >GIGO. I disagree with quiet GIGO -- a programmer should be provided at >least a warning message on use of an "invalid" construct. Sorry, don’t grok this point at all! Cheers, …phsiii -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Gil wrote: >OK. I'll try. Simplicity of specification. Simplicity of implementation. >Filenames are strings. Different strings should refer to different files. Categorical imperative there. Seems circular. >Consistency. With Binder it's easy enough to create a load module: >CASE(M) > >NAME FooBar(R) >Should //STEP EXEC PGM=FOOBAR invoke that program? Why not" >How about //STEP EXEC PGM='FooBar'? Why not? How about >TSO: EXEC *(FooBar)? Binder? Im talking Unix going back 45 years, not USS. But yes, Id expect them to invoke the same program. >Would you submit or vote for an RFE that LOAD/LINK/ATTACH, BLDL, ... >be made case-insensitive? Yes. >Why not? I suspect you supplied the answer: >>So it fits the definition of "tradition": The same stupid old way we've >>always done it! >> >"Stupid" indeed. And z/OS is worse than most for inconsistency. Some >interfaces are case-sensitive; others enforce case-insensitivity. Absolutely z/OS is horrible in this regard. So? >And ethnic diversity. Should files named in Cyrillic, Greek, ... be treated >in a case-insensitive fashion? Imagine the implementation complexity >and documentation complexity. Should it be locale-sensitive? Should >Cyrillic filenames be case-insensitive in the Russia locale and Latin >filenames be case sensitive? And vice-versa in a Latin locale? Well, going back to the early days of Unix, I dont think any of this mattered, so its not a defense for the design. But why would case-sensitivity need to change across locales? >Suppose another language is newly added to the Unicode CECP. Should >characters previously considered distinct suddenly be considered equivalent >because they are upper-lower case pairs? >(Don't be Anglocentric in your answer.) Are you suggesting that there are codepoints that appear in multiple pages but map differentlyso a and O might be the upper/lowercase versions of the same character in Blezerbian? I respectfully disbelieve that. >Others have argued here that the filesystem should ignore diacritical marks. >But a Hispanophone sees "año" and "ano" as two very different nouns and >would probably not approve of using them interchangably as a filename. Those are different characters. Unicode folding is an entirely different issue, I think. >Peter Relson, among others, has written here of "invalid" names, implying >GIGO. I disagree with quiet GIGO -- a programmer should be provided at >least a warning message on use of an "invalid" construct. Sorry, dont grok this point at all! Cheers, phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Seymour Metz wrote: >SCP was certainly inspired by CP/M, but m$ was not. I don't think that's a fair characterization. Microsoft was *deeply* "inspired" by CP/M, per the historical record. In fact, Microsoft was a CP/M licensee and sold CP/M as part of the Microsoft SoftCard for Apple II computers. I'd say that qualifies as "inspired." The Microsoft SoftCard plugged into one of the slots in an Apple II (or successor, such as the popular Apple //e), and it contained a Zilog Z80 microprocessor to run CP/M plus some "glue" logic to wed the card (and operating system) to the Apple II underneath. According to Wikipedia, Microsoft co-founder Paul Allen had the original idea to "port" CP/M to the Apple II. Tim Patterson at Seattle Computer Products (SCP) developed the original SoftCard prototype, and, later, Bill Gates and Don Burtis joined Tim Patterson in finishing the product. The SoftCard was Microsoft's top revenue source in 1980, and it became the #1 most popular CP/M platform. Radoslaw Skorupka wrote: >CP/M was very similar to any DOS version. The most >important (IMHO) exception was lack of directories. 86-DOS, MS-DOS, and PC-DOS did not have subdirectories either when initially released. It wasn't until Version 2.0 (March 8, 1983, along with the IBM PC/XT) that MS-DOS and PC-DOS got subdirectories, inspired by Microsoft's Xenix (UNIX) endeavors. CP/M 2.2 (released sometime in 1979) did not include subdirectories as such but did include 16 numbered user areas, i.e. a fixed number of pre-named subdirectories one level deep. This feature was a direct lift from MP/M. MS-DOS/PC-DOS Version 1.x didn't have any analogous feature. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Mon, 14 May 2018 16:50:41 -0400, Phil Smith III wrote: >The funny part is, find the most rabid Unix-head you know, and ask why it's >A Good Thing that filenames are case-sensitive. In my reasonably extensive >experience at playing this game (including 5 years at Linuxcare, with lots >of victims), several things were always true: > >1) They would assert vehemently that it was A Good Thing > >2) They could not articulate why > OK. I'll try. Simplicity of specification. Simplicity of implementation. Filenames are strings. Different strings should refer to different files. Consistency. With Binder it's easy enough to create a load module: CASE(M) NAME FooBar(R) Should //STEP EXEC PGM=FOOBAR invoke that program? Why not" How about //STEP EXEC PGM='FooBar'? Why not? How about TSO: EXEC *(FooBar)? Would you submit or vote for an RFE that LOAD/LINK/ATTACH, BLDL, ... be made case-insensitive? Why not? I suspect you supplied the answer: >So it fits the definition of "tradition": The same stupid old way we've >always done it! > "Stupid" indeed. And z/OS is worse than most for inconsistency. Some interfaces are case-sensitive; others enforce case-insensitivity. And ethnic diversity. Should files named in Cyrillic, Greek, ... be treated in a case-insensitive fashion? Imagine the implementation complexity and documentation complexity. Should it be locale-sensitive? Should Cyrillic filenames be case-insensitive in the Russia locale and Latin filenames be case sensitive? And vice-versa in a Latin locale? Suppose another language is newly added to the Unicode CECP. Should characters previously considered distinct suddenly be considered equivalent because they are upper-lower case pairs? (Don't be Anglocentric in your answer.) Others have argued here that the filesystem should ignore diacritical marks. But a Hispanophone sees "año" and "ano" as two very different nouns and would probably not approve of using them interchangably as a filename. Peter Relson, among others, has written here of "invalid" names, implying GIGO. I disagree with quiet GIGO -- a programmer should be provided at least a warning message on use of an "invalid" construct. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Two smart guys, two smart opinions, no doubt, on a moot point. I'd like to offer that English is not case-sensitive (to any degree comparable to computing use), for what that's worth (imho, a lot). Many language scripts have no such concept as "case" at all. You can argue that "John" and "john" mean different things, but that's specious. Context matters much more than case, especially in programming. Most intelligent uses of case-sensitivity in naming are related cases that could easily be handled in other ways, say by prefixes or suffixes. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
> CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? Both. The Devil is in the detail, and some of the details are diabolical. I'm one of those who spell Unix as Eunix, with malice aforethought, and who grumbles "When the only tool you have is a pipe, everything looks like a filter!", and I grew up on upper case names, but IMHO the case sensitivity is one of the things they got right. And yes, I have created two files whose names differed only in case, when there was a sound reason for so doing. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Phil Smith III Sent: Monday, May 14, 2018 4:50 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? The funny part is, find the most rabid Unix-head you know, and ask why it's A Good Thing that filenames are case-sensitive. In my reasonably extensive experience at playing this game (including 5 years at Linuxcare, with lots of victims), several things were always true: 1) They would assert vehemently that it was A Good Thing 2) They could not articulate why 3) When asked if they would ever create two files, "foo" and "FOO" (or any two combinations of upper/lower), they would agree that would be stupid So it fits the definition of "tradition": The same stupid old way we've always done it! I suspect that a Linux filesystem that was case-insensitive would not break anything, and might lead to sanity. Now, spaces in filenames is another matter, and harder to fix. My time at Linuxcare cured me of ever creating such deliberately, at least! .phsiii -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
The funny part is, find the most rabid Unix-head you know, and ask why it's A Good Thing that filenames are case-sensitive. In my reasonably extensive experience at playing this game (including 5 years at Linuxcare, with lots of victims), several things were always true: 1) They would assert vehemently that it was A Good Thing 2) They could not articulate why 3) When asked if they would ever create two files, "foo" and "FOO" (or any two combinations of upper/lower), they would agree that would be stupid So it fits the definition of "tradition": The same stupid old way we've always done it! I suspect that a Linux filesystem that was case-insensitive would not break anything, and might lead to sanity. Now, spaces in filenames is another matter, and harder to fix. My time at Linuxcare cured me of ever creating such deliberately, at least! .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
SCP was certainly inspired by CP/M, but m$ was not. Certainly there are things in PC/MS-DOS that are somewhat different from CP/M. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of John McKown Sent: Monday, May 14, 2018 8:23 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? On Sun, May 13, 2018 at 3:26 PM, Seymour J Metz wrote: > 1. m$ started with QDOS, not CP/M > Yes you are correct. I was under the impression that QDOS was "inspired" by CP/M-80. At least MS-DOS 1.0 seemed to be CP/M-ish to me. > > 2. CP/M was influence by RT-11 > My ignorance shows here. I know know nothing about DEC system (RT-11 was DEC/PDP, right?). At college, we had a TOPS-20 system that I loved. Especially compared to MVT and Wylbur. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
As I recall, CP/M had PIP from the DEC world, which PC-DOS did not. Wasn't there also a change from ED to EDLIN? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Steve Thompson Sent: Monday, May 14, 2018 10:58 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? On 05/13/2018 04:26 PM, Seymour J Metz wrote: > 1. m$ started with QDOS, not CP/M I wish I still had the documents -- but a long story quite short: I was told CP/M, and the very first copy of MS/DOS that I got, had the same commands and lack of sub-folders that CP/M I had been using had. Granted, I was not a power user of that system, I was experimenting with it. So I didn't have any reason to question what had been said back then. I don't remember QDOS itself -- I have a hazy memory of the name. > 2. CP/M was influence by RT-11 Thank you for this. I Couldn't remember the precise system, but I knew it was involved with a *nix type OS. Regards, Steve Thompson > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Steve Thompson > Sent: Friday, May 11, 2018 10:48 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the > Devil? > > I've got an observation you and your boss probably won't like. > > Windows is based on CP/M (that is what Microsoft started with). > Guess what CP/M was based on. > > Now, here we are 30+ years from M/S and Windows (~ 1983 for first > release), and they have a lower RAS than does Linux which started > after them (~1991). > > So, perhaps your boss should consider going to Linux Desktops and > get away from the problems of Windows? > > As more and more people go to Linux Desktops, Adobe (and others) > would have to change their position and go back to supporting > their products for Linux distros. > > And then the *nix file structure being case sensitive would stop > being a problem, because one would get use to it from working > with it on a daily basis. > > My biggest problem with *nix (POSIX) on z/OS is the goofy way we > have to define the files for it. > > Perhaps the MVS side of z/OS needs to learn to get along with FBA > and we can stop emulating ECKD with FBA, that then emulate FBA to > allow POSIX (Unix System Services and related file systems) to > work on/with z/OS (what overhead). > > [FBA boxes seem to be cheaper than the ones that emulate ECKD > devices -- well at least from where I sit.] > > Just my 2 cents. > > Regards, > Steve Thompson > > On 05/11/2018 09:03 AM, John McKown wrote: >> 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.
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
QDOS was intended to be a clone of CP/M. PC-DOS had some significant differences form CP/M; I don't know whether that was true of QDOS. I vaguely recall that CP/M had PIP with DEC syntax. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of R.S. Sent: Monday, May 14, 2018 11:08 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? W dniu 2018-05-14 o 16:58, Steve Thompson pisze: > On 05/13/2018 04:26 PM, Seymour J Metz wrote: >> 1. m$ started with QDOS, not CP/M > > I wish I still had the documents -- but a long story quite short: I > was told CP/M, and the very first copy of MS/DOS that I got, had the > same commands and lack of sub-folders that CP/M I had been using had. > Granted, I was not a power user of that system, I was experimenting > with it. So I didn't have any reason to question what had been said > back then. > > I don't remember QDOS itself -- I have a hazy memory of the name. CP/M was very similar to any DOS version. The most important (IMHO) exception was lack of directories. BTW: I still have CP/M and hardware capable to run it ;-) First version of MS-DOS I worked consciously with was 3.30, however I had to do with some older version also. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, http://secure-web.cisco.com/1rtIM8OVbiUKxBmNIv5rUCVThGm9EKCX1lLVqDeNJ4I86OCgpk3f-Sc2LfYDfoWWvdJjORXNqrwgdbTGOEIzVTmSb8D888Ndn9cMbMfYi5QkD1OkXleJqmQEu9DB5sMvIZ3a1voem6AxbcSWXpWwS7wxNvC96m10c2fiLPbA0CzDnQkdj8vjl6T1tD5uPUHE5_P1fAzRA_QfD_cQD3VqNkSeEtpDn6SZS-aiYRLuGk4i3jY1t4gRlf3g4I7pJe7A2p8xK_pUmsE95_SDtD0w90edWWCLS-96IO_PafPZYGrSd9qOwhifqCij6U5vmq-LDoAkpnefCLVGBlEuRG8h7ResxsnzXV1G8XagRVPL0IlTs4KddScA9DxcIotpO3EtH5c0_2Nw3dbgtXCCXL-zpIw5VvW6N6V3PYnMhLw-8b0Un7LmAIE1ud34VunauEeHw/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On May 14, 2018, at 9:58 AM, Steve Thompsonwrote: > >> 1. m$ started with QDOS, not CP/M > > I wish I still had the documents -- but a long story quite short: I was told > CP/M, and the very first copy of MS/DOS that I got, had the same commands and > lack of sub-folders that CP/M I had been using had. Granted, I was not a > power user of that system, I was experimenting with it. So I didn't have any > reason to question what had been said back then. > > I don't remember QDOS itself -- I have a hazy memory of the name. > >> 2. CP/M was influence by RT-11 > > Thank you for this. I Couldn't remember the precise system, but I knew it was > involved with a *nix type OS. If you believe Wikipedia (https://en.wikipedia.org/wiki/CP/M#The_beginning_and_CP/M's_heyday) “Various aspects of CP/M were influenced by the TOPS-10 operating system of the DECsystem-10 mainframe computer, which Kildall had used as a development environment.” and (https://en.wikipedia.org/wiki/86-DOS) “Initially known as QDOS (Quick and Dirty Operating System), the name was changed to 86-DOS once SCP started licensing the operating system in 1980. 86-DOS had a command structure and application programming interface that imitated that of Digital Research's CP/M operating system, which made it easy to port programs from the latter. The system was purchased by Microsoft and developed further as MS-DOS and PC DOS.” (I should say that I do believe Wikipedia, at least on this topic. This matches pretty closely to what I remember reading elsewhere.) -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Mon, 14 May 2018 17:08:27 +0200, R.S. wrote: > >CP/M was very similar to any DOS version. The most important (IMHO) >exception was lack of directories. > Interesting. Earliest releases of Mac OS {which I never used) MFS similarly lacked directories. "Folder" membership was instead an attribute in the catalog entry of any file. But no two files, even "in" different folders could have identical names. Later, HFS filled the gap, leaving bizarre conventions to distinguish relative paths from absolute, required for compatibility. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
W dniu 2018-05-14 o 16:58, Steve Thompson pisze: On 05/13/2018 04:26 PM, Seymour J Metz wrote: 1. m$ started with QDOS, not CP/M I wish I still had the documents -- but a long story quite short: I was told CP/M, and the very first copy of MS/DOS that I got, had the same commands and lack of sub-folders that CP/M I had been using had. Granted, I was not a power user of that system, I was experimenting with it. So I didn't have any reason to question what had been said back then. I don't remember QDOS itself -- I have a hazy memory of the name. CP/M was very similar to any DOS version. The most important (IMHO) exception was lack of directories. BTW: I still have CP/M and hardware capable to run it ;-) First version of MS-DOS I worked consciously with was 3.30, however I had to do with some older version also. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On 05/13/2018 04:26 PM, Seymour J Metz wrote: 1. m$ started with QDOS, not CP/M I wish I still had the documents -- but a long story quite short: I was told CP/M, and the very first copy of MS/DOS that I got, had the same commands and lack of sub-folders that CP/M I had been using had. Granted, I was not a power user of that system, I was experimenting with it. So I didn't have any reason to question what had been said back then. I don't remember QDOS itself -- I have a hazy memory of the name. 2. CP/M was influence by RT-11 Thank you for this. I Couldn't remember the precise system, but I knew it was involved with a *nix type OS. Regards, Steve Thompson -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Steve Thompson Sent: Friday, May 11, 2018 10:48 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? I've got an observation you and your boss probably won't like. Windows is based on CP/M (that is what Microsoft started with). Guess what CP/M was based on. Now, here we are 30+ years from M/S and Windows (~ 1983 for first release), and they have a lower RAS than does Linux which started after them (~1991). So, perhaps your boss should consider going to Linux Desktops and get away from the problems of Windows? As more and more people go to Linux Desktops, Adobe (and others) would have to change their position and go back to supporting their products for Linux distros. And then the *nix file structure being case sensitive would stop being a problem, because one would get use to it from working with it on a daily basis. My biggest problem with *nix (POSIX) on z/OS is the goofy way we have to define the files for it. Perhaps the MVS side of z/OS needs to learn to get along with FBA and we can stop emulating ECKD with FBA, that then emulate FBA to allow POSIX (Unix System Services and related file systems) to work on/with z/OS (what overhead). [FBA boxes seem to be cheaper than the ones that emulate ECKD devices -- well at least from where I sit.] Just my 2 cents. Regards, Steve Thompson On 05/11/2018 09:03 AM, John McKown wrote: 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 Windows. I know the response from both IBM and CA is/will be basically "suck it up, maggot!" (to quote a not-so-favorite D.I.) Oh, well, it is Friday. And, for me, this is almost a reasonable thought. -- 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
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, 11 May 2018 10:46:20 -0400, Hobart Spitzwrote: >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. This reflects a lack of understanding of Unix programming. There are no "separate techniques for processing text ... and binary data", any more so than there are on MVS. A Unix file is a stream of bytes, period. Many programs interpret that stream as a sequence of textual lines, delimited by newlines; this uniform representation makes possible the rich array of text-processing tools available in Unix, and enables files written on one platform to be usefully consumed on another platform. The notion that Unix pipelines are "crippled" by their text orientation reflects a lack of familiarity with Unix. If you WANT to process binary data, it's easy to write programs that treat files as containing a sequence of records, either fixed length (think FB) or variable (think VB) with explicit record lengths. Every program, on any platform, places restrictions on its inputs and outputs. z/OS programs are no different. In fact, the standard z/OS access methods very tightly couple programs to very specific dataset organizations and record formats. Unix System Services has brought all of the powerful text processsing tools of Unix to z/OS. I can't see how that can be considered a bad thing. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Sun, May 13, 2018 at 3:36 PM, Seymour J Metzwrote: > I'm comfortablewith using Unix files. I'm not comfortable with packaging > for MVS components that seems done by people without a clue, but it's not > fair to blame that on the use of Unix. > I'm trying to figure out why IBM uses "pax" files in a z/OS UNIX filesystem for their distribution. I know that they need some way to distribute z/OS UNIX files and "legacy" datasets in a single package. I have a couple things on the CBT which do that. What I did was use pax to write a pax archive as a member of an FB/80 PDS. I then XMIT'd the PDS to a sequential dataset. Of course, the reason that I did this is because that is how Sam Golob wants the things on the CBT to be packaged. I don't really know which method is better. Mine is at least more traditional. If the XMIT'd sequntial dataset is really large, it might be a good idea to AMATERSE it. I think my boss would prefer this, because he wouldn't need to directly interact with UNIX files. The processing of a package would be something like: 1) if needed: use AMATERSE to UNPACK the compressed XMIT'd PDS 2) RECEIVE the XMIT file ( RECEIVE INDATASET(...)) 3) Use ISPF edit to display the PDS directory The restored PDS would perhaps have members such as $DOC, $UNLOAD, and other members which might contain PAX'd UNIX files (one member per directory?), XMIT'd PDS libraries and DSORG=PS datasets. The $UNLOAD job would have steps to "expand" all of the distributed libraries, PS datasets, and UNIX files. All the DSNs and other "customizable" names would be referenced via SET statements at the start of the job (rather than example "hard coded" DSNs which each need to be edited.) Just my thoughts, they are likely worth what you paid for them {grin}. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Sun, May 13, 2018 at 3:26 PM, Seymour J Metzwrote: > 1. m$ started with QDOS, not CP/M > Yes you are correct. I was under the impression that QDOS was "inspired" by CP/M-80. At least MS-DOS 1.0 seemed to be CP/M-ish to me. > > 2. CP/M was influence by RT-11 > My ignorance shows here. I know know nothing about DEC system (RT-11 was DEC/PDP, right?). At college, we had a TOPS-20 system that I loved. Especially compared to MVT and Wylbur. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
I'm comfortablewith using Unix files. I'm not comfortable with packaging for MVS components that seems done by people without a clue, but it's not fair to blame that on the use of Unix. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of John McKown Sent: Friday, May 11, 2018 9:03 AM To: IBM-MAIN@listserv.ua.edu 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 Windows. I know the response from both IBM and CA is/will be basically "suck it up, maggot!" (to quote a not-so-favorite D.I.) Oh, well, it is Friday. And, for me, this is almost a reasonable thought. -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
1. m$ started with QDOS, not CP/M 2. CP/M was influence by RT-11 -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion Liston behalf of Steve Thompson Sent: Friday, May 11, 2018 10:48 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? I've got an observation you and your boss probably won't like. Windows is based on CP/M (that is what Microsoft started with). Guess what CP/M was based on. Now, here we are 30+ years from M/S and Windows (~ 1983 for first release), and they have a lower RAS than does Linux which started after them (~1991). So, perhaps your boss should consider going to Linux Desktops and get away from the problems of Windows? As more and more people go to Linux Desktops, Adobe (and others) would have to change their position and go back to supporting their products for Linux distros. And then the *nix file structure being case sensitive would stop being a problem, because one would get use to it from working with it on a daily basis. My biggest problem with *nix (POSIX) on z/OS is the goofy way we have to define the files for it. Perhaps the MVS side of z/OS needs to learn to get along with FBA and we can stop emulating ECKD with FBA, that then emulate FBA to allow POSIX (Unix System Services and related file systems) to work on/with z/OS (what overhead). [FBA boxes seem to be cheaper than the ones that emulate ECKD devices -- well at least from where I sit.] Just my 2 cents. Regards, Steve Thompson On 05/11/2018 09:03 AM, John McKown wrote: > 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 > Windows. > > I know the response from both IBM and CA is/will be basically "suck it up, > maggot!" (to quote a not-so-favorite D.I.) > > Oh, well, it is Friday. And, for me, this is almost a reasonable thought. > -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Here you go John: DEAR BOSS, YOU MAY BE A LUDDITE. SINCERELY, JOHN MCKOWN Kirk Wolf Dovetailed Technologies http://dovetail.com PS> Seriously, it is fair to say that POSIX and zFS files need better support in z/OS. Take BPXBATCH for example (please :-) On Fri, May 11, 2018 at 8:03 AM, John McKownwrote: > 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 > Windows. > > I know the response from both IBM and CA is/will be basically "suck it up, > maggot!" (to quote a not-so-favorite D.I.) > > Oh, well, it is Friday. And, for me, this is almost a reasonable thought. > > -- > We all have skeletons in our closet. > Mine are so old, they have osteoporosis. > > Maranatha! <>< > John McKown > > -- > 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On May 11, 2018, at 10:39 AM, John McKownwrote: > > I appreciate the response so far. I'm really getting the idea that people > are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic" > about it. I don’t know that I’d describe myself as “enthusiastic”, but “resigned” is more negative than how I feel. I really appreciate being able to use Unix tools like git and make and such in z/OS. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, 11 May 2018 11:47:08 -0400, Carmen Vitullo wrote: >Talking about strange dsn allocations, I worked as a contractor Y2K for state >Govmt, after updating TLSM to support OS/390 2.5 one of our agency's support >folks told me I broke TLMS because the dataset(s) they use to write to take >for DOL is, for example DSN='Sears Roebuck and Co', DISP=(,KEEP),UNIT=CART > >well I said, you can't do that ! that's not a valid datasets name, but we've >been creating them for many years, I found out I was very wrong, CA knew >better and provided a PTF fix for the issue, embarrassed, ah yup , I was ! > When I was very new to MVS I created several data sets with such names. Experimenting, self-training in the use of apostrophes in JCL. I left them allocated. Within a few days, admins descended on me, irritated because their utility for scratching nonconforming data sets couldn't handle them. Too nonconforming, I guess. DFSMS should make the rules. Assembler and all higher layers should obey them and not invent additional restrictions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Talking about strange dsn allocations, I worked as a contractor Y2K for state Govmt, after updating TLSM to support OS/390 2.5 one of our agency's support folks told me I broke TLMS because the dataset(s) they use to write to take for DOL is, for example DSN='Sears Roebuck and Co', DISP=(,KEEP),UNIT=CART well I said, you can't do that ! that's not a valid datasets name, but we've been creating them for many years, I found out I was very wrong, CA knew better and provided a PTF fix for the issue, embarrassed, ah yup , I was ! Carmen Vitullo - Original Message - From: "John McKown"To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, May 11, 2018 10:39:55 AM Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil? On Fri, May 11, 2018 at 9:06 AM, Charles Mills 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'. > Or, if you want to break someone's mind use //SYSUT2 DD DSN='' On my system (likely because my ID is very powerful), a data set is actually created on a volume. So DADSM will accept the DSN. I had to use STORCLAS=NONSMS to force non-SMS allocation. If I didn't, SMS would fail the allocation (yah!). However, I couldn't get it catalogued. And when using JCL to allocate it, I get: 3 IEF648I INVALID DISP FIELD- KEEP SUBSTITUTED 3 IGD01008I NULL STORCLAS ASSIGNED I now have a DSN on a non-SMS volume which is not catalogued (which is valid). But, although it is displayed by ISPF 3.4, it cannot be used in any way that I have found. I get the weird message "Invalid change". I guess ISPF is uppercasing the DSN and then whining that the values are different. Now that I think about it, I remember many years ago, at my first job, they were converting from DOS to VS1. The DOS system actually had a DSN on a volume named 'WATER MONSTER FILE' (aka Water Master File -- city water dept.). And I could "use it" on VS1. But not really, because it was a DOS ISAM dataset. I appreciate the response so far. I'm really getting the idea that people are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic" about it. > > Charles > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, May 11, 2018 at 10:19 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > I hate EBCDIC! I wish IBM had provided just an EBCDIC kernel and let FOSS > supply the shell > and utilities. > NIH. I somewhat understand why IBM did this. First, IBM is very concerned with support and quality. GNU software is top quality. But IBM would need to devote resources to supporting it. And, given the license, any fixes they made to GNU software would need to be returned to GNU and anyone else "on request". If good (which is pretty much a "given"), it would be integrated with the base GNU and distributed to all other GNU user for, horrors!, _FREE_! I am reasonable certain that this causes IBM to totally reject it. More or less "if it cost us money to write, it should cost you use." Damn, there goes my cynicism again. > > Woe be unto web developers who code URLs with chaotic cases then try to > port their > site to a UNIX Apache server! > Yeah, I know some Windows people who CamelCase in some code, for readability, and lowercase in the filesystem for "ease of typing". Also, woe betide those who use Windows file manage to put spaces in the filename. Many parsers break on spaces (or other white space) and so the code whines like a 2yr old (or an old sysprog) when some code (usually a line command) excavates its bowels on it. > > -- gil > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, May 11, 2018 at 9:06 AM, Charles Millswrote: > 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'. > Or, if you want to break someone's mind use //SYSUT2 DD DSN='' On my system (likely because my ID is very powerful), a data set is actually created on a volume. So DADSM will accept the DSN. I had to use STORCLAS=NONSMS to force non-SMS allocation. If I didn't, SMS would fail the allocation (yah!). However, I couldn't get it catalogued. And when using JCL to allocate it, I get: 3 IEF648I INVALID DISP FIELD- KEEP SUBSTITUTED 3 IGD01008I NULL STORCLAS ASSIGNED I now have a DSN on a non-SMS volume which is not catalogued (which is valid). But, although it is displayed by ISPF 3.4, it cannot be used in any way that I have found. I get the weird message "Invalid change". I guess ISPF is uppercasing the DSN and then whining that the values are different. Now that I think about it, I remember many years ago, at my first job, they were converting from DOS to VS1. The DOS system actually had a DSN on a volume named 'WATER MONSTER FILE' (aka Water Master File -- city water dept.). And I could "use it" on VS1. But not really, because it was a DOS ISAM dataset. I appreciate the response so far. I'm really getting the idea that people are more "resigned" to UNIX as part of z/OS, rather than "enthusiastic" about it. > > Charles > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, 11 May 2018 07:06:11 -0700, Charles Mills 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'. > Peter Relson (among others) lectures me that such data set names and member names are "invalid"; GIGO. If invalid, why does DFSMS allow me to create (but not catalog) them? Limited resources a half-century ago for such error checking is the weakest of excuses: nowadays that error checking could easily be added. Or z/OS could be made case-insensitive. NTFS *is* case-sensitive. Cygwin tells me of a bit in Registry that tells applications whether to call the I/O system in a case-sensitive or insensitive manner. (Also need to tweak /etc/fstab for Cygwin.) Alas, most applications ignore that setting and use case-insensitive. With Cygwin I created several files in one directory with names differing only in character case. Cygwin treats them cleanly. Explorer displays all with correct names, but when I click on one it's unpredictable which opens. "dir" displays all correctly: names, sizes, and timestamps. Again, when I use one in a cmd.exe command it's unpredictable which one is actually used. Cygwin warns that executable command search is unconditionally case-insensitive. I hate EBCDIC! I wish IBM had provided just an EBCDIC kernel and let FOSS supply the shell and utilities. Woe be unto web developers who code URLs with chaotic cases then try to port their site to a UNIX Apache server! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, May 11, 2018 at 9:48 AM, Steve Thompsonwrote: > I've got an observation you and your boss probably won't like. > > Windows is based on CP/M (that is what Microsoft started with). Guess what > CP/M was based on. > Hum, I used CP/M on a z80 based system back in the day. I don't recall what it was based upon. I thought it was "new" from Digital Research (Gary Kindall). I know that it targeted the 8080 architecture. > > Now, here we are 30+ years from M/S and Windows (~ 1983 for first > release), and they have a lower RAS than does Linux which started after > them (~1991). > > So, perhaps your boss should consider going to Linux Desktops and get away > from the problems of Windows? > Too bad that the company CIO is a devoted Windows lover who despises any other platform: Wintel or Death! seems to be his mantra. > > As more and more people go to Linux Desktops, Adobe (and others) would > have to change their position and go back to supporting their products for > Linux distros. > I'd love that! > > And then the *nix file structure being case sensitive would stop being a > problem, because one would get use to it from working with it on a daily > basis. > Eventually. Unless the big players like RedHat, Canonical, et al. "did an Apple" and created a filesystem (ext5?) which could be set as "case insensitive" in order to placate the masses and get market share. > > My biggest problem with *nix (POSIX) on z/OS is the goofy way we have to > define the files for it. > Hum, would you expand upon that? I don't really have any problems defining files. Creating a new filesystem is a bit "weird" to me, but that's because I use the zfsadm command from a "true" (not TSO OMVS) UNIX shell prompt. The use of JCL and that program which I can never remember is a bit weird. And needing to enclose the PATH= value in ' marks is a bit strange, but understandable from the JCL viewpoint. > > Perhaps the MVS side of z/OS needs to learn to get along with FBA and we > can stop emulating ECKD with FBA, that then emulate FBA to allow POSIX > (Unix System Services and related file systems) to work on/with z/OS (what > overhead). > [FBA boxes seem to be cheaper than the ones that emulate ECKD devices -- > well at least from where I sit.] > YES! +infinity on that. The is the barest beginning of that in z/OS with "z/OS FBA Services" for a 2107 with the zDDB feature. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa800/fbaasm.htm That gives the conceptual equivalent to using EXCP or XDAP on an unformatted ECKD device. IBM needs to work on supported "access method" type facilities. I'd start with the "next generation" zFS filesystem being able to use "z/OS FBA Services". This shouldn't be, conceptually, a big problem. The current zFS is a VSAM LINEAR dataset. Which is basically a DSN which is formatted as 4K physical blocks. The DSN is physically allocated to the ZFS address space. An FBA device on z/OS is "dedicated" to a single address space, so that should work the same -- the FBA device is dedicated to the ZFS address space. IBM "just" needs to write an I/O routine which uses z/OS FBA Services instead of VSAM LINEAR to access it and Bob's your uncle. > > Just my 2 cents. > > Regards, > Steve Thompson > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
I've got an observation you and your boss probably won't like. Windows is based on CP/M (that is what Microsoft started with). Guess what CP/M was based on. Now, here we are 30+ years from M/S and Windows (~ 1983 for first release), and they have a lower RAS than does Linux which started after them (~1991). So, perhaps your boss should consider going to Linux Desktops and get away from the problems of Windows? As more and more people go to Linux Desktops, Adobe (and others) would have to change their position and go back to supporting their products for Linux distros. And then the *nix file structure being case sensitive would stop being a problem, because one would get use to it from working with it on a daily basis. My biggest problem with *nix (POSIX) on z/OS is the goofy way we have to define the files for it. Perhaps the MVS side of z/OS needs to learn to get along with FBA and we can stop emulating ECKD with FBA, that then emulate FBA to allow POSIX (Unix System Services and related file systems) to work on/with z/OS (what overhead). [FBA boxes seem to be cheaper than the ones that emulate ECKD devices -- well at least from where I sit.] Just my 2 cents. Regards, Steve Thompson On 05/11/2018 09:03 AM, John McKown wrote: 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 Windows. I know the response from both IBM and CA is/will be basically "suck it up, maggot!" (to quote a not-so-favorite D.I.) Oh, well, it is Friday. And, for me, this is almost a reasonable thought. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
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 Millswrote: > 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, May 11, 2018 6:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, May 11, 2018 6:04 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, May 11, 2018 at 8:44 AM, Tony Thigpenwrote: > I don't believe that John said anything about the command line parameters. > He was talking about the file system only. As for the command line, the > only thing 'affected' would be the name of the command (including any > path). It could still be entered in lower-case, but he file system would > find it without regard to the case. So, it could be specified either as > upper-case or lower-case and still work. Correct. Most "historic" UNIX commands are both short and lower case. Making them faster and easier to type on a KSR33 or other "teletype" terminal. Another thing, IMO, is that z/OS UNIX "suffers" for a lact of X-client applications. So "point'n'click" is difficult to implement. But I don't really believe that IBM is positioning z/OS UNIX as a "end user experience" product. Just as an "back office infrastructure" product for things like WAS, CICS Web Services, and so on, to use. > > > Tony Thigpen > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
I don't believe that John said anything about the command line parameters. He was talking about the file system only. As for the command line, the only thing 'affected' would be the name of the command (including any path). It could still be entered in lower-case, but he file system would find it without regard to the case. So, it could be specified either as upper-case or lower-case and still work. Tony Thigpen Mike Wawiorko wrote on 05/11/2018 09:29 AM: Just get used to z/OS Unix (Posix?) being case sensitive. Many command modifiers have entirely different meanings in either case: command -x v. command -X Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Services Limited provides support and administrative services across Barclays group. Barclays Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- 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: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
On Fri, May 11, 2018 at 8:29 AM, Mike Wawiorko < 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > Just get used to z/OS Unix (Posix?) being case sensitive. > I completely agree with you. But many people with a Windows background are going to be "upset". I don't know how difficult it would be make case insensitivity selectable by filesystem. I think it would be of some use. But it is "cost vs. benefit" again. And I am not competent to determine that. > > Many command modifiers have entirely different meanings in either case: > command -x v. command -X > Another thing that Windows corrupted people dislike. But they are a vast majority, so it make make "marketing" wisdom to bow to them. > > Mike Wawiorko > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Just get used to z/OS Unix (Posix?) being case sensitive. Many command modifiers have entirely different meanings in either case: command -x v. command -X Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Services Limited provides support and administrative services across Barclays group. Barclays Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 Windows. I know the response from both IBM and CA is/will be basically "suck it up, maggot!" (to quote a not-so-favorite D.I.) Oh, well, it is Friday. And, for me, this is almost a reasonable thought. -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN