Re: The Road to V9.0

[Simon Clubley]

On 2019-10-10, clair...@vmssoftware.com <clairg...@gmail.com> wrote:
> Below is a recent log from booting the system and executing a few commands and running SDA. (I edited out a bunch of our own debugging messages, otherwise it is the exact screen capture of a real system boot.) Two major things about to round into shape are 1) switching from the memory disk to the real system disk and 2) now that basic exception handling is in place, fleshing out the condition handlers and signaling.
>

[I've changed the subject line back to its original one.]

Ok, now this is starting to look _seriously_ interesting. :-)

Very well done on getting this far. When do you think we might start
seeing some of the user level applications, such as EDT or EVE, running
and a x86 node join a cluster ?

>
> VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFBG-N4A
>
> Copyright 2019 VMS Software, Inc.
>
> MDS Mitigation active, variant verw(MD_CLEAR)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That caught my attention. Which of the other architectural level
vulnerabilities you have had to mitigate against on VMS ?

For anyone wondering what this is all about, the following shows the
steps Red Hat have taken to mitigate against this:

https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it

Thanks for the update Clair,

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[clairg...@gmail.com]

On Thursday, October 10, 2019 at 8:25:39 AM UTC-4, Simon Clubley wrote:
> Very well done on getting this far. When do you think we might start
> seeing some of the user level applications, such as EDT or EVE, running
> and a x86 node join a cluster ?

Testing EDT now. Ran into a compiler issue and should have a fix to test today. (Same problem when testing DIFF.)

We are not planning on clusters for early 9.0 so it is not currently being pursued.

> > MDS Mitigation active, variant verw(MD_CLEAR)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That caught my attention. Which of the other architectural level
> vulnerabilities you have had to mitigate against on VMS ?
>

I'll leave this for Camiel to answer.

[johnwa...@yahoo.co.uk]

I'm not sure I'd class MDS as an "architectural" vulnerability
but I'd speculate that others may disagree. It looks a lot like
an Intel-specific implementation issue in my book.

Fwiw, I spent half an hour or more reading summaries and
white papers and watching a Red Hat talking head (why provide a
YouTube talking head when a paper or even a transcript would
be indexable, searchable, etc???) before I reverted to the
MDSattacks FAQ at
https://mdsattacks.com/
which currently includes the following text:
"Am I affected?

Very likely. Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware.

Processors from other vendors (AMD and ARM) do not appear to be affected. Official statements from these vendors can be found in the RIDL and Fallout papers."

I'll repeat the important bit:
"Processors from AMD and ARM do not appear to be affected."

And over at
https://www.securityweek.com/intel-mds-vulnerabilities-what-you-need-know
it is written that POWER and SPARC architectures are not
affected.

So for the moment it's looking like it's just Intel's own
x86(64) implementations that are broken (again?).

To me it sounds once again like Intel's attempts to deliver
ever-faster x86-compatible silicon, which seem to lead to
chip designers discarding important security-relaed attributes
of data and instructions and other stuff which needs extra
care in a world of speculative execution and branch prediction
and out of order execution and cacheable vs noncacheable
regions and various other such 'modern' delights, without
a clean model for architectural consistency of registers,
memory, interfaces, read and write ordering, privileged
hardware (including hi-res timers), and generally a lack
of attention to "rolling back the speculative changes to
visible state", have once again come back to bite the world
of Intel x86 dependent hardware and software and people.

But it's easy for me to say that.

In passing: Has anybody noticed what happens if you try
searching for
"How do MDS attacks affect VMS"

There's a reason I started referring to VSIVMS a while
back :)

[Dave Froble]

When has Intel ever worried about their CPUs working correctly?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Terry Kennedy]

On Friday, October 11, 2019 at 8:23:09 PM UTC-4, Dave Froble wrote:
> When has Intel ever worried about their CPUs working correctly?

FDIV bug, as one example. Intel took a pre-tax charge of half a billion USD (1995 USD, roughly 850M today). Led to the introduction of patchable microcode and the disclosure of most of the "Appendix H" secrets. Also led to the decision to publish for general consumption (as opposed to OEM-confidential) detailed errata for Intel products.

More recently, Atom C2000 bug (2016).

[Dave Froble]

On 10/11/2019 11:33 PM, Terry Kennedy wrote:
> On Friday, October 11, 2019 at 8:23:09 PM UTC-4, Dave Froble wrote:
>> When has Intel ever worried about their CPUs working correctly?
>
> FDIV bug, as one example.

My memory of this was that Intel really didn't want to replace the
defective CPUs. They finally did, reluctantly, but only if the
defective CPU was returned.

[John Reagan]

Since Clair mentioned that EDT and DIFF were held up by compiler issues, I'll give another one of my exciting episodes of

"Adventures in compiler bugs with static initialization"

As we are compiling a wider variety of BLISS code we had a rash of 3 BLISS bugs all in a week. As background, the interface from the compiler frontends to GEM is a very PSECT-oriented interfaces. Frontend says "put these bytes at offset N in PSECT P" and "associated global name A with PSECT offset N". By contrast, the LLVM notion is that "variables can be placed into sections", "variables have initial values", and the early LLVM we're using for the cross-compilers has limited support for aliased symbols. [Newer LLVMs have better support and we will switch to that when we get there.]

[Short interlude for a free BLISS Tip O' The Week...

In BLISS, the construct PLIT stands for Pure LITeral. It is how you define a readonly literal of any sequence of bytes, words, longwords, strings, etc. PLITs also have a magic count that proceeds the data. By contrast UPLIT (Uncounted Pure LITeral) omits the count. UPLIT is by far the most common form. You only see PLITs in places where tables are built by BLISS macros and you want the compiler to count the number of things placed in the readonly memory.

We now return you to the bug report already in progress...]

Bug #1

There was code in EDT that defined a constant that was shared with multiple modules.

GLOBAL BIND TBL = UPLIT (1,2,3);

[I simplified it for this discussion.] The BLISS frontend created two symbols. An anonymous symbol named P.AAA and a global symbol TBL. As mentioned before, the frontend also said "put literals 1,2,3 into the PLIT PSECT at offset N". It also said "associate global symbol TBL with PLIT PSECT at offset N".

The GEM-to-LLVM converter (ie, G2L) got confused and told LLVM about the variable named P.AAA with the initial values and also about a separate variable named TBL with an initial value of all zeros. We needed extra code to propagate the initial values from P.AAA to TBL; to generate only a single LLVM variable; and to map references from both P.AAA and TBL to that single symbol.

We already did the right thing with non-global BINDs, but GLOBAL BINDs need extra work (GLOBAL BINDs get extra work in the BLISS frontend already).

Bug #2

There was a variable that was being initialized with a sequence of 5 byte elements. A byte followed by a pointer to a counted string with something like

GLOBAL TBL2 = BLOCK[100,BYTE] INITIAL (UPLIT BYTE(1,%ASCIC 'ONE', 2, %ASCIC 'TWO'))

and so on.

As I mentioned earlier, GEM would just want to put those values into the underlying PSECT and also associate the name TBL2 with that same offset. LLVM wants a structured constants. So we have to look at the initializers and invent some type that would match the shape of the initializer in spite of BLISS having no such type. We ended up with a

struct {byte, long, byte, long}

and so forth. BLISS wants those to be byte packed and generated code to match. However, we messed up the inferred type we used to describe the initializer and it ended up with alignment padding between the 'byte' and 'long' fields. The initializer put the bytes in the wrong spot and actually ran over the end putting bytes into subsequent variables. There are 'packing' knobs and 'alignment' knobs in LLVM to support things like __attribute__((packed)) and __attribute__((aligned)) that you can use in clang (and gcc). We just needed to tell LLVM exactly what we wanted and not accept the defaults.

Bug #3

Remember the PLIT I talked about earlier? That is implemented by the BLISS frontend generating TWO symbols. One, the P.AAA, is the data bytes. And another symbol, carefully placed just before P.AAA in the PSECT, that is initialized with the count.

The G2L converter didn't do all the symbols in increasing offset order due to the BLISS frontend not filling in a particular flag in that "preceding count" symbol and it was placed somewhere else. So code that does

INCR I FROM 0 TO (.TBL[-1] - 1) DO

would fetch something that wasn't the count and use that as the loop's termination value. You'd get something that wasn't quite an infinite loop, but instead of being INCR I FROM 0 TO 3, it would be some very large value.

[Phillip Helbig (undress to reply)]

In article <ac8ce415-a2d1-407c...@googlegroups.com>, John

Reagan <xyzz...@gmail.com> writes:

> Since Clair mentioned that EDT and DIFF were held up by compiler issues,

Nice that EDT is still being maintained! :-)

[clairg...@gmail.com]

EDT has always been part of the standard VMS build. We need an editor early on in 9.0 so we started poking at it to see if it worked. We will get back to it soon.

With a couple easy source code workarounds for the compiler problems, DIFF works.

CG$ diff cg.com cg5.com
************
File DMM0:[SYSEXE]CG.COM;18
23 $ type cg.com
24 $ write sys$output "Testing COPY"
25 $ copy/log cg1.com cg2.com
26 $ dir
27 $ write sys$output "Testing DELETE"
28 $ delete/log cg2.com.*
29 $ dir
******
File DMM0:[SYSEXE]CG5.COM;3
23 $ type cg5.com
24 $ write sys$output "Testing COPY"
25 $ copy/log cg1.com cg3.com
26 $ dir
27 $ write sys$output "Testing DELETE"
28 $ delete/log cg3.com.*
29 $ dir
************

Number of difference sections found: 1
Number of difference records found: 6

DIFFERENCES /MERGED=1-
DMM0:[SYSEXE]CG.COM;18-
DMM0:[SYSEXE]CG5.COM;3
CG$
CG$ diff cg.com cg5.com/para
-------------------------------------------------------------------------------
File DMM0:[SYSEXE]CG.COM;18 | File DMM0:[SYSEXE]CG5.COM;3
------------------- 23 ------------------------------------ 23 ----------------
$ type cg.com | $ type cg5.com
$ write sys$output "Testing COPY" | $ write sys$output "Testing COPY"
$ copy/log cg1.com cg2.com | $ copy/log cg1.com cg3.com
$ dir | $ dir
$ write sys$output "Testing DELETE" | $ write sys$output "Testing DELETE"
$ delete/log cg2.com.* | $ delete/log cg3.com.*
-------------------------------------------------------------------------------

Number of difference sections found: 1
Number of difference records found: 6

DIFFERENCES /PARALLEL-
DMM0:[SYSEXE]CG.COM;18-
DMM0:[SYSEXE]CG5.COM;3
CG$

[Alan Frisbie]

On 10/12/2019 08:06 PM, John Reagan wrote:
> Since Clair mentioned that EDT and DIFF were held up by compiler issues,
> I'll give another one of my exciting episodes of
> "Adventures in compiler bugs with static initialization"

Thanks, John, for this peek into the darker regions of the porting
effort. It is a reminder of what a non-trivial job this is.

Alan Frisbie

[Phillip Helbig (undress to reply)]

In article <d12a100d-d42c-4693...@googlegroups.com>,

"clair...@vmssoftware.com" <clairg...@gmail.com> writes:

> > Nice that EDT is still being maintained! :-)
>
> EDT has always been part of the standard VMS build. We need an editor
> early on in 9.0 so we started poking at it to see if it worked. We will
> get back to it soon.

That's good.

[Dave Froble]

Question for you John ...

Are these problems you're correcting actual poor / bad coding? I'm
getting the impression that for most it's just in the conversion to LLVM.

Will the modified code still work on VAX / Alpha / itanic, or is it not
backward compatible?

You have reported some bugs in the past. The reversed operands in the
Macro-32 example was such.

[Robert A. Brooks]

On 10/13/2019 3:18 PM, Dave Froble wrote:

> Question for you John ...
>
> Are these problems you're correcting actual poor / bad coding?  I'm getting the
> impression that for most it's just in the conversion to LLVM.

The BLISS code is not in error and will not be modified. Although John provided
a workaround for the EDT issue, I'm going to wait for a newer compiler, because
there are too many instances of that coding style for me to make a lot of
changes that will not be necessary once we have a newer compiler.

To be clear, the code in question is NOT either poor, unsafe, or otherwise
non-standard.

> Will the modified code still work on VAX / Alpha / itanic, or is it not backward
> compatible?

The code that's being modified is in the compiler tool chain, likely in the
GEM-to-LLVM shim.

The application code in question will remain as is.

--
-- Rob

[Simon Clubley]

On 2019-10-13, Dave Froble <da...@tsoft-inc.com> wrote:
>
> Question for you John ...
>
> Are these problems you're correcting actual poor / bad coding? I'm
> getting the impression that for most it's just in the conversion to LLVM.
>

This is not poor coding as I understand it.

This appears to be about different abstraction levels in VMS interfaces
versus (for example) Linux interfaces.

From what I can see, things which are an hidden implementation detail
in the ABI on Linux (and hence are invisible to the Linux code being
compiled) are visible at source code level in VMS and hence need to be
implemented in a way which does not break existing code.

An example I have used previously might make this clear, although this
is not directly related to the current example John posted:

In traditional VMS control blocks, the address of a memory location is
a raw 32-bit longword. It is _NOT_ an abstracted language level pointer
to a memory location.

You can't move the traditional VMS control blocks to a fully 64-bit
address space without implementing a new VMS control block with addresses
that are 64-bit wide. This is something which is very visible at source
code level.

OTOH, on Linux, when you move between 32-bit and 64-bit the work involved
is a lot easier and, within the application, quite a lot of this can be
handled transparently by the compiler which knows that the width of a
pointer is now 64-bits instead of 32-bit and generates the correct code
for you automatically.

This is not fully automatic (for example, if you are using some external
interface which is only 32-bit aware), but within your code it's a _lot_
easier to handle these kinds of problems at source code level on Linux
than it has traditionally been on VMS.

This is the basic difference between an API designed to support assembly
language applications (VMS) versus APIs designed to support languages
which have additional levels of abstractions (C on Unix).

This memory pointer issue is one example of how the VMS data structures
and APIs simply tend to have a lower level of abstraction at source code
level.

[johnwa...@yahoo.co.uk]

The (Open)VMS calling standard covers a lot of these
sharp edges, as do various flavours of descriptor, but
things like EDT and DIFF (and BLISS) do go back quite
a long time.


This isn't exclusively, or even primarily, an (Open)VMS
issue. E.g. just ask the many folks who were around when
the Sun community moved from 32bit to 64bit. Then there
was DEC OSF/1 aka Tru64; compatibility with 32bit UNIX
code forced DEC OSF/1's 64bit compiler+linker to
introduce -taso ("truncated address space option")
so that software that unwisely assumed that pointers
would fit in 32bits might stand a chance of working on
Tr64.

Eeven RATFOR had pointer types, back in the 1970s. But
how many people took the trouble to thimk ahead?

[John Reagan]

Just the differences in GEM vs LLVM. Nothing more. Not related to pointer sizes, descriptors, Linux, the Illuminati, etc

LLVM's model is that "variables live in sections", "variables have initial values". GEM's model is "data lives in PSECTs" and "variables are associated with offsets into PSECTs".

When you get to ELF, that is exactly the model. Data lives in ELF sections. The ELF symbol table defines names (and sizes and 'data vs procedure') that point to ELF sections plus an offset. The same ELF on OpenVMS and on Linux. No difference.

Just plain and simple bugs in our G2L code that maps between GEM and LLVM. I was just trying to point out that while we did lots of testing and prototyping, these class of bugs are hard to spot but easy to fix. (I changed about 20 lines to fix all 3 bugs).

[Simon Clubley]

On 2019-10-14, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
> On Monday, 14 October 2019 13:50:40 UTC+1, Simon Clubley wrote:
>>
>> This memory pointer issue is one example of how the VMS data structures
>> and APIs simply tend to have a lower level of abstraction at source code
>> level.
>>
>

> The (Open)VMS calling standard covers a lot of these
> sharp edges, as do various flavours of descriptor, but
> things like EDT and DIFF (and BLISS) do go back quite
> a long time.
>

That calling standard says it is ok to encode a pointer to a data
structure as a raw 32-bit integer instead of as some abstracted
language pointer which automatically changes size depending whether
you are compiling your code for use on a 32-bit or 64-bit machine.

When you are using something like fread() on Linux, you may or may not
have a 2GB/4GB/etc file size limitation but even when you do, you don't
have to read the buffer into the lower 32-bit address space until you
manually change your code.

>
> This isn't exclusively, or even primarily, an (Open)VMS
> issue. E.g. just ask the many folks who were around when
> the Sun community moved from 32bit to 64bit. Then there
> was DEC OSF/1 aka Tru64; compatibility with 32bit UNIX
> code forced DEC OSF/1's 64bit compiler+linker to
> introduce -taso ("truncated address space option")
> so that software that unwisely assumed that pointers
> would fit in 32bits might stand a chance of working on
> Tr64.
>

Yes, but they always had the language tools available to handle pointers
even if they didn't see the need to use those tools at the time.

When the need was pointed out, those people adapted to use the tools.
I've not seen any new application level C code in the last 20 years
or so that uses a 32-bit unsigned long int to store an address.

[Dave Froble]

On 10/14/2019 2:00 PM, Simon Clubley wrote:

> I've not seen any new application level C code in the last 20 years
> or so that uses a 32-bit unsigned long int to store an address.

Ok, cannot resist. So you've reviewed all the C code created int he
last 20 years? My, you must read rather fast ...

:-)

[Dave Froble]

On 10/14/2019 1:42 PM, John Reagan wrote:

> Just the differences in GEM vs LLVM. Nothing more. Not related to pointer sizes, descriptors, Linux, the Illuminati, etc
>
> LLVM's model is that "variables live in sections", "variables have initial values". GEM's model is "data lives in PSECTs" and "variables are associated with offsets into PSECTs".
>
> When you get to ELF, that is exactly the model. Data lives in ELF sections. The ELF symbol table defines names (and sizes and 'data vs procedure') that point to ELF sections plus an offset. The same ELF on OpenVMS and on Linux. No difference.
>
> Just plain and simple bugs in our G2L code that maps between GEM and LLVM. I was just trying to point out that while we did lots of testing and prototyping, these class of bugs are hard to spot but easy to fix. (I changed about 20 lines to fix all 3 bugs).
>

Ok, this is something that I've never gotten into. And maybe I should
just drop the questions. But I'm a bit interested.

What is the difference between a PSECT and a SECTION? Isn't it just
different names for the same (or similar) thing?

And yes, you answered my original question. Mostly it's the GEM to LLVM
mapping.

My experience with Basic is that variables have initial values, usually
zero and null string and such.

[Arne Vajhøj]

On 10/14/2019 8:50 AM, Simon Clubley wrote:
> An example I have used previously might make this clear, although this
> is not directly related to the current example John posted:
>
> In traditional VMS control blocks, the address of a memory location is
> a raw 32-bit longword. It is _NOT_ an abstracted language level pointer
> to a memory location.
>
> You can't move the traditional VMS control blocks to a fully 64-bit
> address space without implementing a new VMS control block with addresses
> that are 64-bit wide. This is something which is very visible at source
> code level.
>
> OTOH, on Linux, when you move between 32-bit and 64-bit the work involved
> is a lot easier and, within the application, quite a lot of this can be
> handled transparently by the compiler which knows that the width of a
> pointer is now 64-bits instead of 32-bit and generates the correct code
> for you automatically.

Traditional VMS control blocks are Macro-32 centric
not HLL centric. So ...

The model with a HLL and a pointer type works great if pointers
on a given platform always have the same size.

If pointers on the platform can have different sizes, then
that model becomes very complicated.

> This is the basic difference between an API designed to support assembly
> language applications (VMS) versus APIs designed to support languages
> which have additional levels of abstractions (C on Unix).
>
> This memory pointer issue is one example of how the VMS data structures
> and APIs simply tend to have a lower level of abstraction at source code
> level.

Yep.

Arne

[Arne Vajhøj]

On 10/14/2019 8:06 PM, Dave Froble wrote:
> On 10/14/2019 1:42 PM, John Reagan wrote:
>> LLVM's model is that "variables live in sections", "variables have
>> initial values".  GEM's model is "data lives in PSECTs" and "variables
>> are associated with offsets into PSECTs".
>>
>> When you get to ELF, that is exactly the model.  Data lives in ELF
>> sections.  The ELF symbol table defines names (and sizes and 'data vs
>> procedure') that point to ELF sections plus an offset.  The same ELF
>> on OpenVMS and on Linux.  No difference.

> What is the difference between a PSECT and a SECTION?  Isn't it just
> different names for the same (or similar) thing?
>
> And yes, you answered my original question.  Mostly it's the GEM to LLVM
> mapping.
>
> My experience with Basic is that variables have initial values, usually
> zero and null string and such.

Variables will always have an initial value. Question is whether the
value is deterministic/defined.

Arne

[Bill Gunshannon]

On 10/14/19 8:06 PM, Dave Froble wrote:
>
>
> My experience with Basic is that variables have initial values, usually
> zero and null string and such.
>

The initial state of a variable is dependent on the language and
the implementation. Some languages require initialization some
don't. Of the ones that don't the initial value is indeterminate.

bill

[Simon Clubley]

On 2019-10-14, Dave Froble <da...@tsoft-inc.com> wrote:
> On 10/14/2019 2:00 PM, Simon Clubley wrote:
>
>> I've not seen any new application level C code in the last 20 years
>> or so that uses a 32-bit unsigned long int to store an address.
>
> Ok, cannot resist. So you've reviewed all the C code created int he
> last 20 years? My, you must read rather fast ...
>
>:-)
>

