It feels odd to say this, but one of the reasons I've been looking forwards
to running the x86 version of VMS, is to have access to Python 3. The Alpha
version of VMS only has Python 2, and I'm trying to force myself to use
Python more. Is Python avaialble for x86, and if so where?

I was pleased to see that Perl is included with the base OS.

Zane

On 4/8/2023 10:34 AM, Zane H. Healy wrote:
> It feels odd to say this, but one of the reasons I've been looking forwards
> to running the x86 version of VMS, is to have access to Python 3. The Alpha
> version of VMS only has Python 2, and I'm trying to force myself to use
> Python more. Is Python avaialble for x86, and if so where?

https://vmssoftware.com/products/python/

only has Itanium.

But since it is VSI and VSI want to push VMS x86-64, then
it seems reasonable to expect Python for VMS x86-64 to show
up at some point in time. Only VSI knows when.

Arne

Arne Vajh?j <arne@vajhoej.dk> wrote:
> https://vmssoftware.com/products/python/
>
> only has Itanium.
>
> But since it is VSI and VSI want to push VMS x86-64, then
> it seems reasonable to expect Python for VMS x86-64 to show
> up at some point in time. Only VSI knows when.
>
> Arne

Thanks for the confirmation. I thought that was the case, but wasn't sure
if I was simply looking in the wrong place. These days Python is pretty
much a requirement. Even IBM z/OS supports Python 3 now.

Zane

On 4/8/2023 10:48 AM, Arne Vajhøj wrote:
> On 4/8/2023 10:34 AM, Zane H. Healy wrote:
>> It feels odd to say this, but one of the reasons I've been looking forwards
>> to running the x86 version of VMS, is to have access to Python 3.  The Alpha
>> version of VMS only has Python 2, and I'm trying to force myself to use
>> Python more.  Is Python avaialble for x86, and if so where?
>
> https://vmssoftware.com/products/python/
>
> only has Itanium.
>
> But since it is VSI and VSI want to push VMS x86-64, then
> it seems reasonable to expect Python for VMS x86-64 to show
> up at some point in time. Only VSI knows when.

I know next-to-nothing about open source on VMS, but if Python requires
C++ to build, then that would be an impediment to its being built for X86_64.

The native C++ compiler on X86_64 is in field test.

--

--- Rob

In article <u0s9hd$1bhr0$1@dont-email.me>, FIRST.LAST@vmssoftware.com
(Robert A. Brooks) wrote:

> I know next-to-nothing about open source on VMS, but if Python
> requires C++ to build, then that would be an impediment to its
> being built for X86_64.
>
> The native C++ compiler on X86_64 is in field test.

The reference Python implementation, CPython, is written in C, and needs
a C99-capable compiler (C11 from Python 3.11). So the VSI C ought to be
adequate for 3.10 and earlier, but waiting for an LLVM-based C compiler
would allow building an up-to-date CPython.

John

On 4/8/2023 1:50 PM, Robert A. Brooks wrote:
> On 4/8/2023 10:48 AM, Arne Vajhøj wrote:
>> On 4/8/2023 10:34 AM, Zane H. Healy wrote:
>>> It feels odd to say this, but one of the reasons I've been looking
>>> forwards
>>> to running the x86 version of VMS, is to have access to Python 3.
>>> The Alpha
>>> version of VMS only has Python 2, and I'm trying to force myself to use
>>> Python more.  Is Python avaialble for x86, and if so where?
>>
>> https://vmssoftware.com/products/python/
>>
>> only has Itanium.
>>
>> But since it is VSI and VSI want to push VMS x86-64, then
>> it seems reasonable to expect Python for VMS x86-64 to show
>> up at some point in time. Only VSI knows when.
>
> I know next-to-nothing about open source on VMS, but if Python requires
> C++ to build, then that would be an impediment to its being built for
> X86_64.
>
> The native C++ compiler on X86_64 is in field test.

The standard and the one VSI is using Python implementation
is supposedly written in pure C.

But:

https://github.com/vmssoftware/cpython

claims :

Python 61.4%
C 36.4%
C++ 0.7%

and:

https://github.com/vmssoftware/python_3_8_2

claims:

Python 56.9%
C 40.1%
C++ 0.7%

so maybe there is a tiny little bit of C++ somewhere.

Arne

On 2023-04-08, Zane H. Healy <healyzh@avanthar.avanthar.com> wrote:
>
> Thanks for the confirmation. I thought that was the case, but wasn't sure
> if I was simply looking in the wrong place. These days Python is pretty
> much a requirement. Even IBM z/OS supports Python 3 now.
>

And for very good reason. Python is an excellent scripting language
that is suitable for a _wide_ range of scripting tasks.

