Re: cms parameters
- --- In firstname.lastname@example.org, "kerravon86" <kerravon86@...>
> > home. So indeed the next release of VM/370 has been delayed.
> > Ultimately, if he cannot put it together, I am very willing to
> > the baton and move forward with it. In any event, I believe weOk, it's now past midnight here, which means that
> > have a new release by year's end. So it's not vaporware, just
> > delayed
> Ok, I'm going to stay awake for the special event.
even in the backward areas of the world the clock
has ticked over. And still no sign.
However, I now know what went wrong.
In the phrase "year's end" - which exact year is
that referring to?
- --- In email@example.com, Dave Wade <g4ugm@...> wrote:
>Well upward compatibility is a goal of z/VM too.
> > Although you have to ask what "370" actually means
> > now. With filenames now allowed to have underscores
> > in them etc, it's long stopped being the 370 from
> > IBM, with the various restrictions that that entails.
> But it should still be 370+. Nothing that works in 370 should
> fail on this
And in a case of "real people, real cases",
someone complained that their personal "BASSM"
macro, which worked fine under OS/370, fails under
OS/380 (just as it would under OS/390). So some
people presumably want to keep the 370 concept.
But then, the same thing will happen for people
who used to be able to type:
and get "XYZ" sent through, and are now getting
mixed case. So EPLIST breaks things too.
> but its missing lots of things in SEP & BSEP,Right. So it's always going to be a fork. The
> never mind SP...
question is how many different forks are required,
and what should they be called? IBM didn't bother
maintaining an old 370+ for people who wanted
their BASSM macros to continue to work. So does
it serve any purpose maintaining both a 370 and
a 380 version? (ignoring any issues such as Fujitsu
wanting their own fork for non-technical reasons).
I had always intended to simply graft any
"unaccepted-into-370" 380 code on top of the 370
version so that it was always a superset. For both
CMS and MVS.
But do note that the number of people who run
Hercules/380 is much less than the number who run
Hercules. So some portion of OS/380, most notably
GCC, will simply not work unless measures are taken
to protect against that (measures which I haven't
bothered taking since I didn't really expect to
take over the normal 370 development). And I don't
really want to be involved in all the 370 decisions
either. E.g. how many disks should be defined, what
type, what user names, which software versions
should be installed, etc etc. My interest is
incremental improvements to PDPCLIB and spreading
it and GCC across the remaining mainframe platforms
(DOS/VS, MUSIC/SP). Plus porting other software
to the mainframe (e.g. bwbasic) - and releasing
just the source code, not executables.