From file: gawk_release_note_start.com

This is GNU gawk packaged for VMS.

The original readme files for GAWK for standalone building on VMS are

supplied here along with a procedure for building GAWK for the making

a PCSI kit.

Note: I am a hobbyist and am not providing any support or any commitment

to supply bug fixes or future releases.  This code is as-is with no

warrantees.

The testing of this port of Gawk involved running some self tests that

were provided with the source.

This version of gawk supports dynamically loaded extensions on Alpha and

Itanium versions of VMS.  The pre-built dynamically loaded extensions

are in gnv$gnu:[usr.lib.gawk].

The linker option file used to build a dynamically loaded extension is

located in gnv$gnu:[usr.src.gawk.extension.vms], and the gawkapi.h file

is in gnv$gnu:[usr.include].

Special installation notes:

*  Please see https://sourceforge.net/p/gnv/wiki/InstallingGNVPackages/

   for the latest information on installing GNV related PCSI kits.

*  We are updating and replacing GNV one kit at a time and transitioning

   GNV to be a set of kits that the GNV package will install.  During

   this transition some extra issues will need to be handled during

   installs and upgrades.

*  Due to the way that PCSI identifies packages, if you install a package

   from one producer and then want to upgrade it from another producer,

   you will probably need to uninstall the previous package first.

   Some of these packages were previously created with different producer

   prefixes.  We are standardizing on VMSPORTS and GNV as the branding

   prefixes.  GNV will be for packages that are part of the GNV product

   suite, and VMSPORTS will be for most other packages.

   This uninstall can cause warning messages about dependencies.  If you

   are transitioning to an upwardly compatible package, you can ignore

   those warnings.

*  This package should be installed to the same volume as GNV is installed.

   If you uninstall or upgrade GNV or install a GNV from before the

   transition is complete, you will need to reinstall all other packages

   that install to the same GNV directory tree.

   This is because at least some of the existing GNV installation procedures

   have bugs in them were instead of just deleting the files that were

   installed, they delete all files in the GNV directory tree.

*  Because this is a transition, this package is replacing files from the

   old GNV packages.  This is a necessary issue to allow incremental

   improvement as we can not replace the GNV package until we get all

   the component packages done.

*  The GNV 2.x through at least the 3.0.1 kits make an unusual change

   to the disk directory structure where they are installed where

   they use the [vms$common.gnv] as a mount point and mount the posix

   root on it.  This is a bug because it causes many problems and does

   not offer any advantages.  One of the problems is that it causes

   problems with other PCSI installs and uninstalls to that directory.

   This bug can be manually repaired such as has been done on

   on encompasserve.org as documented in PORTING_TO_VMS notes conference.

   At this time, we do not have a scripted repair to this bug, and it

   may not be possible to fully script a repair because this bug can

   cause the POSIX root and [vms$common.gnv] to have different contents

   when they should be the same directory, and it will take a manual

   inspection to select which files go where.

*  Because of the directory change bug, the gnv$startup.com in the GNV

   kit must be run when the system boots up or the [vms$common.gnv]

   directory will appear to be empty.

   If a PCSI kit like this one is installed when the GNV startup has not

   been run, it will create a new directory tree under [vms$common.gnv]

   that will not be visible to the posix root.  If you uninstall this

   PCSI kit before running the gnv$startup.com procedure then you can

   install it after running the gnv$startup.com procedure.  If you have

   run the gnv$startup.com procedure after the install, then you have

   a mess, and you will need to use the GNV umnt to un-mount the

   [vms$common.gnv] directory before the uninstall of this kit will

   work.

An analyze/disk/repair step on the installation disk should be done after

installation to collect files left over from incomplete deletions into the

SYSLOST directory.  This step should be done on a "quiet" system per HP

recomendations.

Bugs can be logged at the tracker with https://sourceforge.net/projects/gnv/.

There is no guarantee that bugs will be fixed for a hobbyist build.

VMS specific port information:

The logical name GNV$GNU is used to find the simulated posix root and defines

the logical name SYS$POSIX_ROOT in the process table in user mode for child

processes if needed.  This is to comply with VMS logical name conventions.

The logical name BIN is also set in the process table in user mode to be

GNV$GNU:[BIN] if it is not already set.

