[Info-vax] BASIC compiler in the hobbyist distribution

[Stephen Hoffman]

On 2015-05-16 15:15:39 +0000, John Reagan said:

> I suspect the defaults of "NO" for the "Full Install" was based back in 
> the days of TU58s or TK50s.  Reading the next saveset takes time....  
> Today, it doesn't make much difference with DVDs.

The variant installations date back to the era when everybody had slow 
systems, tiny disks and glacial tapes.

> I doubt anybody uses the BASIC Translator anymore.

Y'all really should work on system configuration and usage survey tools 
— intelligence-gathering — as bad data or no data causes more problems 
than it should.

> One of my plans is to switch the remaining compilers that use VMSINSTAL 
> (BASIC and Pascal) over to using PCSI to be consistent with the other 
> compilers (I don't want to start another discussion on whether PCSI is 
> good/bad/modern/etc.). I'll change the defaults and/or just eliminate 
> some of the questions.

Until y'all either overhaul PCSI or replace it with something more 
modern, PCSI works well enough, and is usually preferable to using 
VMSINSTAL.

FWIW, as for options and alternatives and variant installations and 
questions, the more you can remove all of that dreck and provide one 
installation and one option and one configuration, the better.  The 
"pick your directory" dchtick and the "pick which subset(s) get 
installed" are among the worst to deal with, as those options increase 
the product complexity and the testing effort and the errors for all 
sorts of code elsewhere in the product — both for VSI and for those of 
us with application dependencies — as that detection and that variation 
needs to be customized to figure out where stuff was installed, and 
just what is installed.   How many times did < and > delimiters get 
mishandled somewhere, after all?

If you really think that there's a need to allow the layered products 
and the application-private data somewhere other than the system disk, 
then architect an OpenVMS-wide mechanism that is available across and 
works consistently across all of the products and all of the tools — 
maybe add a third system root in SYS$SYSROOT, for instance — and update 
all the tools to deal with this stuff in a consistent and sane and 
simple fashion.  The existing ad-hoc per-product customization approach 
is crappy for everybody involved.

Corollary: the more you can roll into the base distro, the better.  
Apache, for instance.

ps: addressing the configuration and survey and the accessibility of 
the data and the limitations of PCSI, having a way to find out what's 
installed would be handy.   A PCSI callable API of some ilk.  Both 
OpenVMS Engineering Nashua and OpenVMS Engineering Bengaluru got into 
problems with variations of this mess and things would have gotten more 
gnarly as the use of this continuous-deployment practice accelerated.  
This both by using the same GSMATCH across all versions of the various 
language RTLs, and also by releasing software enhancements via patch 
kits, given that there was no (supported) way to see what enhancements 
and features were available — what UPDATE kits were installed — at 
run-time.  The old workarounds removed the "blade guards" against 
downgrades, but the problems that those prevented still exist.   You're 
probably going to be headed toward continuous deployment sooner or 
later, so we're all going to need to have a way to figure out what 
widgets are present short of running and crashing, or digging around in 
API definitions or similar — when the deployed version number doesn't 
differentiate the system.  Think of what will happen with applications 
that target Windows 10 over time, given Microsoft are planning to be 
doing rolling or continuous deployments, for instance.  The PCSI API 
would obviously be useful for configuration collection and application 
and system crash analytics, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC