Re: Some questions on software for VMS 7.3 VAX (Stephen Hoffman)

[box]

I was actually wondering about that recently too, not only with ADA but
with the more ancient VAX Lisp distro, which I believe went by the wayside
back around 1990 from what I've been able to dig up?

Getting any older software to run on a 7.3 system is terrible though, only
a fraction of the binaries of the programs I've tried to set up (from the
old freeware cd archives that are online, and I mention that as a full
caveat on the quality of the programs I've tried to work with) work and
there's little source availability to recompile for newer VMS versions.
ADA seems to be under some level of legacy support by HP according to a
page there, but that may not have been updated since distribution ended 15
years ago, and installing an older language on newer VMS seems like it'd
be a matter of praying to the VMS system team gods that it wouldn't
require too many arcane rituals to get a thing last properly updated for
5.5 to work on 7.3.

I'd love it if the welcome email would include some helpful pointers on
where to find things that might work, but obviously that sort of thing is
an incredibly low priority. That being said, we hobbyists are here mostly
just trying to figure out an interesting system, so if anyone can help us
out with finding any licensed DEC/HP software on the hobbyist license then
please share it. I'd like to try out the ALL-IN-1 software suite that was
the main selling point to small offices for years, for example.


On 1/10/2016 12:00 PM, info-vax...@info-vax.com wrote:
>
> Date: Sun, 10 Jan 2016 11:26:20 -0500
> From: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3 VAX
> Message-ID: <n6u0ia$da0$1...@dont-email.me>
> Content-Type: text/plain; charset=iso-8859-1; format=flowed
>
> On 2016-01-10 15:24:37 +0000, rspon...@gmail.com said:
>
>> RE: ADA, I don't seem to have ADA on my 7.3 hobbyist media distibution,
>> but I do have license keys. How would I go about getting the actual
>> installation stuff?
>
> You send some mail to the folks that provided you with the PAKs and the
> kit downloads, and ask for a pointer to a VAX Ada kit download.
>
> Or you scrounge an old VAX consolidated distribution kit somewhere.
>
> This should probably be included in the welcome mail. Ah, well.
>
>

bif...@sdf.org
SDF Public Access UNIX System - http://sdf.org

[Hans Vlems]

I'm confused (nothing new there ;) what you want. Running an older system or running old software? With VMS the latter implies the first, old hardware remains supported for a long time. And even when support was dropped for a VAX it didn't mean it wouldn't run.
Most hobbyists run VMS because they've worked with the os for years, decades even. We've accumulated layered product distributions so if you'd need a certain version of a product, just ask here.
Before VMS V5.0 having the installation medium with a product was more or less proof that it was legal. Nobody gave those kits away. So it is more difficult to build such a system. I know that VMS 4.6 and 4.7 kits are around possibly with layered products. It depends on what you want to set up.
Hans

[Stephen Hoffman]

On 2016-01-10 21:02:40 +0000, box said:

> I was actually wondering about that recently too, not only with ADA but
> with the more ancient VAX Lisp distro, which I believe went by the
> wayside back around 1990 from what I've been able to dig up?

VAX went by the wayside in ~1992, with the availability of Alpha.

There were very few enhancements to OpenVMS VAX after V6.0.

DEC started pushing folks from OpenVMS over to Microsoft Windows
starting in ~1995. Not that more than a few weren't already heading
to Unix, too.

The old products that were deprecated were effectively tossed out.
That's rather the point of deprecating old software, after all.

If you need any of this and it's not on the recent consolidated
distributions, then — the more obscure — the more effort. You're going
to need to scrounge older kits.

Would some folks be all smiles and joy if there was a big old
repository of vintage software kits around? Sure. But that's
entirely up to the legal folks at HPE and VSI.

More recently, HPE is getting entirely out of the OpenVMS business.
This is the last year for new patches for the last supported OpenVMS
Alpha release. With the exception of OpenVMS I64 V8.4 and then
whatever VSI has available, everything that HPE has that's related to
VAX, Alpha and Itanium ends in ~three years.

In general, OpenVMS VAX — compared to what's expected and normal now —
was rather a pain in the rump to deal with. Even back then.

Integrity boxes are available, with rather more current products.
There's an rx3600 for ~US$250 on eBay, and an rx2660 for ~US$450.

There can be some very good deals, if you watch for them. Alpha and
VAX hardware is much more expensive — if it's still working.

There are CD distribution kits available, too:
http://www.ebay.com/itm/DIGITAL-DEC-OPENVMS-VAX-SOFTWARE-MAY-1991-/200933817590
http://www.ebay.com/itm/DIGITAL-DEC-OPENVMS-VAX-SOFTWARE-SEPTEMBER-1992-/151063764952


If you're into retro-computing — which is most anything that's
involving VAX — then it's going to involve some effort, and there will
be hassles. Missing firmware kits, missing distros, flaky (old)
hardware, etc. Much like adventure tourism, software tourism often
involves hauling your own supplies.

In any case, welcome to OpenVMS.


--
Pure Personal Opinion | HoffmanLabs LLC

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 10-Jan-16 5:45 PM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3

> VAX (Stephen Hoffman)
>
> On 2016-01-10 21:02:40 +0000, box said:
>

[snip..]

>
> More recently, HPE is getting entirely out of the OpenVMS business.

Actually, it looks like HPE is getting out of anything not based on X86-64
and that includes HP-UX and Non-Stop.

Case in point - HPE's new Server Mgmt product that replaces HP SIM and
other similar HP server HW mgmt. and monitoring utilities is called "HPE
OneView". OneView ONLY supports specific ProLiant blade, rack servers
running Windows or Linux and HPE storage and some network switches.

Short Links: (No Integrity server support for ANY platform)
http://tinyurl.com/hvzpjsr
http://tinyurl.com/OneView-Matrix

[snip]

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

On 2016-01-11 01:36:38 +0000, Kerry Main said:

>> More recently, HPE is getting entirely out of the OpenVMS business.
>>
>
>
> Actually, it looks like HPE is getting out of anything not based on
> X86-64 and that includes HP-UX and Non-Stop.

Ignoring The Machine, the HPE folks are now (publicly) interested in RISC-V:

http://riscv.org
HPE UEFI: http://riscv.org/workshop-jan2016/Tues1415%20RISC-V%20and%20UEFI.pdf

They've dabbled some with ARM in the ProLiant line, including the HPE
ProLiant m400 server cartridge. Not that they seem to be pushing all
that much ARM server gear lately, and the HPE Edgeline stuff — where
you'd expect to see some ARM-based boxes — has been marketed as a
partnership between HPE and Intel.

> Case in point - HPE's new Server Mgmt product that replaces HP SIM and
> other similar HP server HW mgmt. and monitoring utilities is called
> "HPE OneView". OneView ONLY supports specific ProLiant blade, rack
> servers running Windows or Linux and HPE storage and some network
> switches.

That's not new. The HPE vendor monitoring tools and error-processing
tools and related seem to get rebranded or replaced every three to five
years or so. Not that DEC and Compaq didn't also change out these and
related tools, too. Not that open-source tools also don't get
shuffled around or abandoned, as well. As for server monitoring,
more than a few folks are using some combination of Nagios/Icinga,
Cacti, Groundwork, Zabbix, Munin, OpenNMS, or otherwise. There were
Nagios NRPE bits for OpenVMS, and likely some others.

[li...@openmailbox.org]

On Sun, 10 Jan 2016 14:02:21 -0800 (PST)
Hans Vlems via Info-vax <info...@rbnsn.com> wrote:

> Most hobbyists run VMS because they've worked with the os for years,
> decades even. We've accumulated layered product distributions so if you'd
> need a certain version of a product, just ask here.

That was how this thread started. But so far no luck!

--
Please do not copy me on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49

[li...@openmailbox.org]

On Sun, 10 Jan 2016 21:02:40 +0000 (UTC)
box via Info-vax <info...@rbnsn.com> wrote:

> distribution ended 15 years ago, and installing an older language on
> newer VMS seems

> properly updated for 5.5 to work on 7.3.

A couple of quick checks indicate it works fine on VMS/VAX 7.3. So do most
or all of the languages included with the hobbyist downloads.

[Hans Vlems]

Please remind me, with all the noise I've forgotten what you'd asked for :-).
Was it All-in-1 for VAX/VMS?

[li...@openmailbox.org]

On Mon, 11 Jan 2016 00:43:27 -0800 (PST)

Hans Vlems via Info-vax <info...@rbnsn.com> wrote:

If you were referring to my post, I'm looking for:

Ada 95
Lisp
Fortran 90/95
Emacs (not MicroEmacs which is available on the web)

I did find a collection of VAX/VMS Software Distribution CDs but have not
been able to go through them yet.

From Simon's post I'm not sure if Ada 95 was ever available for VAX/VMS.
Can anyone confirm/deny? Same question for Fortran 90/95. I believe there
is a copy of that for Alpha though I don't have any way to run an Alpha
emulator.

Thanks :-)

[li...@openmailbox.org]

On Mon, 11 Jan 2016 09:12:07 +0000
li...@openmailbox.org wrote:

> On Mon, 11 Jan 2016 00:43:27 -0800 (PST)

> Hans Vlems via Info-vax <info...@rbnsn.com> wrote:
>

> If you were referring to my post, I'm looking for:
>
> Ada 95
> Lisp

I should have been more specific and written "official" DEC or COMPAQ
Common-Lisp implementation. Common Lisp was standardized around 1989 so
there probably was one available for VAX/VMS.

[hb]

On 01/11/2016 10:14 AM, li...@openmailbox.org wrote:
> I should have been more specific and written "official" DEC or COMPAQ
> Common-Lisp implementation. Common Lisp was standardized around 1989 so
> there probably was one available for VAX/VMS.

As mentioned before: the last version of VAX LISP (V3.1) kit was on the
VMS Consolidated Software Distribution May-1993, and you need a license
aka PAK to run it, no matter what the VMS version is and whether it
actually works on VMS V7.3 (or newer :-)) versions.

I learned something from Wikipedia after I posted my last reply
regarding VAX LISP. During development of version 4.0 VAX LISP was sold
to Lucid Inc. (known for Lucid Common Lisp), but the Wikipedia article
doesn't mention an actual date. Lucid Inc. went bankrupt in 1994, VAX
LISP isn't mentioned in that article. Whatever DEC sold to Lucid Inc.,
HP may still have the right to give you/hobbyists a license for V3.1.
However, the fact that the kit disappeared from the Condist may indicate
that even the rights for older versions were sold to Lucid Inc.

[li...@openmailbox.org]

On Mon, 11 Jan 2016 10:31:35 +0100
hb via Info-vax <info...@rbnsn.com> wrote:

> On 01/11/2016 10:14 AM, li...@openmailbox.org wrote:
> > I should have been more specific and written "official" DEC or COMPAQ
> > Common-Lisp implementation. Common Lisp was standardized around 1989 so
> > there probably was one available for VAX/VMS.
>
> As mentioned before: the last version of VAX LISP (V3.1) kit was on the
> VMS Consolidated Software Distribution May-1993, and you need a license
> aka PAK to run it, no matter what the VMS version is and whether it
> actually works on VMS V7.3 (or newer :-)) versions.

Thanks. I remember the discussion about needing a license for whatever
somebody might find. I did not remember that anybody said conclusively
whether or not any Lisp was in the distribution, only that there might be
one. This is a good lead then. The disks I found were from '92. Maybe I'll
get lucky somehow.

> I learned something from Wikipedia after I posted my last reply
> regarding VAX LISP. During development of version 4.0 VAX LISP was sold
> to Lucid Inc. (known for Lucid Common Lisp), but the Wikipedia article
> doesn't mention an actual date. Lucid Inc. went bankrupt in 1994, VAX
> LISP isn't mentioned in that article. Whatever DEC sold to Lucid Inc.,
> HP may still have the right to give you/hobbyists a license for V3.1.
> However, the fact that the kit disappeared from the Condist may indicate
> that even the rights for older versions were sold to Lucid Inc.