Perhaps you are the one who is reading too fast. :-)

I said code that I've seen (from lots of sources).

I didn't say all code ever written in the last 20 years...

[John Reagan]

But I have seen a ton of code that uses "size_t" to declare a pointer instead of the proper "intptr_t". In almost all cases, they are the same size, but OpenVMS is different. "size_t" (and "ptrdiff_t") is 32-bits but "intptr_t" is 64-bits.

[clairg...@gmail.com]

A few things we could not do 10 days ago.

SYSTEM job terminated at 4-NOV-2019 16:27:35.43

Accounting information:
Buffered I/O count: 706 Peak working set size: 8096
Direct I/O count: 328 Peak virtual size: 191840
Page faults: 2358 Mounted volumes: 0


Username: system
Password:

%LICENSE-I-NOT_STARTED, License Management Facility is not started
%LOGIN-S-LOGOPRCON, login allowed from OPA0:

VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFCX-N4A
Last interactive login on Wednesday, 25-SEP-2019 14:09:33.86
Last non-interactive login on Wednesday, 25-SEP-2019 14:09:58.52
$
$ spa
%DCL-S-SPAWNED, process SYSTEM_55982 spawned
%DCL-S-ATTACHED, terminal now attached to process SYSTEM_55982
$
$ sho sys
OpenVMS XFCX-N4A on node GRANT 4-NOV-2019 16:27:57.55 Uptime 0 00:00:43
Pid Process Name State Pri I/O CPU Page flts Pages
00000021 SWAPPER HIB 16 0 0 00:00:00.00 0 17
00000025 OPCOM HIB 6 42 0 00:00:00.03 154 189
00000026 JOB_CONTROL HIB 8 65 0 00:00:00.01 145 180
00000027 SYSTEM LEF 6 83 0 00:00:00.05 235 174
00000028 SYSTEM_55982 CUR 0 4 81 0 00:00:00.36 399 399 S
$
$ sho user
OpenVMS User Processes at 4-NOV-2019 16:28:03.57
Total number of users = 1, number of processes = 2

Username Interactive Subprocess Batch
SYSTEM 1 1
$
$ start/que/man/new
$ sho que/man/ful
Master file: SYS$SYSROOT:[SYSEXE]QMAN$MASTER.DAT;

Queue manager SYS$QUEUE_MANAGER, stopped
/ON=(*)
Database location: SYS$COMMON:[SYSEXE]
$
$ repl/all "System going down in 5 minutes"


Reply received on GRANT from user SYSTEM at _GRANT$OPA0: 16:38:15
System going down in 5 minutes

$
1 terminal has been notified on GRANT.
$
$ sho proc/all

4-NOV-2019 16:28:27.48 User: SYSTEM Process ID: 00000028
Node: GRANT Process name: "SYSTEM_55982"

Terminal:
User Identifier: [SYSTEM]
Base priority: 4
Default file spec: SYS$SYSROOT:[SYSMGR]
Number of Kthreads: 1 (System-wide limit: 1)

Process Quotas:
Account name: SYSTEM
CPU limit: Infinite Direct I/O limit: 150
Buffered I/O byte count quota: 252736 Buffered I/O limit: 150
Timer queue entry quota: 100 Open file quota: 118
Paging file quota: 685760 Subprocess quota: 9
Default page fault cluster: 64 AST quota: 299
Enqueue quota: 4000 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0

Accounting information:
Buffered I/O count: 167 Peak working set size: 6400
Direct I/O count: 31 Peak virtual size: 190416
Page faults: 811 Mounted volumes: 0
Images activated: 3
Elapsed CPU time: 0 00:00:00.50
Connect time: 0 00:00:39.70

Authorized privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE
SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX
UPGRADE VOLPRO WORLD

Process privileges:
ACNT may suppress accounting messages
ALLSPOOL may allocate spooled device
ALTPRI may set any priority value
AUDIT may direct audit to system security audit log
BUGCHK may make bug check log entries
BYPASS may bypass all object access controls
CMEXEC may change mode to exec
CMKRNL may change mode to kernel
DIAGNOSE may diagnose devices
DOWNGRADE may downgrade object secrecy
EXQUOTA may exceed disk quota
GROUP may affect other processes in same group
GRPNAM may insert in group logical name table
GRPPRV may access group objects via system protection
IMPERSONATE may impersonate another user
IMPORT may set classification for unlabeled object
LOG_IO may do logical i/o
MOUNT may execute mount acp function
NETMBX may create network device
OPER may perform operator functions
PFNMAP may map to specific physical pages
PHY_IO may do physical i/o
PRMCEB may create permanent common event clusters
PRMGBL may create permanent global sections
PRMMBX may create permanent mailbox
PSWAPM may change process swap mode
READALL may read anything as the owner
SECURITY may perform security administration functions
SETPRV may set any privilege bit
SHARE may assign channels to non-shared devices
SHMEM may create/delete objects in shared memory
SYSGBL may create system wide global sections
SYSLCK may lock system wide resources
SYSNAM may insert in system logical name table
SYSPRV may access objects via system protection
TMPMBX may create temporary mailbox
UPGRADE may upgrade object integrity
VOLPRO may override volume protection
WORLD may affect other processes in the world

Process rights:
SYSTEM resource
INTERACTIVE
LOCAL

Auto-unshelve: on

Image Dump: off

Soft CPU Affinity: off

Parse Style: Traditional

Case Lookup: Blind

Symlink search mode: No wildcard

Units: Blocks

Token Size: Traditional

Home RAD: 0

Scheduling class name: none

Process Dynamic Memory Area
Current Size (KB) 528.00 Current Size (Pagelets) 1056
Free Space (KB) 448.17 Space in Use (KB) 79.82
Largest Var Block (KB) 440.00 Smallest Var Block (bytes) 16
Number of Free Blocks 5 Free Blocks LEQU 64 bytes 1

There are 2 processes in this job:

SYSTEM
SYSTEM_55982 (*)
$

[Phillip Helbig (undress to reply)]

In article <eaa255c9-bd05-4ac2...@googlegroups.com>,

"clair...@vmssoftware.com" <clairg...@gmail.com> writes:

> A few things we could not do 10 days ago.
>
> SYSTEM job terminated at 4-NOV-2019 16:27:35.43
>
> Accounting information:
> Buffered I/O count: 706 Peak working set size: 8096
> Direct I/O count: 328 Peak virtual size: 191840
> Page faults: 2358 Mounted volumes: 0

Great news. Having no Itaniums, I am holding out with my ALPHA cluster,
awaiting the chance to move to x86 as soon as reasonably inexpensive
hardware is available (thus, like with the old Seagate disks, it would
be nice to know what definitely works even if it is not officially
supported) as well as a hobbyist or at least reasonably (for me) priced
non-hobbyist license.

[Dave Froble]

On 11/4/2019 11:42 AM, clair...@vmssoftware.com wrote:
> A few things we could not do 10 days ago.
>

So, all done, huh?

:-) :-) :-)

[Kerry Main]

[snip..]

Clair - congrats to everyone involved in getting to this point in the port.

As I think back to all those old notes in the DEC VMSnotes files about "porting to X86", what you just posted would bring many smiles and high fives to all those WW notefile participants and to those participating in the WW VMS Ambassador meetings.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Ian Miller]

Good to see more progress :-)

[clairg...@gmail.com]

We have a batch system.....

$ START/QUEUE/MANAGER/NEW_VERSION
$ INITIALIZE/QUEUE/START/BATCH/JOB_LIMIT=3 SYS$BATCH
$ sho que sys$batch
Batch queue SYS$BATCH, idle, on BOLTON::
$ sho sys
OpenVMS XFES-N4A on node BOLTON 3-JAN-2020 06:31:08.17 Uptime 0 00:03:38

Pid Process Name State Pri I/O CPU Page flts Pages
00000021 SWAPPER HIB 16 0 0 00:00:00.00 0 17

00000025 OPCOM HIB 9 53 0 00:00:00.06 154 189
00000026 AUDIT_SERVER HIB 8 186 0 00:00:00.02 286 322
00000027 JOB_CONTROL HIB 10 107 0 00:00:00.02 175 214
00000028 SMHANDLER HIB 8 47 0 00:00:00.03 458 458
00000029 SYSTEM LEF 5 95 0 00:00:00.09 696 205
0000002A SYSTEM_64711 CUR 0 7 175 0 00:00:00.14 1344 413 S
0000002B QUEUE_MANAGER HIB 8 134 0 00:00:00.04 251 298
$ create test.com
$ show system
$ exit
Exit
$ submit/notify test
Job TEST (queue SYS$BATCH, entry 1) started on SYS$BATCH
$

Job TEST (queue SYS$BATCH, entry 1) completed
$
$ type sys$login:test.log
$ set term/inq
$ set control=t
$ set proc/unit=bytes
$ show system
OpenVMS XFES-N4A on node BOLTON 3-JAN-2020 06:32:17.81 Uptime 0 00:04:48

Pid Process Name State Pri I/O CPU Page flts Pages
00000021 SWAPPER HIB 16 0 0 00:00:00.00 0 17

00000025 OPCOM HIB 9 53 0 00:00:00.06 154 189
00000026 AUDIT_SERVER HIB 8 186 0 00:00:00.02 286 322
00000027 JOB_CONTROL HIB 8 107 0 00:00:00.02 176 215
00000028 SMHANDLER HIB 8 47 0 00:00:00.03 458 458
00000029 SYSTEM LEF 5 95 0 00:00:00.09 696 205
0000002A SYSTEM_64711 LEF 5 250 0 00:00:00.19 1653 205 S
0000002B QUEUE_MANAGER HIB 8 137 0 00:00:00.04 266 313
0000002C BATCH_1 CUR 0 4 85 0 00:00:00.05 857 412 B
$ exit
SYSTEM job terminated at 3-JAN-2020 06:32:17.83

