I'd like to port/build GNV for VAX (I know there are some curl issues and 64/32-bit addressing issues). What do I need to do to get the source code and the build instructions? Everything I've looked at indicated the it will only installed on IA64 and AXP. Pointers would be very helpful.
The pointers are all on the sourceforge GNV and related VMS-PORTS sites in the WIKI.
I would not attempt to build from the source files in the HP GNV kits.
The updated source code (for what has been updated) is in individual Mecurial Repositories on the SOURCEFORGE GNV site, except for gawk, which is up to date on the upstream.
For the other kits, there are generally two directory trees, one is a snapshot of the upstream repository used for the build, and the other is the VMS specific files needed for building.
In general the VMS build procedure provides missing routines or if it has no other option, live patches the original source. That way once a module is ported, it is less work to keep it up to date as there is no manual editing of the upstream source.
Curl is not part of GNV, and is being discussed in the VMS-PORTS discussion groups.
Curl also builds reasonably well on VAX, the problem is supporting the ancient HP SSL kit for VAX is requiring extra hoops. In fact supporting any of the older HP SSL kits has become a problem, so I am waiting the the Richard Levitte OpenSSL port before attempting a new kit.
Richard Levitte is only planning on porting OpenSSL to Alpha and IA64. Claims that there may be issues where both 64 bit integers and IEEE floating point are needed. IEEE floating point may be a deal breaker for getting OpenSSL up and running.
Bash 4.2 is the last Bash that I built on VAX/VMS, and that is with out the shell-shock patches.
I expect that it would build with the shell-shock patches installed.
AR_TOOLS and LD_TOOLS build on VAX. Some LD_TOOLS features do not work on VAX correctly.
Bash 4.3 (pending replacement to 4.4) are only being built for Alpha and I64 as they reference a 64 bit INO_T type.
Coreutils also references the 64 bit INO_T type. grep and sed are only being built for 64 bit VMS.
Gnu Awk from the GNU repository builds on VAX and is currently intermittently failing one test for opening > than filelm or channelcnt number of files.
To get a more functional GNV port on VMS, you may need:
1. A wrapper routine for filename handling that translate NFS escape encoded filenames to Unix filenames, and hides all the translation bugs in the older VAX CRTL.
2. Resurrecting the GCC/VAX compiler and providing it with the above routine. GCC/VAX, possibly even the last know binaries may support 64 bit integer types that would make porting easier. It also may not. I do not know. I do know that GCC/VAX can (should!) use the AACRTL060 kit to use the DECC CRTL unprefixed shared images.
Right now, I am focusing only on the Alpha and IA64, and if something compiles on the VAX, then I try to build it.
I'm actually taking a slightly different path. I'm going to use selective UN*X tools (sed, etc.) that have OpenVMS versions, along with a command procedure I'm writing to process a configure. file, which will generate a makefile., that will be converted to a DESCRIP.MMS file. I'll probably have to parse the configure. file a few times in order to get it specific for OpenVMS (initial pass will assume OpenVMS and UN*X are similar, mostly for the Xwindows, subsequent passes more and more OpenVMS specific). This is instead of using GNV.
Part of the reason is to not have a requirement on GNV for what I was originally going to use it. I'd really like to put something together that works and understand OpenVMS.
Eventually, I'll probably update the directory structure of the project to be ported to follow styles we used when we were part of DEC (rooted logicals, logical search lists, facility codes, etc.).
The updated GNV ports of Bash, gawk, coreutils, grep, sed, and curl all use DCL to generate what is done by the configure script.
They do not use the existing HP GNV kits at all and do not require them.
The AR, LD/C++/C/CPP are pure VMS code that wraps the DCL utilities. They are the existing HP GNV code with significant bug fixes.
The GNV Make fork is functional, but has a lot of bugs and is out of date. I have not had tine to fix all the bugs in the VMS/DCL mode of the upstream GNU Make, which needs to be done before I can merge them.
All can be built and used with out GNV or other components being present. Bash is kind of useless with out the other updated tools though.
These are also not "one-off" ports of the Unix tools, but are up to date builds of the latest releases, and are being kept up to date.
The major thing that stops the current versions from building on VAX is that they code assumes a 64 bit integer ino_t type, and no one has added code to the build script to adjust for that.
After that hurdle is solved, then they may need some additional wrapper routines to work around bugs in the VMS CRTL in handling Unix path names, particularly directories. We have some tickets open for bugs discovered in Bash 4.2.x, as that version does not reference the ino_t type.
The descrip.mms scripts have been hand crafted, but probably require MMK instead of MMS on VAX.
MMS does not work correctly on ODS-5 volumes, and has features that make it better for VAX builds than MMS.
The config_h.com which processes configure input could probably do with some optimization, but it works for the most part and it runs very fast. And it will work on an NFS volume mounted on VAX/VMS. One script that can be common to all the projects.
GNV$ is now a registered facility code, and the updated code supports rooted logical names, logical search lists, etc.
In fact the preferred build procedure for the above is to use a search list as the VMS code and the original Unix code are in two directory trees in the search list.
If you look at the https://sourceforge.net/projects/gnv/ there is now a screen shot. All updated components of GNV are now built by Jenkins every time a commit is made. My ISP does not allow me to make the Jenkins system directly visible to the Internet.
The current goal of the GNV project is to get it to work well enough to run the configure scripts and makefiles for open source projects to speed up the porting and maintenance.
The most short term goal is to get all the components building with current Unix sources with as full of functionality and in separate PCSI kits.
The diffutils port was done using only the updated GNV components, not the old GNV kit. It took about 16 hours of work to get it done, including running the self tests, and creating a PCSI kit. Running the self tests exposed a CRTL bug in that we are attempting to hide in what will be the next release of the updated GNV components, and that delayed the final commits to the diffutils kit by at least a week.
Look over the build procedures for the updated kits for Bash, sed, coreutils, grep, gawk.
Not GNV_MAKE, it was just built with minimal bug fixes so that I could run configure and make scripts on my IA64 system with out having the HP GNV kit installed. It still has many issues, but was blocking other more critical projects.
malmberg December 12 2017 HPE only makes the most current version of OpenVMS Alpha / IA64 /VAX available to hobbyists. When I had access to the Alliance 1 program it was the same. No public downloads are allowed by HPE.
nmbonao December 08 2017 Is anybody knows OpenVMS 8.2 version downloadable version? or CD copy? Thank you very much
aarommes December 02 2017 Bitcoin and Blockchain enthusiasts ( plus distributed computing ) please connec / reply: http://www.openvmshobbyis t.com/forum/viewthread.ph p?forum_id=130&thread_id= 2991
malmberg September 10 2017 https://sourceforge.net/p /vms-ports/wiki/VMSInstal lation/ For the most part just use VMS 6.1 media instead of 7.3. But why run the older release?
DoeveR August 07 2017 Where can I find the write up on running VMS 6.1 using the simh emulator?
Bart March 20 2017 Happy to have found my password again!