[Info-vax] directories other than SYS* on the system disk

[Stephen Hoffman]

On 2015-01-02 08:04:04 +0000, Bart Zorn said:

> On Thursday, January 1, 2015 7:55:55 PM UTC+1, Phillip Helbig (undress 
> to reply) wrote:
>> Apart from SYS* and of course 000000, there are also various TCPIP$*> 
>> directories on the system disk, as well as DOC$TOOLS.
>> 
>> I would like to have them somewhere else.

So you want to hack this VMS system.  Do you have a specific reason?  
Well, other than those excessively and ridiculously small disks?

You're probably like many working in this business, and want to do what 
many folks want to do, and want to use whatever knob or option or 
alternative configuration might be available.  It's there.  Tweak it.  
See what happens.  Which can be laudable for a hobbyist, and a real 
problem for a supportable and/or production environment.

As a programmer and where it's feasible, the preferred goal here is to 
get rid of these options and the capability to customize the 
installation for most or all end-user folks, and to get rid of these 
install-time options, and to get rid of multiple separate data files 
and the rest of this design.  To remove choices here, and to steer 
(most) folks onto a path.  This because folks that see these options 
and that see these install-time prompts will try to use them, and this 
makes testing and support and upgrades far more complex.   Adding 
questions at install time or adding redirections via logical names 
costs more to configure, more to support, and more to test.  It's a 
source of errors and weird behaviors, and upgrade failures.  Not 
everybody copies all the files back to the system disk for an upgrade, 
which means that servers and applications can have to deal with file 
formats that need post-upgrade format conversions, for instance.

As an end-user, I prefer to avoid creating these cases for myself where 
I can; to avoid straying off the default path, and the path that's been 
most tested by the most folks.   Unfortunately within a cluster with 
multiple system disks, some files have to be offloaded due to the 
ancient and crufty and accreted designs involved; accumulated technical 
debt.   But where I don't need to move files and where I don't need to 
use non-default configurations, I don't.   I've already had TCP/IP 
Services blow up enough times.  Make a mistake with some of the 
reconfigurations here, and you can end up with an open SMTP relay, for 
instance.   I don't need more messes.  So I take the defaults, where I 
can.

Now if I was hacking away or if I was testing security, sure, have at.  
Go change, well, whatever.  See what breaks, and how.

Can't say I've had much use for sharing TCP/IP Services files beyond 
the SMTP configuration data, as the disks have free space, and the the 
only other thing I'd want to share beyond the SMTP data is the hosts 
data, and I already share that data via the DNS servers.


>> The TCPIP$* directories seem to correspond to the the corresponding
>> (duh!) TCPIP$* usernames in SYSUAF.

When forming a cluster, note that the UICs involved are often 
inconsistently assigned.  (Instead of having a fixed UIC assignment for 
each server, the assignment is next-available.  Yes, the ability to 
customize the configurations strikes again...)

>> 
>> Can I just copy the stuff over to another disk, redefine the default
>> device in SYSUAF and be done with it?  Or do I need to restart TCPIP?
>> 
>> What about DOC$TOOLS?  I've never consciously used this.  It appears 
>> to> be static so it could stay there if necessary, but I would like to 
>> move> the TCPIP$* stuff to a non-system disk, because it is not static. 
>>  The> aim, of course, is to make semi-automatic copying of the system 
>> disk> from one node to another (after a big upgrade, for example) work 
>> without> problems and without losing any data.  (Otherwise, everything 
>> seems to> be OK; moving the documented files from SYS$COMMON off the 
>> system disk> takes care of almost everything.)
> 
> I have tried to do that, but I would say, forget it. There is no 
> consistency in TCPIP Services with respect to adherence to logical 
> names and file locations are probably hard coded in many places. There 
> is a logical name TCPIP$COMMON but I have not been able to make 
> sensible use of it.

Hopefully VSI can spend some time and effort and bring a more 
consistent management interface and more consistent tools and verbs to 
TCP/IP Services, and to VMS itself.  The scattered data files[1] and 
the DCL commands and foreign commands and programming interfaces and 
the tools — I just found yet another TCP/IP command tool, this one for 
SMTP — have accreted over the years, and are accordingly inconsistent 
and somewhat scattershot, and there's no central place to deal with 
what should be common management tasks.   Resolving and rationalizing 
the current system and network management and removing this 
complexity[2] will take years and multiple releases to design and 
deploy and migrate, of course.

> 
> I don't know what DOC$TOOLS is.

That's DEC (now TTI) Document.  AFAIK, there's no hobbyist version of that.


###########
[1] I've already mentioned authentication and getting an actual 
transactional database; that's all part of sorting this out.
[2] Tried changing the host name of a VMS box lately?  That should be 
one tool and/or one dialog, and in one spot.  Not what we have now.


-- 
Pure Personal Opinion | HoffmanLabs LLC