Accounting information:
Buffered I/O count: 80 Peak working set size: 6592
Direct I/O count: 21 Peak virtual size: 191456
Page faults: 911 Mounted volumes: 0
Charged CPU time: 0 00:00:00.06 Elapsed time: 0 00:00:00.14
$

[clairg...@gmail.com]

We have BACKUP....

$ backup SYS$COMMON:[SYSMGR]*.com btest.bck/save_set
$ dir btest

Directory SYS$SYSROOT:[SYSMGR]

BTEST.BCK;1

Total of 1 file.
$ backup/list btest.bck/save
Listing of save set(s)

Save set: BTEST.BCK
Written by: SYSTEM
UIC: [000001,000004]
Date: 3-JAN-2020 06:39:39.67
Command: BACKUP SYS$COMMON:[SYSMGR]*.COM BTEST.BCK/SAVE_SET
BACKUP version: X9.0-XFES
CPU ID register: 80000000
Written on: _BOLTON$DMM0:
Block size: 32256
Group size: 10
Buffer count: 403

[SYSMGR]ICC$ADD_REGISTRY_TABLE.COM;1 5 12-MAR-1998 12:08
[SYSMGR]JBC$DST_COMMAND.COM;1 1 2-JAN-2020 13:53
[SYSMGR]LMF$COMPLIANCE_REPORT.COM;1 7 2-JAN-2020 13:53
[SYSMGR]LOGIN.COM;2 1 23-OCT-2019 08:45
[SYSMGR]SYSECURITY.COM;1 1 2-JAN-2020 18:40
[SYSMGR]TDF$UTC_STARTUP.COM;1 4 28-DEC-2019 08:11
[SYSMGR]USB$STARTUP.COM;2 12 22-OCT-2008 11:06

Total of 7 files, 31 blocks
End of save set

$ backup/verify btest.bck/save [.c]/log
%BACKUP-S-CREDIR, created directory SYS$COMMON:[SYSMGR.C]
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]JBC$DST_COMMAND.COM;1
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]LMF$COMPLIANCE_REPORT.COM;1
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]LOGIN.COM;2
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]SYSECURITY.COM;1
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]TDF$UTC_STARTUP.COM;1
%BACKUP-S-CREATED, created SYS$COMMON:[SYSMGR.C]USB$STARTUP.COM;2
%BACKUP-I-STARTVERIFY, starting verification pass at 3-JAN-2020 06:41:25.55
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]JBC$DST_COMMAND.COM;1
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]LMF$COMPLIANCE_REPORT.COM;1
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]LOGIN.COM;2
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]SYSECURITY.COM;1
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]TDF$UTC_STARTUP.COM;1
%BACKUP-S-COMPARED, compared SYS$COMMON:[SYSMGR.C]USB$STARTUP.COM;2
$
$ dir [.c]

Directory SYS$COMMON:[SYSMGR.C]

JBC$DST_COMMAND.COM;1 LMF$COMPLIANCE_REPORT.COM;1
LOGIN.COM;2 SYSECURITY.COM;1 TDF$UTC_STARTUP.COM;1
USB$STARTUP.COM;2

Total of 6 files.
$ diff SYSECURITY.COM [.c]
Number of difference sections found: 0
Number of difference records found: 0

DIFFERENCES /MERGED=1-
SYS$COMMON:[SYSMGR]SYSECURITY.COM;1-
SYS$COMMON:[SYSMGR.C]SYSECURITY.COM;1
$
$ sho sys/noproc
OpenVMS XFES-N4A on node BOLTON 3-JAN-2020 06:44:53.57 Uptime 0 00:17:24
$

[clairg...@gmail.com]

Not only can we define new users, we can login.....

$ lo
SYSTEM logged out at 3-JAN-2020 07:10:06.90

Username: santa
Password:
%LICENSE-I-NOLICENSE, no license is active for this software product

%LOGIN-S-LOGOPRCON, login allowed from OPA0:

VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFES-N4A
1 failure since last successful login
$ sho sys
OpenVMS XFES-N4A on node BOLTON 3-JAN-2020 07:11:15.53 Uptime 0 00:43:45

Pid Process Name State Pri I/O CPU Page flts Pages

00000021 SWAPPER HIB 16 0 0 00:00:00.01 0 17
00000025 OPCOM HIB 9 63 0 00:00:00.06 184 169
00000026 AUDIT_SERVER HIB 9 199 0 00:00:00.02 287 323
00000027 JOB_CONTROL HIB 10 188 0 00:00:00.06 182 221

00000028 SMHANDLER HIB 8 47 0 00:00:00.03 458 458

0000002B QUEUE_MANAGER HIB 10 142 0 00:00:00.04 268 315
00000033 SANTA CUR 0 4 65 0 00:00:00.61 461 406
$

[Andy Burns]

clairg...@gmail.com wrote:

> We have a batch system.....

> We have BACKUP....

> Not only can we define new users, we can login.....

VMS hasn't figured on my own radar this millennium, but pleased to see
the progress ...

[Dave Froble]

Great news! Keep up the great work.

Question, why contact from two email names?

[clairg...@gmail.com]

On Friday, January 3, 2020 at 9:40:42 AM UTC-5, Dave Froble wrote:
> On 1/3/2020 7:16 AM, clairg...@gmail.com wrote:
> > Not only can we define new users, we can login.....
> >
> > $ lo
> > SYSTEM logged out at 3-JAN-2020 07:10:06.90
> >
> > Username: santa
> > Password:
> > %LICENSE-I-NOLICENSE, no license is active for this software product
> > %LOGIN-S-LOGOPRCON, login allowed from OPA0:
> > VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFES-N4A
> > 1 failure since last successful login
> > $ sho sys
> > OpenVMS XFES-N4A on node BOLTON 3-JAN-2020 07:11:15.53 Uptime 0 00:43:45
> > Pid Process Name State Pri I/O CPU Page flts Pages
> > 00000021 SWAPPER HIB 16 0 0 00:00:00.01 0 17
> > 00000025 OPCOM HIB 9 63 0 00:00:00.06 184 169
> > 00000026 AUDIT_SERVER HIB 9 199 0 00:00:00.02 287 323
> > 00000027 JOB_CONTROL HIB 10 188 0 00:00:00.06 182 221
> > 00000028 SMHANDLER HIB 8 47 0 00:00:00.03 458 458
> > 0000002B QUEUE_MANAGER HIB 10 142 0 00:00:00.04 268 315
> > 00000033 SANTA CUR 0 4 65 0 00:00:00.61 461 406
> > $
> >
>
> Great news! Keep up the great work.
>
> Question, why contact from two email names?

I wasn't paying attention.

[Bob Gezelter]

Clair,

(Smile intended) Can you logout from SANTA and login as someone else -- correctly?

- Bob Gezelter, http://www.rlgsc.com

[clairg...@gmail.com]

>
> Clair,
>
> (Smile intended) Can you logout from SANTA and login as someone else -- correctly?
>
> - Bob Gezelter, http://www.rlgsc.com

Perfectly legitimate question since up until a week ago the answer was no but now...

$ lo
SYSTEM logged out at 3-JAN-2020 07:42:52.25

Username: santa
Password:
%LICENSE-I-NOLICENSE, no license is active for this software product
%LOGIN-S-LOGOPRCON, login allowed from OPA0:
VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFES-N4A

Last interactive login on Friday, 3-JAN-2020 07:21:06.09
$ sho user
OpenVMS User Processes at 3-JAN-2020 07:43:07.58
Total number of users = 1, number of processes = 1

Username Interactive Subprocess Batch
SANTA 1
$ lo
SANTA logged out at 3-JAN-2020 07:43:09.56

Username: system

Password:
%LICENSE-I-NOLICENSE, no license is active for this software product
%LOGIN-S-LOGOPRCON, login allowed from OPA0:
VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFES-N4A

Last interactive login on Friday, 3-JAN-2020 07:33:39.98
Last non-interactive login on Friday, 3-JAN-2020 06:32:17.78
$ sho user
OpenVMS User Processes at 3-JAN-2020 07:43:22.61
Total number of users = 1, number of processes = 1

Username Interactive Subprocess Batch
SYSTEM 1

$

[Phillip Helbig (undress to reply)]

In article <48882852-3536-4fbf...@googlegroups.com>,

"clair...@vmssoftware.com" <clairg...@gmail.com> writes:

> We have a batch system.....

> SYSTEM job terminated at 3-JAN-2020 06:32:17.83

Great!

When will VMS on x86 be available?

What hardware will be supported?