Interesting. Thanks for the info.

[Bob Koehler]

In article <mailman.25.1452503591.2...@rbnsn.com>, li...@openmailbox.org writes:

> Fortran 90/95

I think VAXen are stuck at Fortran 77.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 10-Jan-16 9:21 PM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
> VAX (Stephen Hoffman)
>

And that is why the DC config mgmt. world is such a mess. Each group
thinks they know better than the other group what is best from a systems
and network mgmt. perspective. Tools tend to grow from each group,
not as part of an overall service management strategy.

As an example - few groups understand that you need an Operations
Bridge function that takes events, alerts etc. from many tools, filters them,
correlates them and then does smart processing to determine if events
are symptoms or causes of the issue. Once processed, notification should
be sent to the right group to take action and info only notification is sent to
those groups impacted, but who need not take any action. Without this,
you get ticket bounce i.e. event happens and all groups scramble to fix
the event e.g. switch dies and App, Storage, Server, Network groups all
scramble before someone eventually determines it is a network issue.

The more mature IT groups will also integrate these processed alerts
with their service desk (smart ticketing), but that requires communication
& cooperation between groups and that unfortunately is in short supply
in many companies today.

What usually happens is companies spend a lot of $'s (prod's, resource
time) on products without really having a good overall and proactive
service management strategy in place. A year after spending big $'s on
tool projects, execs typically are frustrated because they do not see the
returns or efficiencies they expected. They fail to understand that the
custom work required to do the smart event filtering and correlation is
very customized and requires lots of time (internal or external resources)

Note - part of a service management strategy involves tools consolidation
and that can be almost as politically sensitive as server consolidation, but
that’s a different discussion.

[Stephen Hoffman]

Looks that way. V6.6-201, December, 1999, supports V5.4 to (likely)
V7.3, and implements FORTRAN-77.

The joys of ~twenty year old software and older, on a ~forty year old
architecture, and scrounging old distro kits.

After HPE and VSI no longer care about this stuff, then some of the
kits will probably get posted over at BitSavers.

[li...@openmailbox.org]

On Mon, 11 Jan 2016 10:23:48 -0500
Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:

> On 2016-01-11 14:35:16 +0000, Bob Koehler said:
>
> > In article <mailman.25.1452503591.2...@rbnsn.com>,
> > li...@openmailbox.org writes:
> >
> >> Fortran 90/95
> >
> > I think VAXen are stuck at Fortran 77.

That would be somewhat surprising. Would they really put the VAX out to
pasture when it came to something VMS/VAX was so famous for!?

> Looks that way. V6.6-201, December, 1999, supports V5.4 to (likely)
> V7.3, and implements FORTRAN-77.

That's the one, fort066 and I confirm it works quite nicely on 7.3. Kind of
a funny name for the release given FORTRAN 66 was also a standard. Not a
lot to like about UNIX but I still can't get used to not having a version
command or option on VMS/VAX. Had to see what sys$help there was to find
out what version I had.

But, how do we know there's nothing newer for VAX?

> The joys of ~twenty year old software and older, on a ~forty year old
> architecture, and scrounging old distro kits.

Luckily this still comes with the layered products in the hobbyist distro.

> After HPE and VSI no longer care about this stuff, then some of the
> kits will probably get posted over at BitSavers.

That's only if there's something newer than F77!

[Stephen Hoffman]

So we shift from HPE's changes in tools and strategy to the changes in
end-user tools and strategy. Okay. For the major hardware vendors,
each one pushes their own tools. That's their value-add. The
second-tier hardware vendors tend to push more of the de facto
standards and open-source tools.

Bottom-up enterprises always get software weeds and software thickets,
and divisions or groups can diverge from whatever corporate policies
and tools are in use. What some folks have called Shadow IT.
Top-down enterprises always get generic tools that are almost
inherently ill-suited for some particular local requirements and which
then means the local requirements can get ignored, or expunged and
standardized. There's no right answer here, either. Standardized
responses and solutions have better costs at scale, but the migrations
and the replacements are vastly larger projects and can be a budget
killer. (The budget-killing project weeds with distributed and Shadow
IT tend to be a whole lot less visible, individually.)

> As an example - few groups understand that you need an Operations
> Bridge function that takes events, alerts etc. from many tools, filters
> them, correlates them and then does smart processing to determine if
> events are symptoms or causes of the issue.

Who isn't running something like syslog or syslog-ng or related for a
production network, after all? Other than smaller-scale OpenVMS users
— who have to port and integrate those tools — that is.

The inability to easily integrate OpenVMS into networks makes new
OpenVMS deployments into existing heterogeneous environments more
effort.

This as somebody around here that has been grumbling about the lack of
OpenVMS integration for a while, as well as the effort involved in
managing installations, the difficulty of managing herds of OpenVMS
servers, the limited usefulness of LDAP on OpenVMS, etc. OpenVMS
leaves you with a limited box of tools, and the end-user or the
integrator then gets to build a workable system — without the installed
base and without sorts of libraries and tools and add-ons and technical
postings that were once what you'd find via DECUS — you get to do all
the work, often as a one-off. Or — has happens — you pick a different
platform which already has these capabilities and where you don't need
to do quite as many one-off projects, and retire the OpenVMS boxes.
More than a little of this stuff is part of what's now marketed as
"cloud management", after all.

> Once processed, notification should be sent to the right group to take
> action and info only notification is sent to those groups impacted,
> but who need not take any action. Without this, you get ticket bounce
> i.e. event happens and all groups scramble to fix the event e.g. switch
> dies and App, Storage, Server, Network groups all scramble before
> someone eventually determines it is a network issue.

ML is getting better but ain't there yet. The folks providing coroner
duty or triage will still guess wrong, too.

> The more mature IT groups will also integrate these processed alerts
> with their service desk (smart ticketing), but that requires
> communication & cooperation between groups and that unfortunately is in
> short supply in many companies today.

It's often in short supply because the current messy solution works
well enough that the more efficient and elegant and integrated solution
isn't viewed as a benefit to justify the expenses. Management gets
paid to make trade-offs, and — for more than a few decisions — all the
choices can be bad.

> What usually happens is companies spend a lot of $'s (prod's, resource
> time) on products without really having a good overall and proactive
> service management strategy in place. A year after spending big $'s on
> tool projects, execs typically are frustrated because they do not see
> the returns or efficiencies they expected. They fail to understand
> that the
>
> custom work required to do the smart event filtering and correlation is
> very customized and requires lots of time (internal or external
> resources)

Ready-Fire-Aim has a very long history in business management.

> Note - part of a service management strategy involves tools
> consolidation and that can be almost as politically sensitive as server
> consolidation, but that’s a different discussion.

Ayup. These quite commonly involves platform consolidation, too.
Which is part of why OpenVMS is declining. Beyond the insecurity and
the logging, OpenVMS just doesn't play well with others. Adding a
third OS team to your existing Windows and Linux OS support teams isn't
very popular, and that's before discussing the hardware or emulation
requirements for OpenVMS.

[hb]

On 01/11/2016 04:52 PM, li...@openmailbox.org wrote:
> Not a lot to like about UNIX but I still can't get used to not having
> a version command or option on VMS/VAX. Had to see what sys$help
> there was to find out what version I had.

The version is usually in the compiler listing, on each page. On recent
VMS versions with "pipe" one can get to the version with something like

$ pipe fort/old/list=sys$output nl:/noobj | (read sys$pipe x ;
x=f$edit(x,"compress,trim") ; x=x-f$element(0," ",x)-f$element(1,"
",x)-"Page 1" ; write sys$output f$edit(x,"trim"))
Compaq Fortran 77 V7.2-180
$

Or, if you like GNV more than UNIX :-)

bash-4.3$ dcl 'fort/old/list=sys$output nl:/noobj' | head -n1 | awk
'{for (i=3; i<NF-1; i++) printf "%s ", $i; printf "\n"}'
Compaq Fortran 77 V7.2-180
bash-4.3$

Shouldn't be a big deal to write a generic script to do this for all the
compilers, available on your system.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 11-Jan-16 11:05 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
> VAX (Stephen Hoffman)
>

[snip]

>
> > As an example - few groups understand that you need an Operations
> > Bridge function that takes events, alerts etc. from many tools, filters
> > them, correlates them and then does smart processing to determine if
> > events are symptoms or causes of the issue.
>
> Who isn't running something like syslog or syslog-ng or related for a
> production network, after all? Other than smaller-scale OpenVMS users
> — who have to port and integrate those tools — that is.
>
> The inability to easily integrate OpenVMS into networks makes new
> OpenVMS deployments into existing heterogeneous environments
> more
> effort.
>

While I agree OpenVMS needs improvements, let's not try and say that
integrating Windows with Linux and Solaris and Cisco server alarms is
easy either.

Case in point - SNMP service on Windows servers is off by default. In
addition, while it was raised previously here as a knock against VNS,
SNMP V3 is not supported on Windows platforms either.

[Google SNMP V3 Windows 2012]

[snip]

> It's often in short supply because the current messy solution works
> well enough that the more efficient and elegant and integrated solution
> isn't viewed as a benefit to justify the expenses. Management gets
> paid to make trade-offs, and — for more than a few decisions — all the
> choices can be bad.
>

Current drivers are senior business types who are frustrated with the old
way of internal IT where end users have to call and tell IT there is an issue
with something. Business types are asking "why can't IT be more proactive
and notify us that there is something that has failed and what services are
impacted?"

Maintaining the old way of reactive IT (each group doing their own tools)
is a great way to get out-sourced or, using today's hype, "moved to a public
cloud" which is just another name for selective IT outsourcing.

[snip]

[li...@openmailbox.org]

On Mon, 11 Jan 2016 18:21:10 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> On 01/11/2016 04:52 PM, li...@openmailbox.org wrote:
> > Not a lot to like about UNIX but I still can't get used to not having
> > a version command or option on VMS/VAX. Had to see what sys$help
> > there was to find out what version I had.
>
> The version is usually in the compiler listing, on each page.

Yeah I know. That's where I usually find it. I just forgot to leave a
listing around and it was easier to go fishing in sys$help. I understand at
some point later in time they did standardize a /VERSION switch.

> On recent VMS versions with "pipe" one can get to the version with
> something like
>
> $ pipe fort/old/list=sys$output nl:/noobj | (read sys$pipe x ;
> x=f$edit(x,"compress,trim") ; x=x-f$element(0," ",x)-f$element(1,"
> ",x)-"Page 1" ; write sys$output f$edit(x,"trim"))
> Compaq Fortran 77 V7.2-180

That's truly horrible, man. It looks like Perl.

> Or, if you like GNV more than UNIX :-)

Less, actually.

> bash-4.3$ dcl 'fort/old/list=sys$output nl:/noobj' | head -n1 | awk
> '{for (i=3; i<NF-1; i++) printf "%s ", $i; printf "\n"}'
> Compaq Fortran 77 V7.2-180
> bash-4.3$

I can say with certainty "No VMS system of mine is ever gonna have bash on
it!" I don't even use bash on UNIX! On VMS how much more so!

> Shouldn't be a big deal to write a generic script to do this for all the
> compilers, available on your system.

Probably easier and less offensive to just remember to leave listings lying
around in dev directories. Thanks, I'm gonna be sick now.. ;-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of hb
> via Info-vax
> Sent: 11-Jan-16 12:21 PM
> To: info...@info-vax.com

> Cc: hb <end...@inter.net>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
> VAX
>

Not sure if available on VAX/VMS, but for recent systems, you simply
enter the following native commands:

$ fort /version
VSI Fortran V8.3-104956-50P85
$
$ cc /version
VSI C V7.4-001 on OpenVMS IA64 V8.4-1H1
$
$ CXX /version
HP C++ V7.4-004 on OpenVMS IA64 V8.4-1H1
$
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment "1.6.0-6"
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b06, mixed mode)
$
$ cobol /version
VSI COBOL V3.1-0007 on OpenVMS IA64 V8.4-1H1
$
$ pascal /version
VSI Pascal I64 V6.2-125 on OpenVMS I64 V8.4-1H1
$

[John Reagan]

On Monday, January 11, 2016 at 12:21:23 PM UTC-5, hb wrote:

>
> The version is usually in the compiler listing, on each page. On recent
> VMS versions with "pipe" one can get to the version with something like
>

Most of the compilers also put a version string in the image ident of the compiler's image.

[John Reagan]

On Monday, January 11, 2016 at 12:55:05 PM UTC-5, Kerry Main wrote:

Yep, just BASIC is missing. It is on our list.

[John Reagan]

On Monday, January 11, 2016 at 10:55:05 AM UTC-5, li...@openmailbox.org wrote:
> On Mon, 11 Jan 2016 10:23:48 -0500
> Stephen Hoffman via Info-vax <> wrote:
>
> > On 2016-01-11 14:35:16 +0000, Bob Koehler said:
> >

> > > In article <>,

> > > li...@openmailbox.org writes:
> > >
> > >> Fortran 90/95
> > >
> > > I think VAXen are stuck at Fortran 77.
>
> That would be somewhat surprising. Would they really put the VAX out to
> pasture when it came to something VMS/VAX was so famous for!?
>

The F95 frontend uses C89/C99 language features that VAX C can't compile.

The F95 frontend was designed to attach to GEM. There is no GEM for VAX.

[li...@openmailbox.org]

On Mon, 11 Jan 2016 17:50:50 +0000
Kerry Main via Info-vax <info...@rbnsn.com> wrote:

> Not sure if available on VAX/VMS, but for recent systems, you simply
> enter the following native commands:


> $ fort /version
> VSI Fortran V8.3-104956-50P85

I read this was added at some point but it does not seem to work with the
VAX/VMS compilers.

[li...@openmailbox.org]

Thanks. Your definitive explanations are always appreciated :-)