In fact, if VSI had to choose one only, I would have said that Python,
instead of Perl, should have been the one that's part of the base
installation. (Although it would be better to have both of them as
part of the base installation.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/11/23 8:23 AM, Simon Clubley wrote:
> On 2023-04-08, Zane H. Healy <healyzh@avanthar.avanthar.com> wrote:
>>
>> Thanks for the confirmation. I thought that was the case, but wasn't sure
>> if I was simply looking in the wrong place. These days Python is pretty
>> much a requirement. Even IBM z/OS supports Python 3 now.
>>
>
> And for very good reason. Python is an excellent scripting language
> that is suitable for a _wide_ range of scripting tasks.
>
> In fact, if VSI had to choose one only, I would have said that Python,
> instead of Perl, should have been the one that's part of the base
> installation. (Although it would be better to have both of them as
> part of the base installation.)

I don't think there was any such choice and I agree that having a Python
package available is essential. I'm not sure why Python isn't available
yet. The native C and C++ compilers are still in field test state and
have long lists of known issues, so it's possible the dependencies just
aren't there quite yet to build CPython.

Perl is available because I built it with the cross tools kit and VSI
repackaged and signed it with my blessing. That means, among other
things, that you can't build Perl extensions with the native compilers
until Perl itself is built with them. Building Perl with the native
compilers is well under way but not quite there yet. Perl and its test
suite have a way of revealing bugs in the C compiler, the CRTL, and even
the OS itself occasionally.

On 4/11/2023 6:45 PM, Craig A. Berry wrote:
> On 4/11/23 8:23 AM, Simon Clubley wrote:
>> On 2023-04-08, Zane H. Healy <healyzh@avanthar.avanthar.com> wrote:
>>> Thanks for the confirmation.  I thought that was the case, but wasn't
>>> sure
>>> if I was simply looking in the wrong place.  These days Python is pretty
>>> much a requirement.  Even IBM z/OS supports Python 3 now.
>>
>> And for very good reason. Python is an excellent scripting language
>> that is suitable for a _wide_ range of scripting tasks.
>>
>> In fact, if VSI had to choose one only, I would have said that Python,
>> instead of Perl, should have been the one that's part of the base
>> installation. (Although it would be better to have both of them as
>> part of the base installation.)
>
> I don't think there was any such choice and I agree that having a Python
> package available is essential.  I'm not sure why Python isn't available
> yet.  The native C and C++ compilers are still in field test state and
> have long lists of known issues, so it's possible the dependencies just
> aren't there quite yet to build CPython.
>
> Perl is available because I built it with the cross tools kit and VSI
> repackaged and signed it with my blessing.  That means, among other
> things, that you can't build Perl extensions with the native compilers
> until Perl itself is built with them.  Building Perl with the native
> compilers is well under way but not quite there yet.  Perl and its test
> suite have a way of revealing bugs in the C compiler, the CRTL, and even
> the OS itself occasionally.

Python is way more popular than Perl today, so we know it is not
a business priority.

It could be a technical dependency problem as you describe.

But it could also be an estimated effort problem. It is my impression
that Perl is evolving reasonable slowly and that the VMS port has
been rock solid for decades. And all versions has been build
for both Alpha and Itanium. That sort of make it easier to
port and know what is a source problem and what is a tool problem.
Python situation is a bit more uncertain. The Python language is
evolving pretty quickly as they have joined the arms race with
C++/Java/C#/PHP about having most features. And first JFP did 2.x on
both Alpha and Itanium, then JFP did a 3.x on Itanium only and finally
VSI did a 3.x on Itanium only. As we speak (hmm, write) there is an
outstanding question on VSI Python over on the VSI forum. I suspect that
an estimate for Python port to x86-64 would be much higher than the Perl
one.

Arne

PS: And a million thanks to the people that have worked on Perl and
Python over the years!!

On 4/12/2023 11:30 AM, Zane H. Healy wrote:
> Arne Vajh?j <arne@vajhoej.dk> wrote:
>> But it could also be an estimated effort problem. It is my impression
>> that Perl is evolving reasonable slowly and that the VMS port has
>> been rock solid for decades. And all versions has been build
>> for both Alpha and Itanium. That sort of make it easier to
>> port and know what is a source problem and what is a tool problem.
>
> One thought I had, after reading the replies. The technical reasons make
> sense. However, in reality, might there not be more Perl code running on
> VMS than Python? I know that on my personal servers I have a fair amount of
> Perl, but then I've spent over 26 years with Perl as my primary language.
> My interest in Python is that I am now doing things that require it, so
> being able to use it on VMS would be an advantage to me.

Maybe.

If we look at the IT industry over all then:
- Perl is a niche language known by the smart *nix nerds
primarily used for admin scripting today (after having had
some golden years in the late 90's early 00's for web
development)
- Python is one of the top 3 languages - widely used for
admin scripting, big data/data-analysis/ML/AI, web
development (Django), education etc. etc.

But VMS is not like the overall IT industry.

A lot of VMS systems are old and from a time where
Perl was bigger than Python.

In traditional admin scripts for VMS there are
probably way more Perl than Python (DCL is still king
in this area despite its various gaps).

But there has also been done a lot of Python work on VMS
the last 15 years in the area of integration between
VMS applications and other stuff the companies are
running.

Arne

Arne Vajh?j <arne@vajhoej.dk> wrote:
> But it could also be an estimated effort problem. It is my impression
> that Perl is evolving reasonable slowly and that the VMS port has
> been rock solid for decades. And all versions has been build
> for both Alpha and Itanium. That sort of make it easier to
> port and know what is a source problem and what is a tool problem.

One thought I had, after reading the replies. The technical reasons make
sense. However, in reality, might there not be more Perl code running on
VMS than Python? I know that on my personal servers I have a fair amount of
Perl, but then I've spent over 26 years with Perl as my primary language.
My interest in Python is that I am now doing things that require it, so
being able to use it on VMS would be an advantage to me.

Zane

On 4/12/23 11:37 AM, Arne Vajhøj wrote:
> On 4/12/2023 11:30 AM, Zane H. Healy wrote:
>> Arne Vajh?j <arne@vajhoej.dk> wrote:
>>> But it could also be an estimated effort problem. It is my impression
>>> that Perl is evolving reasonable slowly and that the VMS port has
>>> been rock solid for decades. And all versions has been build
>>> for both Alpha and Itanium. That sort of make it easier to
>>> port and know what is a source problem and what is a tool problem.
>>
>> One thought I had, after reading the replies.  The technical reasons make
>> sense.  However, in reality, might there not be more Perl code running on
>> VMS than Python?  I know that on my personal servers I have a fair
>> amount of
>> Perl, but then I've spent over 26 years with Perl as my primary language.
>> My interest in Python is that I am now doing things that require it, so
>> being able to use it on VMS would be an advantage to me.
>
> Maybe.
>
> If we look at the IT industry over all then:
> - Perl is a niche language known by the smart *nix nerds
>   primarily used for admin scripting today (after having had
>   some golden years in the late 90's early 00's for web
>   development)

And not just local admin scripting. It's a dependency for autoconf.
It's heavily used by other build processes and system utilities in the
BSD and Linux worlds. Various potentially breaking changes in Perl
analogous to those in Python 3 have been shot down because the whole
internet would stop. And because Hyrum's Law.

> - Python is one of the top 3 languages - widely used for
>   admin scripting, big data/data-analysis/ML/AI, web
>   development (Django), education etc. etc.

It's had massive investment by Google and others and its original author
has stuck around to see it through the 2 to 3 transition even if
stepping back from the role of benevolent dictator for life. Its success
is impressive but I don't know how much it has to do with the language
itself.

> But VMS is not like the overall IT industry.
>
> A lot of VMS systems are old and from a time where
> Perl was bigger than Python.
>
> In traditional admin scripts for VMS there are
> probably way more Perl than Python (DCL is still king
> in this area despite its various gaps).
>
> But there has also been done a lot of Python work on VMS
> the last 15 years in the area of integration between
> VMS applications and other stuff the companies are
> running.

Python 3 requires libffi. I believe it was an impediment to getting
Python 3 on Alpha because it involved finding someone who knew Alpha
assembler who could implement a module in that. Obviously a lot of
people, relatively speaking, know x86 assembler, but the ones at VSI may
have other stuff to do. Also, I believe Perl is a dependency for
building OpenSSL, which is part of the VMS base install. While the
current OpenSSL kits are probably cross builds, that may be changing
soon and it may have something to do with the order of porting. I also
have the impression that at least some people at VSI use Perl frequently
as the swiss army chainsaw it's known for.

On Wednesday, April 12, 2023 at 9:49:05 PM UTC-4, Craig A. Berry wrote:
> On 4/12/23 11:37 AM, Arne Vajhøj wrote:
> > On 4/12/2023 11:30 AM, Zane H. Healy wrote:
> >> Arne Vajh?j <ar...@vajhoej.dk> wrote:
> >>> But it could also be an estimated effort problem. It is my impression
> >>> that Perl is evolving reasonable slowly and that the VMS port has
> >>> been rock solid for decades. And all versions has been build
> >>> for both Alpha and Itanium. That sort of make it easier to
> >>> port and know what is a source problem and what is a tool problem.
> >>
> >> One thought I had, after reading the replies. The technical reasons make
> >> sense. However, in reality, might there not be more Perl code running on
> >> VMS than Python? I know that on my personal servers I have a fair
> >> amount of
> >> Perl, but then I've spent over 26 years with Perl as my primary language.
> >> My interest in Python is that I am now doing things that require it, so
> >> being able to use it on VMS would be an advantage to me.
> >
> > Maybe.
> >
> > If we look at the IT industry over all then:
> > - Perl is a niche language known by the smart *nix nerds
> > primarily used for admin scripting today (after having had
> > some golden years in the late 90's early 00's for web
> > development)
> And not just local admin scripting. It's a dependency for autoconf.
> It's heavily used by other build processes and system utilities in the
> BSD and Linux worlds. Various potentially breaking changes in Perl
> analogous to those in Python 3 have been shot down because the whole
> internet would stop. And because Hyrum's Law.
> > - Python is one of the top 3 languages - widely used for
> > admin scripting, big data/data-analysis/ML/AI, web
> > development (Django), education etc. etc.
> It's had massive investment by Google and others and its original author
> has stuck around to see it through the 2 to 3 transition even if
> stepping back from the role of benevolent dictator for life. Its success
> is impressive but I don't know how much it has to do with the language
> itself.
> > But VMS is not like the overall IT industry.
> >
> > A lot of VMS systems are old and from a time where
> > Perl was bigger than Python.
> >
> > In traditional admin scripts for VMS there are
> > probably way more Perl than Python (DCL is still king
> > in this area despite its various gaps).
> >
> > But there has also been done a lot of Python work on VMS
> > the last 15 years in the area of integration between
> > VMS applications and other stuff the companies are
> > running.
> Python 3 requires libffi. I believe it was an impediment to getting
> Python 3 on Alpha because it involved finding someone who knew Alpha
> assembler who could implement a module in that. Obviously a lot of
> people, relatively speaking, know x86 assembler, but the ones at VSI may
> have other stuff to do. Also, I believe Perl is a dependency for
> building OpenSSL, which is part of the VMS base install. While the
> current OpenSSL kits are probably cross builds, that may be changing
> soon and it may have something to do with the order of porting. I also
> have the impression that at least some people at VSI use Perl frequently
> as the swiss army chainsaw it's known for.

Actually, the original author, Guido van Rossum, was hired by Google for no other reason than to port python2 up tp python3 along the lines that google wanted. As an enticement, he was told to work on python3 only in the mornings so would be allowed to work on anything else the rest of the day. IIRC, he stayed in that roll for seven years.

And although python is used to do a lot of admin scripting on Linux platforms (tools like "yum" and "firewall-cmd" are written in python), python does a really good job supporting server-side scripting under apache cgi-bin. I don't know how this is possible, but python programs are faster than compiled DEC-BASIC programs started via apache.

So IMHO python3 on OpenVMS is a must-have.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net
http://neilrieck.net/OpenVMS.html

On 4/13/2023 6:44 AM, Neil Rieck wrote:
> Actually, the original author, Guido van Rossum, was hired by Google
> for no other reason than to port python2 up tp python3 along the
> lines that google wanted. As an enticement, he was told to work on
> python3 only in the mornings so would be allowed to work on anything
> else the rest of the day. IIRC, he stayed in that roll for seven
> years.

Yes. According to wikipedia:

CWI -2005
Google 2005-2012
Dropbox 2012-2019
retired 2019-2020
Microsoft 2020-

> And although python is used to do a lot of admin scripting on Linux
> platforms (tools like "yum" and "firewall-cmd" are written in
> python), python does a really good job supporting server-side
> scripting under apache cgi-bin. I don't know how this is possible,
> but python programs are faster than compiled DEC-BASIC programs
> started via apache.

That is unexpected. If both are run via CGI mechanism then
script activation should be the same. And compiled code should be
faster than interpreted code. And if libraries used are also the
same then it is a mystery.

High performance Python web services would use Flask or
something similar to avoid the activation overhead.

> So IMHO python3 on OpenVMS is a must-have.

Absolutely.

Python is a very important language today.

And it has to be Python 3 as Python 2 is obsolete.

Arne

On 4/13/2023 6:44 AM, Neil Rieck wrote:
> Actually, the original author, Guido van Rossum, was hired by Google
> for no other reason than to port python2 up tp python3 along the
> lines that google wanted. As an enticement, he was told to work on
> python3 only in the mornings so would be allowed to work on anything
> else the rest of the day. IIRC, he stayed in that roll for seven
> years.

Yes. According to wikipedia:

CWI -2005
Google 2005-2012
Dropbox 2012-2019
retired 2019-2020
Microsoft 2020-

> And although python is used to do a lot of admin scripting on Linux
> platforms (tools like "yum" and "firewall-cmd" are written in
> python), python does a really good job supporting server-side
> scripting under apache cgi-bin. I don't know how this is possible,
> but python programs are faster than compiled DEC-BASIC programs
> started via apache.

That is unexpected. If both are run via CGI mechanism then
script activation should be the same. And compiled code should be
faster than interpreted code. And if libraries used are also the
same then it is a mystery.

High performance Python web services would use Flask or
something similar to avoid the activation overhead.

> So IMHO python3 on OpenVMS is a must-have.

Absolutely.

Python is a very important language today.

And it has to be Python 3 as Python 2 is obsolete.

Arne

Den 2023-04-13 kl. 12:44, skrev Neil Rieck:
> On Wednesday, April 12, 2023 at 9:49:05 PM UTC-4, Craig A. Berry wrote:
>> On 4/12/23 11:37 AM, Arne Vajhøj wrote:
>>> On 4/12/2023 11:30 AM, Zane H. Healy wrote:
>>>> Arne Vajh?j <ar...@vajhoej.dk> wrote:
>>>>> But it could also be an estimated effort problem. It is my impression
>>>>> that Perl is evolving reasonable slowly and that the VMS port has
>>>>> been rock solid for decades. And all versions has been build
>>>>> for both Alpha and Itanium. That sort of make it easier to
>>>>> port and know what is a source problem and what is a tool problem.
>>>>
>>>> One thought I had, after reading the replies. The technical reasons make
>>>> sense. However, in reality, might there not be more Perl code running on
>>>> VMS than Python? I know that on my personal servers I have a fair
>>>> amount of
>>>> Perl, but then I've spent over 26 years with Perl as my primary language.
>>>> My interest in Python is that I am now doing things that require it, so
>>>> being able to use it on VMS would be an advantage to me.
>>>
>>> Maybe.
>>>
>>> If we look at the IT industry over all then:
>>> - Perl is a niche language known by the smart *nix nerds
>>> primarily used for admin scripting today (after having had
>>> some golden years in the late 90's early 00's for web
>>> development)
>> And not just local admin scripting. It's a dependency for autoconf.
>> It's heavily used by other build processes and system utilities in the
>> BSD and Linux worlds. Various potentially breaking changes in Perl
>> analogous to those in Python 3 have been shot down because the whole
>> internet would stop. And because Hyrum's Law.
>>> - Python is one of the top 3 languages - widely used for
>>> admin scripting, big data/data-analysis/ML/AI, web
>>> development (Django), education etc. etc.
>> It's had massive investment by Google and others and its original author
>> has stuck around to see it through the 2 to 3 transition even if
>> stepping back from the role of benevolent dictator for life. Its success
>> is impressive but I don't know how much it has to do with the language
>> itself.
>>> But VMS is not like the overall IT industry.
>>>
>>> A lot of VMS systems are old and from a time where
>>> Perl was bigger than Python.
>>>
>>> In traditional admin scripts for VMS there are
>>> probably way more Perl than Python (DCL is still king
>>> in this area despite its various gaps).
>>>
>>> But there has also been done a lot of Python work on VMS
>>> the last 15 years in the area of integration between
>>> VMS applications and other stuff the companies are
>>> running.
>> Python 3 requires libffi. I believe it was an impediment to getting
>> Python 3 on Alpha because it involved finding someone who knew Alpha
>> assembler who could implement a module in that. Obviously a lot of
>> people, relatively speaking, know x86 assembler, but the ones at VSI may
>> have other stuff to do. Also, I believe Perl is a dependency for
>> building OpenSSL, which is part of the VMS base install. While the
>> current OpenSSL kits are probably cross builds, that may be changing
>> soon and it may have something to do with the order of porting. I also
>> have the impression that at least some people at VSI use Perl frequently
>> as the swiss army chainsaw it's known for.
>
> Actually, the original author, Guido van Rossum, was hired by Google for no other reason than to port python2 up tp python3 along the lines that google wanted. As an enticement, he was told to work on python3 only in the mornings so would be allowed to work on anything else the rest of the day. IIRC, he stayed in that roll for seven years.
>
> And although python is used to do a lot of admin scripting on Linux platforms (tools like "yum" and "firewall-cmd" are written in python), python does a really good job supporting server-side scripting under apache cgi-bin. I don't know how this is possible, but python programs are faster than compiled DEC-BASIC programs started via apache.

The performance depends a lot on if you are using standard Apache CGI
or Apache "loadable modules". If you are just writing your own server
apps, I guess they run as standard CGI (one process started per call).
And I would expect Python to be available as a "loadable module". And
that makes a big differnce, in particular on VMS with it's process
creation overhead.

Here are some figures for WASD and Apache.
http://wasd.vsm.com.au/wasd_root/wasdoc/features/#11.2.scripting

We are using Python 2 in the form of PyRTE (persisting processes) and
have OK performance. First call (starting the Python process) does have
a 1-2 sec overhead, but following calls are processes in fractions of a
second (incl. Rdb processing).

We are currently looking at writing our own persistent server processes
to see if we can tweek the performance a bit more by using compiled
code (Cobol, in our case).

Using a test C application (just returns a timestamp to the browser, the
reply time including starting the VMS process is 172 ms. Additional calls
to the server with the process started are around 60 ms. As reported by
the performance tools in Firefox.
(Firefix running ona Citrix server pointing to one of our DS20e systems.)

>
> So IMHO python3 on OpenVMS is a must-have.
>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net
> http://neilrieck.net/OpenVMS.html

Den 2023-04-13 kl. 12:44, skrev Neil Rieck:
> On Wednesday, April 12, 2023 at 9:49:05 PM UTC-4, Craig A. Berry wrote:
>> On 4/12/23 11:37 AM, Arne Vajhøj wrote:
>>> On 4/12/2023 11:30 AM, Zane H. Healy wrote:
>>>> Arne Vajh?j <ar...@vajhoej.dk> wrote:
>>>>> But it could also be an estimated effort problem. It is my impression
>>>>> that Perl is evolving reasonable slowly and that the VMS port has
>>>>> been rock solid for decades. And all versions has been build
>>>>> for both Alpha and Itanium. That sort of make it easier to
>>>>> port and know what is a source problem and what is a tool problem.
>>>>
>>>> One thought I had, after reading the replies. The technical reasons make
>>>> sense. However, in reality, might there not be more Perl code running on
>>>> VMS than Python? I know that on my personal servers I have a fair
>>>> amount of
>>>> Perl, but then I've spent over 26 years with Perl as my primary language.
>>>> My interest in Python is that I am now doing things that require it, so
>>>> being able to use it on VMS would be an advantage to me.
>>>
>>> Maybe.
>>>
>>> If we look at the IT industry over all then:
>>> - Perl is a niche language known by the smart *nix nerds
>>> primarily used for admin scripting today (after having had
>>> some golden years in the late 90's early 00's for web
>>> development)
>> And not just local admin scripting. It's a dependency for autoconf.
>> It's heavily used by other build processes and system utilities in the
>> BSD and Linux worlds. Various potentially breaking changes in Perl
>> analogous to those in Python 3 have been shot down because the whole
>> internet would stop. And because Hyrum's Law.
>>> - Python is one of the top 3 languages - widely used for
>>> admin scripting, big data/data-analysis/ML/AI, web
>>> development (Django), education etc. etc.
>> It's had massive investment by Google and others and its original author
>> has stuck around to see it through the 2 to 3 transition even if
>> stepping back from the role of benevolent dictator for life. Its success
>> is impressive but I don't know how much it has to do with the language
>> itself.
>>> But VMS is not like the overall IT industry.
>>>
>>> A lot of VMS systems are old and from a time where
>>> Perl was bigger than Python.
>>>
>>> In traditional admin scripts for VMS there are
>>> probably way more Perl than Python (DCL is still king
>>> in this area despite its various gaps).
>>>
>>> But there has also been done a lot of Python work on VMS
>>> the last 15 years in the area of integration between
>>> VMS applications and other stuff the companies are
>>> running.
>> Python 3 requires libffi. I believe it was an impediment to getting
>> Python 3 on Alpha because it involved finding someone who knew Alpha
>> assembler who could implement a module in that. Obviously a lot of
>> people, relatively speaking, know x86 assembler, but the ones at VSI may
>> have other stuff to do. Also, I believe Perl is a dependency for
>> building OpenSSL, which is part of the VMS base install. While the
>> current OpenSSL kits are probably cross builds, that may be changing
>> soon and it may have something to do with the order of porting. I also
>> have the impression that at least some people at VSI use Perl frequently
>> as the swiss army chainsaw it's known for.
>
> Actually, the original author, Guido van Rossum, was hired by Google for no other reason than to port python2 up tp python3 along the lines that google wanted. As an enticement, he was told to work on python3 only in the mornings so would be allowed to work on anything else the rest of the day. IIRC, he stayed in that roll for seven years.
>
> And although python is used to do a lot of admin scripting on Linux platforms (tools like "yum" and "firewall-cmd" are written in python), python does a really good job supporting server-side scripting under apache cgi-bin. I don't know how this is possible, but python programs are faster than compiled DEC-BASIC programs started via apache.

The performance depends a lot on if you are using standard Apache CGI
or Apache "loadable modules". If you are just writing your own server
apps, I guess they run as standard CGI (one process started per call).
And I would expect Python to be available as a "loadable module". And
that makes a big differnce, in particular on VMS with it's process
creation overhead.

Here are some figures for WASD and Apache.
http://wasd.vsm.com.au/wasd_root/wasdoc/features/#11.2.scripting

We are using Python 2 in the form of PyRTE (persisting processes) and
have OK performance. First call (starting the Python process) does have
a 1-2 sec overhead, but following calls are processes in fractions of a
second (incl. Rdb processing).

We are currently looking at writing our own persistent server processes
to see if we can tweek the performance a bit more by using compiled
code (Cobol, in our case).

Using a test C application (just returns a timestamp to the browser, the
reply time including starting the VMS process is 172 ms. Additional calls
to the server with the process started are around 60 ms. As reported by
the performance tools in Firefox.
(Firefix running ona Citrix server pointing to one of our DS20e systems.)

>
> So IMHO python3 on OpenVMS is a must-have.
>
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net
> http://neilrieck.net/OpenVMS.html

On 2023-04-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>> And although python is used to do a lot of admin scripting on Linux
>> platforms (tools like "yum" and "firewall-cmd" are written in
>> python), python does a really good job supporting server-side
>> scripting under apache cgi-bin. I don't know how this is possible,
>> but python programs are faster than compiled DEC-BASIC programs
>> started via apache.
>
> That is unexpected. If both are run via CGI mechanism then
> script activation should be the same. And compiled code should be
> faster than interpreted code. And if libraries used are also the
> same then it is a mystery.
>

Maybe. Maybe not. Based purely on some comments from people here who
know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
imposes some serious runtime overheads.

Perhaps for one of your many articles (:-)), you may be interested in
coding the same set of problems in the various DEC languages and seeing
what the performance differences are.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2023-04-13 kl. 14:26, skrev Simon Clubley:
> On 2023-04-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>> And although python is used to do a lot of admin scripting on Linux
>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>> python), python does a really good job supporting server-side
>>> scripting under apache cgi-bin. I don't know how this is possible,
>>> but python programs are faster than compiled DEC-BASIC programs
>>> started via apache.
>>
>> That is unexpected. If both are run via CGI mechanism then
>> script activation should be the same. And compiled code should be
>> faster than interpreted code. And if libraries used are also the
>> same then it is a mystery.
>>
>
> Maybe. Maybe not. Based purely on some comments from people here who
> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
> imposes some serious runtime overheads.
>
> Perhaps for one of your many articles (:-)), you may be interested in
> coding the same set of problems in the various DEC languages and seeing
> what the performance differences are.
>
> Simon.
>

