[Info-vax] CPython has removed OpenVMS support

[John E. Malmberg]

On 12/21/2013 2:36 PM, Simon Clubley wrote:
> On 2013-12-21, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>
>> CPython "Issue #16136: Remove VMS support and VMS-related code"
>> <http://hg.python.org/cpython/rev/568391b3eda9>
>>
>
> To anyone interested, I recommend a read through the following links:
>
> http://bugs.python.org/issue16136
>
> and
>
> http://www.python.org/dev/peps/pep-0011/
>
>  From the first link, look for "msg191211" from about 6 months ago. That
> may have set the tone for the followup decision to remove VMS support.

It is interesting that no-one pointed the person to the VMS hobbyist 
program, which could have provided licenses and media.

At this time, GNV with the Bash and Coreutils update should be able to 
produce a configure and make file for all packages.  Until the SED fix 
gets done, it may take a bit longer than normal to run the configure script.

And some simple hacks are needed, because the generated configure tests 
are incorrect for all platforms with backwards binary compatibility, and 
this shows up on VMS.  I and some others are trying to get these 
documented on the sourceforge.net vms-ports and GNV projects.

And in the both the Bash and Coreutils ports, the config.h file was 
generated by a DCL script.

It can actually be a help to start out porting a package like Python 3 
to VMS by having all the VMS specific code removed.

Typically I find that a lot of pre-existing VMS changes are no longer 
needed with current VMS.

I prefer to use either supplemental or replacement libraries that are 
pulled in either by first include, or a hack to the VMS generated 
config.h file.

Right now, in my spare time, I am working on rebuilding each GNV 
component and putting it in its own PCSI package.  Current build target 
is gawk.

After gawk, my next target is SED, to fix the issue where it is taking 
seconds of high I/O and CPU to do an operation that should take 
milliseconds.  So far the investigation shows that only the existing VMS 
specific port is using the suspect code path, and removing the VMS 
specific change will probably fix the issue.

Regards,
-John
wb8tyw at qsl.network
Personal Opinion Only