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-MAIN@listserv.ua.edu> on behalf of 
Steve Thompson <ste...@copper.net>
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 <IBM-MAIN@listserv.ua.edu> on behalf of 
> Steve Thompson <ste...@copper.net>
> 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
>

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

Reply via email to