Re: cms parameters
- --- In email@example.com, "kerravon86" <kerravon86@...>
>I've now tried this with an EXEC on z/VM. I don't
> --- In firstname.lastname@example.org, "kerravon86" <kerravon86@>
> > 2. Only for &CONTROL NOMSG
> For some reason I have a script that needs to run
> &CONTROL MSG.
> So I won't have an EPLIST (even on z/VM?).
appear to be getting an EPLIST under any circumstances.
Unless I make it a REXX instead.
I've tried &CONTROL MSG, &CONTROL NOMSG, &CONTROL
None of them give me an EPLIST. Real z/VM.
- --- 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.