python / openvms

[John Tannahill]

I have written a lot of python for unix/linux platforms, but openvms is relatively new to me. My task is to convert a bunch of openvms dcl command procedures to python. I have python installed on our openvms system and can execute things just fine with "python doit.py". What I would like to do is execute the python script directly, with something like "@doit" or "@doit.py". It does not appear that there is an openvms equivalent to "#!/bin/env python"? Do I need to create a wrapper dcl script for each python script? I hope not. Does anyone have a solution for this?

Also, there does not appear to be any sort of path mechanism in openvms? If I were to put several python scripts in a single directory, how can I easily get the system to find these? Do I create a logical name for the directory and then create a symbol for each file like "doit LogicalName:doit"? Again I hope there is a better way.

Thanks,
John

[Craig A Berry · Accepted solution]

There is no shebang line as such, and setting the execute bit is purely a permissions setting and does not tell the OS "this is a runnable program."

As you've discovered, you can set up a so-called foreign command symbol like so:

$ doit :== "$python doit.py"

or you can set up DCL$PATH as documented here:

http://h71000.www7.hp.com/doc/731FINAL/6489/6489pro_033.html#index_x_1482

but that only works for .com and .exe files. You can probably have your Python scripts end with .com and make the first line something like:

$ python 'f$env("procedure")' "''p1'" "''p2'" "''p3'" "''p4'" "''p5'" "''p6'" "''p7'" "''p8'"

which will cause the DCL script to run itself as a Python script and pass through any parameters. It's a little more verbose than a shebang line, but will get you more or less the same thing.

[Hein van den Heuvel]

Note: Minor flame ahead, skip if soft skinned.

>> My task is to convert a bunch of openvms dcl command procedures to python.

That's likely to be very silly. I guess the salary is good enough to get you over any moral objections in this excercise in futility, but not good enough to educate the powers that be huh?

I would react the same for a Perl or C conversion , even though I use Perl a lot on OpenVMS myself... for newly written DCL scripts which issue very few commands and performance mostly string parsing and data manipulation.

But to convert supposedly working scripts?
What problem are they trying to fix?
"more maintainable by summer hires?"?
"make the system go faster"?

Don't get me wrong, DCL has been mis-used many time for tasks better done in Python, Perl, C or any other language.

But most DCL scripts, notably those issueing a lot of system commands like COPY, SUBMIT, CONVERT, F$FILE, F$GETJPI,...
are best left just so.
Now if the tasks are $OPEN/WRITE, $OPEN/READ, $RENAME, $DELETE, and simple file attributes, then a language with those functions will built in may well be a better choice.

fwiw,
Hein.

[John Tannahill]

Hein,

Our end game is to get off of OpenVMS, which means that DCL will no longer be available. With the end of the Alphas it seems like the time is right to move on (slowly). Also, at least at the national labs in the US, few if any developers have a desire to work on OpenVMS systems anymore.

John

[Hoff]

Do you have a plan and a schedule for getting off of OpenVMS established? All the work you do -- prior to a successful move off of OpenVMS -- is a waste of time and money. More than a few folks have started similar efforts, and haven't completed the port.

That is not intended to try to dissuade you from your plans nor from the port, merely to dissuade you from committing a common failure when seeking to port the code. A porting effort really works best if it's approached holistically and systematically. If you should find an unexpected and intractable dependency in your environment, you've got a budgetary and staffing and political problem; the folks that supervise these effort and the expenditures and the organization can get cranky about these surprises.

As for the language, Bash would seem a more direct analog to DCL for typical shell-oriented tasks, and that's available for both platforms. Most any Unix has bash. And most anything written in DCL tends to be a complete re-write; it's non-portable. (Rewriting DCL into Python that then uses and expects OpenVMS constructs or OpenVMS files or such is, well, going to involve a second port and a second pass.) (Though there is a bash shell available for OpenVMS, so you can use the existing DCL code and the new shell scripts while you're working on the port.)

I'd also tend to be looking at the shell scripts toward the end of the port, for instance. Applications and layered product dependencies can be more involved, though the source code is (somewhat) more likely to be portable and ported. DCL doesn't port all that well -- shell-level applications tend to be a re-architect and a rewrite.

For application scripting for general programming tasks as differentiated from Bash or DCL used for invoking system tasks and for command scripting, Python, php, perl and various of the other scripting languages can be good choices. Or if you're rewriting the DCL code, you might want to look at a compiled language.

Some of the available porting-related topics:
http://64.223.189.234/node/225
http://64.223.189.234/node/226
The first is a high-level overview of an off-platform port, while the second introduces porting to OpenVMS I64.

Stephen Hoffman
HoffmanLabs LLC

[John Tannahill]

Hoff,

This has been pretty well thought out, although I suspect there will be some bumps along the way. We have a two phase port.

First phase (on an Alpha running OpenVMS 7.3-2) is Dec Ada Compilation System (ACS) to GNAT Pro 83, modify Ada system calls as necessary, DEC Ada 83 to GNAT Pro 95 or 2005, OpenVMS 7.3-2 to 8.3, Alpha to Itanium. During this time we will also be working on DCL to Python.

Second phase is to complete the DCL to Python conversion, migrate OpenVMS to Linux/Unix, and port the networking software.

We plan on a complete re-write of the DCL scripts, and you are right in that there will have to be two passes, one on the OpenVMS system and one on the Linux/Unix system. Our target platform is the HP Integrity and we actually plan on delivering the system to at least one site at the end of the first phase.

At the end of the project we will be free of OpenVMS and much more platform independent.

Regards,
John

[John Tannahill]

No really good solution.