I'm quite sure that the difference seen come from the fact that
the Basic application is using standard CGI (one process per call)
and Python is a "Loadable Module" in Apache (stays loaded between
calls).

If both was using the same server technique, I'd expect the Basic
process to be faster. Of course, also depends on what the server
applications actualy does...

Or was the Basic application written as a "loadable module"?

On 4/12/2023 9:49 PM, Craig A. Berry wrote:
> On 4/12/23 11:37 AM, Arne Vajhøj wrote:
>> - Python is one of the top 3 languages - widely used for
>>    admin scripting, big data/data-analysis/ML/AI, web
>>    development (Django), education etc. etc.
>
> It's had massive investment by Google and others and its original author
> has stuck around to see it through the 2 to 3 transition even if
> stepping back from the role of benevolent dictator for life. Its success
> is impressive but I don't know how much it has to do with the language
> itself.

The relationship between language syntax/features and language
success is rarely clear.

:-)

I remember back when Perl, Python and Tcl was 3 equivalent choices
for scripting.

They evolved very different - Perl stayed where it was, Python became
a widely used language and Tcl is practically dead.

Why did Python become such a success while the other did not?

My guess:
- Python managed to get into education - not just CS like
Perl but much broader
- Python web approaches with Django etc. turned more future oriented
than Perl CGI
- Python got on the big data / analytics / ML / AI train
and when that took off it pulled Python with it

