Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

2018-05-15 Thread Paul Gilmartin
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?

2018-05-15 Thread Seymour J Metz
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 List  on 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?

2018-05-15 Thread Seymour J Metz
> 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 List  on 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?

2018-05-15 Thread Phil Smith III
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


Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

2018-05-15 Thread Timothy Sipples
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?

2018-05-14 Thread Paul Gilmartin
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?

2018-05-14 Thread Steve Smith
​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?

2018-05-14 Thread Seymour J Metz
>  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 List  on 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?

2018-05-14 Thread Phil Smith III
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?

2018-05-14 Thread Seymour J Metz
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 List  on 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?

2018-05-14 Thread Seymour J Metz
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 List  on 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?

2018-05-14 Thread Seymour J Metz
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 List  on 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?

2018-05-14 Thread Pew, Curtis G
On May 14, 2018, at 9:58 AM, Steve Thompson  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.

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?

2018-05-14 Thread Paul Gilmartin
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?

2018-05-14 Thread R.S.

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?

2018-05-14 Thread Steve Thompson

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.  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?

2018-05-14 Thread Jerry Callen
On Fri, 11 May 2018 10:46:20 -0400, Hobart Spitz  wrote:

>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?

2018-05-14 Thread John McKown
On Sun, May 13, 2018 at 3:36 PM, Seymour J Metz  wrote:

> 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?

2018-05-14 Thread John McKown
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


Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

2018-05-13 Thread Seymour J Metz
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 List  on 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?

2018-05-13 Thread Seymour J Metz
 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 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.  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?

2018-05-11 Thread Kirk Wolf
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 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.
>
> --
> 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?

2018-05-11 Thread Pew, Curtis G
On May 11, 2018, at 10:39 AM, John McKown  wrote:
> 
> 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?

2018-05-11 Thread Paul Gilmartin
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?

2018-05-11 Thread Carmen Vitullo
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?

2018-05-11 Thread John McKown
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?

2018-05-11 Thread John McKown
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


Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?

2018-05-11 Thread Paul Gilmartin
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?

2018-05-11 Thread John McKown
On Fri, May 11, 2018 at 9:48 AM, Steve Thompson  wrote:

> 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?

2018-05-11 Thread Steve Thompson

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?

2018-05-11 Thread Hobart Spitz
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  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: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?

2018-05-11 Thread Charles Mills
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?

2018-05-11 Thread John McKown
On Fri, May 11, 2018 at 8:44 AM, Tony Thigpen  wrote:

> 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?

2018-05-11 Thread Tony Thigpen
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?

2018-05-11 Thread John McKown
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?

2018-05-11 Thread Mike Wawiorko
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?

2018-05-11 Thread John McKown
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