On what hardware could one expect it to work (say, like one could expect
SEAGATE disks to work, even if they weren't officially supported)?

Will there be something close to the normal hobbyist license and/or a
license affordable for people who don't earn money with VMS? If not,
what sort of pricing are we talking about?

What version of VMS on Alpha will be supported in the same cluster, at
least for migration, and when will it be available?

Will there be enough graphics to support DECwindows and CDE?

Which compilers will fully support reasonably new standards of the
respective languages?

Is there any chance of a reasonable graphical web browser? (Probably
there will be no development for VMS, but perhaps some open-source
browser could be made to work on VMS.)

Will I be able to use my LK-411 keyboard like I do now?

Is there anything we know and love which will not be ported to x86?

I have enough Alpha hardware to last me until I die, but I would like to
move to x86 sooner rather than later.

[Phillip Helbig (undress to reply)]

In article <14018f30-872f-446f...@googlegroups.com>,

"clair...@vmssoftware.com" <clairg...@gmail.com> writes:

> > Question, why contact from two email names?
>

> I wasn't paying attention.

I often use TCPIP$SMTP_FROM.

[IanD]

All valid questions

Perhaps we should create a FAQ and tick them off as they are answered?

[Phillip Helbig (undress to reply)]

In article <6a173aae-2957-409e...@googlegroups.com>, IanD
<iloveo...@gmail.com> writes:

> All valid questions

Mine, presumably.

> Perhaps we should create a FAQ and tick them off as they are answered?

I think that there is a substantial number of customers who had planned
to ditch VMS but, for various reasons, are still hanging on. Some of
these would go to x86; the earlier there are concrete answers to the
questions, the easier it is to convince management that VMS on x86 would
be a good idea.

[IanD]

Yes, sorry, your questions

I'm using a mobile and Google groups defaults to no quoting and I'm too lazy to switch it into desktop mode because of all the pinch and zoom I need to do to do the quote selection

I'd also add to the questions, 'What's going to become of DCL and what's planned to replace it?'

I agree, there's a number of places I know of who have plans for the replacement of VMS, the word of VMS-x86 still isn't widespread

Some are moving to a totally different technology base in areas VMS have yet to even dip a foot into, I'm thinking of a major stock exchange that's retiring VMS to move to a blockchain based solution, so even if VMS-x86 popped out of the woodwork in the next 6 months it's another few years before VMS can play in that arena, with updated compilers, tool chains and associated open source code moved to VMS and tested and accepted

Another question would be 'When will VSI have a plan on getting Python 3 supported on VMS?'
The language just keeps growing in importance and still there's no official word about it other than it's under consideration

*Post deleted then edited and posted again since groups doesn't support editing...(at least not on Mobile)

[Robert A. Brooks]

On 1/4/2020 6:53 AM, IanD wrote:

> I'd also add to the questions, 'What's going to become of DCL and what's
> planned to replace it?'

As you can see from Clair's postings, DCL is still there;
there are no plans to replace it.

I am not aware of any plans to enhance it to do 64-bit math.

--
-- Rob

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of IanD via Info-
> vax
> Sent: January 4, 2020 6:54 AM
> To: info...@rbnsn.com
> Cc: IanD <iloveo...@gmail.com>
> Subject: Re: [Info-vax] The Road to V9.0
>

> Yes, sorry, your questions
>
> I'm using a mobile and Google groups defaults to no quoting and I'm too
lazy
> to switch it into desktop mode because of all the pinch and zoom I need to
> do to do the quote selection
>
> I'd also add to the questions, 'What's going to become of DCL and what's
> planned to replace it?'
>

Agree with Rob on not replacing DCL. There is always room for improvements,
and possibly addition of other scripting languages, but why would anyone
think of replacing the DCL CLI which is a core part of the OS and used not
only for managing the system, but also as the core to batch jobs and command
files used extensively on every (ok there may be a few systems with no
command files or batch files) OpenVMS system?

Is there any OS platform that does not have a native CLI? Heck, even most
GUI based appliances like FW's have a native mgmt. command line CLI in
addition to the GUI interface.

For decades, MS tried to avoid having a native CLI other than the CMD DOS
CLI, but over time, they came to realize that enterprise environments depend
on CLI's for batch and other task based jobs. Hence, PowerShell finally came
into being in the early 2000's as I recall.

> I agree, there's a number of places I know of who have plans for the
> replacement of VMS, the word of VMS-x86 still isn't widespread
>
> Some are moving to a totally different technology base in areas VMS have
> yet to even dip a foot into, I'm thinking of a major stock exchange that's
> retiring VMS to move to a blockchain based solution, so even if VMS-x86
> popped out of the woodwork in the next 6 months it's another few years
> before VMS can play in that arena, with updated compilers, tool chains and
> associated open source code moved to VMS and tested and accepted
>

Might have already known this, and its no doubt a controversial subject, but
just in case:
<https://www.ab2l.org.br/blockchain-just-became-obsolete-the-future-is-hashg
raph/>

<
https://www.swirlds.com/vms-software-selects-swirlds-hashgraph-as-platform-t
o-build-secure-distributed-applications/>
" VMS Software Selects Swirlds Hashgraph as Platform to Build Secure,
Distributed Applications"

[snip..]

[Jan-Erik Söderholm]

Yes but... The majority of *your* questions were hobbyist oriented and
I do not see much relevance in them for ordinary (paying) customers.
I'm fully confident that VSI has a clear picture of what they need
to deliver and supply in regard to VMS. There will always be some that
feel that *their* specific questions has not been answered. So be it.

[Craig A. Berry]

Most of these questions have been answered before and/or have some kind
of answer on the current roadmap. For example v9.1 is now expected in
the second have of this year (2020). A year ago it was expected in Q2
of 2019. Apparently porting is hard, or something.

[Jan-Erik Söderholm]

Ha! I had missed that a new road map had been posted on the 4 Dec...

[Scott Dorsey]

Kerry Main <kemain...@gmail.com> wrote:
>
>Agree with Rob on not replacing DCL. There is always room for improvements,
>and possibly addition of other scripting languages, but why would anyone
>think of replacing the DCL CLI which is a core part of the OS and used not
>only for managing the system, but also as the core to batch jobs and command
>files used extensively on every (ok there may be a few systems with no
>command files or batch files) OpenVMS system?

It would be nice to have an alternate and more advanced command language.
Say, like Software Tools for VMS. But that's a thing to worry about in
the future, once x86 VMS is established and well wrung-out. I'm not in
any way suggesting doing away with DCL, just providing an alternative for
those who choose to use it. Five or six years from now it will be likely
worth looking into.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 1/4/2020 9:23 AM, Robert A. Brooks wrote:
> On 1/4/2020 6:53 AM, IanD wrote:
>> I'd also add to the questions, 'What's going to become of DCL and what's
>> planned to replace it?'
>
> As you can see from Clair's postings, DCL is still there;
> there are no plans to replace it.

Removing DCL would be a disaster due to all the DCL code
out there. DCL must stay.

But supplementing DCL wit a script language for advanced
scripting by adding something with VSI backing could make
sense.

Python would probably be most obvious. Ship a Python
as part of base VMS with good VMS sysadm library and
official VSI support. Would be nice.

For VMS 10.x or so.

Arne

[clairg...@gmail.com]

The answers to many of "the questions" can be found on the public roadmap. I will take a quick swing at a few of the others.

Will there be something close to the normal hobbyist license and/or a
license affordable for people who don't earn money with VMS?

<CG: Currently we have no plans for a Hobbyist. To be perfectly clear, I am not saying we have decided never to have one. I am saying we have no plans at this time. Please, understand that distinction.

>

What version of VMS on Alpha will be supported in the same cluster, at
least for migration, and when will it be available?

<CG: Regardless of HW or virtual platform, you must be running a VSI version of VMS to be in a cluster with a 9.X system. We will have patch kits for previous releases. We need to do this in order to make upgrades to the cluster protocol.

>

Is there anything we know and love which will not be ported to x86?

<CG: Not yet but we are constantly evaluating (by surveying customers) what antiquated things we could ditch and have acceptable modern alternatives.
>

RE: DCL

We have the same discussion too often. There will always be a DCL, period. We will have minor fixes and updates but we will never put significant work into it. We now ship PERL and PYTHON could be in the future...who knows what else.

RE: "some" and "those" and "they"

If you have names of customers VSI should know about, let's see them. If you do not want to put them up in public, send me mail and I will see if they are on our contact list.

[Bill Gunshannon]

Why five or six years? If you are talking about The Software Tools
Virtual Operating System as described in CACM, Volume 23, Number 9,
September 1980, I wouldn't expect it to take more than a few man-hours
to revive that and you could do it on a current version of VMS and it
should move easily when the new VMS is ready.

Personally, I have wanted to see it come back to life for quite some
time now.

bill

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Jan-Erik
> Söderholm via Info-vax
> Sent: January 4, 2020 10:37 AM
> To: info...@rbnsn.com
> Cc: Jan-Erik Söderholm <jan-erik....@telia.com>
> Subject: Re: [Info-vax] The Road to V9.0
>

Thanks for highlighting this. I also missed this.

This Dec 2019 roadmap update has some really interesting (read yay!)
tidbits:

OpenVMS 9.2 on X86 (2021) - full prod release
- Oracle VM VirtualBox, KVM and VMware
- supported servers - HPE DL380, DL580 and Dell 2 socket, 4 socket models
(additional servers tbd)
- Additional File System - GFS2
- OpenSSL 3.x.x, including
- FIPS 140-2 compliance –Network stack
- OpenJDK

See link:
<http://www.vmssoftware.com/pdfs/VSI_Roadmap_20191209.pdf>

[Scott Dorsey]

In article <h7c8gm...@mid.individual.net>,

I'd be happy with SWT as it was in 1980 (In fact, I have it running on the
vaxen where I am happy with it today), but I think a lot of people would
now consider the limitations of Bourne shell unacceptable and would want
something bashlike.

But it has never been supported as a layered product of course.

[Simon Clubley]

On 2020-01-03, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
> In article <48882852-3536-4fbf...@googlegroups.com>,
> "clair...@vmssoftware.com" <clairg...@gmail.com> writes:
>
>> We have a batch system.....
>
>> SYSTEM job terminated at 3-JAN-2020 06:32:17.83
>
> Great!
>
> When will VMS on x86 be available?
>

Phillip, some of this reads like your own shopping list for x86-64 VMS
instead of what normal VMS users are likely to want...

>
> Will there be enough graphics to support DECwindows and CDE?
>

Perhaps it's time to switch to running X over SSH and use a non-VMS
display host such as Linux. You can also use Windows (with third party
software) to display X sessions. Perhaps the only console graphics
support on x86-64 should be the standard basic VGA and above.

I don't see advanced graphics support on the console as being high on
the list of priorities for VSI.

>
> Is there any chance of a reasonable graphical web browser? (Probably
> there will be no development for VMS, but perhaps some open-source
> browser could be made to work on VMS.)
>

The source code is there if you want to port one of them. :-)

Seriously however, I see this as being even less of a priority than
advanced graphics support.

> Will I be able to use my LK-411 keyboard like I do now?
>

Those things are history. Adapt as the rest of us have done. I can still
use the EDT style keypad both on VMS and in emacs and I have been using
PC keyboards only for the last 15+ years.

> Is there anything we know and love which will not be ported to x86?
>

The last information we had was that an Ada compiler for x86-64 was
unlikely.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Simon Clubley]

On 2020-01-04, Kerry Main <kemain...@gmail.com> wrote:
>
> Agree with Rob on not replacing DCL. There is always room for improvements,
> and possibly addition of other scripting languages, but why would anyone
> think of replacing the DCL CLI which is a core part of the OS and used not
> only for managing the system, but also as the core to batch jobs and command
> files used extensively on every (ok there may be a few systems with no
> command files or batch files) OpenVMS system?
>

If you look into DCL in detail you will see that DCL is more heavily tied
into VMS than that and way more than other shells such as bash on Linux are.
Bash is a normal user-mode program no different from the programs it runs.
DCL is most certainly _NOT_ a normal user-mode shell.

> Is there any OS platform that does not have a native CLI? Heck, even most
> GUI based appliances like FW's have a native mgmt. command line CLI in
> addition to the GUI interface.
>

The difference is that DCL has a privileged role within the VMS security
model whereas bash is just a normal user-mode program.

You may still be able to compromise a Linux box using bash provided that
bash is just one part of the vulerability chain (there was a well published
issue with bash when used with a webserver in some environments).

However, with DCL, you only need to get shellcode you control running
inside DCL itself to stand a good chance of being able to compromise
the VMS system itself.

[Simon Clubley]

