[Info-vax] Where to locate software

[Paul Sture]

On 2016-06-10, Paul Richards <paulrichards at iinet.net.au> wrote:
> Dale Dellutri wrote:
>
>> On Wed, 08 Jun 2016 19:18:47, Paul Richards
>> <paulrichards at iinet.net.au> wrote:
>> > I'm running OpenVMS 8.4 on FreeAXP and am a comparative newbie. So,
>> > a noob question: I am planning to install some of the HP Open-source
>> > software and Freeware.
>> > 
>> > For those applications which don't automatically install where
>> > should I locate them such that I can run them from any directory?
>> > 
>> 
>> Here's what I do for my "acquired software".
>> 
>> First I create a hierarchy on the system disk:
>> $ CRE/DIR/LOG SYS$SYSDEVICE:[AS]
>> $ CRE/DIR/LOG SYS$SYSDEVICE:[AS.CKERMIT]
>> $ CRE/DIR/LOG SYS$SYSDEVICE:[AS.TOOLS]
>> $ CRE/DIR/LOG SYS$SYSDEVICE:[AS.LYNX]
>> $ CRE/DIR/LOG SYS$SYSDEVICE:[AS.VIM]
>> 
>> Then in system startup I define a system logical for the top:
>> $ DEFINE /SYSTEM /EXECUTIVE_MODE -
>>         /TRANSLATION_ATTRIBUTES=CONCEALED AS_ROOT SYS$SYSDEVICE:[AS.]
>> And logicals for the rest of the directories
>> $ @SYS_DEFINE_LOGICALS_STARTUP AS
>> 
>> which executes:
>> $!
>> $! DEFINE_LOGICALS.COM - Define logical names for a hierarchy on
>> SYS$SYSDEVICE $!
>> $! P1 = Top level directory name
>> $!
>> $ ON ERROR THEN EXIT
>> $ IF p1 .EQS. ""
>> $ THEN
>> $  WRITE SYS$OUTPUT "No top level directory name given"
>> $  EXIT
>> $ ENDIF
>> $ IF F$TRNLNM("''p1'_ROOT") .EQS. ""
>> $ THEN
>> $  WRITE SYS$OUTPUT "''p1'_ROOT not defined"
>> $  EXIT
>> $ ENDIF
>> $GET_DIRNAME:
>> $ filespec = F$SEARCH("SYS$SYSDEVICE:[''p1']*.DIR")
>> $ dirname = F$PARSE(filespec,,,"NAME","SYNTAX_ONLY")
>> $ IF dirname .EQS. "" THEN EXIT
>> $ trnname = F$TRNLNM("''p1'_''dirname'")
>> $ IF trnname .NES. "" THEN GOTO GET_DIRNAME
>> $ DEFINE /SYSTEM /EXECUTIVE_MODE 'p1'_'dirname' 'p1'_ROOT:['dirname']
>> $ GOTO GET_DIRNAME
>> $!
>> 
>> I've put all of the ckermit files in [as.ckermit], and
>> miscellaneous tools like zip in [as.tools].
>> 
>> Then for all the *.exe files in as_tools, I have this
>> in the system login procedure:
>> ...
>> $!
>> $get_as_tools_exe:
>> $ f = f$search("AS_TOOLS:*.*EXE")
>> $ if f .eqs. "" then goto done_as_tools_exe
>> $ e = f$parse(f,,,"NAME","SYNTAX_ONLY")
>> $ t = f$parse(f,,,"TYPE","SYNTAX_ONLY")
>> $ 'e' :== $as_tools:'e''t'
>> $ goto get_as_tools_exe
>> $!
>> $done_as_tools_exe:
>> ...
>> 
>> and something similar for the specific directories
>> like [as.ckermit]
>> 
>> However, HP has in the past used a different hierarchy for
>> some tools.  For example, LTT gets put in
>>   sys$sysdevice:[vms$common.opt.ltt]
>> I assume that if I installed LTT on some Linux system, it
>> woudl get put in /opt/ltt.
>> 
>> You might consider that as well.
>
> Dale: thank you for that. I've still not decided what I'm going to do
> but, probably, I'll create a 'MISCELLANEOUS' directory on my second
> virtual disk - not the system disk - and keep all my
> freeware/open-source software in subdirectories. Essentially what you
> and others have suggested. I prefer not to mix up 'my' stuff with the
> system directories, at least where I have the option of choosing.

Hi Paul,

I've been watching this thread with interest, and I particularly like
Dale's solution.  I would probably put a copy of the last code snippet
above in its own file so that it is easily executed on demand when new
utilities are added, or the rare occasions when logging in via
<username>/NOCOMMMAND is appropriate (this to skip execution of the
system wide login procedure, for example a runaway process hogging the
system and you wish to login as quickly as possible without the normal
login file overhead, or simply when you've broken something in there).

Dale's approach of putting utilities such as kermit, lynx, "tools"
(which I envisage to be things like zip/unzip, gzip, gunzip etc) on the
system disk is a favourite too, because they are available when only the
system disk mounted, often precisely the time you need them.

What I would refer to as "applications" or "end-user" utilities would
probably, but not necessarily, live on a separate disk; benefits:

a) a clear separation of system and applications for management purposes
b) performance: not only to avoid I/O contention between the system and
   applications but to avoid unnecessary file fragmentation

Wherever you decide to put them, applications should live in a well
defined directory structure of their own.

FWIW, the "naming" bit of my sig is entirely serious.  Well thought out
and easily enforceable naming conventions at the beginning of a project
*will* save much pain later.

-- 
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.