[David Froble]

Oh, the perfidity! No mention of Basic!

And why might that be?

DFE90A::DFEUL> basic

VAX BASIC V3.8-000

Ready

Well, it was there on VAX, but in 60 seconds of looking, the Alpha
implementation seems to not have a method of listing the version.

:-(

[David Froble]

Ah, someone remembers ...

:-)

[John Reagan]

As I mentioned earlier, most compilers (including Alpha BASIC) put their version numbers in the image header. Depending on what info the developer's wanted to encode, it might be a little cryptic since there is a limit of just 15 chars (and that rather small limit was carried over to Itanium - I wish we made it larger... I'll add *that* to the list too.)

$ write sys$output f$getsyi("arch_name")
Alpha
$ anal/image/select=ident sys$system:basic.exe
SYS$COMMON:[SYSEXE]BASIC.EXE;2
"BASIC V1.5-000"
$ anal/image/select=ident sys$system:pascal.exe
SYS$COMMON:[SYSEXE]PASCAL.EXE;2
"V5.7-73-408BJ"
$ ! The word PASCAL was dropped to make room for GEM version

I don't know about the VAX compilers as I don't have a VAX system.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

John - thanks!

To add to my earlier list of compiler versions:
$ anal/image/select=ident sys$system:basic.exe
SYS$COMMON:[SYSEXE]BASIC.EXE;1
"BASIC V1.8-004"
$

Btw, Pascal already supports "/version"

$ pascal /version
VSI Pascal I64 V6.2-125 on OpenVMS I64 V8.4-1H1
$

:-)

[Stephen Hoffman]

On 2016-01-11 17:40:42 +0000, Kerry Main said:

>>
>>
> While I agree OpenVMS needs improvements, let's not try and say that
> integrating Windows with Linux and Solaris and Cisco server alarms is
> easy either.

Um, if Linux or Solaris or Cisco are or are not easy — they do have
various add-ons available, of course — then maybe being easier than
those platforms might be an opportunity?

This is not about the current situations from other vendors, nor about
the past. The current situation with other vendors is already at
least a year or two in the past, pragmatically.

This is about operating systems going forward, and about problems folks
are having right now, and about what can be done — and what other
vendors may or will be doing.

Other platforms which you keep telling me are problematic.

But then, these problematic platforms are less problematic than OpenVMS, too.

> Case in point - SNMP service on Windows servers is off by default.

So what? Or is the Microsoft way the only way to do things?

> In addition, while it was raised previously here as a knock against
> VNS, SNMP V3 is not supported on Windows platforms either.

Again, so what? Or, again, is following Microsoft the only approach?

> Current drivers are senior business types who are frustrated with the
> old way of internal IT where end users have to call and tell IT there
> is an issue with something. Business types are asking "why can't IT be
> more proactive and notify us that there is something that has failed
> and what services are impacted?"

Given OpenVMS is arguably worse than these other platforms — in terms
of what's installed and what's available without having to port it all
yourself — then maybe that's likely a problem for the folks that might
be considering the OpenVMS platform? Or the folks that might be
having problems defending keeping the platform around, for that matter.
SNMPv3, syslog/syslog-ng, patch management, crash management, remote
inventory, etc.

> Maintaining the old way of reactive IT (each group doing their own
> tools) is a great way to get out-sourced or, using today's hype, "moved
> to a public cloud" which is just another name for selective IT
> outsourcing.

Which means maybe VMS should not be even more private and more
isolated. Or did I miss something?

Also, get off of Windows for a while, and learn where there might be
different approaches and opportunities. OpenVMS is not competitive
with Windows and Linux, and will have to coexist with them. And
OpenVMS needs to be substantially easier to deal with than it is now,
and in comparison to the other platforms.

[Jan-Erik Soderholm]

Den 2016-01-11 kl. 18:52, skrev li...@openmailbox.org:
> On Mon, 11 Jan 2016 18:21:10 +0100
> hb via Info-vax <info...@rbnsn.com> wrote:
>
>> On 01/11/2016 04:52 PM, li...@openmailbox.org wrote:
>>> Not a lot to like about UNIX but I still can't get used to not having
>>> a version command or option on VMS/VAX. Had to see what sys$help
>>> there was to find out what version I had.
>>
>> The version is usually in the compiler listing, on each page.
>
> Yeah I know. That's where I usually find it. I just forgot to leave a
> listing around and it was easier to go fishing in sys$help. I understand at
> some point later in time they did standardize a /VERSION switch.
>
>> On recent VMS versions with "pipe" one can get to the version with
>> something like
>>
>> $ pipe fort/old/list=sys$output nl:/noobj | (read sys$pipe x ;
>> x=f$edit(x,"compress,trim") ; x=x-f$element(0," ",x)-f$element(1,"
>> ",x)-"Page 1" ; write sys$output f$edit(x,"trim"))
>> Compaq Fortran 77 V7.2-180
>
> That's truly horrible, man. It looks like Perl.

And to much then actualy needed:

$ fort/old/list=sys$output nl:/noobj

[About a page of info snipped...]


COMPILER: HP Fortran 77 V7.6-198-48H9K

COMPILATION STATISTICS

CPU time: 0.01 seconds
Elapsed time: 0.10 seconds
Pagefaults: 73
I/O Count: 54
$

[David Froble]

John Reagan wrote:

> I don't know about the VAX compilers as I don't have a VAX system.

Well, that needs to be fixed ....

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 11-Jan-16 4:54 PM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
> VAX (Stephen Hoffman)
>

> On 2016-01-11 17:40:42 +0000, Kerry Main said:
>
> >>
> >>
> > While I agree OpenVMS needs improvements, let's not try and say that
> > integrating Windows with Linux and Solaris and Cisco server alarms is
> > easy either.
>
> Um, if Linux or Solaris or Cisco are or are not easy — they do have
> various add-ons available, of course — then maybe being easier than
> those platforms might be an opportunity?
>
> This is not about the current situations from other vendors, nor about
> the past. The current situation with other vendors is already at
> least a year or two in the past, pragmatically.
>
> This is about operating systems going forward, and about problems folks
> are having right now, and about what can be done — and what other
> vendors may or will be doing.
>
> Other platforms which you keep telling me are problematic.
>
> But then, these problematic platforms are less problematic than
> OpenVMS, too.
>

[snip..]

No one is saying that OpenVMS does not need improvements. To be fair,
VSI has provided a fairly good roadmap of some major things they plan to
address in the next 24 months. However, Rome was not built in a day.

What I am saying is that many of the "big" issues you keep pointing out
that OpenVMS has are issues with many of the other platforms as well.

> Also, get off of Windows for a while, and learn where there might be
> different approaches and opportunities. OpenVMS is not competitive
> with Windows and Linux, and will have to coexist with them. And
> OpenVMS needs to be substantially easier to deal with than it is now,
> and in comparison to the other platforms.

OpenVMS's future server competition absolutely is going to be Linux and
Windows on X86-64 server platforms as the Solaris, AIX, HP-UX folks are
in a race to the bottom, so yes there needs to be lots of improvements
and OpenVMS transformations.

Again, no one is saying this is not the case. The choir already knows this.

:-)

[Bob Koehler]

In article <mailman.114.1452527624....@rbnsn.com>, li...@openmailbox.org writes:
> On Mon, 11 Jan 2016 10:23:48 -0500
> Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:
>
>> On 2016-01-11 14:35:16 +0000, Bob Koehler said:
>>
>> > In article <mailman.25.1452503591.2...@rbnsn.com>,
>> > li...@openmailbox.org writes:
>> >
>> >> Fortran 90/95
>> >
>> > I think VAXen are stuck at Fortran 77.
>
> That would be somewhat surprising. Would they really put the VAX out to
> pasture when it came to something VMS/VAX was so famous for!?

Yes, I remember when HP, Sun, an IBM were pushing that thier UNIX
workstations had Fortran compilers that were compatable with
"VAX Fortran".

Sadly, that is no longer the defacto industry standard. I get much
better support from gfortran on other platforms.

[Stephen Hoffman]

On 2016-01-12 14:10:04 +0000, Bob Koehler said:

> In article <mailman.114.1452527624....@rbnsn.com>,
> li...@openmailbox.org writes:
>> On Mon, 11 Jan 2016 10:23:48 -0500
>> Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:
>>
>>> On 2016-01-11 14:35:16 +0000, Bob Koehler said:
>>>
>>>> In article <mailman.25.1452503591.2...@rbnsn.com>,
>>>> li...@openmailbox.org writes:
>>>>
>>>>> Fortran 90/95
>>>>
>>>> I think VAXen are stuck at Fortran 77.
>>
>> That would be somewhat surprising. Would they really put the VAX out to
>> pasture when it came to something VMS/VAX was so famous for!?

So is that trolling, willful blindness, or genuine ignorance?

Yes, the VAX compilers are fossils. Not that the current compilers on
Alpha and Integrity aren't now a revision or two behind the current
major language standards, too.

VAX is utterly and totally dead, having been replaced over twenty years ago.

That replacement was during the era before Windows 95 and Windows NT
became established, too.

OpenVMS itself is very much on a retirement and deprecation schedule
over at HPE.

Whether existing sites migrate to VSI products, or migrate off of OpenVMS?

OpenVMS may still be entirely dead too, if VSI can't find and pull some
sufficiently profitable rabbits out of their hat.

But VAX? VAX was a pain to back-port software to back in the 1990s
after the OS forked, and the problems and the effort involved in
backports has only increased , and particularly increased after 64-bit
support was added to OpenVMS. This other than BASIC, Macro32 and
Bliss32, that is — most of the other compilers moved to newer standards
and to 64-bit support and to newer code generation tools and APIs.
The migration from VCG to GEM was already mentioned else-thread, and
code generation is being entirely replaced again with LLVM with the
x86-64 port.

> Yes, I remember when HP, Sun, an IBM were pushing that thier UNIX
> workstations had Fortran compilers that were compatable with "VAX
> Fortran".
>
> Sadly, that is no longer the defacto industry standard. I get much
> better support from gfortran on other platforms.

VAX and OpenVMS in general has not been the industry standards in much
of anything since the 1990s. Not in anything that folks were willing
to pay for.

[David Froble]

VAX is dead ..
Alpha is dead ..
itanic is dead ..

Perhaps VMS has a chance on x86, we will see ..

Hobbyist and retro-computing can still use the above HW.

[John Reagan]

On Tuesday, January 12, 2016 at 10:18:56 AM UTC-5, Stephen Hoffman wrote:

> The migration from VCG to GEM was already mentioned else-thread, and
> code generation is being entirely replaced again with LLVM with the
> x86-64 port.
>

VAX Fortran does not use the VCG. It has its own code generator. Only PL/1, C, SCAN, and Ada used the VCG on VAX (and they are clones of each other, each subtly different). BASIC, BLISS-32, COBOL, Fortran, and Pascal each have their own code generator.

[li...@openmailbox.org]

On Tue, 12 Jan 2016 10:18:54 -0500

Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:

> On 2016-01-12 14:10:04 +0000, Bob Koehler said:
>
> > In article <mailman.114.1452527624....@rbnsn.com>,
> > li...@openmailbox.org writes:
> >> On Mon, 11 Jan 2016 10:23:48 -0500
> >> Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:
> >>
> >>> On 2016-01-11 14:35:16 +0000, Bob Koehler said:
> >>>
> >>>> In article
> >>>> <mailman.25.1452503591.2...@rbnsn.com>,
> >>>> li...@openmailbox.org writes:
> >>>>
> >>>>> Fortran 90/95
> >>>>
> >>>> I think VAXen are stuck at Fortran 77.
> >>
> >> That would be somewhat surprising. Would they really put the VAX out
> >> to pasture when it came to something VMS/VAX was so famous for!?
>
> So is that trolling, willful blindness, or genuine ignorance?

If it's a question from me about VAX/VMS it is almost genuine ignorance.
But thanks for considering the first two possibilities ;-)

I wasn't there so I really don't know. I thought I read in a recent post
here that VAX was still sold into the early 2000s (2002?). If so I would
have thought there would have been an F90 compiler given the VAX apparently
had very nice floating point hardware support and the amount of VAX hardware
already out there where people didn't want to/need to migrate to Alpha.

> VAX is utterly and totally dead, having been replaced over twenty years
> ago.

Fortran 90 came out twenty five years ago, hence my question.

[li...@openmailbox.org]

On Tue, 12 Jan 2016 16:27:41 +0000
li...@openmailbox.org wrote:

> On Tue, 12 Jan 2016 10:18:54 -0500

> Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:
>
> > On 2016-01-12 14:10:04 +0000, Bob Koehler said:
> >
> > > In article
> > > <mailman.114.1452527624....@rbnsn.com>,
> > > li...@openmailbox.org writes:
> > >> On Mon, 11 Jan 2016 10:23:48 -0500
> > >> Stephen Hoffman via Info-vax <info...@rbnsn.com> wrote:
> > >>
> > >>> On 2016-01-11 14:35:16 +0000, Bob Koehler said:
> > >>>
> > >>>> In article
> > >>>> <mailman.25.1452503591.2...@rbnsn.com>,
> > >>>> li...@openmailbox.org writes:
> > >>>>
> > >>>>> Fortran 90/95
> > >>>>
> > >>>> I think VAXen are stuck at Fortran 77.
> > >>
> > >> That would be somewhat surprising. Would they really put the VAX out
> > >> to pasture when it came to something VMS/VAX was so famous for!?
> >
> > So is that trolling, willful blindness, or genuine ignorance?
>

> If it's a question from me about VAX/VMS it is almost genuine ignorance.

Hah, hah, hah, I meant "almost *always* genuine ignorance." I'm sure
Hoffman can distinguish the difference based on his own question.

[Stephen Hoffman]

On 2016-01-12 15:57:59 +0000, David Froble said:

> Stephen Hoffman wrote:
>>
>> VAX and OpenVMS in general has not been the industry standards in much
>> of anything since the 1990s. Not in anything that folks were willing
>> to pay for.
>>
>
> VAX is dead ..
> Alpha is dead ..
> itanic is dead ..

Probably one more generation for the lattermost Itanium servers per
reported HPE plans, but yes.

> Perhaps VMS has a chance on x86, we will see ..

VSI probably has some idea, but — for the folks that don't have a
backdoor view to Clair Grant's office whiteboards and notes — the time
and effort involved in bringing OpenVMS forward to something that's
(more) competitive should not and cannot be underestimated. OpenVMS
is not competitive with Linux nor Windows. Not in its present state.

For the next ~five years, VSI is entirely about the installed base.

The downside of any installed base on any platform being that most will
want things that most potential new customers probably will not.
These are not easy choices to make, either. In the face of
fundamentally broken tools and interfaces, compatibility eventually and
inevitably kills. Which means VSI has the choice to ride the OpenVMS
installed base down for whatever profits can be extracted, or to break
things and to annoy and to risk alienating the existing folks, and to
start working to expand the installed base.

But to what end, what features, and for what potential customers, too?
Not to draw off even a rounding error from the total number of Linux
or Windows Server users, certainly.

> Hobbyist and retro-computing can still use the above HW.

Ayup; but please do remember to check any modern mental baggage — the
sorts of standards and features that folks accustomed to Windows,
Linux, BSD or OS X might expect to have available in a computer — at
the door.

[Stephen Hoffman]

Thanks. (As if there needed to be yet another reason to toss VAX
under under the I/O bus.)

[Bob Koehler]

In article <mailman.119.1452616123....@rbnsn.com>, li...@openmailbox.org writes:
>
> I wasn't there so I really don't know. I thought I read in a recent post
> here that VAX was still sold into the early 2000s (2002?). If so I would
> have thought there would have been an F90 compiler given the VAX apparently
> had very nice floating point hardware support and the amount of VAX hardware
> already out there where people didn't want to/need to migrate to Alpha.

Long before VAXen stopped being sold, DEC stopped providing any
significant software updates.

The excuse at the time was a claim that all the customers still on
VAX wanted the freeze.

[Stephen Hoffman]

On 2016-01-12 21:56:51 +0000, Bob Koehler said:

> In article <mailman.119.1452616123....@rbnsn.com>,
> li...@openmailbox.org writes:
>>
>> I wasn't there so I really don't know. I thought I read in a recent
>> post here that VAX was still sold into the early 2000s (2002?). If so I
>> would have thought there would have been an F90 compiler given the VAX
>> apparently had very nice floating point hardware support and the amount
>> of VAX hardware already out there where people didn't want to/need to
>> migrate to Alpha.

Why would you spend time, effort and money updating an older platform,
when that budget comes directly out of work on the newer platform?

Among the many issues with VAX, VAX lacked PCSI for OpenVMS
installations. VAX lacks a consistent console. VAX lacks optical
media requirements, and had way too many distribution media types.
When the last of the magtape and the TK media finally became
unavailable, the platform was far too gone to overhaul and upgrade to
PCSI installs, for that matter. VAX booted standalone backup from
tape distro with 9-track and TK50 being the most common, and — other
than optical, RC25 and maybe one or two other older media types —
couldn't boot "full" OpenVMS off of distro kits. VAX didn't use VCG
for the compilers. VAX was 32-bit, and folks were increasingly
slamming into S0/S1 space limits. You had to reboot the system once
a year or remember to save the time manually between January and April,
or the TOY clock would wrap, too. VAX didn't have IEEE FP, either —
which is part of why Java never got to VAX.

So... Why mess around with VAX, at the expense of the Alpha platform —
the platform that DEC was trying to get accepted for Tru64 Unix /
Digital UNIX / OSF/1, Microsoft Windows and OpenVMS, and was seeking to
get other vendors — reportedly including Apple and other vendors — to
use?

> Long before VAXen stopped being sold, DEC stopped providing any
> significant software updates.
>
> The excuse at the time was a claim that all the customers still on
> VAX wanted the freeze.

The folks that wanted changes were moving to Alpha, or were porting off
of VMS. Those that didn't want to move — same as now — didn't want to
change anything.

The OpenVMS VAX APIs were effectively frozen at V6.0, at both user-mode
and kernel-mode. The kernel-mode freeze was a then-new thing for
OpenVMS developers.

[abrsvc]

Most of the VAX clients I deal with still (there are a few), remain there due mostly to hardware constraints. There are many sites that have custom hardware connected to the VAX that has no direct replacement on either Alpha or IA64. Since the code (and machine) continue to work without failures, it continues. While I am concerned that hardware of this age is likely to fail at any time, these clients continue to depend on it.

In these cases, "new" stuff really has no value...

Dan

[David Froble]

Well, DEC made a run of N-VAX CPUs, but not enough, they ran out before the (I
believe) 5 years they forecast. These were used in the last VAX models to milk
the customer base. Things like the MicroVAX 3100 Model 98. A rather nice
system, but still without a bus for plugging in various things.

As for software, there was no new stuff that I'm aware of in the late 1990s.

[David Froble]

Well when (if) VMS gets to x86, perhaps some of the custom stuff could be easily
replaced, and such customers would then have a new life for their applications.

Not knowing what the custom devices are, can't determine the difficulty in
replacements.

[Stephen Hoffman]

On 2016-01-13 00:39:12 +0000, David Froble said:

> abrsvc wrote:
>> Most of the VAX clients I deal with still (there are a few), remain
>> there due mostly to hardware constraints. There are many sites that
>> have custom hardware connected to the VAX that has no direct
>> replacement on either Alpha or IA64. Since the code (and machine)
>> continue to work without failures, it continues. While I am concerned
>> that hardware of this age is likely to fail at any time, these clients
>> continue to depend on it.
>> In these cases, "new" stuff really has no value...
>

> Well when (if) VMS gets to x86, perhaps some of the custom stuff could
> be easily replaced, and such customers would then have a new life for
> their applications.
>
> Not knowing what the custom devices are, can't determine the difficulty
> in replacements.

That's not likely. The I/O buses aren't going to change all that much
from what's available now with Itanium: mostly PCIe and USB, or
outboard PLCs or embedded boards.

Migrations are probably going to FPGA on PCIe, or to some PLC or
analog, or wholesale replacement of the OpenVMS end with whatever is
current when whatever is out on the far end of the connection — what's
usually the expensive or hard-to-change part of the configuration —
gets replaced.

What freezes more than a few of these cases involves both the weird
network protocols — and which tend to be completely bizarre, and more
than a little timing sensitive — and recreating the device driver
interfaces that are more of a problem, if you can't disrupt the apps on
the OpenVMS end. That, and what they have is working. There's not
much point in upgrading or replacing OpenVMS for these folks, in other
words. If they could even do it.

PLC communications protocols commonly used back in the 1980s were... demented.

For more than a few folks, the factory or the equipment test frame or
the crane or the turbine or whatever is out on the other end of the
connection will eventually get replaced. Until then, the VMS box is
little more than a peripheral of that other function.

These sites are not going to be VSI customers, either. Not until and
unless the third-party providers and integrators that are inevitably
involved here decide to use OpenVMS for their embedded computing, too.

This is kind of like replacing the vehicle in-dash entertainment
systems that are being sold in more than a few cars — possible, but a
whole lot of work for not much gain, and will usually only happen when
(if) you buy another car. The cases that Dan and I and others have
seen or have worked on aren't that far off what the IoT folks will be
seeing — and the rest of us — all over the place, either.