> Python 3 requires libffi.  I believe it was an impediment to getting
> Python 3 on Alpha because it involved finding someone who knew Alpha
> assembler who could implement a module in that.

I remember the Python 3 "port problem" being libffi.

But if the libffi problem is assembler knowledge then I am
puzzled - I would expect way more Alpha assembler programmers
than Itanium programmers.

> Also, I believe Perl is a dependency for
> building OpenSSL, which is part of the VMS base install.  While the
> current OpenSSL kits are probably cross builds, that may be changing
> soon and it may have something to do with the order of porting.  I also
> have the impression that at least some people at VSI use Perl frequently
> as the swiss army chainsaw it's known for.

:-)

Arne

Den 2023-04-13 kl. 14:31, skrev Arne Vajhøj:

>
> I remember the Python 3 "port problem" being libffi.
>

A few weeks ago I got information from JFP on his new
Python 3 port to Itanium.

I do not have any Itanium server, so I havn't looked further.
And I have no idea about this libffi thing...

And VSI has a Python 3 offering.
https://vmssoftware.com/products/python/

I do not know if I have missed something, but why is Python 3
discusses as an issue? Would it not be expected that these
Python 3 ports also would build on x86?

On 4/13/2023 8:40 AM, Jan-Erik Söderholm wrote:
> And VSI has a Python 3 offering.
> https://vmssoftware.com/products/python/
>
> I do not know if I have missed something, but why is Python 3
> discusses as an issue? Would it not be expected that these
> Python 3 ports also would build on x86?

I think everybody is expecting Python 3 to become available
on VMS x86-64.

But it is not available yet.

While Perl is.

And given the huge interest here in speculating about anything
VMS related, then we are just guessing on why Perl came before
Python.

:-)

Arne

On 4/13/2023 8:26 AM, Simon Clubley wrote:
> On 2023-04-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>> And although python is used to do a lot of admin scripting on Linux
>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>> python), python does a really good job supporting server-side
>>> scripting under apache cgi-bin. I don't know how this is possible,
>>> but python programs are faster than compiled DEC-BASIC programs
>>> started via apache.
>>
>> That is unexpected. If both are run via CGI mechanism then
>> script activation should be the same. And compiled code should be
>> faster than interpreted code. And if libraries used are also the
>> same then it is a mystery.
>>
>
> Maybe. Maybe not. Based purely on some comments from people here who
> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
> imposes some serious runtime overheads.

VMS Basic is a language with a high level of abstraction
so more "happens under the hood" than in C/Fortran/Cobol.

There are some overhead due to that.

Obvious example is strings. VMS Basic use dynamic
strings. The RTL does some work there.

But Python is even more high level and does similar
work - including the equivalent of dynamic strings.

But it is still interpreted (for standard Python
implementation) while VMS Basic get compiled.

Only thing in Pythons favor is that there must
be spent 1000 times more effort optimizing Python
libraries than optimizing VMS Basic RTL.

Arne

On 4/13/2023 9:24 AM, Arne Vajhøj wrote:
> On 4/13/2023 8:26 AM, Simon Clubley wrote:
>> On 2023-04-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/13/2023 6:44 AM, Neil Rieck wrote:
>>>> And although python is used to do a lot of admin scripting on Linux
>>>> platforms (tools like "yum" and "firewall-cmd" are written in
>>>> python), python does a really good job supporting server-side
>>>> scripting under apache cgi-bin. I don't know how this is possible,
>>>> but python programs are faster than compiled DEC-BASIC programs
>>>> started via apache.
>>>
>>> That is unexpected. If both are run via CGI mechanism then
>>> script activation should be the same. And compiled code should be
>>> faster than interpreted code. And if libraries used are also the
>>> same then it is a mystery.
>>>
>>
>> Maybe. Maybe not. Based purely on some comments from people here who
>> know/use DEC Basic, it's quite possible that DEC Basic has a RTL which
>> imposes some serious runtime overheads.
>
> VMS Basic is a language with a high level of abstraction
> so more "happens under the hood" than in C/Fortran/Cobol.
>
> There are some overhead due to that.
>
> Obvious example is strings. VMS Basic use dynamic
> strings. The RTL does some work there.
>
> But Python is even more high level and does similar
> work - including the equivalent of dynamic strings.
>
> But it is still interpreted (for standard Python
> implementation) while VMS Basic get compiled.
>
> Only thing in Pythons favor is that there must
> be spent 1000 times more effort optimizing Python
> libraries than optimizing VMS Basic RTL.

One can do a little test.

VMS Alpha.

$ type app.c
#include <stdio.h>
#include <string.h>

void app(char *buf, int n)
{ int i;
for(i = 0; i < n; i++)
{
strcat(buf, "X");
}
}

int main(int argc, char *argv[])
{ char buf[100];
strcpy(buf, "");
app(buf, 10);
printf("%s\n", buf);
return 0;
} $ cc app
$ link app
$ run app
XXXXXXXXXX
$ type app.bas
program appdemo

declare string buf
external sub app(string, integer)

buf = ""
call app(buf, 10)
print buf

end program
! sub app(string buf, integer n)

declare integer i

for i = 1 to n
buf = buf + "X"
next i

end sub
$ bas app
$ link app
$ run app
XXXXXXXXXX

C compiler generates:

0000 APP::
EE200020 0000 BLE R17, L$11
; 001948
23DEFFC0 0004 LDA SP, -64(SP)
; 001945
B77E0000 0008 STQ R27, (SP)
B75E0008 000C STQ R26, 8(SP)
B45E0010 0010 STQ R2, 16(SP)
B47E0018 0014 STQ R3, 24(SP)
B49E0020 0018 STQ R4, 32(SP)
B4BE0028 001C STQ R5, 40(SP)
B7BE0030 0020 STQ FP, 48(SP)
47FE041D 0024 MOV SP, FP
47FF0405 0028 CLR R5
47F10404 002C MOV R17, R4
47F00403 0030 MOV R16, R3
47FB0402 0034 MOV R27, R2
2FFE0000 0038 UNOP
2FFE0000 003C UNOP
0040 L$6:
; 001948
A7420020 0040 LDQ R26, 32(R2)
; 001950
40A03005 0044 ADDL i, 1, i
; R5, 1, R5 ; 001948
47E30410 0048 MOV buf, R16
; R3, R16 ; 001950
22220030 004C LDA R17, 48(R2)
47E05419 0050 MOV 2, R25
A7620028 0054 LDQ R27, 40(R2)
6B5A4000 0058 JSR R26, DECC$STRCAT
; R26, R26
40A409A0 005C CMPLT i, n, R0
; R5, R4, R0 ; 001948
F41FFFF7 0060 BNE R0, L$6
47FD041E 0064 MOV FP, SP
; 001952
A75D0008 0068 LDQ R26, 8(FP)
A45D0010 006C LDQ R2, 16(FP)
A47D0018 0070 LDQ R3, 24(FP)
A49D0020 0074 LDQ R4, 32(FP)
A4BD0028 0078 LDQ R5, 40(FP)
A7BD0030 007C LDQ FP, 48(FP)
23DE0040 0080 LDA SP, 64(SP)
0084 L$11:
6BFA8001 0084 RET R26
2FFE0000 0088 UNOP
2FFE0000 008C UNOP

Basic compiler generates:

0120 APP::
; 000011
23DEFF00 0120 LDA SP, -256(SP)
473FF019 0124 AND R25, 255, R25
B75E00C0 0128 STQ R26, 192(SP)
B77E0000 012C STQ R27, (SP)
B7FE0008 0130 STQ R31, 8(SP)
B45E00C8 0134 STQ R2, 200(SP)
B47E00D0 0138 STQ R3, 208(SP)
B49E00D8 013C STQ R4, 216(SP)
B4BE00E0 0140 STQ R5, 224(SP)
B4DE00E8 0144 STQ R6, 232(SP)
B7BE00F0 0148 STQ FP, 240(SP)
63FF0000 014C TRAPB
47FE041D 0150 MOV SP, FP
47FB0402 0154 MOV R27, R2
47F00403 0158 MOV R16, R3
432059B0 015C CMPLT R25, 2, R16
B63E00B0 0160 STQ R17, 176(SP)
F600003A 0164 BNE R16, L$4
43205DB0 0168 CMPLE R25, 2, R16
2FFE0000 016C UNOP
E600003A 0170 BEQ R16, L$5
A63BFF90 0174 LDQ R17, -112(R27)
A75BFFA0 0178 LDQ R26, -96(R27)
221E0008 017C LDA R16, 8(SP)
47E05419 0180 MOV 2, R25
A762FFA8 0184 LDQ R27, -88(R2)
22310084 0188 LDA R17, 132(R17)
2FFE0000 018C UNOP
6B5A4000 0190 JSR R26, DBASIC$INIT
; R26, R26
A41D00B0 0194 LDQ R0, 176(FP)
; 000016
2C200000 0198 LDQ_U R1, (R0)
2E000003 019C LDQ_U R16, 3(R0)
482004C1 01A0 EXTLL R1, R0, R1
4A000D50 01A4 EXTLH R16, R0, R16
44300404 01A8 BIS R1, R16, R4
43E40004 01AC SEXTL R4, R4
47E03405 01B0 MOV 1, I
; 1, R5
EC800010 01B4 BLE R4, L$8
24DF010E 01B8 LDAH R6, 270(R31)
; 000017
20C60001 01BC LDA R6, 1(R6)
01C0 L$10:
A7420030 01C0 LDQ R26, 48(R2)
40481011 01C4 ADDL R2, 64, R17
47E30410 01C8 MOV R3, R16
225D00B8 01CC LDA R18, 184(FP)
B23D00BC 01D0 STL R17, 188(FP)
B0DD00B8 01D4 STL R6, 184(FP)
47E30411 01D8 MOV R3, R17
47E07419 01DC MOV 3, R25
A7620038 01E0 LDQ R27, 56(R2)
6B5A4000 01E4 JSR R26, STR$CONCAT
; R26, R26
40A03805 01E8 ADDL/V I, 1, I
; R5, 1, R5 ; 000018
40A40DA0 01EC CMPLE I, R4, R0
; R5, R4, R0
F41FFFF3 01F0 BNE R0, L$10
40A03925 01F4 SUBL/V I, 1, I
; R5, 1, R5
01F8 L$8:
; 000020
A742FFD0 01F8 LDQ R26, -48(R2)
221D0008 01FC LDA R16, 8(FP)
63FF0000 0200 TRAPB
47E03419 0204 MOV 1, R25
A762FFD8 0208 LDQ R27, -40(R2)
2FFE0000 020C UNOP
6B5A4000 0210 JSR R26, DBASIC$END
; R26, R26
63FF0000 0214 TRAPB
; 000012
47FD041E 0218 MOV FP, SP
A75D00C0 021C LDQ R26, 192(FP)
A45D00C8 0220 LDQ R2, 200(FP)
47E03400 0224 MOV 1, R0
; 000020
A47D00D0 0228 LDQ R3, 208(FP)
; 000012
A49D00D8 022C LDQ R4, 216(FP)
A4BD00E0 0230 LDQ R5, 224(FP)
A4DD00E8 0234 LDQ R6, 232(FP)
A7BD00F0 0238 LDQ FP, 240(FP)
23DE0100 023C LDA SP, 256(SP)
6BFA8001 0240 RET R26
2FFE0000 0244 UNOP
2FFE0000 0248 UNOP
2FFE0000 024C UNOP
0250 L$4:
; 000011
261F001B 0250 LDAH R16, 27(R31)
2210830C 0254 LDA R16, -31988(R16)
000000AA 0258 GENTRAP
025C L$5:
261F001B 025C LDAH R16, 27(R31)
221082CC 0260 LDA R16, -32052(R16)
000000AA 0264 GENTRAP

On Thu, 2023-04-13 at 08:43 -0400, Arne Vajhøj wrote:
> And given the huge interest here in speculating about anything
> VMS related, then we are just guessing on why Perl came before
> Python.

"I was here first!"
--
Tactical Nuclear Kittens