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

[Jan-Erik Soderholm]

Stephen Hoffman skrev den 2015-01-02 15:17:
> 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.

But you can get a descent discount if you ask. I did at least, but
that was, hm, gosh, must have been something like 10 years ago...

Jan-Erik.