[abrsvc]

You hit the nail on the head here. I think the best way to describe the attitude of these sites is: If it ain't broke, don't fix it...

Unfortunately, when it breaks, is damn near impossible to replace it.

Dan

[Hans Vlems]

I'm glad to hear that...

[Bob Koehler]

In article <n7466d$ojt$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> Well when (if) VMS gets to x86, perhaps some of the custom stuff could be easily
> replaced, and such customers would then have a new life for their applications.
>
> Not knowing what the custom devices are, can't determine the difficulty in
> replacements.

Start with this difficulty: custom stuff that costs millions of
dollars. The computer attached to it is a small expense.

I've worked with several of these, and they're not getting off VAX.

[lji...@gmail.com]

NuVAX from The Logical Company can replace the VAX components (CPU, memory, disk, tape, network) while preserving the VMS-based applications and connections to any custom devices:
http://logical-co.com/nuvax/

[hb]

On 01/11/2016 10:12 AM, li...@openmailbox.org wrote:
> Emacs (not MicroEmacs which is available on the web)

As we learned the other day, you - ahem I - shouldn't work with VAXes
any more. So this is for entertainment, only:

$ @[-.emacs212_3]configure --with-tcpip=NO --with-x=NO
--WITH-X-TOOLKIT=NO --prefix=bld_root:[LOCAL]
--startupdir=bld_root:[LOCAL.STAR
TUP]
$ ...
$ @BLD_ROOT:[LOCAL.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS
%GNU_STARTUP-I-SETTING_UP, setting up Emacs version 21.2
$
$ define term vt100
$ runemacs
...
or
$ emacs
[Spawning a new Kept EMACS]
...

Welcome to GNU Emacs

Get help C-h (Hold down CTRL and press h)
Undo changes C-x u Exit Emacs C-x C-c
Get a tutorial C-h t Use Info to read docs C-h i
Ordering manuals C-h RET
Activate menubar F10 or ESC ` or M-`
(`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
If you have no Meta key, you may instead type ESC followed by the
character.)

GNU Emacs 21.2.1 (vax-dec-vms7.3)
of 2016-01-14 14:23:42 on one of the few remaining VMS machines on Earth
Copyright (C) 2001 Free Software Foundation, Inc.

...

Interesting, the source code directory indicates version 21.2.3 but
emacs itself prints 21.2.1.

This is based on the emacs21_2.zip from the 8.0 freeware cd. There are a
couple of changes to let emacs make a computer slow. It looks like that
code was never built or tested on VAXes. Also, this VAX is a simh and I
use the console, OPA0:, set to a reasonable baud rate. I can't get it to
work when logged in via telnet to port 60123, which is a simh DZ device,
aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
overrun" when I type very fast, aka do a cut and paste. So, it's not yet
production quality, but for hobbyists ...

Yes, I had some fun :-)

[li...@openmailbox.org]

On Thu, 14 Jan 2016 15:13:49 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> On 01/11/2016 10:12 AM, li...@openmailbox.org wrote:
> > Emacs (not MicroEmacs which is available on the web)
>
> As we learned the other day, you - ahem I - shouldn't work with VAXes
> any more. So this is for entertainment, only:

I very little idea what you did or how much effort it was. And I purposely
didn't install the C compiler on my hobbyist system so perhaps this won't
be so easy. But:

> Welcome to GNU Emacs
>
> Get help C-h (Hold down CTRL and press h)
> Undo changes C-x u Exit Emacs C-x C-c
> Get a tutorial C-h t Use Info to read docs C-h i
> Ordering manuals C-h RET
> Activate menubar F10 or ESC ` or M-`
> (`C-' means use the CTRL key. `M-' means use the Meta (or Alt) key.
> If you have no Meta key, you may instead type ESC followed by the
> character.)
>
> GNU Emacs 21.2.1 (vax-dec-vms7.3)

Yay!

> of 2016-01-14 14:23:42 on one of the few remaining VMS machines on Earth

Haha, does it really say that? The FSF people are huge idiots.

> Copyright (C) 2001 Free Software Foundation, Inc.
>
> ...
>
> Interesting, the source code directory indicates version 21.2.3 but
> emacs itself prints 21.2.1.

Sue the above copyright holders! Why would they copyright anything when
they claim copyrights are the world's greatest evil btw? Don't answer that.

> This is based on the emacs21_2.zip from the 8.0 freeware cd. There are a
> couple of changes to let emacs make a computer slow. It looks like that
> code was never built or tested on VAXes. Also, this VAX is a simh and I
> use the console, OPA0:, set to a reasonable baud rate. I can't get it to
> work when logged in via telnet to port 60123, which is a simh DZ device,
> aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
> have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
> overrun" when I type very fast, aka do a cut and paste. So, it's not yet
> production quality, but for hobbyists ...

If it overruns it's not ready for hobbyists either. Very little is worse
than an editor that doesn't work or screws up your code.

Is the above via X-server? Emacs is supposed to have at least two ways it
can run, one in a console and one with X. I'm susprised it doesn't work
over telnet. The MicroEmacs I found works over telnet here.

[hb]

On 01/15/2016 10:31 AM, li...@openmailbox.org wrote:

> I very little idea what you did or how much effort it was. And I purposely
> didn't install the C compiler on my hobbyist system so perhaps this won't
> be so easy. But:

You need a recent C compiler and you need a recent mms (I don't have it
and I don't know which version is available for VAX and if that version
works) or mmk as source code to fix an RMS-W-RTB error. Then you need a
couple of VAX specific Emacs source files - and some instructions and
time to do the build.

>> of 2016-01-14 14:23:42 on one of the few remaining VMS machines on Earth
>
> Haha, does it really say that? The FSF people are huge idiots.

It is probably in one of the init/site scripts, which are in Lisp, as
far as I understand. Should be easy to change, if necessary.

>> This is based on the emacs21_2.zip from the 8.0 freeware cd. There are a
>> couple of changes to let emacs make a computer slow. It looks like that
>> code was never built or tested on VAXes. Also, this VAX is a simh and I
>> use the console, OPA0:, set to a reasonable baud rate. I can't get it to
>> work when logged in via telnet to port 60123, which is a simh DZ device,
>> aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
>> have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
>> overrun" when I type very fast, aka do a cut and paste. So, it's not yet
>> production quality, but for hobbyists ...
>
> If it overruns it's not ready for hobbyists either. Very little is worse
> than an editor that doesn't work or screws up your code.

Maybe I didn't make it clear, to me this is a simh problem, not an Emacs
problem. The overrun shows in DCL. I didn't try to debug the hang in Emacs.

> Is the above via X-server? Emacs is supposed to have at least two ways it
> can run, one in a console and one with X. I'm susprised it doesn't work
> over telnet. The MicroEmacs I found works over telnet here.
>

As you may have noticed, I didn't configure X. To me it makes no sense,
as I don't have TCP/IP (or UCX) installed. On a simhVAX, accessing an
X-server needs at least one network protocol. Again, I expect Emacs to
work with telnet, but I can't prove it, I don't have access to any other
VAX. Any VAX on the net to which I can copy the Emacs binaries or
re-build it from scratch would be OK. Anyway, if you want to try the
binaries, let me know to which public directory I should copy them.

[John E. Malmberg]

On 1/15/2016 5:00 AM, hb wrote:
> On 01/15/2016 10:31 AM, li...@openmailbox.org wrote:
>
>>> This is based on the emacs21_2.zip from the 8.0 freeware cd. There are a
>>> couple of changes to let emacs make a computer slow. It looks like that
>>> code was never built or tested on VAXes. Also, this VAX is a simh and I
>>> use the console, OPA0:, set to a reasonable baud rate. I can't get it to
>>> work when logged in via telnet to port 60123, which is a simh DZ device,
>>> aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
>>> have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
>>> overrun" when I type very fast, aka do a cut and paste. So, it's not yet
>>> production quality, but for hobbyists ...
>>
>> If it overruns it's not ready for hobbyists either. Very little is worse
>> than an editor that doesn't work or screws up your code.
>
> Maybe I didn't make it clear, to me this is a simh problem, not an Emacs
> problem. The overrun shows in DCL. I didn't try to debug the hang in Emacs.

It is entirely possible that the SYSTEM-W-DATAOVERUN can be reproduced
with a physical VAX of the same speed or slower rating as the SimH system.

The DZ device family does not have buffering and will not work reliably
for high speed input.

Using them for high-speed output is self-limiting. They will chew up so
much CPU that it will throttle the output, and anything else you are
attempting to do.

It is also possible to bugcheck a physical VAX by sending data to
multiple DZ interfaces too fast at the same time. I have seen it happen
multiple times. The only fix is to change to using a better serial
controller.

A DZ interface is basically good enough for human typing speed. If you
are trying anything faster over it, you are rolling the dice.

Which is why trying to use the serial console of a VAX for anything
other than system maintenance very bad idea, since that is almost always
a DZ port.

Regards,
-John
wb8...@qsl.network

[Rich Alderson]

hb <end...@inter.net> writes:

> Again, I expect Emacs to work with telnet, but I can't prove it, I don't have
> access to any other VAX. Any VAX on the net to which I can copy the Emacs
> binaries or re-build it from scratch would be OK. Anyway, if you want to try
> the binaries, let me know to which public directory I should copy them.

HB,

If you apply for an account on the VAX-11/780-5 at Living Computer Museum and
note that you want to install Emacs in the optional "Describe your interest"
box, I'll mark your account request High Priority if you do that. I would love
to see Emacs on this system myself, but I have no time to track down a freeware
CD to install it; I have other system projects with higher priority.

This VAX is running 7.3 with TCP/IP Services. It is in a museum setting, so
uptime is not guaranteed, but it generally runs 24x7.

http://www.livingcomputermuseum.org/Online-Systems/Request-a-Login.aspx

Once the installation is done, we can announce its availability here.

Oh, (edited) work .sig:

Rich Alderson
Vintage Computing Sr. System Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

http://www.LivingComputerMuseum.org/

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[hb]

On 01/15/2016 07:46 PM, Rich Alderson wrote:

> If you apply for an account on the VAX-11/780-5 at Living Computer Museum and
> note that you want to install Emacs in the optional "Describe your interest"
> box, I'll mark your account request High Priority if you do that. I would love
> to see Emacs on this system myself, but I have no time to track down a freeware
> CD to install it; I have other system projects with higher priority.

Thanks, but there are too many stared fields in the request form and no
https.

Installing the binary kit is as easy as 1-2-3:

Get the emacs21_2_vax_bin.zip archive from
https://www.sendspace.com/file/icqsn3 onto your VAX.

Uncompress the archive. It contains a VMS backup save set, which was
archived with the -V option.
$ UNZIP EMACS21_2_VAX_BIN.ZIP

Restore the backup save set
$ BACKUP EMACS21_2_VAX_BIN.BCK/SAV [.LOCAL...]

To run/test emacs, as already mentioned,
$ @[.LOCAL.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS
$ DEFINE TERM VT100
$ EMACS
or
$ RUNEMACS

You need permanent disk space for emacs, a minumum of 80MB - estimated
from the save set size, and temporary disk space for the zip archive,
25MB, and the save set, 76MB.

[li...@openmailbox.org]

On Sat, 16 Jan 2016 12:55:47 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> Installing the binary kit is as easy as 1-2-3:
>
> Get the emacs21_2_vax_bin.zip archive from
> https://www.sendspace.com/file/icqsn3 onto your VAX.
>
> Uncompress the archive. It contains a VMS backup save set, which was
> archived with the -V option.
> $ UNZIP EMACS21_2_VAX_BIN.ZIP
>
> Restore the backup save set
> $ BACKUP EMACS21_2_VAX_BIN.BCK/SAV [.LOCAL...]
>
> To run/test emacs, as already mentioned,
> $ @[.LOCAL.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS
> $ DEFINE TERM VT100
> $ EMACS
> or
> $ RUNEMACS
>
> You need permanent disk space for emacs, a minumum of 80MB - estimated
> from the save set size, and temporary disk space for the zip archive,
> 25MB, and the save set, 76MB.

Thanks, this sounds great! I didn't realize there was a binary.

[li...@openmailbox.org]

On Fri, 15 Jan 2016 08:03:56 -0600
"John E. Malmberg via Info-vax" <info...@rbnsn.com> wrote:

> A DZ interface is basically good enough for human typing speed. If you
> are trying anything faster over it, you are rolling the dice.
>
> Which is why trying to use the serial console of a VAX for anything
> other than system maintenance very bad idea, since that is almost always
> a DZ port.

Thanks, this is good info.

[Johnny Billquist]

On 2016-01-15 15:03, John E. Malmberg wrote:
> On 1/15/2016 5:00 AM, hb wrote:
>> On 01/15/2016 10:31 AM, li...@openmailbox.org wrote:
>>
>>>> This is based on the emacs21_2.zip from the 8.0 freeware cd. There
>>>> are a
>>>> couple of changes to let emacs make a computer slow. It looks like that
>>>> code was never built or tested on VAXes. Also, this VAX is a simh and I
>>>> use the console, OPA0:, set to a reasonable baud rate. I can't get
>>>> it to
>>>> work when logged in via telnet to port 60123, which is a simh DZ
>>>> device,
>>>> aka TTA0:. The process hangs in LEF with two busy channels to TTA0:. I
>>>> have/had other problems with that device: "-SYSTEM-W-DATAOVERUN, data
>>>> overrun" when I type very fast, aka do a cut and paste. So, it's not
>>>> yet
>>>> production quality, but for hobbyists ...
>>>
>>> If it overruns it's not ready for hobbyists either. Very little is worse
>>> than an editor that doesn't work or screws up your code.
>>
>> Maybe I didn't make it clear, to me this is a simh problem, not an Emacs
>> problem. The overrun shows in DCL. I didn't try to debug the hang in
>> Emacs.
>
> It is entirely possible that the SYSTEM-W-DATAOVERUN can be reproduced
> with a physical VAX of the same speed or slower rating as the SimH system.

Yes. Throwing lots of data at a (simulated) serial port will cause loss
of data. The OS normally will not be able to empty the buffers fast
enough. Not at all related to Emacs, or whatever. It's a problem between
the hardware and device driver+OS.

This is why flow control exists. However, on simulated systems, flow
control works even worse. DEC normally use software flow control (ie.
XON/XOFF), and that is not managed by emulated serial lines, meaning you
essentially have no flow control at all. If the OS buffers start filling
up, and you don't respect the XOFF the OS sends, data will be lost. Same
as it always was.

It's also not an easy problem to solve in the emulator.

> The DZ device family does not have buffering and will not work reliably
> for high speed input.

Right. DZ is a horrible device.

> Using them for high-speed output is self-limiting. They will chew up so
> much CPU that it will throttle the output, and anything else you are
> attempting to do.

Yes.

> It is also possible to bugcheck a physical VAX by sending data to
> multiple DZ interfaces too fast at the same time. I have seen it happen
> multiple times. The only fix is to change to using a better serial
> controller.

That, on the other had, would be a bug in the code. There is no reason
the OS should bugcheck because a serial line controller is going wild.

> A DZ interface is basically good enough for human typing speed. If you
> are trying anything faster over it, you are rolling the dice.

Well, it can take a little more than that, but not much more, and it of
course also depends on which CPU we're talking about.

> Which is why trying to use the serial console of a VAX for anything
> other than system maintenance very bad idea, since that is almost always
> a DZ port.

Actually never. DZ ports cannot be used as the console port. Old VAXen
with Unibuses have the serial port specially connected as its own device
hooked into the CPU. Does not pass through the Unibus at all.
The same is true for old, small Qbus machines. Console is special.
And of course, anything newer than Unibus/Qbus do not have a DZ
controller to start with.

But the actual serial console interface is pretty much just as stupid as
a DZ controller anyway, but at least it is only one serial line, and not
8, which is what a DZ11 have...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[hb]

On 01/17/2016 07:08 PM, li...@openmailbox.org wrote:

> Thanks, this sounds great! I didn't realize there was a binary.

Which is just the result of what I generated on a VAX and saved in a
backup save set of the emacs installation directory. Restoring that
should do. But what do I know about emacs.

[li...@openmailbox.org]

On Sun, 17 Jan 2016 22:05:07 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

In that case thank you very much! I will report back in the next couple
days as soon as I can I grab a copy and try it out.

[li...@openmailbox.org]

On Sat, 16 Jan 2016 12:55:47 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> Installing the binary kit is as easy as 1-2-3:
>
> Get the emacs21_2_vax_bin.zip archive from
> https://www.sendspace.com/file/icqsn3 onto your VAX.
>
> Uncompress the archive. It contains a VMS backup save set, which was
> archived with the -V option.
> $ UNZIP EMACS21_2_VAX_BIN.ZIP
>
> Restore the backup save set
> $ BACKUP EMACS21_2_VAX_BIN.BCK/SAV [.LOCAL...]
>
> To run/test emacs, as already mentioned,
> $ @[.LOCAL.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS
> $ DEFINE TERM VT100
> $ EMACS
> or
> $ RUNEMACS

Thanks a lot. Got it. Hopefully will try tomorrow if work lets up on me.

[hb]

Whoever is interested, for other reasons I upgraded simh from "VAX
simulator V3.8-1" to "MicroVAX 3900 simulator V4.0-0 Beta git commit id:
db3531e5" and "the DZ problems" no longer show.

[li...@openmailbox.org]

On Sat, 16 Jan 2016 12:55:47 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> On 01/15/2016 07:46 PM, Rich Alderson wrote:
>
> > If you apply for an account on the VAX-11/780-5 at Living Computer
> > Museum and note that you want to install Emacs in the optional
> > "Describe your interest" box, I'll mark your account request High
> > Priority if you do that. I would love to see Emacs on this system
> > myself, but I have no time to track down a freeware CD to install it; I
> > have other system projects with higher priority.
>
> Thanks, but there are too many stared fields in the request form and no
> https.
>
> Installing the binary kit is as easy as 1-2-3:
>
> Get the emacs21_2_vax_bin.zip archive from
> https://www.sendspace.com/file/icqsn3 onto your VAX.
>
> Uncompress the archive. It contains a VMS backup save set, which was
> archived with the -V option.
> $ UNZIP EMACS21_2_VAX_BIN.ZIP

This took like a half hour. Unbelievable.

> Restore the backup save set
> $ BACKUP EMACS21_2_VAX_BIN.BCK/SAV [.LOCAL...]

This took like 15 minutes. Wow. This is surprising.

I may have screwed up here by using [...] as the target (see my problem
further on). Although it did create local.dir so maybe not. I was going to
try to delete the local directory and try your command as you specified. I
didn't understand whether you were giving an example or the actual command.
But anyway I can't delete the gigantic directory tree it created. Is it
really a full-time job to delete a directory tree in VMS? So I figure I'll
send this email and go from there.

> To run/test emacs, as already mentioned,
> $ @[.LOCAL.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS

@[.STARTUP]GNU_STARTUP EMACS-21.2 NOLOGICALS

%GNU_STARTUP-I-SETTING_UP, setting up Emacs version 21.2

> $ DEFINE TERM VT100
> $ EMACS
> or
> $ RUNEMACS

%DCL-W-ACTIMAGE, error activating image BLD_ROOT:[LOCAL.BIN]EMACS-21_2
-CLI-E-IMGNAME, image file DUA0:[REDACTED.][LOCAL.BIN]EMACS-21_2.EXE;
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

Your name was REDACTED above. But I got the sense something about your
directory structure was compiled in. And although I followed your
instructions (I think) I am totally confused by the multiple directories
this creates (although I should have expected that with gnu-anything) and
how I would deal with this when trying to set it up properly on my system.

I guess one thing at a time. What should I do now? Thanks a lot for helping
with this. Sorry it took me awhile to get to this. Usually whenever I have
something interesting to try on my home systems I get to work overtime that
day. I will never know how they know...

[li...@openmailbox.org]

On Wed, 20 Jan 2016 19:42:13 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

I'm hoping they eventually get the idle working for OpenBSD hosts. I have
one box dedicated to SIMH but it runs 85% whenever SIMH is running.

Did you notice any important upgrades or regressions? I've been pretty
happy with 3.9, not that I stress it very hard. But so far no bugs. Nice
piece of software. I wish everything was written so portably and well.

[hb]

On 01/21/2016 04:58 PM, li...@openmailbox.org wrote:

> %DCL-W-ACTIMAGE, error activating image BLD_ROOT:[LOCAL.BIN]EMACS-21_2
> -CLI-E-IMGNAME, image file DUA0:[REDACTED.][LOCAL.BIN]EMACS-21_2.EXE;
> -RMS-E-DNF, directory not found
> -SYSTEM-W-NOSUCHFILE, no such file

I apologize, my fault. I should have checked GNU_STARTUP.COM for
BLD_ROOT and what it is set to.

> I guess one thing at a time. What should I do now? Thanks a lot for helping
> with this. Sorry it took me awhile to get to this. Usually whenever I have
> something interesting to try on my home systems I get to work overtime that
> day. I will never know how they know...
>

(Re)-Define BLD_ROOT, the rooted logical. Assumed your current directory
when restoring the saveset was DUA1:[USER] then

$ define BLD_ROOT /trans=(conc,term) DUA1:[USER.]

It seems, when BLD_ROOT is defined before GNU_STARTUP runs, the command
procedure will not change it.

Or change GNU_STARTUP.COM. It seems in line 278 BLD_ROOT is defined.

[li...@openmailbox.org]

On Thu, 21 Jan 2016 17:36:10 +0100

hb via Info-vax <info...@rbnsn.com> wrote:

> On 01/21/2016 04:58 PM, li...@openmailbox.org wrote:
>
> > %DCL-W-ACTIMAGE, error activating image BLD_ROOT:[LOCAL.BIN]EMACS-21_2
> > -CLI-E-IMGNAME, image file DUA0:[REDACTED.][LOCAL.BIN]EMACS-21_2.EXE;
> > -RMS-E-DNF, directory not found
> > -SYSTEM-W-NOSUCHFILE, no such file
>
> I apologize, my fault. I should have checked GNU_STARTUP.COM for
> BLD_ROOT and what it is set to.

Thanks, no apology necessary. I appreciate the help.

> > I guess one thing at a time. What should I do now? Thanks a lot for
> > helping with this. Sorry it took me awhile to get to this. Usually
> > whenever I have something interesting to try on my home systems I get
> > to work overtime that day. I will never know how they know...
> >
>
> (Re)-Define BLD_ROOT, the rooted logical. Assumed your current directory
> when restoring the saveset was DUA1:[USER] then
>
> $ define BLD_ROOT /trans=(conc,term) DUA1:[USER.]
>
> It seems, when BLD_ROOT is defined before GNU_STARTUP runs, the command
> procedure will not change it.
>
> Or change GNU_STARTUP.COM. It seems in line 278 BLD_ROOT is defined.

Thanks, I'll try this asap but right now I have a half-deleted directory
tree since I was trying to delete everything and start again.

How do I delete everything under local? the set file/prot worked but the
delete [.local]*.*;* comes back with a lot of messages about various
directories that aren't empty.

[abrsvc]

> How do I delete everything under local? the set file/prot worked but the
> delete [.local]*.*;* comes back with a lot of messages about various
> directories that aren't empty.
>
> --

I you are intending o delete the entire tree, execute the following command multiple times ignoring the "not empty messages".

Delete [.local...]*.*;*
This part=====^^^ will tell DCL to walk down the directory tree and delete on the way. As the lowest branch becomes empty, the directory files (.DIR) will be deleted until the command will yield no files to be deleted.

Dan

[Craig A. Berry]

or for the impatient:

$ set process/priv=(bypass,sysprv)
$ mcr dfu delete/tree/directory/nolog local.DIR

v8.4 also has DELETE/TREE, but it's much slower than DFU.

[li...@openmailbox.org]

Thanks, that worked. Not too terrible! :-)

I'll get back to the main issue over the weekend. Thanks guys.

[Kerry Main]

As I found out the hard way, be careful with delete/tree if you are
working on system with GNV and other UNIX programs and there are
hardlinks set on the non-system volume which link back to system
directories.

$ delete/tree user2:[gnv...]*.* seemed like simple way to clean out an
old version of GNV unless you do a
$ dir user2:[gnv...]*.* and then notice all the system directories
below it!

Otherwise, make sure you have good backups as system files will also
get deleted.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[hb]

On 01/21/2016 07:14 PM, Kerry Main wrote:
> As I found out the hard way, be careful with delete/tree if you are
> working on system with GNV and other UNIX programs and there are
> hardlinks set on the non-system volume which link back to system
> directories.

Hardlinks, going from the non-system volume to system directories on
which volume? Or softlinks?

On the other hand, hardlinks (and softlinks) are independent of "GNV and
other UNIX programs". They are ODS-5 features. Any VMS user can use them.

[David Froble]

li...@openmailbox.org wrote:

> Is it
> really a full-time job to delete a directory tree in VMS?

Not really.

$ DELETE [<top of tree>...]*.*;*

then type ^ and <return>

Repeat until no informational messages ...

Now, to delete a directory file, you either need privs, or, set the file
protection mask to include "D".

[John Reagan]

On Thursday, January 21, 2016 at 2:14:00 PM UTC-5, hb wrote:
> On 01/21/2016 07:14 PM, Kerry Main wrote:
> > As I found out the hard way, be careful with delete/tree if you are
> > working on system with GNV and other UNIX programs and there are
> > hardlinks set on the non-system volume which link back to system
> > directories.
>
> Hardlinks, going from the non-system volume to system directories on
> which volume? Or softlinks?
>

Yes, it is/was a poor attempt by the GNV startup to allow installations on alternate disks, but to still populate the root emulation. I was looking at the GNV$STARTUP today (which calls PSX$UP_STARTUP.COM). All that stuff has been commented out in the current V3.0 GNV kits.

[Stephen Hoffman]

On 2016-01-21 21:09:49 +0000, John Reagan said:

> Yes, it is/was a poor attempt by the GNV startup to allow installations
> on alternate disks, but to still populate the root emulation. I was
> looking at the GNV$STARTUP today (which calls PSX$UP_STARTUP.COM). All
> that stuff has been commented out in the current V3.0 GNV kits.

The GNV kit is a crucible of informative mistakes, to paraphrase a sig file...

http://labs.hoffmanlabs.com/node/1481

If there are any changes made to the kit, please make always the kit
always install always in the same always spot always. Stop trying to
save room on the system disk — that hasn't been an issue for any sanely
managed site in a decade or more. The added software complexity costs
everybody else more than the few folks that are overdue for a disk
upgrade might save, too.


--
Pure Personal Opinion | HoffmanLabs LLC

[Johnny Billquist]

Well, hardlinks exists even in ODS-1...

Johnny

--

[John Reagan]

On Thursday, January 21, 2016 at 4:27:39 PM UTC-5, Stephen Hoffman wrote:
> On 2016-01-21 21:09:49 +0000, John Reagan said:
>
> > Yes, it is/was a poor attempt by the GNV startup to allow installations
> > on alternate disks, but to still populate the root emulation. I was
> > looking at the GNV$STARTUP today (which calls PSX$UP_STARTUP.COM). All
> > that stuff has been commented out in the current V3.0 GNV kits.
>
> The GNV kit is a crucible of informative mistakes, to paraphrase a sig file...
>
> http://labs.hoffmanlabs.com/node/1481
>
> If there are any changes made to the kit, please make always the kit
> always install always in the same always spot always. Stop trying to

> save room on the system disk -- that hasn't been an issue for any sanely

> managed site in a decade or more. The added software complexity costs
> everybody else more than the few folks that are overdue for a disk
> upgrade might save, too.
>

I'd love to remove PCSI's /DESTINATION qualifier. Plus, the GNV install script also gives you the ability to move the POSIX root as well (the default is on the system disk). Kerry (and others who bumped into this) went out of their way to use /DESTINATION or asked to move the POSIX root. I also see no benefit.

[hb]

On 01/21/2016 10:32 PM, Johnny Billquist wrote:
> Well, hardlinks exists even in ODS-1...

Alias, hardlink? There are only aliases in ODS-2.

[Stephen Hoffman]

On 2016-01-21 22:18:45 +0000, John Reagan said:

> I'd love to remove PCSI's /DESTINATION qualifier. Plus, the GNV
> install script also gives you the ability to move the POSIX root as
> well (the default is on the system disk). Kerry (and others who bumped
> into this) went out of their way to use /DESTINATION or asked to move
> the POSIX root. I also see no benefit.

It's in the GNV documentation. Start there. Yank that startup schtick
from the kit, too. Yank anything in the kit that allows or supports
relocating the kit.

Deprecate the PCSI /DESTINATION qualifier for general use. Maybe make
PCSI check that the target disk looks like an appropriate system disk
before allowing /DESTINATION to be used. (BTW, there used to be a
simple check for system architecture and likely system boot support in
the bootblock-related code, but that undocumented check looks to have
been broken in some patch. That didn't look at the version, though.)

As for PCSI, that tool is ripe for a replacement. It was good for its
time, and the design has served well for over twenty years. But
expectations and environments have changed. Using an actual
transactional database underneath and not the home-grown RMS database
and RMS turd-file crap (this alone likely would have made the HP to VSI
product vendor migration vastly easier — rather than having everybody
recode their kits or use that rekitting hack) and thus not needing
per-kit tracking to manage what's installed, having the ability to
cryptographically verify the integrity of the kits to be installed and
of the files in the kits that have already been installed, deeper
rollbacks, remote TLS-protected access to VSI patch servers, integrate
the installer with the licensing with the new VSI license key servers,
integration with installation and configuration profiles, integration
with a local software update server, etc.

Adding support for application packages — avoiding scattering files all
over the system disk — is probably a step or three past all that, too.

But y'all probably don't have enough staff nor enough schedule time for
all what you want to do now and all of what you have to do now.
Certainly not enough folks for overhauling or replacing the related
installation and patch management, and for hauling the
closely-associated software licensing environment forward, which
unfortunately VMS continues to accrue technical debt and to add
complexity due to compatibility.

So... Don't provide folks with the metatarsal-seeking firearm lurking
in the GNV documentation.

[John E. Malmberg]

On 1/21/2016 8:04 PM, Stephen Hoffman wrote:
> On 2016-01-21 22:18:45 +0000, John Reagan said:
>
>> I'd love to remove PCSI's /DESTINATION qualifier. Plus, the GNV
>> install script also gives you the ability to move the POSIX root as
>> well (the default is on the system disk). Kerry (and others who
>> bumped into this) went out of their way to use /DESTINATION or asked
>> to move the POSIX root. I also see no benefit.
>
> It's in the GNV documentation. Start there. Yank that startup schtick
> from the kit, too. Yank anything in the kit that allows or supports
> relocating the kit.
>
> Deprecate the PCSI /DESTINATION qualifier for general use.

It is not the PCSI /Destination that is the issue. The existing GNV 2.x
through 3.0.1 kits did not really use PCSI tools for the install. The
kit builder made up a hack to unpack some type of archive into the
resulting directory structure and just used PCSI to deliver that archive.

At first the gnv$startup.com did not know how to find where the
/destination caused the kit to be installed. Later kit versions were
updated so that gnv$startup.com could find the correct volume.

Then for GNV 2.1.x, a PSX$ROOT was hacked on to this which added to the
mess. Especially if you did not add gnv$startup.com to the system startup.

Because the GNV 2.x and GNV 3.0.1 kits use their own archive
installation method, they also delete everything in the [vms$common.gnv]
directory on install.

See: https://sourceforge.net/p/gnv/wiki/InstallingGNVPackages/


PCSI has several issues.

1. It does not fully understand ODS-5, even the versions that claim to.
It kind of works if you are lucky. Assuming that it does not support
ODS-5 at all makes installations more successful.

2. It does not really understand that you can have multiple disks to
install on. It assumes that it is installing on the boot disk and that
the /destination disk is the boot disk. So it does not know to put
stuff in SYS$HELP: and SYS$STARTUP that it should. Or VMS does not know
enough to have SYS$HELP: and SYS$STARTUP be search lists for all the
volumes that PCSI has installed things on.

3. PCSI kit builder knows that all files with the same name have the
same content regardless of what directory they are found in. So if you
have a [.vms]readme. and a [.linux]readme. file, PCSI kit builder will
grab one of them at install time and use it for both copies when doing
the install.

Regards,
-John
wb8...@qsl.network

[Craig A. Berry]

On 1/21/16 9:22 PM, John E. Malmberg wrote:

>
> PCSI has several issues.
>
> 1. It does not fully understand ODS-5, even the versions that claim to.
> It kind of works if you are lucky. Assuming that it does not support
> ODS-5 at all makes installations more successful.

ODS-5 comprises multiple features. I'm not sure which features you've
had trouble with, but I don't recall having problems with case
preservation or filenames with extended characters in them, or multiple
dots. Assuming you're using one of the later ECOs of PCSI on 8.3 or 8.4.

> 2. It does not really understand that you can have multiple disks to
> install on. It assumes that it is installing on the boot disk and that
> the /destination disk is the boot disk. So it does not know to put
> stuff in SYS$HELP: and SYS$STARTUP that it should. Or VMS does not know
> enough to have SYS$HELP: and SYS$STARTUP be search lists for all the
> volumes that PCSI has installed things on.

I don't bother with more than one disk very often, so I don't know what
trouble that causes.

> 3. PCSI kit builder knows that all files with the same name have the
> same content regardless of what directory they are found in. So if you
> have a [.vms]readme. and a [.linux]readme. file, PCSI kit builder will
> grab one of them at install time and use it for both copies when doing
> the install.

I think you are right that it did have this bug at one time. So did MMS,
IIRC. But I've not had this problem recently. A recent Perl installation
has five instances of "File.pm" and three instances of "file.pm" in
various directories, and I haven't seen PCSI get confused about which is
which.

[Johnny Billquist]

What do you mean by that?

Hardlinks are hardlinks. They are not so difficult to understand. And
they exist under ODS-1. In RSX you even have the ability to create them
with PIP. Supported since the 70s.

The same FID, referred to by another name, possibly in another directory.

[hb]

On 01/22/2016 10:48 AM, Johnny Billquist wrote:
> On 2016-01-21 23:43, hb wrote:
>> On 01/21/2016 10:32 PM, Johnny Billquist wrote:
>>> Well, hardlinks exists even in ODS-1...
>>
>> Alias, hardlink? There are only aliases in ODS-2.
>
> What do you mean by that?
>
> Hardlinks are hardlinks. They are not so difficult to understand. And
> they exist under ODS-1. In RSX you even have the ability to create them
> with PIP. Supported since the 70s.
>
> The same FID, referred to by another name, possibly in another directory.

With a link count or not. With a link count it is a hardlink without it
is an alias.

[Bob Koehler]

In article <n7ralh$1mn8$1...@gioia.aioe.org>, hb <end...@inter.net> writes:
> On 01/21/2016 07:14 PM, Kerry Main wrote:
>> As I found out the hard way, be careful with delete/tree if you are
>> working on system with GNV and other UNIX programs and there are
>> hardlinks set on the non-system volume which link back to system
>> directories.
>
> Hardlinks, going from the non-system volume to system directories on
> which volume? Or softlinks?
>
> On the other hand, hardlinks (and softlinks) are independent of "GNV and
> other UNIX programs". They are ODS-5 features. Any VMS user can use them.

I haven't installed GNV in a long time. But I do recall a "system
manager" who didn't use the provided DCL script to delelete an old
system root on the shared system disk. Just started something
like delete [sys10...]*.*;*

You should see what the host did after sys$system:delete.exe was
marked for delete.

[Bob Koehler]

In article <n7stt1$hjs$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
> On 2016-01-21 23:43, hb wrote:
>> On 01/21/2016 10:32 PM, Johnny Billquist wrote:
>>> Well, hardlinks exists even in ODS-1...
>>
>> Alias, hardlink? There are only aliases in ODS-2.
>
> What do you mean by that?
>
> Hardlinks are hardlinks. They are not so difficult to understand. And
> they exist under ODS-1. In RSX you even have the ability to create them
> with PIP. Supported since the 70s.
>
> The same FID, referred to by another name, possibly in another directory.

For at least ODS-2 and -5, the second name entered by PIP,
or by "set file/enter", is an alias, not a hardlink. VMS aliases do
not have the same behaviour as hardlinks. VMS hardlinks behave
link UNIX hardlinks, aliases do not.

[Stephen Hoffman]

On 2016-01-22 10:54:13 +0000, hb said:

> With a link count or not. With a link count it is a hardlink without it
> is an alias.

Maybe that gets better documented? The official documentation in the
HPE V8.4-to-V8.2-inclusive System Manager's Manual /10.12 Understanding
Hard Links/ appears correct but also a little conflated, and that
material is old enough that it doesn't even mention softlinks.
Whether there's other and newer documentation at HPE or VSI? VSI
might better document the distinction here, though the VSI folks are
~six months late in posting any OpenVMS V8.4-1H1 documentation AFAICT,
and there seems a decent chance that the VSI V8.4-2 release will arrive
first.

[Stephen Hoffman]

On 2016-01-22 15:00:53 +0000, Bob Koehler said:

> For at least ODS-2 and -5, the second name entered by ... "set

> file/enter", is an alias, not a hardlink.

With OpenVMS V7.3 and later on OpenVMS Alpha and on OpenVMS I64, SET
FILE /ENTER creates either an alias or a hard link, depending on the
setting of the target ODS-5 volume.

ODS-2 gets only aliases.

The DCL command for both aliases and hard links is the same.

What happens depends on the setting of the target ODS-5 volume.

This is another example of a command or a routine that can do different
things based on some compatibility setting(s) located elsewhere.

[Craig A. Berry]

Yes, and even more to the point considering how the discussion got here
is whether PCSI REMOVE, DELETE/TREE, and/or DFU DELETE/TREE have
explicit designs around whether to follow links and what kind of links,
or whether what you get is just the random intersection of the evolving
behaviors of the lower layers.

I would expect a tool designed to delete a directory tree to remove
links but not follow them, at least by default, and in the case of PCSI
I would expect it to only remove whatever it installed, whether that's
both the link and the target or only the link.

[Stephen Hoffman]

On 2016-01-22 19:11:20 +0000, Craig A. Berry said:

> On 1/22/16 9:28 AM, Stephen Hoffman wrote:
>>
>> This is another example of a command or a routine that can do different
>> things based on some compatibility setting(s) located elsewhere.
>
> Yes, and even more to the point considering how the discussion got here
> is whether PCSI REMOVE, DELETE/TREE, and/or DFU DELETE/TREE have
> explicit designs around whether to follow links and what kind of links,
> or whether what you get is just the random intersection of the evolving
> behaviors of the lower layers.

Ayup. Try defining a few DECC$ logical names, and watch other random
hunks of code go deep into the weeds with odd errors.

Except through utter isolation of the applications and careful
management of the upgrades, the current programming environment is
neither stable, reliable, predictable, nor easily understandable by
anyone not steeped in the OpenVMS origin and history, and the API
complexity is only getting worse.

When hauling around software among various systems, anything from a
system parameter change to a logical name to some random disk setting
can derail the application code.

That's without discussing the subtle and pernicious effects of actual
system configuration errors — I'm increasingly checking process quotas
and system parameters and some of the logical name knobs at application
startup.

There's no clear list of this stuff anymore (if there ever was?), and
the the mechanisms and controls and knobs used to ensure that old code
still works — at the expense of new code — are all over the place.

Application porting among OpenVMS systems — a subset of app stacking —
is just one system-wide DECC$ logical name away from run-time chaos.

Usual solution for compatibility? Add knobs and APIs and run-time
checks, and throw it all over the wall and let somebody else figure it
out when — when, not if — it breaks.

Design abdication.

> I would expect a tool designed to delete a directory tree to remove
> links but not follow them, at least by default, and in the case of PCSI
> I would expect it to only remove whatever it installed, whether that's
> both the link and the target or only the link.

Ayup. But then the GNV kit added features such as source savesets
that are optionally unpack manually — which means those files are
understandably and completely and arguably entirely correctly out of
scope during GNV product removal, but that's very likely not what the
user intends or expects here, either. PCSI doesn't have a particular
way to add files or dependencies after installation, and OpenVMS
doesn't have a way to package applications for easy removal.

I really do like what OpenVMS was, but it's not at all what OpenVMS is
now, and nobody (outside of VSI, maybe) has any idea of where OpenVMS
is going.

[Johnny Billquist]

That was a rather weird distinction that I've never heard before.

If it walks like a duck, and talks like a duck, it probably is a duck.
They behave exactly the same, with the exception that you do not have a
reference count. How does that make them different?

Well, when you delete the entry, different things happen. In both cases,
the file disappears from where you deleted it, but without a reference
count, you'll either end up like nothing happened, or have dangling
directory entries pointing to something that does not exist, depending
on how you did the delete.

And dangling directory entries can be created in other ways as well. So,
why would you consider this reference count to be important, except as a
convenience?

Johnny

[Johnny Billquist]

The point with hard links is that you cannot tell if you are following a
link or not, since all directory entries are hard links, at the bottom
line. All hard links are equal.

An interesting distinction between aliases and hardlinks here, by the
way. I have never seen that one before. Curious question then, how does
VMS deal with if you create a hard link, but remove it as an alias? Or
vice versa? Can you even tell if an entry is a hard link or an alias?
What happens if you create both hard links and aliases to a file?

The only place where the distinction is made is in the handling of the
reference count. You can you tell, when you remove something if it is an
alias or a hard link?

Johnny

[David Froble]

Stephen Hoffman wrote:
> On 2016-01-22 19:11:20 +0000, Craig A. Berry said:
>
>> On 1/22/16 9:28 AM, Stephen Hoffman wrote:
>>>
>>> This is another example of a command or a routine that can do
>>> different things based on some compatibility setting(s) located
>>> elsewhere.
>>
>> Yes, and even more to the point considering how the discussion got
>> here is whether PCSI REMOVE, DELETE/TREE, and/or DFU DELETE/TREE have
>> explicit designs around whether to follow links and what kind of
>> links, or whether what you get is just the random intersection of the
>> evolving behaviors of the lower layers.
>
> Ayup. Try defining a few DECC$ logical names, and watch other random
> hunks of code go deep into the weeds with odd errors.
>
> Except through utter isolation of the applications and careful
> management of the upgrades, the current

"C" (fixed it for you)

> programming environment is
> neither stable, reliable, predictable, nor easily understandable by
> anyone not steeped in the OpenVMS origin and history, and the API
> complexity is only getting worse.
>
> When hauling around software among various systems, anything from a
> system parameter change to a logical name to some random disk setting
> can derail the application code.

Rather scary ...

> That's without discussing the subtle and pernicious effects of actual
> system configuration errors — I'm increasingly checking process quotas
> and system parameters and some of the logical name knobs at application
> startup.
>
> There's no clear list of this stuff anymore (if there ever was?), and
> the the mechanisms and controls and knobs used to ensure that old code
> still works — at the expense of new code — are all over the place.
>
> Application porting among OpenVMS systems — a subset of app stacking —
> is just one system-wide DECC$ logical name away from run-time chaos.

The more you point out, the more I agree with your intense dislike of using
logical names to affect V language behavior.

[David Froble]

David Froble wrote:

> The more you point out, the more I agree with your intense dislike of
> using logical names to affect V language behavior.

That should be "C language behavior"

[hb]

On 01/22/2016 08:11 PM, Craig A. Berry wrote:
> I would expect a tool designed to delete a directory tree to remove

> links but not follow them, at least by default, ...

You probably want to specify which kind of links. Symbolic links (can be
easily identified and they) should be removed and not followed.
Hardlinks should be followed and removed, by default.

[hb]

On 01/22/2016 09:21 PM, Johnny Billquist wrote:
> That was a rather weird distinction that I've never heard before.

HP OpenVMS System Manager’s Manual, Volume 1: Essentials

Paragraph 10.12 Understanding Hard Links

A link, or directory entry, is an object in a directory that associates
a file name and a version number with a specific file. All links on a
volume must represent files on the same volume.

With the introduction of hard link support in OpenVMS Alpha Version 7.3,
OpenVMS supports three kinds of links:
Primary links
Aliases
Hard links
...

[Stephen Hoffman]

On 2016-01-22 22:20:28 +0000, David Froble said:

> Stephen Hoffman wrote:
>>
>> Ayup. Try defining a few DECC$ logical names, and watch other random
>> hunks of code go deep into the weeds with odd errors.
>>
>> Except through utter isolation of the applications and careful
>> management of the upgrades, the current
>
> "C" (fixed it for you)

Call me back when you're using 64-bit OpenVMS and (when/if) 64-bit
BASIC and whatever compatibility knobs and hooks get implemented as
part of the updates, and we'll talk.

BASIC has changed little on OpenVMS, which is good news for the
existing code base, and can be bad news when it comes to features that
might be useful or necessary in current and new applications. As
you're quite aware, there are things that BASIC doesn't do very well,
and — if/when some of those additions or updates are made — that may
well put BASIC right into the same morass with the rest of the
environment.

[Stephen Hoffman]

...And some folks grumbled about my earlier suggestions around
application guides; around the sorts of task-targeted documentation
materials that try to keep folks out of the weeds. Particularly those
folks that haven't read section 10.12 / Understanding Hard Links of the
_System Manager's Manual_ and Chapter 12 / Symbolic Links and POSIX
Pathname Support over in the _C Run-Time Library Reference Manual_, and
that may have missed one or two other sections of the documentation.
The Programming Concepts has no index references to links or hard links
or symbolic links. I'd wager that the PCSI manual has zilch on the
topic, too. (But then, who can even find the OpenVMS manuals at either
HPE or VSI?)

[li...@openmailbox.org]

On Sat, 16 Jan 2016 12:55:47 +0100
hb via Info-vax <info...@rbnsn.com> wrote:

> Restore the backup save set
> $ BACKUP EMACS21_2_VAX_BIN.BCK/SAV [.LOCAL...]

This is causing the saveset to expand into [.local.local]

How can get it to not create two local subdirectories? I tried a few things
from your most recent manual but I think the fact the code gets placed two
levels down instead of one made a mess. I've been real busy but I realize I
need to understand VMS directories and filespecs a lot better.

Thanks and sorry for the dumb questions. This is still all smoke and
mirrors for me at this point.

--
Please do not copy me on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8 ACAA 557C 4B36 98E4 4D49