On 2020-01-04, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
> On 1/4/2020 6:53 AM, IanD wrote:
>
>> I'd also add to the questions, 'What's going to become of DCL and what's
>> planned to replace it?'
>
> As you can see from Clair's postings, DCL is still there;
> there are no plans to replace it.
>

It would still be nice if DCL and VMS could be changed so that
DCL never ever sees the privileges of any privileged image at
_any_ point during the loading and execution of that privileged image.

[Simon Clubley]

On 2020-01-04, clair...@vmssoftware.com <clairg...@gmail.com> wrote:
> The answers to many of "the questions" can be found on the public roadmap. I will take a quick swing at a few of the others.
>
> Will there be something close to the normal hobbyist license and/or a
> license affordable for people who don't earn money with VMS?
>
><CG: Currently we have no plans for a Hobbyist. To be perfectly clear, I am
>not saying we have decided never to have one. I am saying we have no plans at
>this time. Please, understand that distinction.
>>
>

Just to be clear, I do indeed understand the difference between will never
have one and _currently_ have no plans to have one.

However, having said that, there is a more immediate issue in that the
HPE hobbyist program will be coming to an end by the end of this year.

This means that during this year VSI are going to be seeing more and more
calls to outline any hobbyist program they may have planned and to outline
when that program might start running.

If we get to the end of the year without a VSI hobbyist program being
announced, you are likely to see a permanent reduction in the number
of VMS hobbyists even if you then implement one.

In an era of free operating systems (Linux/FreeBSD/etc), hobbyist programs
serve an important role in keeping people interested in what you have to
offer by allowing them to play with VMS at home.

In some ways, you can regard the VMS hobbyist program as being a valuable
marketing tool. For example, can you imagine the number of people who
would become skilled on z/OS if IBM offered a run z/OS itself at home
style hobbyist program ? The closest IBM have which I am (now) aware of
is the Master the Mainframe program.

[Bill Gunshannon]

Then, what did you mean by "Software Tools"?

Which shell would you want? I dislike BASH, but there are clones
of csh that I use all the time. And there is also pdksh.

bill

[Phillip Helbig (undress to reply)]

In article <quq9kn$not$1...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> Yes but... The majority of *your* questions were hobbyist oriented

Right.

> and
> I do not see much relevance in them for ordinary (paying) customers.

Both need the same OS.

> I'm fully confident that VSI has a clear picture of what they need
> to deliver and supply in regard to VMS.

Perhaps. If so, it wouldn't hurt to answer my questions.

> There will always be some that
> feel that *their* specific questions has not been answered. So be it.

One thing which used to be better was hobbyist access to patches.
Hobbyists often installed them before paying customers did, and
sometimes they found and reported bugs. The more people who use VMS,
both hobbyists and others, the better; 99% of their needs are the same.

[Phillip Helbig (undress to reply)]

In article <quqdso$uf0$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

<ar...@vajhoej.dk> writes:

> Python would probably be most obvious. Ship a Python
> as part of base VMS with good VMS sysadm library and
> official VSI support. Would be nice.

And VMS people would be happy with something which breaks backward
compatibility?

[Snowshoe]

On 1/4/2020 5:31 PM, Simon Clubley wrote:
> On 2020-01-04, Kerry Main <kemain...@gmail.com> wrote:
>>
>> Agree with Rob on not replacing DCL. There is always room for improvements,
>> and possibly addition of other scripting languages, but why would anyone
>> think of replacing the DCL CLI which is a core part of the OS and used not
>> only for managing the system, but also as the core to batch jobs and command
>> files used extensively on every (ok there may be a few systems with no
>> command files or batch files) OpenVMS system?
>>
>
> If you look into DCL in detail you will see that DCL is more heavily tied
> into VMS than that and way more than other shells such as bash on Linux are.
> Bash is a normal user-mode program no different from the programs it runs.
> DCL is most certainly _NOT_ a normal user-mode shell.
>
>> Is there any OS platform that does not have a native CLI? Heck, even most
>> GUI based appliances like FW's have a native mgmt. command line CLI in
>> addition to the GUI interface.
>>
>
> The difference is that DCL has a privileged role within the VMS security
> model whereas bash is just a normal user-mode program.
>

If, in theory, one wanted to create a new shell/CLI or modify something
like bash to run as a new VMS shell, what special VMS-specific mods
would be needed? Assume it still runs in super mode, but what other
special abilities would it need? I do know the path to do certain DCL
things like read/set DCL symbols and other CLI$ functions is convoluted
and undocumented so if an equivalent is supplied there is that.
Something must be done for execute-only images (although I think that's
actually dealt with in exec mode) or privileged images (ditto).

> You may still be able to compromise a Linux box using bash provided that
> bash is just one part of the vulerability chain (there was a well published
> issue with bash when used with a webserver in some environments).
>
> However, with DCL, you only need to get shellcode you control running
> inside DCL itself to stand a good chance of being able to compromise
> the VMS system itself.
>

You mentioned before that certain exec mode routines were called via
$CMEXEC which is always allowed from supervisor mode regardless of
privs, what would it take to eliminate them, then changing $CMEXEC to
require privs when called from super mode?

[Phillip Helbig (undress to reply)]

In article <bf700d09-a66a-4711...@googlegroups.com>,

"clair...@vmssoftware.com" <clairg...@gmail.com> writes:

> The answers to many of "the questions" can be found on the public
> roadmap. I will take a quick swing at a few of the others.

Thanks.

> Will there be something close to the normal hobbyist license and/or a
> license affordable for people who don't earn money with VMS?
>

> <CG: Currently we have no plans for a Hobbyist. To be perfectly clear,
> I am not saying we have decided never to have one. I am saying we have
> no plans at this time. Please, understand that distinction. >

I understand it. However, I asked this question at the conference call
when the port was announced, and the answer was that there would be. It
would be nice if there would be a hobbyist license.

> What version of VMS on Alpha will be supported in the same cluster, at
> least for migration, and when will it be available?
>

> <CG: Regardless of HW or virtual platform, you must be running a VSI
version of VMS to be in a cluster with a 9.X system. We will have patch
kits for previous releases. We need to do this in order to make upgrades
to the cluster protocol.>

Right. It would be nice to know in advance when such a version is
available for Alpha, so one could go ahead and upgrade Alpha and then be
ready when x86 appears.

> RE: DCL

Not one of my questions; I never doubted that it would stay.

> We have the same discussion too often. There will always be a DCL,
> period.

And EDT? :-)

> If you have names of customers VSI should know about, let's see them.
> If you do not want to put them up in public, send me mail and I will see
> if they are on our contact list.

No-one specific. But in how many places is VMS still running, with
plans to ditch it in the future, despite the porting effort, and people
just not aware that x86 will be here soon? Not big customers, but
several small ones.

[Arne Vajhøj]

How does adding Python with VMS integration and VSI support to DCL
break anything??

Arne

[Phillip Helbig (undress to reply)]

In article <qur2sk$mms$3...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> Phillip, some of this reads like your own shopping list for x86-64 VMS
> instead of what normal VMS users are likely to want...

There is not that much difference. For 22 years I've owned my own VMS
systems, from 1992--2000 I worked with VMS in a university environment,
since then in a business environment. The basic needs are not that
different.

> > Will there be enough graphics to support DECwindows and CDE?
>
> Perhaps it's time to switch to running X over SSH and use a non-VMS
> display host such as Linux.

Why? Isn't there on-chip graphics on X86? Why bring an additional
system into the loop, one with extra costs, worries, problems, and
vulnerabilities?

> You can also use Windows (with third party
> software) to display X sessions.

See above. Why?

> Perhaps the only console graphics
> support on x86-64 should be the standard basic VGA and above.
>
> I don't see advanced graphics support on the console as being high on
> the list of priorities for VSI.

There is a difference between high-end graphics and what I said, CDE and
DECwindows. Those are NOT high-end graphics. We're talking about stuff
which ran well on hardware a quarter of a century old by now. This
should be trivial to do on x86.

> Those things are history. Adapt as the rest of us have done. I can still
> use the EDT style keypad both on VMS and in emacs and I have been using
> PC keyboards only for the last 15+ years.

But they don't have the same keys, so are using only a subset of the
functionality.

[Phillip Helbig (undress to reply)]

In article <qura7e$ro2$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

> How does adding Python with VMS integration and VSI support to DCL
> break anything??

Didn't Python recently break backwards compatibility with itself? That
doesn't seem like something VMS users would be happy with.

[Arne Vajhøj]

They made some non backwards compatible changes going from 2.x to 3.x.
Including the infamous change of int / int. They support
2.x for 12 years after releasing 3.0.

I would not discard Python due to that.

Arne

[Dave Froble]

On 1/4/2020 7:25 PM, Phillip Helbig (undress to reply) wrote:

As long as DCL is included, and that's already been established, then
nobody is forced to use Python, or any other such tool.

Now, why is DCL going to be part of x86 VMS? That's rather obvious.
DCL is used in many things, including startup of VMS. The x86 port is
of things that already exist. Without DCL, VMS doesn't even start up.
So, without DCL it becomes much more than port, which is already taking
a large effort. Like it or not, DCL will be included with VMS. Use it
or not, that's each user's choice.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/4/2020 9:33 PM, Dave Froble wrote:
> On 1/4/2020 7:25 PM, Phillip Helbig (undress to reply) wrote:
>> In article <qura7e$ro2$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <ar...@vajhoej.dk> writes:
>>>>> Python would probably be most obvious. Ship a Python
>>>>> as part of base VMS with good VMS sysadm library and
>>>>> official VSI support. Would be nice.
>>>>
>>>> And VMS people would be happy with something which breaks backward
>>>> compatibility?
>>>
>>> How does adding Python with VMS integration and VSI support to DCL
>>> break anything??
>>
>> Didn't Python recently break backwards compatibility with itself?  That
>> doesn't seem like something VMS users would be happy with.
>
> As long as DCL is included, and that's already been established, then
> nobody is forced to use Python, or any other such tool.
>
> Now, why is DCL going to be part of x86 VMS?  That's rather obvious. DCL
> is used in many things, including startup of VMS.  The x86 port is of
> things that already exist.  Without DCL, VMS doesn't even start up. So,
> without DCL it becomes much more than port, which is already taking a
> large effort.  Like it or not, DCL will be included with VMS.  Use it or
> not, that's each user's choice.

DCL has to be there. There are so much DCL code out there.
VMS without DCL would not be VMS.

And for simple stuff then a DCL COM file is fine.

But for large scripting tasks then there better languages today.

Arne

[Simon Clubley]