The following DECC$Feature settings are in in effect for Gawk by default:

DECC$ACL_ACCESS_CHECK enabled.

DECC$ALLOW_REMOVE_OPEN_FILES enabled.

DECC$ARGV_PARSE_STYLE enabled.

DECC$EFS_CASE_PRESERVE enabled.

DECC$EFS_CHARSET enabled.

DECC$EFS_FILE_TIMESTAMPS enabled.

DECC$ENABLE_GETENV_CACHE enabled.

DECC$EXEC_FILEATTR_INHERITANCE set to 2.

DECC$FILE_PERMISSION_UNIX enabled.

DECC$FILE_SHARING enabled.

DECC$FILE_OWNER_UNIX enabled.

DECC$FILENAME_REPORT_UNIX enabled.

DECC$FILENAME_UNIX_NO_VERSION enabled.

DECC$GLOB_UNIX_STYLE enabled.

DECC$POSIX_SEEK_STREAM_FILE enabled.

DECC$READDIR_DROPDOTNOTYPE enabled.

DECC$RENAME_NO_INHERIT enabled.

DECC$STDIO_CTX_EOL enabled.

DECC$STRTOL_ERANGE enabled.

DECC$UNIX_PATH_BEFORE_LOGNAME enabled.

While more strict UNIX compatibility feature settings can be applied by users

by setting feature logical names, these settings are all the Bash and most

ported programs need.

This port of Gawk uses the VMS CRTL to handle the Unix format pathnames

and as such is dependent on them.  It is a known issue that directories with

a Unix name "file.dir/" and some symbolic links are not handled correctly.

This is a combination of problems with RMS and CRTL.  The RMS portion is

fixed with the VMS84?_RMS-V0300 ECO kit.  I am not aware of a CRTL kit that

fixes the issues.

This kit is designed to be used with the GNV Bash 4.2.45 or later kit.

Fixes and enhancements:

 Gawk 4.1.3 ECO 1

* The previous GAWK kits were placing the binaries in /bin instead of

  /usr/bin, and not cleaning up the older binaries from the /bin directory

  after an update.

* The older kits could not properly detect the VSI releases of OpenVMS.

 Older kits:

* No logical names required for proper Gawk operations other than GNV$GNU

  for locating the simulated "/".

* GNV$GNU is used to find the posix root and locally sets SYS$POSIX_ROOT

  for child processes if needed.  This is to comply with VMS logical

  name conventions.  The logical name BIN is also set locally to be

  GNV$GNU:[BIN] if it is not already set.

* config.h now generated at part of the build from a template.

The supplied GNV$GAWK_STARTUP.COM procedure is provided in

[VMS$COMMON.SYS$STARTUP] can be put in your VMS startup procedure to install

selected images as known because they need privileges.  It is recommended

that the GNV$STARTUP.COM procedure be run first, followed by the

GNV$BASH_STARTUP.COM procedure before the GNV$GAWK_STARTUP.COM is

executed.

The names of the gawk image have been prefixed with GNV$ to prevent

possible naming conflicts with other programs that are on the system.  The

GNV$ prefix has been registered with HP for this purpose.

OpenVMS specific building and kitting instructions are after the standard

bash readme file below.

The source kits contains files for building Gawk using MMK.

MMK 4.0 was used for this build on Alpha and Itanium Itanium.

Currently, the focus of the OpenVMS GNV porting team is to address bugs in

the OpenVMS port of GNV components that pose immediate barriers to running

configure and make scripts for Open Source Software packages targeting

OpenVMS environments.

The GNV development team is involved in an ongoing effort to identify and

document the underlying technical causes for these current limitations and (if

available) workarounds as well as developing code fixes to eliminate them. The

VMS-Ports Source Forge project at https://sourceforge.net/p/vms-ports/tickets/

currently documents OpenVMS CRTL bugs and limitations with respect to porting

Open Source Software using OpenVMS. The VMS-Ports Source Forge Project also

contains examples of ported packages provided by volunteer contributors as well

as documentation with recommendations on how to setup, modify and use the

OpenVMS GNV environment for the purpose of porting Open Source software

packages to OpenVMS. Browse to https://sourceforge.net/p/vms-ports/wiki/Home/

for more information.