Discussion:
CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
(too old to reply)
John McKown
2018-05-11 13:02:29 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Wawiorko
2018-05-11 13:28:40 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-11 13:34:27 UTC
Permalink
Raw Message
On Fri, May 11, 2018 at 8:29 AM, Mike Wawiorko <
Post by Mike Wawiorko
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.
Post by Mike Wawiorko
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.​
Post by Mike Wawiorko
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-05-11 13:43:21 UTC
Permalink
Raw Message
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
Post by 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-11 14:03:13 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-05-11 14:04:45 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Friday, May 11, 2018 6:04 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-05-11 14:45:00 UTC
Permalink
Raw Message
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.
Post by 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-----
Behalf Of John McKown
Sent: Friday, May 11, 2018 6:04 AM
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-11 15:38:53 UTC
Permalink
Raw Message
Post by 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'.
​Or, if you want to break someone's mind use

//SYSUT2 DD DSN='&SYSUID.x.DATA'

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.
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2018-05-11 15:45:45 UTC
Permalink
Raw Message
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" <***@GMAIL.COM>
To: IBM-***@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?
Post by 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'.
​Or, if you want to break someone's mind use

//SYSUT2 DD DSN='&SYSUID.x.DATA'

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.
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
2018-05-11 15:46:55 UTC
Permalink
Raw Message
well, of course a type, CA-TLMS sorry CA :(



Carmen Vitullo

----- Original Message -----

From: "Carmen Vitullo" <***@HUGHES.NET>
To: IBM-***@LISTSERV.UA.EDU
Sent: Friday, May 11, 2018 10:47:08 AM
Subject: 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" <***@GMAIL.COM>
To: IBM-***@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?
Post by 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'.
​Or, if you want to break someone's mind use

//SYSUT2 DD DSN='&SYSUID.x.DATA'

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.
Post by Charles Mills
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2018-05-11 16:13:48 UTC
Permalink
Raw Message
Post by John McKown
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
***@austin.utexas.edu
ITS Systems/Core/Administrative Services


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2018-05-11 14:46:27 UTC
Permalink
Raw Message
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
Post by 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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-11 15:11:43 UTC
Permalink
Raw Message
Post by 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.
​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.​
Post by Steve Thompson
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.​
Post by Steve Thompson
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!​
Post by Steve Thompson
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.​
Post by Steve Thompson
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.​
Post by Steve Thompson
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.
Post by Steve Thompson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-13 20:25:36 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of Steve Thompson <***@COPPER.NET>
Sent: Friday, May 11, 2018 10:48 AM
To: IBM-***@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
Post by 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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-14 12:22:28 UTC
Permalink
Raw Message
Post by Seymour J Metz
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. ​
Post by Seymour J Metz
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.​
Post by Seymour J Metz
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-14 19:27:45 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of John McKown <***@GMAIL.COM>
Sent: Monday, May 14, 2018 8:23 AM
To: IBM-***@listserv.ua.edu
Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Post by Seymour J Metz
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. ​
Post by Seymour J Metz
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.​
Post by Seymour J Metz
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2018-05-14 14:56:42 UTC
Permalink
Raw Message
Post by Seymour J Metz
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.
Post by Seymour J Metz
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
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 10:48 AM
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
Post by 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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-05-14 15:07:16 UTC
Permalink
Raw Message
  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: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-14 19:17:39 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of R.S. <***@BREMULTIBANK.COM.PL>
Sent: Monday, May 14, 2018 11:08 AM
To: IBM-***@listserv.ua.edu
Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Post by Seymour J Metz
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: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2018-05-14 17:17:13 UTC
Permalink
Raw Message
Post by Seymour J Metz
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.
Post by Seymour J Metz
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
***@austin.utexas.edu
ITS Systems/Core/Administrative Services


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-14 19:19:37 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of Steve Thompson <***@COPPER.NET>
Sent: Monday, May 14, 2018 10:58 AM
To: IBM-***@listserv.ua.edu
Subject: Re: CONTROVERSY! z/OS UNIX: is it an enhancement or a tool of the Devil?
Post by Seymour J Metz
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.
Post by Seymour J Metz
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
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 10:48 AM
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
Post by 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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-11 15:17:44 UTC
Permalink
Raw Message
Post by 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'.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-11 15:38:22 UTC
Permalink
Raw Message
On Fri, May 11, 2018 at 10:19 AM, Paul Gilmartin <
Post by Paul Gilmartin
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.​
Post by Paul Gilmartin
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.​
Post by Paul Gilmartin
-- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-11 15:59:24 UTC
Permalink
Raw Message
Post by 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 !
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
2018-05-11 19:16:13 UTC
Permalink
Raw Message
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 :-)
Post by 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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-13 20:35:10 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of John McKown <***@GMAIL.COM>
Sent: Friday, May 11, 2018 9:03 AM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-14 12:34:29 UTC
Permalink
Raw Message
Post by 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.
​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}.
Post by Seymour J Metz
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jerry Callen
2018-05-14 13:37:42 UTC
Permalink
Raw Message
Post by Hobart Spitz
- 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-14 15:31:40 UTC
Permalink
Raw Message
Post by R.S.
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith III
2018-05-14 20:49:21 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-14 20:59:58 UTC
Permalink
Raw Message
Post by Charles Mills
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 <IBM-***@listserv.ua.edu> on behalf of Phil Smith III <***@AKPHS.COM>
Sent: Monday, May 14, 2018 4:50 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-05-14 22:19:01 UTC
Permalink
Raw Message
​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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-14 23:31:14 UTC
Permalink
Raw Message
Post by 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
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?
Post by Phil Smith III
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...