I M P O R T A N T  - R E A D   T H I S ! ! !



Important: Read this ENTIRELY before using the files in this kit.  You have
to make the changes described here before replacing the live files on your
system with the ones provided.

If you do this, you may have issues with future GNV installs ane removes as
this completely changes the layout of your GNV installation to be different
from HP.

This has previously been submitted to the HP GNV maintainer, however I do not
know if it will ever be put in a GNV kit, or what the future plans are for
GNV.

PROCEED AT YOUR OWN RISK!!!!

In GNV_COM_2_1_PATCH.ZIP are the changes that I needed to make to the
[vms$common.sys$startup]gnv$startup.com and psx$up_startup.com in order
to get GNV 2.1.1 to work on my VMS 8.3 system.

My system disk is ODS-2 and my application disk is ODS-5 and I install all
applications that require ODS-5 on that second disk.

I added the psx$root:[dev] directory because in the new POSIX mode, a device
special file named /dev/null is required.  I did not find one created by the
installation, and that is something I will need to find out about.
I suspect that it tried to create the special file on my ODS-2 system disk and
failed.

I removed the psx$root:[tmp] directory.  UNIX software expects it to be world
writable, and that usually causes security problems.  So the policy of dealing
with that will end up being site specific.  If the directory is missing,
existing applications tend to fall back to SYS$SPECIFIC.  And existing
applications that are expecting the fallback may have security problems if a
global /tmp shows up.  And of course most will fail if a readonly /tmp shows
up.

I had to rename the files back to [vms$commmon.gnv] in order to get rid of the
directory loop, and then set the [gnv.*] directories back as mount points so
that the POSIX root looked like it did before, so that symbolic links will
work.

Mounting "/" anywhere is guaranteed to cause a directory loop, just like
creating a hard link to it will.  According to the O'Reily "Learning Perl"
book, UNIX systems may have protection in them to prevent this type of
configuration.


My development environment requires that I can make the GNV$GNU directory a
search list, so that non-privileged users can extend GNV, and that I can safely
verify the effects of the "make install" step.

I also fixed with a hack the issue where GNV was breaking other applications
globally by defining SYS$POSIX_ROOT and BIN if they were not defined by moving
those logical name definitions into the process table in
GNV$GNU:[LIB]GNV_SETUP.COM.  It now defines GNV$GNU system wide instead.

The hack to inhibit the creation of the conflicting logical names is activated
by a logical name set before running the GNV$STARTUP.COM procedure.  If it is
not set, then GNV sets the same logical names in the system table as before,
just in case that there are now some applications that depend on this
mis-behavior.

I would rather the bad logical name creation be disabled by default and a
release note explaining how to restore the mis-behavior.

Having the mount point stuff require GNV to be installed, greatly increases the
number of sites that will be using GNV, so bugs like the logical name conflicts
are going to be more visible than they were before, so it is likely more sites
will be inconvenienced by the conflicts than there are depending on the
existing behavior.

I had quite a number of applications installed in [vms$common.gnv...] that were
unexpectedly deleted by the GNV 2.1-1 installation. Essentially I had all the
additional tools needed to build several applications, and I had GLIB 2.0 and
all of its required libraries extending GNV.  They were all installed with PCSI
kits, so it should not be too much to put them back in.

The auto mount point routine also created a mount point for the CDROM that I
had mounted at the time.

While with the older GNV, I could have put them in their own directory under a
search list, with the new POSIX root, if they are to work in POSIX compliant
mode, currently there is no choice but to put them in the [gnv] directory tree. 
It also means that there is no way for non-privileged users to test new
applications that require their new files to be under the POSIX root on a
shared system.

The fix below was required in past versions of GNV and still appears needed
for GNV 2.1.1.

Most applications that need TAR need the gnutar, not vmstar.
This may require making a change to your GNV installation after doing the above
fixes.

$ set proc/parse=ext
$ Rename gnv$gnu:[bin]tar. gnv$gnu:[bin]vmstar.
$ rename gnv$gnu:[bin]tar.exe gnv$gnu:[bin]VMSTAR.EXE
$ set file/enter gnu:[bin]tar. gnv$gnu:[bin]GNUTAR.EXE
$ set file/enter gnu:[bin]TAR.EXE gnv$gnu:[bin]GNUTAR.EXE
$!

The above leaves vmstar and gnutar names for applications that need to
specifically use one of them, but sets gnutar as the default.

I do not know if either version of *tar supports large files.