On 2020-01-04, Snowshoe <n...@spam.please> wrote:
> On 1/4/2020 5:31 PM, Simon Clubley wrote:
>>
>> The difference is that DCL has a privileged role within the VMS security
>> model whereas bash is just a normal user-mode program.
>>
>
> If, in theory, one wanted to create a new shell/CLI or modify something
> like bash to run as a new VMS shell, what special VMS-specific mods
> would be needed? Assume it still runs in super mode, but what other
> special abilities would it need? I do know the path to do certain DCL
> things like read/set DCL symbols and other CLI$ functions is convoluted
> and undocumented so if an equivalent is supplied there is that.
> Something must be done for execute-only images (although I think that's
> actually dealt with in exec mode) or privileged images (ditto).
>

A couple of things come immediately to mind:

An implementation of sys$cli() would need to be added

Handling VMS's rather "unique" approach to image activation (image
activation on VMS is not atomic and images share the same address
space as the shell).

Actually co-existing in the same address space as the program when it
is running. Until the problem I described below is fixed, that includes
making sure you can't do anything security sensitive in the shell when
control is returned back to the shell while a privileged image is running.

It also includes making sure that non-privileged users cannot supply
their own shell until that same problem is fixed.

>> You may still be able to compromise a Linux box using bash provided that
>> bash is just one part of the vulerability chain (there was a well published
>> issue with bash when used with a webserver in some environments).
>>
>> However, with DCL, you only need to get shellcode you control running
>> inside DCL itself to stand a good chance of being able to compromise
>> the VMS system itself.
>>
>
> You mentioned before that certain exec mode routines were called via
> $CMEXEC which is always allowed from supervisor mode regardless of
> privs, what would it take to eliminate them, then changing $CMEXEC to
> require privs when called from super mode?
>

Special supervisor mode access to $CMEXEC outside of what I describe
below would be a new one on me if true. Are you sure you are not
misremembering what I said ?

The problem I described (and is the problem I was able to exploit)
is that DCL has access to the privileges of the programs it runs.

This means that if an image is installed with CMKRNL (for example)
then, if you can get shellcode running inside DCL itself while the
privileged program is loaded (as I did), you can use those image
privileges to do whatever you want in your shellcode even though you
are a non-privileged user.

In the current VMS design, if you allowed a non-privileged user to supply
their own supervisor mode login shell, then the user can also do whatever
they want with those privileges during execution of that shell.

The only proper fix for this is to make sure that DCL (or any other
shell) _never_ sees the privileges of that image at any point during
image loading and image execution.

That includes making sure that DCL cannot see the image privileges
during image activation and having the _kernel_ and _NOT_ DCL strip
the privileges from the current process when Ctrl-Y is pressed.

At the moment, DCL just turns off the privileges when you press Ctrl-Y.
They need to actually be stripped by the kernel (not just turned off)
before any DCL Ctrl-Y code is run and then restored by the kernel when
DCL has finished executing the Ctrl-Y handler code.

Until you do that, that is a VMS-specific weakness just waiting to be
exploited if you can find a way into supervisor mode and there's no way
you can allow a non-privileged user to supply their own shell to run as
their supervisor mode login shell.

[Tim Lovern]

I'd still like to see a way to extend DCL with new lexical functions. I understand the issues with needing to execute in privileged modes.

This would not be something the average user could do, but they would have access to the extensions created by competent IT folks.

This is not any more risky than a developer writing other privileged code. Could it be abused? sure, just like any other privileged code.

I'd settle for an Alternative DCL CLI kit. one where you could do whatever and install it as an alternative to DCL for those that need it.

[mcle...@gmail.com]

What's required is the introduction of an alternative to DCL and perhaps other packages that can be run automatically in parallel with the existing software. (For example, if the first character on the first line of a command procedure is '#' then the DCL alternative is used.)
,
Use of the new software would be encouraged but few, if any, penalties imposed for running the old software.

Over time, which could be 15 or more years, the old software would be gradually slipped out of the picture, moving though steps like "optional" and "no longer upgraded" status.

The problem of course is that maintenance of both versions will be required for some time, but if that's a cost-effective option given the income from clients then it's the way to go.


John

[IanD]

Sorry, I used the wrong word when mentioning 'replacing' DCL

In future I will refer to what will 'supercede' DCL

As much as I love Python, I'm not sure even Python itself would be the right language long term, there might be other languages that would play in a VMS cluster better and could help enhance cluster based applications

I really like what Microsoft did with it's CLR and how many languages it ties under that banner. I think perhaps something similar could be looked at rather than just a single language to supercede DCL

I do like what I've seen in functional languages overall though, and F# looks like it's growing in popularity, from the ground up without fanfare. It's open source too and has the ability to generate GPU based output via Alea GPU.

If you want productivity then Wolfram language looks awesome but that would have to be licensed

Then there's machine learning and deep learning that's now starting to make it's way into the application space but you need GPU support of some description to play in this arena, so while VMS folk say GPU support isn't on the cards, I think in time it's going to need to be, not for workstation VMS but for support for application execution on GPU's

Now to have a look at the Dec VMS roadmap, seems like I missed it...

[VAXman-]

What do you want added? Let's talk.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Arne Vajhøj]

On 1/8/2020 6:55 AM, IanD wrote:
> Sorry, I used the wrong word when mentioning 'replacing' DCL
>
> In future I will refer to what will 'supercede' DCL
>
> As much as I love Python, I'm not sure even Python itself would be
> the right language long term, there might be other languages that
> would play in a VMS cluster better and could help enhance cluster
> based applications

Python is in some ways an unusual language. Some people like
Python.Other people does not like Python.

It is a fact that Python is a very widely used language. Including in
the area of sysadm scripting.

If a non-VMS sysadm take over a VMS system then it is highly likely
that he (or she) knows Python.

That alone is enough to make Python a strong contender.

> I really like what Microsoft did with it's CLR and how many languages
> it ties under that banner. I think perhaps something similar could be
> looked at rather than just a single language to supercede DCL

That is a slightly different topic.

The CLR shell PowerShell is pretty good. But I still believe that
there will be more Python knowledge than PS knowledge among
the future VMS sysadms.

> I do like what I've seen in functional languages overall though, and
> F# looks like it's growing in popularity, from the ground up without
> fanfare. It's open source too and has the ability to generate GPU
> based output via Alea GPU.

FP languages are getting some traction. And FP features are being added
to OOP languages.

I believe Scala is still ahead of F# in usage.

Anyway those languages definitely not relevant for new preferred
language for advanced scripting on VMS.

Arne

[Jean-François Piéronne]

Le 09/01/2020 à 01:43, Arne Vajhøj a écrit :
> On 1/8/2020 6:55 AM, IanD wrote:
>> Sorry, I used the wrong word when mentioning 'replacing' DCL
>>
>> In future I will refer to what will 'supercede' DCL
>>
>> As much as I love Python, I'm not sure even Python itself would be
>> the right language long term, there might be other languages that
>> would play in a VMS cluster better and could help enhance cluster
>> based applications
>
> Python is in some ways an unusual language. Some people like
> Python.Other people does not like Python.
>
> It is a fact that Python is a very widely used language. Including in
> the area of sysadm scripting.
>
> If a non-VMS sysadm take over a VMS system then it is highly likely
> that he (or she) knows Python.
>
> That alone is enough to make Python a strong contender.
>
>

I agree, you can like or dislike Python but you can't ignore it.

Just see how it is popular on github:
https://githut.info/

[snip]

Jean-François

[osuv...@gmail.com]

On Wednesday, January 8, 2020 at 7:43:56 PM UTC-5, Arne Vajhøj wrote:
>
> The CLR shell PowerShell is pretty good. But I still believe that
> there will be more Python knowledge than PS knowledge among
> the future VMS sysadms.

Any proposed replacement has to address updating all sysadmin related commands that expect parameters and qualifiers with or without values that may or may not
be keyword with their own lists of values. DCL is a far more elaborate syntax
than what is usually expressed on a C program argument vector.

[Robert A. Brooks]

Let me be clear; DCL will not be replaced.

If another tool is offered for scripting purposes, it'll be viewed as an add-on, and
no migration mechanism will be offered for existing DCL command procedures.

--

-- Rob

[Simon Clubley]

As Rob says, DCL isn't going to be replaced although it would be nice
to at least give it some bash-like history and long line editing features.

I think that DCL is going to be the only shell which is going to be
running in supervisor mode. Everything else is likely to be user mode
(as bash on VMS is) and run on top of DCL.

[Arne Vajhøj]

On 1/9/2020 2:21 PM, Simon Clubley wrote:
> On 2020-01-09, osuv...@gmail.com <osuv...@gmail.com> wrote:
>> On Wednesday, January 8, 2020 at 7:43:56 PM UTC-5, Arne Vajhøj wrote:
>>>
>>> The CLR shell PowerShell is pretty good. But I still believe that
>>> there will be more Python knowledge than PS knowledge among
>>> the future VMS sysadms.
>>
>> Any proposed replacement has to address updating all sysadmin related commands that expect parameters and qualifiers with or without values that may or may not
>> be keyword with their own lists of values. DCL is a far more elaborate syntax
>> than what is usually expressed on a C program argument vector.
>
> As Rob says, DCL isn't going to be replaced although it would be nice
> to at least give it some bash-like history and long line editing features.
>
> I think that DCL is going to be the only shell which is going to be
> running in supervisor mode. Everything else is likely to be user mode
> (as bash on VMS is) and run on top of DCL.

I suspect that DCL will be the only real shell.

But that does not mean that it is the only supported scripting language.

Arne

[Arne Vajhøj]

On 1/9/2020 12:42 PM, Robert A. Brooks wrote:
> On 1/9/2020 12:29 PM, osuv...@gmail.com wrote:
>> On Wednesday, January 8, 2020 at 7:43:56 PM UTC-5, Arne Vajhøj
>> wrote:
>>> The CLR shell PowerShell is pretty good. But I still believe that
>>> there will be more Python knowledge than PS knowledge among the
>>> future VMS sysadms.
>>
>> Any proposed replacement has to address updating all sysadmin related
>> commands that expect parameters and qualifiers with or without values
>> that may or may not be keyword with their own lists of values. DCL is
>> a far more elaborate syntax than what is usually expressed on a C
>> program argument vector.
>
> Let me be clear; DCL will not be replaced.

We got that.

> If another tool is offered for scripting purposes, it'll be viewed as an add-on, and
> no migration mechanism will be offered for existing DCL command procedures.

That is fine.

Since DCL will continue to work, then it will not be required.

And conversions from one language to another language rarely result in
good code.

Arne

[Richard Maher]

People have successfully being ignoring Python 3 for over a decade.

