(go to: table of contents, index)
VMS and OpenVMS are two names for the same operating system. Originally,
the operating system was called VAX-11/VMS; it changed to VAX/VMS at
around VAX/VMS V2.0. When the VMS operating system was ported to the
Alpha platform, it was renamed OpenVMS, for both VAX and Alpha, in part
to signify the high degree of support for industry standards such as
POSIX, which provides many features of UNIX systems. An OpenVMS license
allows you to install and run POSIX for OpenVMS at no additional charge;
all you need is the media and documentation which can be found on the
Consolidated Distribution and On-Line Documentation CD-ROMs. For more
information on POSIX for VMS see question SOFT2.
What became confusing is that the OpenVMS name was introduced first
for OpenVMS AXP V1.0 causing the widespread misimpression that OpenVMS
was for Alpha AXP only, while "regular VMS" was for VAX. In fact, Digital
officially changed the name of the VAX operating system as of V5.5,
though the name did not start to be actually used in the product until
V6.0.
The proper names for OpenVMS on the two platforms are now "OpenVMS VAX"
and "OpenVMS Alpha", the latter having superseded "OpenVMS AXP".
(Conversion from PYVMS_NOTES.TXT which was last updated on 26-JAN-1998 ZE.)
Changes/additions since last release (PYVMS_970216) are marked with a vertical
bar ( ) in the leftmost column. Some information has been move from this file
to other, better suited places.
- compilers
- DEC C: tested on OpenVMS Alpha and VAX
OpenVMS VAX V6.1 + DEC C V5.0-003
OpenVMS Alpha V6.2-1H3 + DEC C 5.2-003
OpenVMS Alpha V7.1 + DEC C V5.6-003
- GNU C: my port for Python V1.3 did include 'support' for GCC
(on VAX)
This port does not contain any changes for files of the
original python distribution.
Files from my distribution contain artifacts for GCC 'support',
but they are NOT up to date!
I have tried to maintain the usage of shell$... vs decc$...
compatible for people who want to try GCC or VAX C.
- VAX C: no work done (has been replaced by DEC C anyway)
- C++ : I have not tried any C++ compiler
All DCC_*.COM procedures have been enhanced to allow compilation
of a single module. E.g.:
$ @DCC_VMS VMSMODULE
$ @DCC_MODULES IMAGEOP
All PCC_*.COM procedures have been enhanced as well.
Because PCC_VMS.COM must call DCC.COM and not all object files
are included they have become a bit messy... Watch out!
DCC_VMS.COM allows chaining to the link procedure - please check
the text inside this file.
- control-c handling
I _think_ this port uses the default handler of the C RTL with
SIGNALMODULE when running in the POSIX environment. Python for
DCL uses SMG$READ_COMPOSED_LINE.
- curses
cursesmodule does not compile with the VMS Versions (Alpha V6.2-1H3
and VAX V6.1) that I had available. I've thought about a port of
'ncurses' but it contains lots of UNIX specials and my time is
limited. Perhaps this works better with a new version of VMS (V7.0
and up) - there has been a lot of work for 'UNIX compatibility'.
Still nothing done.
- file names support
well, that's a problem...
VMS and UNIX filespecifications are quite different.
There is some experimental code in [.VMS]POSIXMODULE.C,
but I haven't come to a decision what to do. Lots of code uses UNIX
type filespecifications (e.g. "abc.def.ghi" or "/tmp/@test") which
cannot be handled directly in the DCL environment. It's even a
problem when running in the POSIX environment but the file should
be created in VMS' native file system.
28-MAY-1998 - an extension to the ODS-2 filesystem (named ODS-5) is
underway and planned for OpenVMS Alpha V7.2 which will have better
support for unix-like filenames.
OpenVMS Alpha V7.2 being delivered since JAN 1999 - no tests done, yet.
| Added interfaces for DECC$TO_VMS() and DECC$FROM_VMS() to the
| 'pyvms' module.
- file types, usage in this project
.OBJ = object module for DCL environment (DEC C)
.OLB = object library for DCL environment (DEC C)
.GBJ = object module for DCL environment (GNU C) ! not currently
.GLB = object library for DCL environment (GNU C) ! in use
.O = object module for POSIX environment
.A = object library for POSIX environment
- gettimeofday() is usually provided by vms__gettimeofday(),
(in VMS__GETTIMEOFDAY.C) because only very new versions of VMS +
DEC C have it implemented.
It's still not available in POSIX on VMS V7.1 / DECC V5.6.
- gmtime() is superceeded by vms__gmtime() (in VMS__GMTIME.C) which
should give a better emulation of gmtime() although it still returns
the current time. The routine in the C library just returns NULL
(meaning no support) which Python cannot cope with.
- installation
The current version of the VMS port is 'development/experimental'.
No code changes have been submitted back, yet.
On Unix, parts of the distribution tree are copied to other directories
(e.g. below /usr/local or other). I do feel very uncomfortable copying
files to SYS$LIBRARY:! Currently I keep everything in the [PYTHON...]
tree.
The module search path is calculated in [.MODULES]GETPATH.C -
perhaps one should create a VMS-specific version...
08-MAY-1998: some work has begun on VMS__GETPATH.C but is NOT finished.
- item codes
They are passed as strings. (e.g: vms_lib.getsyi("SYI$_VERSION",0))
to the function which looks up the numerical value. This version of
Python on VMS does no longer put names like 'SYI__VERSION' into the
dictionary of a module. Only bitmasks and constants remain (e.g.:
QUI_M_FILE_BURST in vms_quidef). Note that the '$' from QUI$ has
been replaced by an underscore ('_') because Python does not allow
dollars, right?
Item codes, bitmask definitions and constants are converted from a
.DAT file to Macro-source which is further translated to an object
module. These tables contain the VMS version which first provides
support for the item. The translation tables of 'C' have almost
been removed.
Access to this information is possible via the 'pyvms' module.
See 'the VMSDEF data structures' for details.
There are still some problems with the current format in the .DAT
file. Expect changes in a future version!
- octaword (128 bit) support
Since PYVMS V1.5.1 V001P7 the octaword support is provided by using
Python's "long integer" datatype.
- POSIX support
No attempt has been made to make any calls to RTL and system services
available for this environment, yet.
Unfortunately, POSIX for OpenVMS has been killed by DEC!
- quadword (64 bit) support
Since PYVMS V1.5.1 V001P3 the quadword support is provided by using
Python's "long integer" datatype.
Some work has been started to support OpenVMS Alpha V7.x features,
but *no* 64-bit adressing is used!
- rmdir() emulation in the DCL environment (via VMS__RMDIR.C)
It is not necessary on VMS (because you can just delete the name.DIR;1
file), but I have tried to mimic the behaviour of rmdir() as
implemented in VMS_POSIX. Please check VMS__RMDIR.C for details.
- sys module
- The module is imported from PYTHONSTARTUP.PY and the prompts are
changed for VMS style output when running under DCL.
- sys.executable (=argv[0])
This path is turned into Unix notation from PyVMS_init() when
running under DCL.
- TCL/TK
Some code contains references to TCL/TK. I did some tests with a
previous Python port and a (now) outdated version of TCL/TK. The
URL was: http://www.rsmas.miami.edu/vms-tcl.html
I don't have any newer information and haven't done any work with
Python V1.4 (or later) together with any version of TCL/TK.
28-MAY-1998 - I've got a report back from one person who has tried
the preview of V1.5.1 V001P1 with a newer port of TCL. Well, a
little test did succeed...
- threads
| VMS supports threads since version V5.5, but several procedures in
| the [.VMS] directory are very likely _NOT_ thread-save !!
| A small test to enable threading was done on 21-DEC-1998, but this
| is disabled by default - check CONFIG.H
- utime() emulation in the DCL environment (via VMS__UTIME.C). Of
course, the 'access time' cannot be changed because files in an
ODS-2 file system don't have such a thing.
- VMS vs OpenVMS
copied from the OpenVMS FAQ:
------------------------------------------------------------
VMS2. What is the difference between VMS and OpenVMS?
------------------------------------------------------------
- 'VMS objects'
No work has been done to create a 'process' object or a 'queue' object.
13-MAR-1999 - Objects have been create to be able to use RMS features,
see 'VMS Objects - list.
- [.VMS] directory tree structure
[.VMS] - additional code and support files
[.DEMO] - examples
[.DOC] - documentation about PYVMS
(and some support DCL files)
[.O_ALPHA] - object files for the Alpha architecture
[.O_VAX] - object files for the VAX architecture
DCC_*.LOG - created if DCC_name.COM is called from DCC-ALL.COM
DMACRO_*.LOG - created if DMACRO_name.COM is called from "
PCC_*.LOG - created if PCC_name.COM is called from PCC-ALL.COM
file.A - object library for POSIX environment
do not confuse them with the first file from a
VMSINSTAL kit which really is a BACKUP save-set
file.OLB - object library for dcl environment
[.MODULES] - object modules for directories parallel
[.OBJECTS] - " to [.VMS]
[.PARSER] - "
[.PYTHON] - "
[.VMS] - "
[.VMS_TOOLS] - object modules for files in [.VMS.TOOLS]
*.OBJ = compiled with DEC C for DCL
*.O = compiled with DEC C for POSIX
[.PATCHES] - all patches to Python that were available
when PYVMS was released
[.TEST] - files to test out functions of PYVMS
(currently only HTML2RNO)
[.TMP] - used while building of PYVMS
[.TOOLS] - some tools to maintain and build PYVMS