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.