2.7 on OTOH . . .

[Arne Vajhøj]

On 1/9/2020 9:42 PM, Richard Maher wrote:
> People have successfully being ignoring Python 3 for over a decade.
>
> 2.7 on OTOH . . .

That was the case for a long time, but it is changing now.

In fall 2018 the numbers were 84% using 3.x and 16% using 2.x.

https://www.jetbrains.com/research/python-developers-survey-2018/?_ga=2.144037745.573218899.1578625167-1984034965.1578625167

Arne

[already...@yahoo.com]

On Thursday, January 9, 2020 at 11:29:57 PM UTC+2, Arne Vajhøj wrote:
>
> I suspect that DCL will be the only real shell.
>

How do you distinguish between 'shell' and 'real shell'?

[Simon Clubley]

Can your shell function as the initial login shell without needing
to first be run by DCL ?

If so, it's a real shell. If not, it's just another user mode
program running on top of DCL.

[already...@yahoo.com]

If that's all the difference then I'd say it does not matter.
But, may be, Arne meant something else?

[osuv...@gmail.com]

On Friday, January 10, 2020 at 9:24:37 AM UTC-5, already...@yahoo.com wrote:
> If that's all the difference then I'd say it does not matter.
> But, may be, Arne meant something else?

If VMS forked a new process for each command program run, then it wouldn't matter.
DCL does not work that way.

[Arne Vajhøj]

On 1/10/2020 9:24 AM, already...@yahoo.com wrote:
> On Friday, January 10, 2020 at 4:02:38 PM UTC+2, Simon Clubley wrote:
>> On 2020-01-10, already...@yahoo.com <already...@yahoo.com> wrote:
>>> On Thursday, January 9, 2020 at 11:29:57 PM UTC+2, Arne Vajhøj wrote:
>>>>
>>>> I suspect that DCL will be the only real shell.
>>>
>>> How do you distinguish between 'shell' and 'real shell'?
>>
>> Can your shell function as the initial login shell without needing
>> to first be run by DCL ?
>>
>> If so, it's a real shell. If not, it's just another user mode
>> program running on top of DCL.
>

> If that's all the difference then I'd say it does not matter.
> But, may be, Arne meant something else?

My distinction was between:

real shell = an interpreter that users normally use for interactive commands

advanced scripting = an interpreter mostly used to execute script files

On Windows CMD and PS fall in the first category while VBS and Python
fall in the second category.

On Linux bash etc. fall in the first category while Perl, Python
etc. fall in the second category.

On VMS DCL is in the first category while Python would go in the second.

Arne

[already...@yahoo.com]

That sounds like even less important technical detail than the one mentioned by Simon.
I am sure it was mighty important on 11/780. Not now.

[already...@yahoo.com]

On Saturday, January 11, 2020 at 4:33:49 AM UTC+2, Arne Vajhøj wrote:
> On 1/10/2020 9:24 AM, already...@yahoo.com wrote:
> > On Friday, January 10, 2020 at 4:02:38 PM UTC+2, Simon Clubley wrote:
> >> On 2020-01-10, already...@yahoo.com <already...@yahoo.com> wrote:
> >>> On Thursday, January 9, 2020 at 11:29:57 PM UTC+2, Arne Vajhøj wrote:
> >>>>
> >>>> I suspect that DCL will be the only real shell.
> >>>
> >>> How do you distinguish between 'shell' and 'real shell'?
> >>
> >> Can your shell function as the initial login shell without needing
> >> to first be run by DCL ?
> >>
> >> If so, it's a real shell. If not, it's just another user mode
> >> program running on top of DCL.
> >
> > If that's all the difference then I'd say it does not matter.
> > But, may be, Arne meant something else?
>
> My distinction was between:
>
> real shell = an interpreter that users normally use for interactive commands
>
> advanced scripting = an interpreter mostly used to execute script files
>
> On Windows CMD and PS fall in the first category while VBS and Python
> fall in the second category.
>

By that description it sounds like you would categorize bash of MSYS2 (on Windows) as a real shell.

> On Linux bash etc. fall in the first category while Perl, Python
> etc. fall in the second category.
>
> On VMS DCL is in the first category while Python would go in the second.
>
> Arne

I agree that Python command prompt is not particularly handy (understatement) for use as "real shell". But I don't see why something like bash can't serve as "real shell" on VMS.

[Arne Vajhøj]

Yes.

>> On Linux bash etc. fall in the first category while Perl, Python
>> etc. fall in the second category.
>>
>> On VMS DCL is in the first category while Python would go in the
>> second.
>

> I agree that Python command prompt is not particularly handy
> (understatement) for use as "real shell". But I don't see why
> something like bash can't serve as "real shell" on VMS.

It could.

I just don't see the need.

For interactive usage then DCL works OK.

DCL is primitive for advanced scripting - it is lacking
in data types, control structures etc..

So a language that could handle "programming" would
in my opinion be sufficient.

Other may disagree and want bash.

Arne

[Scott Dorsey]

No, that's much of the difference between VMS and Unix: VMS processes are
very heavyweight. fork() is a very fast thing to do, SPAWN is a thing that
takes much longer because there is much more to be done. Much of the system
design is a consequence of this difference.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Bill Gunshannon]

On 1/11/20 12:54 PM, Arne Vajhøj wrote:
>
>
> Other may disagree and want bash.

As odd as it may sound, not all serious Unix users find bash to
be the best shell.

Regarding VMS, I thought I remembered there being a way to
change one's default CLI. I thought, for at least a little
while, I was able to set up my account to use the DEC provided
POSIX Shell instead of DCL. Don't remember how it was done
and I didn't like it when I tried it (I had to try everything
as I was the guy people came to with their questions when things
didn't go as they planned!) A shell was fine as a CLI for Unix,
but DCL was the proper CLI for VMS.

bill

[Arne Vajhøj]

VMS supports multiple CLI's.

You can set CLI per user in SYSUAF.

You can specify /CLI=xxxxx after username when you login.

I believe that back on old VMS version you could use the MCR CLI.

And POSIX may have had a CLI as well - never tried it.

But currently I believe it is DCL or DCL.

Arne

[Bill Gunshannon]

On 1/11/20 1:43 PM, Arne Vajhøj wrote:
> On 1/11/2020 1:23 PM, Bill Gunshannon wrote:
>> On 1/11/20 12:54 PM, Arne Vajhøj wrote:
>>> Other may disagree and want bash.
>>
>> As odd as it may sound, not all serious Unix users find bash to
>> be the best shell.
>>
>> Regarding VMS, I thought I remembered there being a way to
>> change one's default CLI.  I thought, for at least a little
>> while, I was able to set up my account to use the DEC provided
>> POSIX Shell instead of DCL.  Don't remember how it was done
>> and I didn't like it when I tried it (I had to try everything
>> as I was the guy people came to with their questions when things
>> didn't go as they planned!)  A shell was fine as a CLI for Unix,
>> but DCL was the proper CLI for VMS.
>
> VMS supports multiple CLI's.
>
> You can set CLI per user in SYSUAF.
>
> You can specify /CLI=xxxxx after username when you login.

That's the option I remember.

>
> I believe that back on old VMS version you could use the MCR CLI.
>
> And POSIX may have had a CLI as well - never tried it.

The POSIX shell could be used as a CLI.

>
> But currently I believe it is DCL or DCL.

As it should be. I was also against the proliferation of
abbreviations that attempted to make VMS use Unix-like
commands. And I was a Unix user more than a VMS user when
I first entered academia.

bill

[Arne Vajhøj]

I agree.

Having bash on VMS would be handy for the occasional
user logging in to a VMS system a few times per year.

But the system manager for a VMS system or a programmer
writing code for VMS need to know VMS and that it is not
just another *nix. So DCL.

What I miss is the scripting language with good
integration and formal support. DCL is fine for
interactive. DCL is fine for the 10-20 lines with
COPY, RENAME and DELETE commands. But for the 500-2000
lines program, then we can get something better.

Arne



Arne

[Michael Moroney]

VMS and Unixes take different approaches to shells and command execution.
Unix only has kernel and user modes. VMS has the 4 modes.

As others have mentioned, Unix shells are user mode processes which fork()
commands as needed and wait for them to complete. When they complete, the
forked processes are gone.

VMS runs the user image in the same process in user mode, DCL runs in
supervisor mode.

When a process (in user mode) runs SYS$EXIT() (*) to terminate, several things
happen.

1) If there are any user mode exit handlers declared, they are run.
2) The system starts tearing down user mode resources, memory space, user
mode logicals, etc. This is the image just run.

3) If there are any supervisor mode exit handlers declared, they are run. (**)
4) The system starts tearing down supervisor mode resources, memory space,
supervisor mode logicals, etc.

5) If there are any executive mode exit handlers declared, they are run.
6) The system starts tearing down executive mode resources, memory space,
executive mode logicals, etc.

7) I'm not sure kernel mode does the same, I think it's different.

8) The process is gone.

(*) Returning from a C main() routine is much the same for this discussion.
(**) DCL declares a routine of itself as a supervisor mode exit handler,
this routine makes DCL run in a loop, $ prompt, run program, $ prompt etc.
instead of your process terminating. Once in a while DCL will crash, so no
supervisor exit handler runs, go to Step 5 and shortly you are logged out.

So, a VMS shell will need to run in supervisor (or at least not user) mode,
sharing the same process as the image being run (in user mode), declare itself
with a supervisor mode exit handler to run in a loop. Other than no P0 space
available and the need to emulate/deal with CLI$ calls, I don't really know too
much which needs to be done. Oh security related stuff. But the stuff which
needs to be done is rather arcane, so don't expect new shells soon...

[Dave Froble]

Agreed! It's called BASIC ...


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

Basic could be used.

MS did in 1996 with WSH and VBS.

There are more Python users than Basic users
in this field though.

And VMS Basic would need some changes to fill that
role. For starters these people like interpreted over
compiled. And something more easy to use than LIB$
and SYS$ for system interface.

Arne

[VAXman-]

In article <qvdpmo$lji$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>On 1/11/2020 5:01 PM, Dave Froble wrote:

>Basic could be used.
>
>MS did in 1996 with WSH and VBS.
>
>There are more Python users than Basic users
>in this field though.
>
>And VMS Basic would need some changes to fill that
>role. For starters these people like interpreted over
>compiled. And something more easy to use than LIB$
>and SYS$ for system interface.

There is already a Python for VMS. If you want it, use it. You'll find yourself
pining for most/many/all of the existing VMS utilities if you supplant DCL because
most/many/all rely upon DCL to parse the commands in most/many/all of the utilities.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.