Python for OpenVMS -General Manual PAGE 1 title page __ | \ | | _ |__/ | | - / \ -O- | \ / \_/ \_/ | | ___ / / | \/ / | /\ |- ( )--| \/ / /\ | / / --- Copyright, 1996 - 2001 by Uwe Zessin ------------------------------------------------------------------------ Python for OpenVMS - General Manual July 2001 This manual contains all sorts of information including an introduction, instructions how to access the documentation, programming and necessary tools. Software Version: 2.1.1-V001 Uwe Zessin, Germany ------------------------------------------------------------------------ 27-JUL-2001 ZE. Python for OpenVMS -General Manual PAGE 2 the Python license 0.1 the Python license (copied from LICENSE.) A. HISTORY OF THE SOFTWARE ========================== Python was created in the early 1990s by Guido van Rossum at Stichting Mathematisch Centrum (CWI) in the Netherlands as a successor of a language called ABC. Guido is Python's principal author, although it includes many contributions from others. The last version released from CWI was Python 1.2. In 1995, Guido continued his work on Python at the Corporation for National Research Initiatives (CNRI) in Reston, Virginia where he released several versions of the software. Python 1.6 was the last of the versions released by CNRI. In 2000, Guido and the Python core development team moved to BeOpen.com to form the BeOpen PythonLabs team. Python 2.0 was the first and only release from BeOpen.com. Following the release of Python 1.6, and after Guido van Rossum left CNRI to work with commercial software developers, it became clear that the ability to use Python with software available under the GNU Public License (GPL) was very desirable. CNRI and the Free Software Foundation (FSF) interacted to develop enabling wording changes to the Python license. Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. Python 2.1 is a derivative work of Python 1.6.1, as well as of Python 2.0. After Python 2.0 was released by BeOpen.com, Guido van Rossum and the other PythonLabs developers joined Digital Creations. All intellectual property added from this point on, starting with Python 2.1 and its alpha and beta releases, is owned by the Python Software Foundation (PSF), a non-profit modeled after the Apache Software Foundation. See http://www.python.org/psf/ for more information about the PSF. Thanks to the many outside volunteers who have worked under Guido's direction to make these releases possible. B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON =============================================================== PSF LICENSE AGREEMENT --------------------- 1. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 2.1.1 software in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide Python for OpenVMS -General Manual PAGE 3 the Python license license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python 2.1.1 alone or in any derivative version, provided, however, that PSF's License Agreement and PSF's notice of copyright, i.e., "Copyright (c) 2001 Python Software Foundation; All Rights Reserved" are retained in Python 2.1.1 alone or in any derivative version prepared by Licensee. 3. In the event Licensee prepares a derivative work that is based on or incorporates Python 2.1.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python 2.1.1. 4. PSF is making Python 2.1.1 available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 2.1.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 2.1.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 2.1.1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between PSF and Licensee. This License Agreement does not grant permission to use PSF trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By copying, installing or otherwise using Python 2.1.1, Licensee agrees to be bound by the terms and conditions of this License Agreement. BEOPEN.COM TERMS AND CONDITIONS FOR PYTHON 2.0 ---------------------------------------------- BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1 1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization ("Licensee") accessing and otherwise using this software in source or binary form and its associated documentation ("the Software"). 2. Subject to the terms and conditions of this BeOpen Python License Agreement, BeOpen hereby grants Licensee a non-exclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and Python for OpenVMS -General Manual PAGE 4 the Python license otherwise use the Software alone or in any derivative version, provided, however, that the BeOpen Python License is retained in the Software, alone or in any derivative version prepared by Licensee. 3. BeOpen is making the Software available to Licensee on an "AS IS" basis. BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 5. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 6. This License Agreement shall be governed by and interpreted in all respects by the law of the State of California, excluding conflict of law provisions. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between BeOpen and Licensee. This License Agreement does not grant permission to use BeOpen trademarks or trade names in a trademark sense to endorse or promote products or services of Licensee, or any third party. As an exception, the "BeOpen Python" logos available at http://www.pythonlabs.com/logos.html may be used according to the permissions granted on that web page. 7. By copying, installing or otherwise using the software, Licensee agrees to be bound by the terms and conditions of this License Agreement. CNRI OPEN SOURCE GPL-COMPATIBLE LICENSE AGREEMENT ------------------------------------------------- 1. This LICENSE AGREEMENT is between the Corporation for National Research Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191 ("CNRI"), and the Individual or Organization ("Licensee") accessing and otherwise using Python 1.6.1 software in source or binary form and its associated documentation. 2. Subject to the terms and conditions of this License Agreement, CNRI hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python 1.6.1 alone or in any derivative version, provided, however, that CNRI's License Agreement and CNRI's notice of copyright, i.e., "Copyright (c) 1995-2001 Corporation for National Research Initiatives; All Rights Reserved" are retained in Python 1.6.1 alone or in any derivative version prepared by Licensee. Alternately, in lieu of CNRI's License Agreement, Licensee may substitute the following text (omitting the Python for OpenVMS -General Manual PAGE 5 the Python license quotes): "Python 1.6.1 is made available subject to the terms and conditions in CNRI's License Agreement. This Agreement together with Python 1.6.1 may be located on the Internet using the following unique, persistent identifier (known as a handle): 1895.22/1013. This Agreement may also be obtained from a proxy server on the Internet using the following URL: http://hdl.handle.net/1895.22/1013". 3. In the event Licensee prepares a derivative work that is based on or incorporates Python 1.6.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python 1.6.1. 4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS" basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT INFRINGE ANY THIRD PARTY RIGHTS. 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON 1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 6. This License Agreement will automatically terminate upon a material breach of its terms and conditions. 7. This License Agreement shall be governed by the federal intellectual property law of the United States, including without limitation the federal copyright law, and, to the extent such U.S. federal law does not apply, by the law of the Commonwealth of Virginia, excluding Virginia's conflict of law provisions. Notwithstanding the foregoing, with regard to derivative works based on Python 1.6.1 that incorporate non-separable material that was previously distributed under the GNU General Public License (GPL), the law of the Commonwealth of Virginia shall govern this License Agreement only as to issues arising under or with respect to Paragraphs 4, 5, and 7 of this License Agreement. Nothing in this License Agreement shall be deemed to create any relationship of agency, partnership, or joint venture between CNRI and Licensee. This License Agreement does not grant permission to use CNRI trademarks or trade name in a trademark sense to endorse or promote products or services of Licensee, or any third party. 8. By clicking on the "ACCEPT" button where indicated, or by copying, installing or otherwise using Python 1.6.1, Licensee agrees to be bound by the terms and conditions of this License Agreement. ACCEPT CWI PERMISSIONS STATEMENT AND DISCLAIMER Python for OpenVMS -General Manual PAGE 6 the Python license ---------------------------------------- Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The Netherlands. All rights reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Stichting Mathematisch Centrum or CWI not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ------------------------------------------------------------------------ 22-JUL-2001 ZE. Python for OpenVMS -General Manual PAGE 7 the Python for OpenVMS license 0.2 the Python for OpenVMS license Copyright 1996-2001, by Uwe Zessin This software is provided to you free of charge. Use at your own risk - if it doesn't work, I disclaim all responsibility. This software may be freely distributed as long as it is accompanied by the copyright notice. If you change this software, you may re-distribute it only if you keep the original notes AND an additional notice identifying you and indicating that you have changed it. ------------------------------------------------------------------------ I have found this wording somewhere on the Internet and liked it. Unfortunately I haven't noted the author's name so I cannot give credit. ------------------------------------------------------------------------ 22-JUL-2001 ZE. Python for OpenVMS -General Manual PAGE 8 table of contents CONTENTS 0.1 the Python license . . . . . . . . . . . . . . . . 2 0.2 the Python for OpenVMS license . . . . . . . . . . 7 CHAPTER 1 Introduction 1.1 Welcome . . . . . . . . . . . . . . . . . . . . . 1-1 1.2 Version numbers / file names . . . . . . . . . . . 1-3 CHAPTER 2 Documentation 2.1 access to the Python for OpenVMS documentation . . 2-1 2.2 conventions used in the documentation . . . . . . 2-3 CHAPTER 3 Patches 3.1 Patches to OpenVMS . . . . . . . . . . . . . . . . 3-1 3.1.1 Patches are available from: . . . . . . . . . . 3-1 3.1.2 Patches for OpenVMS Alpha . . . . . . . . . . . 3-1 3.1.2.1 Version 6.2-1H3 . . . . . . . . . . . . . . . . 3-1 3.1.2.2 Version 7.2-1 . . . . . . . . . . . . . . . . . 3-1 3.1.3 Patches for OpenVMS VAX . . . . . . . . . . . . 3-2 3.1.3.1 version 6.1 . . . . . . . . . . . . . . . . . . 3-2 3.1.3.2 version 6.2 . . . . . . . . . . . . . . . . . . 3-2 3.2 Patches to Python . . . . . . . . . . . . . . . . 3-3 CHAPTER 4 Python in the OpenVMS environment 4.1 initialization file . . . . . . . . . . . . . . . 4-1 4.2 path support . . . . . . . . . . . . . . . . . . . 4-1 4.3 command line editing . . . . . . . . . . . . . . . 4-3 4.4 dynamic loading . . . . . . . . . . . . . . . . . 4-4 4.5 embedding Python on OpenVMS . . . . . . . . . . . 4-4 CHAPTER 5 programming guidelines 5.1 file I/O . . . . . . . . . . . . . . . . . . . . . 5-1 5.1.1 record lengths . . . . . . . . . . . . . . . . . 5-1 5.2 floating point . . . . . . . . . . . . . . . . . . 5-2 5.3 functions . . . . . . . . . . . . . . . . . . . . 5-3 5.3.1 arguments . . . . . . . . . . . . . . . . . . . 5-3 5.3.2 keyword arguments . . . . . . . . . . . . . . . 5-3 5.3.3 functions returning no data . . . . . . . . . . 5-3 5.3.4 functions returning dictionaries . . . . . . . . 5-3 5.4 OpenVMS condition values . . . . . . . . . . . . . 5-4 5.5 special OpenVMS datatypes . . . . . . . . . . . . 5-5 5.5.1 64-bit quadword . . . . . . . . . . . . . . . . 5-5 5.5.1.1 date and time calculations . . . . . . . . . . . 5-6 Python for OpenVMS -General Manual PAGE 9 table of contents 5.5.2 128-bit octaword . . . . . . . . . . . . . . . . 5-7 5.6 processes . . . . . . . . . . . . . . . . . . . . 5-7 5.6.1 privileges . . . . . . . . . . . . . . . . . . . 5-8 5.6.2 process identification (PID) . . . . . . . . . . 5-9 5.7 RMS . . . . . . . . . . . . . . . . . . . . . . 5-10 5.8 security related objects . . . . . . . . . . . . 5-10 5.8.1 ACL + ACE . . . . . . . . . . . . . . . . . . 5-10 5.8.2 rightslist identifiers . . . . . . . . . . . . 5-11 CHAPTER 6 configuration guidelines 6.1 Introduction . . . . . . . . . . . . . . . . . . . 6-1 6.2 components . . . . . . . . . . . . . . . . . . . . 6-1 6.3 builtin modules . . . . . . . . . . . . . . . . . 6-2 6.3.1 format of CONFIG.DAT . . . . . . . . . . . . . . 6-3 6.4 module methods . . . . . . . . . . . . . . . . . . 6-4 6.4.1 format of mod__METHODS.DAT . . . . . . . . . . . 6-5 CHAPTER 7 embedding the Python interpreter CHAPTER 8 changes to Python modules 8.1 compileall.py . . . . . . . . . . . . . . . . . . 8-1 8.2 getpass.py . . . . . . . . . . . . . . . . . . . . 8-2 8.3 site.py . . . . . . . . . . . . . . . . . . . . . 8-2 8.4 tempfile.py . . . . . . . . . . . . . . . . . . . 8-2 8.5 test_bufio.py . . . . . . . . . . . . . . . . . . 8-3 8.6 test_import.py . . . . . . . . . . . . . . . . . . 8-3 8.7 test_rgbimg.py . . . . . . . . . . . . . . . . . . 8-4 8.8 test_sax.py . . . . . . . . . . . . . . . . . . . 8-4 8.9 test_signal.py . . . . . . . . . . . . . . . . . . 8-4 8.10 test_support.py . . . . . . . . . . . . . . . . . 8-4 8.11 user.py . . . . . . . . . . . . . . . . . . . . . 8-4 CHAPTER 9 changes to Python source 9.1 exceptions.c . . . . . . . . . . . . . . . . . . . 9-1 9.2 fcntlmodule.c . . . . . . . . . . . . . . . . . . 9-1 9.3 fileobject.c . . . . . . . . . . . . . . . . . . . 9-2 9.4 import.c . . . . . . . . . . . . . . . . . . . . . 9-2 9.5 main.c . . . . . . . . . . . . . . . . . . . . . . 9-2 9.6 marshal.h . . . . . . . . . . . . . . . . . . . . 9-2 9.7 pyerrors.h . . . . . . . . . . . . . . . . . . . . 9-2 9.8 python.c . . . . . . . . . . . . . . . . . . . . . 9-2 9.9 selectmodule.c . . . . . . . . . . . . . . . . . . 9-2 9.10 signalmodule.c . . . . . . . . . . . . . . . . . . 9-3 9.11 socketmodule.c . . . . . . . . . . . . . . . . . . 9-3 9.12 stringobject.c . . . . . . . . . . . . . . . . . . 9-3 9.13 timemodule.c . . . . . . . . . . . . . . . . . . . 9-3 9.14 timing.h . . . . . . . . . . . . . . . . . . . . . 9-3 Python for OpenVMS -General Manual PAGE 10 table of contents 9.15 _localemodule.c . . . . . . . . . . . . . . . . . 9-4 CHAPTER 10 Tools 10.1 coming with Python for OpenVMS . . . . . . . . . 10-1 10.1.1 BLDRUN - compile modules . . . . . . . . . . . 10-1 10.1.1.1 usage . . . . . . . . . . . . . . . . . . . . 10-1 10.1.1.2 examples: . . . . . . . . . . . . . . . . . . 10-1 10.1.1.3 internals . . . . . . . . . . . . . . . . . . 10-2 10.1.2 CVT_DOC - convert .HTML to final docu formats 10-2 10.1.3 CVT__HTML - convert .HTML to .RNO . . . . . . 10-3 10.1.4 CVT__RNO - convert .RNO to final docu . . . . 10-5 10.1.5 FILE2URL - convert filespec to file: URL . . . 10-6 10.1.6 FILE_SET_DATE - alter CDT and RDT . . . . . . 10-6 10.1.7 HTML2RNO.PY - convert .HTML to .RNO . . . . . 10-7 10.1.8 UNTAR2DATESET - create procedure to change dates . . . . . . . . . . . . . . . . . . . . 10-10 10.1.9 VMSDEF2MAR - convert a VMSDEF .DAT file to macro . . . . . . . . . . . . . . . . . . . . 10-11 10.1.10 VMSDEF_BLDDIR2MAR - build VMSDEF directory . . 10-12 10.1.11 VMSVER2MAR - build VMS version table . . . . . 10-13 10.2 not delivered with Python for VMS . . . . . . . 10-14 10.2.1 GZIP - (de)compress files to/from archive . . 10-14 10.2.2 UNZIP - decompress files from archive . . . . 10-15 10.2.3 VMSTAR - maintain TapeARchive file . . . . . . 10-15 CHAPTER 11 The history of Python for OpenVMS 11.1 reason for this chapter . . . . . . . . . . . . 11-1 11.2 first contact + Python V1.3 . . . . . . . . . . 11-1 11.3 Python V1.4 . . . . . . . . . . . . . . . . . . 11-1 11.4 Python V1.5 . . . . . . . . . . . . . . . . . . 11-2 11.5 Python V1.5.1 . . . . . . . . . . . . . . . . . 11-2 11.6 Python V1.5.2 . . . . . . . . . . . . . . . . . 11-3 11.7 Python V1.6 . . . . . . . . . . . . . . . . . . 11-4 11.8 Python V2.0 . . . . . . . . . . . . . . . . . . 11-4 11.9 Python V2.1 . . . . . . . . . . . . . . . . . . 11-4 11.10 Python V2.1.1 . . . . . . . . . . . . . . . . . 11-4 CHAPTER 12 The future of Python for OpenVMS CHAPTER 13 Notes 13.1 Python for OpenVMS - notes . . . . . . . . . . . 13-1 13.2 the VMSDEF data structures . . . . . . . . . . . 13-5 INDEX INDEX-1 CHAPTER 1 Introduction __ | \ | | _ |__/ | | - / \ -O- | \ / \_/ \_/ | | ___ / / | \/ / | /\ |- ( )--| \/ / /\ | / / --- 1.1 Welcome Welcome to the Python programming language running on the OpenVMS operating system. This is the '*General Manual*'. It contains all sorts of information. Other documentation is in the 'Installation Manual', the 'Reference Manual' and the 'Demoes Manual'. ------------------------------------------------------------------------ For information about Python, please refer to its homepage at: - http://www.python.org/ Information about the OpenVMS operating system can be found at: - http://www.openvms.compaq.com/ ------------------------------------------------------------------------ Please note: This text is/was originally written in HTML format so it can be viewed with a browser. The '.HTML' files are also converted by a tool named Python for OpenVMS -General Manual PAGE 1-2 Introduction HTML2RNO to '.RNO' files. Those are then processed by the RUNOFF text-formatter (which comes with the OpenVMS operating system) to produce '.MEM' or '.LNI' files which can be printed. So, some things may look strange when this documentation is viewed with a browser or read as a text file, but now you know why. ------------------------------------------------------------------------ Python for OpenVMS has been configured with as much builtin modules as possible. Here is a list as of 10-JUL-2001: >>> print sys.builtin_module_names ('__builtin__', '__main__', '_codecs', '_socket', '_sre', '_symtable', '_testcapi', '_weakref', 'array', 'audioop', 'binascii', 'cPickle', 'cStringIO', 'cmath', 'errno', 'exceptions','gc', 'imageop', 'imp', 'marshal', 'math', 'md5', 'new', 'operator', 'parser', 'pcre', 'posix', 'pyvms', 'regex', 'rgbimg', 'rotor', 'select', 'sha', 'signal', 'strop', 'struct', 'sys', 'thread', 'time', 'timing', 'unicodedata', 'vms__struct', 'vms_brkdef', 'vms_ciadef', 'vms_clidef', 'vms_dcdef', 'vms_dmtdef', 'vms_dvidef', 'vms_fabdef', 'vms_fscndef', 'vms_impdef', 'vms_initdef', 'vms_jpidef', 'vms_kgbdef', 'vms_lbr', 'vms_lbrdef', 'vms_lckdef', 'vms_lib', 'vms_libdtdef', 'vms_lnmdef', 'vms_mail', 'vms_maildef', 'vms_mntdef', 'vms_namdef', 'vms_ossdef', 'vms_prcdef', 'vms_prvdef', 'vms_pscandef', 'vms_quidef', 'vms_rabdef', 'vms_rsdmdef', 'vms_sjcdef', 'vms_smg', 'vms_smgdef', 'vms_statedef', 'vms_sys', 'vms_trmdef', 'vms_uaidef', 'vms_xaballdef', 'vms_xabfhcdef', 'vms_xabitmdef', 'vms_xabkeydef', 'vms_xabprodef', 'xreadlines') Beginning with version 1.5.2-V005 the 'vms_lbr' and the 'vms_mail' modules are no longer enabled by default - see 'configuration: builtin modules' for how to re-enable them if wanted. Beginning with version 1.5.2-V007 the 'vms_smg' module exists, but is not enabled by default. The 'Installation Manual' describes how to add those components. ------------------------------------------------------------------------ Python for OpenVMS consists of the following elements: - the original Python distribution stored in the directory tree [PYTHON.PYTHON2_1_1...] - some files that have been changed for OpenVMS e.g. [.MODULES]TIMEMODULE.C - files that implement the interfaces to OpenVMS routines (e.g. VMS_LIB.C). Take a look in the 'reference manual' under 'modules'. - additional files that implement / provide enhanced functionality that is not available on (some versions of) OpenVMS (e.g. utime() ). Python for OpenVMS -General Manual PAGE 1-3 Introduction - a number of data files that describe OpenVMS version-related information, item codes, bitmasks and constants (VMSD*.DAT) - command procedures to ease translation (e. g. VMSDEF related data files) and compilation - examples and documentation I have tried to keep the original directory tree unchanged as much as possible. Additional files are located in the [.VMS...] sub-tree. No changes have been sent back to have them included into the original source. 1.2 Version numbers / file names The current release of Python for OpenVMS is version 2.1.1-V001. The filename layout is as follows: PYTHON2_1_1-V001typ.ZIP An OpenVMS specific file. That looks like: 2_1_1 based on Python version 2.1.1 V001 OpenVMS port - version 1, full kit. It will be incremented for each new release. If the Python version increments (e.g. to 2.2) then the version number of the next OpenVMS port will reset to V001 again. An update kit's version looks like: V001U4 a kit that contains updates from version 001 (including 002 and 003) to 004. typ Type of the kit: SRC The Python for OpenVMS source kit. Documentation in HTML format is included. You can first build Python and then convert the HTML to other formats - see chapter 'installing and building' in the 'Installation Manual'. DOC This file contains pre-build Python for OpenVMS documentation. A documentation kit (the ".TLB" file) is Python for OpenVMS -General Manual PAGE 1-4 Introduction always complete. OBJ_arch This file contains precompiled objects code. arch can be 'ALPHA' or 'VAX'. Download sources are listed in the Installation Manual. ------------------------------------------------------------------------ As of 10-JUL-2001 'Python for OpenVMS' is still a 'hobby' project of mine (Uwe Zessin) which I do for my own pleasure in my spare time. ------------------------------------------------------------------------ 22-JUL-2001 ZE. CHAPTER 2 Documentation 2.1 access to the Python for OpenVMS documentation Documentation about Python for OpenVMS is available in a number of formats. This chapter describes various methods to access them. ------------------------------------------------------------------------ The original source is written as a number of '.HTML' files which you can find in the [.VMS.DOC...] subdirectory tree of the Python for OpenVMS source kit. You have several options to access them: - If you run a web-server yourself, then you can include the files there. You only need to extract all '.HTML' and '.JPG' files from the [.VMS.DOC] subdirectory. As of 15-JUL-2001 I am aware of the following 3 HTTP servers, which run on the OpenVMS operating system: o the 'OSU DECthreads HTTP server' is available at: http://www.er6.eng.ohio-state.edu/www/doc/serverinfo.html o the 'WASD HTTP Server Package' is available at: http://wasd.vsm.com.au/ o the 'Compaq secure web server' (CSWS) is available at: http://www.openvms.compaq.com/openvms/products/ ips/apache/csws.html - You can access the files directly from your web-browser like: $! define a foreign command $ NETSCAPE == "$disk:[directory]NETSCAPE.EXE" $ NETSCAPE - file://localhost/DSA3/PYTHON/PYTHON2_1_1/VMS/DOC/DOCU.HTML The procedure PYTHON_TOOLS:FILE2URL.COM eases this task. ------------------------------------------------------------------------ Python for OpenVMS -General Manual PAGE 2-2 access to the Python for OpenVMS documentation As of 15-JUL-2001 I am aware of the following browsers, which are available for the OpenVMS operating system: - NETSCAPE for OpenVMS is available from Compaq Computer Corporation and can be used if you have a valid DECwindows/ Motif license. It is part of the 'Internet Product Suite for OpenVMS'. The URL is: http://www.openvms.compaq.com/openvms/internetworks/ - MOZILLA for OpenVMS is currently under development. Is is available from: http://www.openvms.compaq.com/openvms/products/ ips/register_mozilla.html - LYNX is a text-only browser that allows reading the '.HTML' files from an ASCII terminal. Please start from: http://lynx.browser.org/ You won't be able to see example pictures for interfaces of the 'vms_smg' modules. - MOSAIC is included with some versions of DECwindows /Motif. Different versions of MOSAIC are also available from other sources, but I do not have any information. ------------------------------------------------------------------------ I have created a simple converter (written in Python) named HTML2RNO that is able to convert the '.HTML' files into RUNOFF format ('.RNO' files). RUNOFF, also known as DSR - Digital Standard Runoff, is a text-formatter that is supplied with the OpenVMS operating system. It converts the '.RNO' files to a '.MEM' file for line-printer output or a '.LNI' file for printers understanding ANSI format. I have not tried to include much '.test page nn' hints into the '.HTML' files to help RUNOFF make a better looking documentation - the page breaks are sometimes located at very 'unfortunate' positions... A simple set of EDT commands converts the '.MEM' file to a '.TXT' file which is for reading the text with a text editor. They just delete the '' sequences and remove any lines for bold printing. The file TXT.FDL is used to change the record attributes of the '.TXT' files. ------------------------------------------------------------------------ 22-JUL-2001 ZE. Python for OpenVMS -General Manual PAGE 2-3 conventions used in the documentation 2.2 conventions used in the documentation The documentation of Python for OpenVMS uses a number of conventions: The printed documentation (files '*.MEM' and '*.LNI') contain a table of contents and an index that are generated by RUNOFF. Some lines (commands or output messages) which are too long for a single line are manually wrapped. This is indicated by a trailing backslash (). Here is an example: UAF> add /identifier ID_1 /attributes=resource %UAF-I-RDBADDMSG, identifier ID_1 value %X80010011 added to rights\ database ^ | The HTML version which you can read with a browser has both a simple table of contents and an index, which are manually maintained. ------------------------------------------------------------------------ You very likely have found out already that the documention is scattered with lots of dates. They indicate the last time a specific chapter, page, or paragraph has been modified or a specific sentence stating a fact has been checked. ------------------------------------------------------------------------ If you read the documentation from a browser you will see that some pages have LOTS of hypertext links. They should help you to easily switch between the information. ------------------------------------------------------------------------ Places where information is missing or perhaps incorrect are marked with '@@'. ------------------------------------------------------------------------ 08-FEB-1999 ZE. CHAPTER 3 Patches 3.1 Patches to OpenVMS This section describes which Patches to OpenVMS might have to be applied. 3.1.1 Patches are available from: - http://www.support.compaq.com/patches/ Beginning with Python for OpenVMS version 2.1.1-V001 the main development is on OpenVMS VAX V6.2 and OpenVMS Alpha V6.2-1H3 - no tests on older versions will be done. 3.1.2 Patches for OpenVMS Alpha 3.1.2.1 Version 6.2-1H3 @@ No list compiled for now. 3.1.2.2 Version 7.2-1 VMS721_UPDATE Python interface routines to OpenVMS services do only ensure that a string is small enough to fit in a string descriptor. The actual string length that the service accepts is usually much shorter. There is a length check problem on OpenVMS Alpha V7.2 and V7.2-1 where a non-privileged user can crash the operating system. You should install the appropriate patch. Python for OpenVMS -General Manual PAGE 3-2 patches to Python and OpenVMS 3.1.3 Patches for OpenVMS VAX 3.1.3.1 version 6.1 VAXACRT11_061 There is a bug in some versions of the C RTL. The value of the environment name "TERM", obtained by calling the getenv function, can return a wrong value like this: >>> import posix >>> print posix.environ['USER'] ZESSIN >>> print posix.environ['TERM'] USER=ZESSIN >>> This is supposed to be fixed in the VAXACRT01_061 (and later) kits. I had installed VAXACRT11_061 which applies to OpenVMS VAX Versions: V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1 and the bug has disappeared. >>> import posix >>> print posix.environ['TERM'] vt300-80 >>> Relinking of Python was _not_ necessary. Please check your environment. It looks OK on OpenVMS Alpha V6.2-1H3 + V7.1, but there are patches (named ALPACRTxx_xxx) for these DEC C RTL versions available, too. 3.1.3.2 version 6.2 The following ECOs have been installed on the development system: VAXCLUSIO01_062, VAXCMAR04_062, VAXCRTL11_062, VAXY2K02_062, VMS62TO71_PCSI-V0200 The 'test_thread' part, however, still hangs during execution. A workaround is to issue a series of rapid calls to vms_sys.wake() from another process while pressing on the testing process' screen. This error has not been reported to OpenVMS engineering - the development system is a hobbyist system without maintenance. Python for OpenVMS -General Manual PAGE 3-3 patches to Python and OpenVMS 3.2 Patches to Python No patches to the Python interpreter are available. Changes to adapt Python to OpenVMS are documented in 'changes to Python modules' and 'changes to Python source'. ------------------------------------------------------------------------ 05-JUL-2001 ZE. CHAPTER 4 Python in the OpenVMS environment This section explains how Python works in the OpenVMS environment. See also the 'programming guidelines' chapter. 4.1 initialization file Python does not run any user-specific code during startup. If a script wants to do that it uses the code in 'user.py': >>> import user Usually, it looks for the file '.pythonrc.py' in the user's login directory. For OpenVMS, this has been changed to 'pythonrc.py' The 'system-wide' procedure is 'PYTHONSTARTUP.PY'. This is controlled by defining the symbol 'PYTHONSTARTUP' in procedure 'SETUP.COM'. 4.2 path support The 'sys' module contains a list named 'path' that is used to locate files from the library. Beginning with Python for OpenVMS V2.1-V001 the PREFIX and EXEC_PREFIX mechanism is implemented on OpenVMS. Please note that the dot ('.') from 'sys.version' is replaced by an underscore ('_') (e.g. '2.1' -> '2_1') to work around a limitation of the ODS-2 file system (no multiple dots in a filename). PREFIX This directory tree contains the platform independent common '.py' and '.pyc' files. Python for OpenVMS -General Manual PAGE 4-2 Python in the OpenVMS environment There are two logical names that are defined by the SETUP.COM procedure: PYTHON_PREFIX_P The equivalence string uses the Posix filename notation like: "/python_disk/python/prefix2_1_1" PYTHON_PREFIX_V The equivalence string uses the DCL filename notation like: "PYTHON_DISK:[PYTHON.PREFIX2_1_1]" EXEC_PREFIX This directory tree contains the platform dependent files - so called shared library modules, which are similar to OpenVMS' shareable images. They are used to dynamically loaded additional modules. There is currently (04-JUL-2001) no support for 'dynamic loading'. On OpenVMS, however, this directory contains configuration-dependent data (MACRO source, options files, the objects, LINKer maps and the executables). There are two logical names that are defined by the SETUP.COM procedure: PYTHON_EXEC_PREFIX_P The equivalence string uses the Posix filename notation like: "/python_disk/python/exec_prefix2_1_1/vax_dddt" PYTHON_EXEC_PREFIX_V The equivalence string uses the DCL filename notation like: "PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT]" Python for OpenVMS -General Manual PAGE 4-3 Python in the OpenVMS environment There should be a DCL procedure in this directory (named "CONFIG_SHOW.COM") to translate the configuration that is encoded in the directory name: $ @ PYTHON_EXEC_PREFIX_V:CONFIG_SHOW.COM configuration for directory: [PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT] Architecture.........: VAX Debug compile........: yes Environment..........: DCL Floating point format: VAX D_Floating Thread support.......: yes $ CONFIG_SHOW.COM is copied to PYTHON_EXEC_PREFIX_V whenever SETUP.COM is run and cannot find it there. This will result in a path that looks similar to: >>> import sys >>> for p in sys.path: ... print p ... /python_disk/python/python2_1_1/vms/tools /python_disk/python/site-packages /python_disk/python/prefix2_1_1/lib/python2_1 /dsa3/python/exec_prefix2_1/vax_dddt/lib/python2_1/lib-dynload /python_disk/python/prefix2_1_1/lib/python2_1/site-packages >>> ------------------------------------------------------------------------ @@ explain PYTHONPATH defined by SETUP.COM ... $ show symbol PYTHONPATH PYTHONPATH == "/python_disk/python/python2_1_1/vms/tools: /python_disk/python/site-packages" ------------------------------------------------------------------------ 4.3 command line editing The DCL environment uses an enhanced readline function located in PYVMS_READLINE.C that uses the SMG$ routines for editing and command history. Module 'pyvms' allows access to the readline history. Note: this means that the shareable image SMGSHR.EXE is always linked to the interpreter, even if the 'vms_smg' module is not configured. ------------------------------------------------------------------------ Python for OpenVMS -General Manual PAGE 4-4 Python in the OpenVMS environment 4.4 dynamic loading On a Unix operation system this means, quoted from: ftp://ftp.cwi.nl/pub/dynload/dl.txt 'Dynamic loading: adding object code to the text segment of a running process, with the purpose -- usually -- of executing instructions from it' ... On OpenVMS it is not possible to load object code this way. One might, instead, put a module in a shareable image. The interpreter, however is not linked against it, so it is not loaded at startup. The shareable image is only activated when the module is being imported. 17-NOV-1999 Some work has been done, but it did not made it into version 1.5.2-V006. I don't believe that makes much sense unless the module is _very_ big and not used often. The minimum page size of an Alpha processor is at least 8 KBytes and I think you would need at least several pages if you map a shareable image via LIB$FIND_IMAGE_SYMBOL() Note: module 'vms_lib' provides an interface to LIB$FIND_IMAGE_SYMBOL() to look up a symbol value in a shareable image, but there is currently (17-NOV-1999) no way to call a routine in this image. ------------------------------------------------------------------------ 4.5 embedding Python on OpenVMS Some comments in an earlier version of this manual raised some confusion. The idea was to put all routines in a shareable image to save space if multiple variants were build. As mentioned above, some experiments have been done, but it's not ready for release. There is nothing in the implementation that tries to prevent embedding. See the 'embedding the Python interpreter' chapter for a simple demo. ------------------------------------------------------------------------ 24-JUN-2001 ZE. CHAPTER 5 programming guidelines This section gives some guidelines how to use the programming interface to OpenVMS routines. 5.1 file I/O You should also take a look at the RMS section below. 5.1.1 record lengths The DEC C RTL (or at least some versions) set the LRL (longest record length) field of a file to the maximum value (32767). This can cause problems with other applications (e.g. SORT). There a two possibilities to attack the problem from the Python side: - via DEC C RTL Recent ECOs allow the programmer to set the logical name "DECC$DEFAULT_LRL". >>> fo = open ('TEST1.TMP', 'w') >>> fo.write ('data') >>> fo.close() $ write SYS$OUTPUT F$FILE_ATTRIBUTES ("TEST1.TMP", "LRL") 32767 $ $ define DECC$DEFAULT_LRL 49 >>> fo = open ('TEST2.TMP', 'w') >>> fo.write ('data') >>> fo.close() $ write SYS$OUTPUT F$FILE_ATTRIBUTES ("TEST2.TMP", "LRL") 49 $ Python for OpenVMS -General Manual PAGE 5-2 programming guidelines $ deassign DECC$DEFAULT_LRL Note that this affects ALL files created through the DEC C RTL. - use a special interface to the DEC C RTL open() routine and pass an RMS option. Note that this returns a file descriptor number, not a file object! >>> import os, pyvms >>> >>> # O_TRUNC requests a NEW version of the file to be created ! >>> flags = os.O_CREAT + os.O_TRUNC + os.O_WRONLY >>> >>> fd = pyvms.crtl_open ('TEST3.TMP', flags, 0777, ('mrs=53',)) >>> >>> import os >>> os.write (fd, 'data') >>> os.close (fd) $ write SYS$OUTPUT F$FILE_ATTRIBUTES ("TEST3.TMP", "LRL") 53 $ Beginning with version 1.5.2-V007 there is also pyvms.file_open() available, which does return a file object. >>> import pyvms >>> >>> fo = pyvms.file_open ('TEST4.TMP', 'w', 1, ('mrs=54',)) >>> >>> fo.write ('data') >>> fo.close () $ write SYS$OUTPUT F$FILE_ATTRIBUTES ("TEST4.TMP", "LRL") 54 $ 5.2 floating point Beginning with Python for OpenVMS version 2.1-V001 the default floating point format on OpenVMS Alpha is T_float (IEEE format) - on OpenVMS VAX it is still D_float. T_float and D_float have different internal formats and ranges. Outputs can vary and calculations that succeeded on one platform can fail on the other. @@@ add more text. Python for OpenVMS -General Manual PAGE 5-3 programming guidelines 5.3 functions 5.3.1 arguments Some functions (e. g.: vms_lib.currency) do not have any arguments. If you provide any, then the programming interface WILL raise a Python exception. The redundant argument is not silently ignored! Some arguments of a function might not be required in a specific situation. As keyword arguments are not implemented you have to use 'None' as a placeholder instead - internally this will be changed to '0 passed by value'. See the examples of vms_lib.day() or vms_lib.getdvi() to get an idea. OpenVMS system services usually require ALL arguments be specified. The Python interface routines usually substitute 'None' with '0 passed by value' to indicate an omitted argument. They also allow trailing 'unused' arguments to be omitted. 5.3.2 keyword arguments e.g.: >>> ret = routine (p1 = val1) are not supported for OpenVMS interface routines. 5.3.3 functions returning no data Some routines do not need to return any 'data' - e.g. vms_lib.attach() returns 'None' upon successful completion. If an error happens, they will still raise a Python exception. 5.3.4 functions returning dictionaries Some routines like 'vms_sys.getjpiw()' or 'vms_sys.getuai()' need to return a variable amount of data depending on its input parameters (the item list in this case). The data is stored under different 'keys' in a dictionary. Using a tuple or a list would raise the question of which data is stored at which position. The examples usually use 'dict' as the name for the reference to the object, but this is of course no requirement. Python for OpenVMS -General Manual PAGE 5-4 programming guidelines 5.4 OpenVMS condition values Using the native interfaces a programmer should _always_ check the returned condition value. Some routines also use the OpenVMS condition mechanism to signal errors, but a programmer should not rely on it. Almost all routines within Python do not return the 'status' code from the underlying OpenVMS service. They use the Python model of raising a Python exception when an error happens. There are some routines which behave differently - e.g. vms_lib.set_logical(). The reason for this is a uniform style of returning data - in this case it is a dictionary. Routines with different status values that can indicate success do not raise an exception, too. The vms_sys.getmsg() routine allows the translation of the code into its text message: >>> import vms_sys >>> print vms_sys.getmsg (0x2c) ('%SYSTEM-F-ABORT, abort', (0, 0, 0, 0)) >>> >>> print vms_sys.getmsg (0x2c) [0] %SYSTEM-F-ABORT, abort >>> Sometimes, the condition value is in an IOSB (I/O status block) for which the 'vmsobj_iosb' object provides storage. See the examples section of vms_sys.getjpiw() --- Beginning with Python for OpenVMS version 2.1-V001 the 'error' exception in the following modules is based on 'VMSerror' which is based on 'OSError': - vms_lbr - vms_lib - vms_mail - vms_smg - vms_sys which makes it possible to trap all OpenVMS-based Python exceptions: >>> import vms_lib >>> try: ... vms_lib.get_symbol ('NO_SYMBOL') ... except VMSerror, x: ... print x ... print x.args ... Python for OpenVMS -General Manual PAGE 5-5 programming guidelines [Errno 1409892] %LIB-F-NOSUCHSYM, no such symbol (1409892, '%LIB-F-NOSUCHSYM, no such symbol') >>> print VMSerror.__bases__ (,) >>> print OSError.__bases__ (,) >>> Note that the decimal value after 'Errno' is not an 'errno' value from the 'C' run-time library, it is an OpenVMS condition code: >>> import vms_sys >>> print x.args[0] 1409892 >>> print vms_sys.getmsg (x.args[0]) ('%LIB-F-NOSUCHSYM, no such symbol', (0, 0, 0, 0)) >>> The changes to the Python core interpreter were minimal, however, a side effect is that uncaught exceptions now look different (and perhaps a little confusing): >>> import vms_lib >>> vms_lib.get_symbol ('NO_SYMBOL') Traceback (most recent call last): File "", line 1, in ? vms_lib.error: [Errno 1409892] %LIB-F-NOSUCHSYM, no such symbol >>> 19-APR-2001 - It will take some time before the entire documentation has been updated to reflect this change... 5.5 special OpenVMS datatypes On OpenVMS, Python does not have a builtin 64-bit or 128-bit datatype. 5.5.1 64-bit quadword These are simulated by using Python's "long integer" datatype. See vms_sys.gettim() or vms_sys.asctim() for examples. An exception are quadwords that are used for rightslist identifiers - see the explanation more below this text. Using a "long integer" does allow the programmer to do calculations within Python. See the next section. Date and time values are returned as a signed long integer, however bitmasks like privileges are returned as a positive long integer. Python for OpenVMS -General Manual PAGE 5-6 programming guidelines 5.5.1.1 date and time calculations An OpenVMS binary date + time is internally represented by a signed quadword. A positive value (including 0) indicates an absolute date + time (e.g. 29-FEB-2000 12:34:45.78). A negative value means a delta time (12 21:56:34.91), meaning 12 days, twenty-one hours, fifty-six minutes, thirty-four seconds and 91 hundredth of a second. Although an OpenVMS 'delta time' is represented by a negative value it does not have a "direction". If you see something like "+01:00:00" - this is a 'combination time' - it means "add one hour to the current date + time". Let's do some examples: >>> import vms_lib, vms_sys If you are like me and always forget VMS' base date: >>> vms_sys.asctim (0L) '17-NOV-1858 00:00:00.00' >>> The smallest increment is 100 nanoseconds. It's easy to find out how many of these 'ticks' are in a second: >>> vms_sys.bintim ('17-NOV-1858 00:00:01.00') 10000000L >>> Warning! The trailing 'L' shows that this is a Python 'long integer'. This is not a delta-time! '10000000L' really indicates the 17th of November in the year 1858, one second after midnight. Now, a one-second delta time: >>> vms_sys.bintim ('0 00:00:01.00') -10000000L >>> Let's use a different date: >>> feb29_y2k = vms_sys.bintim ('29-FEB-2000 12:34:56.78') >>> feb29_y2k 44585444967800000L >>> Calculate one second. >>> one_second = vms_sys.bintim ('0 00:00:01.00') >>> one_second -10000000L Python for OpenVMS -General Manual PAGE 5-7 programming guidelines >>> To add one second, we have to subtract the delta-time: >>> new_time = feb29_y2k - one_second >>> new_time 44585444977800000L >>> vms_sys.asctim (new_time) '29-FEB-2000 12:34:57.78' * >>> print new_time - feb29_y2k 10000000L >>> Remember: this value does NOT represent a one-second 'delta-time'! There are also OpenVMS RTL routines to do date + time calculations: >>> new_time_2 = vms_lib.add_times (feb29_y2k, one_second) >>> new_time_2 44585444977800000L >>> vms_sys.asctim (new_time_2) '29-FEB-2000 12:34:57.78' * >>> This routine, however, has some restrictions. Please see 'REFMAN Modules, vms_lib module, vms_lib.add_times' for details. To subtract a delta time from an absolute date + time using Python's long integer datatype you have to ADD both values. There is also an OpenVMS RTL routine for this - see 'REFMAN Modules, vms_lib module, vms_lib.sub_times()'. 5.5.2 128-bit octaword These are simulated by using Python's "long integer" datatype. See vms_sys.getutc() or vms_sys.ascutc() for examples. Using a "long integer" does allow the programmer to do calculations within Python. 5.6 processes Python for OpenVMS -General Manual PAGE 5-8 programming guidelines 5.6.1 privileges A Python executable is not meant to be installed (via $INSTALL) with any privileges on OpenVMS! It is possible to turn off these elevated privileges by a call to vms_sys.setprv(), but a user can always just '$RUN' the Python executable... The user can also enable additional privileges from his authorized privilege mask or turn on any privilege if he has the SETPRV privilege by calling vms_sys.setprv(). --- Privilege bitmask values are stored in module 'vms_prvdef'. @@ Ignore the 'PRV$_NULL' item code in this module. It is a work-around to a deficy in the VMSDEF2MAR.COM procedure which currently cannot cope with a VMSDEF module that has no item codes. A privilege bitmask is 64 bits wide. All bit definitions in 'vms_prvdef' are defined as Python long integers. >>> import vms_prvdef >>> >>> # a bit in the first longword >>> vms_prvdef.PRV_M_ALLSPOOL 16L >>> type (vms_prvdef.PRV_M_ALLSPOOL) >>> >>> # a bit in the second longword >>> hex (vms_prvdef.PRV_M_READALL) '0x800000000L' >>> type (vms_prvdef.PRV_M_READALL) >>> The following bits are still defined in the 'vms_prvdef' module with their (32-bit) values in the second longword: PRV_M2_UPGRADE, PRV_M2_DOWNGRADE, PRV_M2_GRPPRV, PRV_M2_READALL, PRV_M2_IMPORT, PRV_M2_AUDIT, PRV_M2_SECURITY. (_M2_ indicates that this bit is located in the 2nd longword.) 'vms_prvdef' also includes the bits with the '_M_' code and their real 64-bit value. See the example of PRV_M_READALL above. Python for OpenVMS -General Manual PAGE 5-9 programming guidelines Privileges are used, for example, in the following routines: - vms_lib.getjpi() - vms_sys.creprc() - vms_sys.getjpiw() - vms_sys.getuai() - vms_sys.process_scan() - vms_sys.setprv() - vms_sys.setuai() 5.6.2 process identification (PID) OpenVMS DCL utilities use an 8-character hex number as input and output for the PID and translate it internally because system services and run-time library routines use a binary longword. Within Python a PID must always be specified as an integer data type - it is never a hex-string. e.g.: $ PID = F$GETJPI(0,"PID") $ show symbol PID PID = "0000021A" $ NUMBER = %X'PID' $ show symbol NUMBER NUMBER = 538 Hex = 0000021A Octal = 00000001032 $ You can use one of the following number representations within Python: - 538 - decimal - 01032 - octal - note the leading zero - 0x21a - hex - note the leading '0x' >>> ctx,data = vms_lib.getjpi("JPI$_IMAGNAME",538) >>> print data DSA3:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT]PYTHON.EXE;5 >>> ('ctx' is either the process' PID or, during wildcard lookups, a context value. Please see the description of vms_lib.getjpi() for details.) Several system services (vms_sys.delprc(), vms_sys.forcex(), ...) return the target process' PID if you specifiy the process name and pass '0-by-reference' for the PID argument. For consistency the Python interface always returns the target process' PID - no matter if you specify an explicit PID or use the process name argument. Python for OpenVMS -General Manual PAGE 5-10 programming guidelines --- Almost all examples in this documentation use a 'low' value for the PID. This is because most development happens on non-clustered OpenVMS systems. 5.7 RMS Many parts of the interfaces to the 'Record Management Services' (RMS) are not very thoroughly or even not at all (e.g. tape handling) tested. You do need a good understanding of RMS and you need access to the 'OpenVMS Record Management Services Reference Manual' to make use of the interfaces - testers are always welcome. RMS control blocks are accessible through so-called 'VMS objects'. The 'Python for OpenVMS Reference Manual' contains a list of these 'VMS objects'. There are also some minimal example scripts in the 'demoes manual'. 5.8 security related objects 5.8.1 ACL + ACE An ACL (Access Control List) is made up from one or more ACEs (Access Control list Entries). They are stored inside normal Python strings. Warning! ACEs are a set of bytes, not a set of printable characters. You should not output a binary ACE/ACL to a terminal, because the data stream can contain control sequences that alter the terminal's settings. Using the 'repr()' builtin is safe: >>> print repr (acestr) '\x0c\x01\x00\x00\x10\x00\x00\x00\x04\x00\x03\x00' >>> The vms_sys.format_acl() routine accepts a binary ACE and translates it in its ASCII equivalent. The vms_sys.parse_acl() routine accepts an ASCII string and translates it to the binary representation that is used inside OpenVMS. The vms_sys.get_security() routine and the 'vmsobj_xabpro' object can be used to retrieve ACLs or ACEs from files and other objects (not via XABPRO). Python for OpenVMS -General Manual PAGE 5-11 programming guidelines 5.8.2 rightslist identifiers Identifiers (UIC and general) and their attributes are represented by Python integers (32-bit values). The 'vms_kgbdef' module contains the attribute bitmask values (KGB_M_name). Translation to / from the names can be done using the vms_sys.asctoid() and vms_sys.idtoasc() routines. Some system services like vms_sys.add_holder() require a quadword containing the identifier in one of the longwords. The other usually is used for the attributes. In this case the interface routines do not use a single Python long integer but a tuple of 2 integers. ------------------------------------------------------------------------ 10-JUL-2001 ZE. CHAPTER 6 configuration guidelines 6.1 Introduction Beginning with Python for OpenVMS version 1.5.2-V004 it is possible to do better customization when creating an executable file. This especially helps people which do not have access to a C compiler. This section explains how this is to be done. ------------------------------------------------------------------------ 6.2 components Beginning with Python for OpenVMS version 1.5.2-V007 a new build mechanism has been created using the BLDRUN.COM procedure. The text file CONFIG_MODULES.TXT contains a pre-defined list of modules (=compile units) which can be managed with the Python script REGISTER_CONFIG.PY to add or remove so-called 'components' (that means one needs a working Python executable before doing customization with this file!). The following Python modules are currently available as 'components': - vms_lbr file: CONFIG_VMS_LBR.TXT - vms_mail file: CONFIG_VMS_MAIL.TXT - vms_smg file: CONFIG_VMS_SMG.TXT Each file should contain the necessary information on how to register or unregister the component. BLDRUN.COM, however, does not work with the text files - it is necessary to convert CONFIG_MODULES.TXT and CONFIG_OLB.TXT into indexed sequential form: $ @ PYTHON_TOOLS:CVT_CONFIG_MODULES.COM Python for OpenVMS -General Manual PAGE 6-2 configuration: components which creates file CONFIG_MODULES.DAT and $ @ PYTHON_TOOLS:CVT_CONFIG_OLB.COM which creates file CONFIG_OLB.DAT. The documentation for BLDRUN.COM describes how to compile all modules of a component. 03-MAY-2001 ZE. ------------------------------------------------------------------------ 6.3 builtin modules The list of Python's builtin modules has been historically defined by a 'C' structure in file CONFIG.C. Since version 1.5.2-V004 this file has been replaced by a data file (CONFIG.DAT). This are the steps: - Edit CONFIG.DAT - the format is described more below. Take care not to destroy the component-specific information. - Use the procedure (CONFIG_INITTAB2MAR.COM to convert this file to an assembler source file and create an additional linker options file (CONFIG.OPT). - Run procedure BLDRUN.COM to create an object file. Beginning with version 1.5.2-V007 the object module is put into the object library VMS_MACRO.OLB! - Create the executable by running the procedure LINK_PY.COM which calls the OpenVMS linker. Example: $ edit CONFIG.DAT ... $ @ PYTHON_VMS:CONFIG_INITTAB2MAR.COM CONFIG.DAT "D" $ @ PYTHON_VMS:BLDRUN VMS_MACRO CONFIG_INITTAB %MACRO_VMS-I-COMPILE, module: CONFIG_INITTAB $ directory PYTHON_EXEC_PREFIX_V:CONFIG*; Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT] CONFIG.OPT;2 CONFIG_INITTAB.MAR;2 CONFIG_SHOW.COM;1 Total of 3 files. $ Python for OpenVMS -General Manual PAGE 6-3 configuration: builtin modules $ @ LINK_PY ---------------------------------------------------------------- %LINK_PY-I-CFGINFO, configured for: CC,DEBUG,ENV=DCL,FLT=VAXD,THREADS %LINK_PY-I-LINKPRG, linking program PYTHON_VAX.EXE $ $ directory PYTHON_EXEC_PREFIX_V:PYTHON.EXE; Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT] PYTHON.EXE;5 Total of 1 file. $ The file 'CONFIG.C' is no longer used and can be deleted after its contents have been merged with those of CONFIG.DAT. 6.3.1 format of CONFIG.DAT A comment is started by the "!" character. It must be in column 1 on a comment-only line. A ";" in column 1 is also treated as a comment, however the entire line is also copied to the output '.MAR' file where it is used as a comment as well. column 1 The module name as seen inside Python. Mixed case is allowed. One or more SPACE characters delimit this column from the next one. column 2 Name of the initialization routine for this module. Some internal routines have 'NULL' here, which is translated to a NULL pointer. Mixed case is allowed, but is currently not used on OpenVMS. One or more SPACE characters delimit this column from the next one. column 3 configuration indicator This is validated against input parameter 2 to procedure CONFIG_INITTAB2MAR.COM. The "D" means "DCL environment", the "P" means "POSIX" environment, "T" is for threading support. ALL characters must be specified together as parameter 2. E. g.: for threading support in the DCL environment the following call has to be done: $ @ PYTHON_VMS:CONFIG_INITTAB2MAR.COM CONFIG.DAT "DT" Python for OpenVMS -General Manual PAGE 6-4 configuration: builtin modules column 4 linker option Data from this column goes into file "CONFIG.OPT". Look for a column that contains the string "zlib" as an example. There must not be a SPACE character in this column! The list is terminated by a line containing '0 0'. 04-JUL-2001 ZE. ------------------------------------------------------------------------ 6.4 module methods The list of a modules' methods is usually defined by a 'C' structure within the 'C' souce file of the module. Beginning with version 1.5.2-V004 this table _can_ be replaced by an external data file per module. To date, the following modules have been changed: - pyvms - vms_lbr (not enabled by default) - vms_lib - vms_smg (not enabled by default) - vms_sys These modules have been the prime target in order to support multiple operation system versions, because newer ones provide additional calls which result in LINK errors, at minimum. Adaption of other modules (if that is wanted) should be easy by taking them as an example. Maintenance: - Edit file 'mod__METHODS.DAT' - the format is described more below. - Use the procedure MODULEMETHODS2MAR.COM to convert this file to an assembler source file. - Run procedure BLDRUN.COM to create an object file and put it into the object library VMS_MACRO.OLB. - Create the executable by running the procedure LINK_PY.COM that calls the OpenVMS linker. Example: $ edit VMS_SYS__METHODS.DAT ... $ @ PYTHON_VMS:MODULEMETHODS2MAR VMS_SYS__METHODS.DAT "." "." $ directory VMS_SYS__METHODS; Python for OpenVMS -General Manual PAGE 6-5 configuration: module methods Directory PYTHON_DISK:[PYTHON.PYTHON2_1_1.VMS] VMS_SYS__METHODS.DAT;2 Total of 1 file. $ $ @ PYTHON_VMS:BLDRUN VMS_MACRO VMS_SYS__METHODS %MACRO_VMS-I-MODULE, module: VMS_SYS__METHODS $ directory VMS_SYS__METHODS.*;,PYTHON_EXEC_PREFIX_V: Directory PYTHON_DISK:[PYTHON.PYTHON2_1_1.VMS] VMS_SYS__METHODS.DAT;18 Total of 1 file. Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT] VMS_SYS__METHODS.MAR;8 Total of 1 file. Grand total of 2 directories, 2 files. $ $ @ LINK_PY --------------------------------------------------------------------- %LINK_PY-I-CFGINFO, configured for: CC,DEBUG,ENV=DCL,FLT=VAXD,THREADS %LINK_PY-I-LINKPRG, linking program PYTHON.EXE $ $ directory PYTHON_EXEC_PREFIX_V:PYTHON.EXE; Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1_1.VAX_DDDT] PYTHON.EXE;5 Total of 1 file. $ 6.4.1 format of mod__METHODS.DAT A comment is started by the "!" character. It must be in column 1 on a comment-only line. A ";" in column 1 is also treated as a comment, however the entire line is also copied to the output '.MAR' file where it is used as a comment as well. A line that begins with 'LABEL=' defines the name of that table. This name is used by the module's initialization routine when calling Python for OpenVMS -General Manual PAGE 6-6 configuration: module methods 'Py_InitModule4()' - Please lookup the string 'vms_lib__methods' in file 'VMS_LIB.C' to see how this works. All remaining lines define a module's methods - their layout is as follows: column 1 The method name as seen inside Python. Mixed case is allowed. One or more SPACE characters delimit this column from the next one. column 2 Name of the method's routine - usually a 'C'-function. Mixed case is allowed, but is currently not used on OpenVMS. One or more SPACE characters delimit this column from the next one. column 3 Method-Flags "MV" indicates "METH_VARARGS" - no other values are currently implemented. Mixed case is not allowed. One or more SPACE characters delimit this column from the next one. column 4 DOC-String label Address of a documentation string that will be attached to the method. This is a zero-terminated string, that is usually defined like: char meth__doc [] = "v = meth (p1, p2)\nshort description."; Mixed case is allowed, but is currently not used on OpenVMS. One or more SPACE characters delimit this column from the next one. column 5 VAX/Alpha version The earliest version number for the VAX or Alpha architecture where this method is supported. This is usually only used for operation system interfaces - other modules will use the standard mechanism. There is no explicit termination indicator required / supported in this file. 04-JUL-2001 ZE. ------------------------------------------------------------------------ 26-AUG-1999 ZE. (introduction) CHAPTER 7 embedding the Python interpreter The Python distribution contains an embedding example in the [.DEMO.EMBED] directory. This has been copied to [.VMS.DEMO.EMBED] and adapted for the OpenVMS environment. This section gives some more hints. ------------------------------------------------------------------------ Comments about some files: BUILD_DEMO.COM This file contains code copied and updated from CC_PYTHON.COM and LINK_PY.COM. It is used to turn DEMO_EMBED.C into DEMO_EMBED.EXE DEMO_EMBED.C Copied from [.DEMO.EMBED]DEMO.C. DEMO_EMBED.MAP Map file from the link process - stored in PYTHON_EXEC_PREFIX_V: DEMO_EMBED.EXE Resulting executables - stored in PYTHON_EXEC_PREFIX_V: DEMO_EMBED.OBJ Object module - stored in PYTHON_EXEC_PREFIX_V: You need to execute the procedure PYTHON_VMS:SETUP.COM before calling BUILD_DEMO.COM to pick up the right object libraries. The demo is linked against the full interpreter and all of its extension modules which creates a big '.EXE' file! ------------------------------------------------------------------------ 30-APR-2001 ZE. CHAPTER 8 changes to Python modules This section explains changes to modules of the Python library that have been made to support OpenVMS. - [.LIB] o compileall.py o getpass.py o site.py o tempfile.py o user.py - [.LIB.DISTUTILS] @@@ Note that these changes do not make 'distutils' working on OpenVMS. Those are just the first step to get familiar with it. o spawn.py o sysconfig.py o util.py o [.LIB.DISTUTILS.COMMAND] * build.py * install.py - [.LIB.TEST] o test_bufio.py o test_import.py o test_rgbimg.py o test_sax.py o test_signal.py o test_support.py - [.TOOLS.SCRIPTS] @@@ o h2py.py 8.1 compileall.py is used to pre-compile all modules of the Python library. The default OpenVMS filesystem (ODS-2) supports only uppercase filenames. The modification makes the module compliant. This module is used during the installation. See the 'Installation Python for OpenVMS -General Manual PAGE 8-2 changes to Python modules Manual', 'installing and building', 'compile Python files'. 8.2 getpass.py is used to accept a password from the terminal without echoing. The 'getuser()' method can be called to return the username. GETPASS.PY has been modified to call pyvms.pylib_getpass() on OpenVMS systems. 8.3 site.py One of the changes affects the output when the user has entered 'exit' or 'quit' at the interactive interpreter prompt. Old: >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' >>> Now: >>> exit 'Use Ctrl-Z (i.e. EOF) to exit.' >>> The other changes ('.pth' vs '.PTH') and replacement of the dot (.) in the version number to build PREFIX and EXEC_PREFIX are work arounds to limitations of the ODS-2 file system. 8.4 tempfile.py is used to create 'temporary' filenames and possibly open temporary files. The module was using a filename character ("@") that is invalid on ODS-2 disks. The 'TemporaryFileWrapper' class uses a construct (os.open(), os.unlink()) that does not work on OpenVMS. The port pretends to be a 'POSIX' environment, so the appropriate check fails. The check has been removed - the required piece of code is directly executed. Beginning with version 1.5.2-V007 there is no '.' in the temporary name, because 'TEST_PKG.PY' uses this module to create temporary directory names. (On a Unix system there is no fixed 'type' for a directory as on OpenVMS where this is always '.DIR;1'.) Python for OpenVMS -General Manual PAGE 8-3 changes to Python modules The '/tmp' directory is handled by some code that translates the logical name "PYTHON_TMP_P" which is defined by the procedure SETUP.COM. SETUP.COM creates a subdirectory "[.PYTHON_TMP]" within the directory that the logical name "SYS$SCRATCH" points to. >>> import tempfile >>> >>> tempfile.gettempdir () '/user_here/zessin/python_tmp' >>> tempfile.gettempprefix () 'python_tmp_213_' >>> tempfile.mktemp () '/user_here/zessin/python_tmp/python_tmp_213_0' >>> $ show logical PYTHON_TMP* /process (LNM$PROCESS_TABLE) "PYTHON_TMP_P" = "/user_here/zessin/python_tmp" "PYTHON_TMP_V" = "USER_HERE:[ZESSIN.PYTHON_TMP]" $ $ show logical SYS$SCRATCH "SYS$SCRATCH" = "USER_HERE:[ZESSIN]" (LNM$JOB_845CE780) $ There can be a problem if SYS$SCRATCH points to a logical name search list. The 'pkg' test fails for some reason that I have not tried to find out - please redefine SYS$SCRATCH in such a situation. This module requires vms_sys.trnlnm() 8.5 test_bufio.py Delete testfile (using 'os.unlink()') after use - otherwise more than 1000 versions of the test-file will be created (unless a version limit is set, of course). 8.6 test_import.py The module was trying to import a module with an invalid mixed-case filename (which failes on a case-sensitive / -preserving filesystem). On OpenVMS, the import succeeded which whould have raised an (error) exception. After the modification, the exception is just not raised. Python for OpenVMS -General Manual PAGE 8-4 changes to Python modules 8.7 test_rgbimg.py The module was using a filename character ("@") that is invalid on ODS-2 and used filenames with multiple '.'s which does not work on ODS-2, too. 8.8 test_sax.py The module was using a filename with multiple '.'s which does not work on ODS-2. 8.9 test_signal.py This test is currently disabled, because signal handling usually works different on OpenVMS. @@ It might come back after some tests with a current DEC C RTL. 8.10 test_support.py The module was using a filename character ("@") that is invalid on ODS-2. 8.11 user.py is used to execute the script ".pythonrc.py" in the user's "home" directory on Unix systems when the command 'import user' is given. This is an invalid file specification for an ODS-2 formatted disk; the default OpenVMS file system. On OpenVMS systems the script executes the file 'PYTHONRC.PY' from the user's login directory. It does not use "SYS$LOGIN" - instead it uses the C RTL's "HOME" environment variable. See the script for details. ------------------------------------------------------------------------ 24-JUN-2001 ZE. CHAPTER 9 changes to Python source This section explains changes to the Python source code have been made to support OpenVMS. - exceptions.c - fcntlmodule.c - fileobject.c - import.c - main.c - marshal.h - posixmodule.c - pyerrors.h - python.c - selectmodule.c - signalmodule.c - socketmodule.c - stringobject.c - timemodule.c - timing.h - _localemodule.c 9.1 exceptions.c Add exception 'PyExc_VMSerror'. 9.2 fcntlmodule.c A small change to keep the compiler quiet. FCNTL() is not available on all OpenVMS versions. No tests have been done. Python for OpenVMS -General Manual PAGE 9-2 changes to Python source 9.3 fileobject.c Pipe handling on OpenVMS. 9.4 import.c Changes for OpenVMS file system. 9.5 main.c - OpenVMS specific initialization code is called (PyVMS_init) - an OpenVMS-compliant condition code is returned when in the DCL environment - line-buffering is enabled for stdin, stdout, stderr - the hardware architecture (Alpha, VAX) is output in the banner - the floating point format is output in the banner 9.6 marshal.h Redefine symbol 'PyMarshal_ReadLastObjectFromFile' with a shorter name to work around the 31 character limit on OpenVMS. 9.7 pyerrors.h Add exception 'PyExc_VMSerror'. 9.8 python.c This is the 'real' main. The file contains changes so it can be compiled with the DEC / Compaq C++ compiler, which is necessary when C++ based extensions are used. Note: last time this was checked (MAR-2000) the Python interpreter itself could not be compiled with the DEC / Compaq C++ compiler! 9.9 selectmodule.c Socket handling on OpenVMS is different than Unix. The changes try to accomodate different environments (DCL, POSIX) and compiler versions. Python for OpenVMS -General Manual PAGE 9-3 changes to Python source Values of the 'mode' argument of the 'makefile()' function might be altered: 'rb' is changed to 'r' and 'wb' is changed to 'w', because the run-time library on OpenVMS does not tolerate 'rb' and 'wb'. This saves changes to several Python modules. No detailled tests have been done. 9.10 signalmodule.c Minor changes for OpenVMS. No tests have been done. 9.11 socketmodule.c Socket handling on OpenVMS is different than Unix. The changes try to accomodate different environments (DCL, POSIX) and compiler versions. They also try to get around a 65535 byte limit on read / write I/O. No tests have been done. 9.12 stringobject.c Small optimization for output of raw strings. 9.13 timemodule.c Again, socket handling on OpenVMS is different than Unix. Old OpenVMS versions are missing timezone handling. Some incomplete workarounds (vms__gettimeofday, vms__gmtime, vms__localtime) are put in the code. No tests have been done. 9.14 timing.h Is included by TIMINGMODULE.C - the same comments apply. Python for OpenVMS -General Manual PAGE 9-4 changes to Python source 9.15 _localemodule.c This module is only usable with OpenVMS V6.2 and higher. @@ It might work on older versions when using the C compiler 'backport library'. The changes try to accomodate different compiler versions. No tests have been done. ------------------------------------------------------------------------ 30-APR-2001 ZE. CHAPTER 10 Tools 10.1 coming with Python for OpenVMS 10.1.1 BLDRUN - compile modules Beginning with Python for OpenVMS version 1.5.2-V007 the mechanism to compile modules has been changed. There is a central module 'database' that has information about all modules. It is accessed by BLDRUN.COM which has replaced several procedures. (They have never been really documented, so they are not listed here either). 10.1.1.1 usage Parameters: @@ to be enhanced 10.1.1.2 examples: - compile all modules $ @ PYTHON_VMS:BLDRUN "$ALL" - compile all modules of a single component $ @ PYTHON_VMS:BLDRUN "C:name" %BLDRUN-W-NOMODULE, no modules in component: name $ $ @ PYTHON_VMS:BLDRUN c:PYTHON.VMS_LBR %BLDRUN-I-MODCNT, found 16 modules in component: PYTHON.VMS_LBR %CC_PYTHON-I-COMPILE, module ( 1/ 16): VMS_LBR %CC_PYTHON-I-COMPILE, module ( 2/ 16): VMS_LBR_CLOSE [...] Python for OpenVMS -General Manual PAGE 10-2 BLDRUN - compile modules %CC_PYTHON-I-COMPILE, module ( 16/ 16): VMS_LBR_SET_MOVE %BLDRUN-I-DONE, completed: C:PYTHON.VMS_LBR $ In the example above no new object library has been created. - list all defined components $ @ PYTHON_VMS:BLDRUN "C:*" %BLDRUN-I-CMPLIS, listing component names... PYTHON.BASE PYTHON.VMS_LBR PYTHON.VMS_SMG - compile all modules for a single object library $ @ PYTHON_VMS:BLDRUN "PYTHON" "*" %BLDRUN-I-MODCNT, found 23 modules in OLB: PYTHON %BLDRUN-I-OLBCRE, creating PYTHON_DDT.OLB %CC_PYTHON-I-COMPILE, module ( 1/ 23): BLTINMODULE %CC_PYTHON-I-COMPILE, module ( 2/ 23): CEVAL [...] %CC_PYTHON-I-COMPILE, module ( 23/ 23): TRACEBACK %BLDRUN-I-DONE, completed: PYTHON 10.1.1.3 internals All modules are now defined in file CONFIG_MODULES.TXT. This is a sequential file that can be maintained with a text editor. During the installation it is converted by the CVT_CONFIG_MODULES.COM procedure to an indexed sequential file named CONFIG_MODULES.DAT. BLDRUN.COM also needs access to the OpenVMS version table. This information is now maintained in file VMSDAT_VMSVER.TXT. During the installation it is converted by the CVT_VMSDAT_VMSVER.COM proecdure to an indexed sequential file named VMSDAT_VMSVER.DAT to allow faster access. @@ explain passing of information between BLDRUN.COM and CC_PYTHON.COM ------------------------------------------------------------------------ 09-MAY-2000 ZE. 10.1.2 CVT_DOC - convert .HTML to final docu formats This procedure is used to convert all '.HTML' files to the final documentation formats: Python for OpenVMS -General Manual PAGE 10-3 CVT_DOC - convert .HTML to final docu formats '.LNI' This file is for ANSI printer output. Bold printing is controlled using ANSI sequences. '.MEM' This file is for line printer output. Bold printing is controlled via carriage control and double printing. It is then converted to: '.TXT' This file is for viewing with a text editor or printing without bold characters from a non-VMS system. CVT_DOC.COM calls the following procedures: CVT__HTML.COM convert '.HTML' files to '.RNO' files CVT__RNO.COM convert '.RNO' files to the final 3 files explained above. Conversion from HTML to RUNOFF can take some time on a slow machine. One can run CVT__HTML.COM parallel to an edit session and have all new files converted while editing a new one. CVT__HTML.COM will check creation dates and only convert new HTML files. After the last '.HTML' file was changed the programmer can run CVT_DOC.COM and conversion will only be done for files where it is necessary. Format: $ @CVT_DOC ["*"] Arguments: P1, optional An asterisk ("*") is passed to CVT__HTML.COM and means that all files will be translated whether the '.RNO' file is current or not. ------------------------------------------------------------------------ 06-APR-1999 ZE. 10.1.3 CVT__HTML - convert .HTML to .RNO CVT__HTML.COM is normally called from CVT_DOC.COM. It converts all '.HTML' files in the [.VMS.DOC.] subdirectories except for those which have the '' tag in the first line. Because the conversion process takes some time CVT__HTML.COM does only convert those '.HTML' files which have a later creation date than the corresponding '.RNO' file. Passing a "*" as parameter 1 to the procedure however means that CVT__HTML will ignore the dates on the files and translate all files Python for OpenVMS -General Manual PAGE 10-4 CVT__HTML - convert .HTML to .RNO (except those that use the tag mentioned above). Beginning with version 1.5.2-V002 it is also possible to specify a filename as parameter 1 to convert a single file - no matter if the '.RNO' file is up to date or not. One can also delete all versions of a '.RNO' file to force a new translation of the '.HTML' file. It requires a working Python executable (named [.VMS]PYTHON_arch.EXE), the procedure SETUP.COM and HTML2RNO.PY. ('arch' can be "ALPHA" or "VAX"). The procedure contains only minimal error checking - e. g. it fails on an empty '.HTML' file. Format: $ @CVT__HTML ["*"|"filespec"] Arguments: P1, optional An asterisk ("*") means that all files will be translated whether the '.RNO' file is current or not. A single filespecification (.HTML) is set automatically to translate this file only. Examples: $ @CVT__HTML %CVT__HTML-I-CVTFIL, converting file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]CFG_BUILTIN.HTML;27\ %CVT__HTML-I-CVTFIL, converting file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]CFG_INTRO.HTML;13\ %CVT__HTML-I-NOCVT, converting not necessary for file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]CFG_MODULE_METHODS.HTML;20\ %CVT__HTML-I-NOCVT, converting not necessary for file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]CVT_DOC.HTML;10\ %CVT__HTML-I-NOCVT, converting not necessary for file [...] %CVT__HTML-I-NOCVT, converting not necessary for file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]HTML2RNO.HTML;9\ %CVT__HTML-W-CVTREJ, file conversion rejected due to \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]IDX_GEN.HTML;44\ %CVT__HTML-W-CVTREJ, file conversion rejected due to \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]INDEX.HTML;5\ %CVT__HTML-I-NOCVT, converting not necessary for file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]INTRO_GEN.HTML;68\ [...] %CVT__HTML-I-NOCVT, converting not necessary for file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]VMSVER2MAR.HTML;8\ Python for OpenVMS -General Manual PAGE 10-5 CVT__HTML - convert .HTML to .RNO %CVT__HTML-I-CVTCNT, converted 2 files $ $! .HTML is always set v-- $ @CVT__HTML INSBLD.HTMX %CVT__HTML-I-CVTFIL, converting file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.INSMAN]INSBLD.HTML\ %CVT__HTML-I-CVTCNT, converted 1 files $ $! .HTML is always set --------------v $ @CVT__HTML [-.REFMAN]VMS_LIB_ATTACH %CVT__HTML-I-CVTFIL, converting file \DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.REFMAN]VMS_LIB_ATTACH.HTML\ %CVT__HTML-I-CVTCNT, converted 1 files $ ------------------------------------------------------------------------ 27-OCT-1999 ZE. 10.1.4 CVT__RNO - convert .RNO to final docu CVT__RNO.COM is normally called from CVT_DOC.COM. It converts all '.RNO' files that have been created from a prior run of CVT__HTML.COM to the final files ('.MEM', '.LNI', '.TXT') for printer output or viewing with a text editor. Format: $ @CVT__RNO Arguments: none Example: $ @CVT__RNO %CVT__RNO-I-CREINTMED, creating intermediate file %CVT__RNO-I-CRETOC, creating table of contents %CVT__RNO-I-CREIDX, creating index %CVT__RNO-I-CREMEM, creating final .MEM file %CVT__RNO-I-CVTTXT, converting .MEM to .TXT file 83 lines deleted DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]GENMAN-TXT.TMP;1 3181 lines Input file does not have standard text file format [EOB] %CVT__RNO-I-CRELNI, creating final .LNI file 7 lines deleted DKA100:[PYTHON.PYTHON-1_5_2.VMS.DOC.GENMAN]GENMAN.LNI;2 3257 lines [EOB] %CVT__RNO-I-DONE, RNO translation completed Python for OpenVMS -General Manual PAGE 10-6 CVT__RNO - convert .RNO to final docu $ Beginning with Python for OpenVMS version 1.5.1-V008 there are several manuals and each has a dedicated procedure. ------------------------------------------------------------------------ 27-OCT-1999 ZE. 10.1.5 FILE2URL - convert filespec to file: URL The FILE2URL.COM proecdure converts a given file specification to a 'file:' URL and activates the NETSCAPE browser. The symbol "NETSCAPE" must be defined as a foreign command. Examples: If no parameter is supplied the entry page to the documentation is activated. $ @PYTHON_TOOLS:FILE2URL _FILESPEC = "DKA100:[PYTHON.PYTHON2_1.VMS.DOC]DOCU.HTML;" _PATH = "/DKA100/PYTHON/PYTHON2_1/VMS/DOC/DOCU.HTML" Relative addressing is used $ @PYTHON_TOOLS:FILE2URL [.GENMAN]IDX_GEN _FILESPEC = "DKA100:[PYTHON.PYTHON2_1.VMS.DOC.GENMAN]IDX_GEN.HTML;" _PATH = "/DKA100/PYTHON/PYTHON2_1/VMS/DOC/GENMAN/IDX_GEN.HTML" Absolute adressing is possible, too: $ @PYTHON_TOOLS:FILE2URL - _$ PYTHON_DISK:[PYTHON.PYTHON2_1.VMS.DOC.REFMAN]TOC_REF.HTML _FILESPEC = "DKA100:[PYTHON.PYTHON2_1.VMS.DOC.REFMAN]TOC_REF.HTML;" _PATH = "/DKA100/PYTHON/PYTHON2_1/VMS/DOC/REFMAN/TOC_REF.HTML" ------------------------------------------------------------------------ 30-APR-2001 ZE. 10.1.6 FILE_SET_DATE - alter CDT and RDT The FILE_SET_DATE program changes the creation + revision date of a file. It is used when the VMSTAR program did not preserve the dates from the '.TAR' file or a '$ SET FILE' command has been done to Python's original files. UNTAR2DATESET.COM creates a command procedure that uses FILE_SET_DATE to change the creation + revision dates. Python for OpenVMS -General Manual PAGE 10-7 FILE_SET_DATE - alter CDT and RDT Format: $! define a foreign command $ FILE_SET_DATE = "$disk:[directory.subdir]FILE_SET_DATE" $ FILE_SET_DATE filespecification date+time Arguments: filespecification Cannot contain any wildcards or a node name because FILE_SET_DATE does calls to the ACP-QIO interface. date+time Month names must be in uppercase on some versions of OpenVMS. Special warning: if you ommit the hundreth of seconds, they are not automatically set to '.00'! Example: $ COPY _NLA0: FILE.TMP $ DIRECTORY/DATE=(CREATED,MODIFIED) FILE.TMP Directory DKA100:[PYTHON.PYTHON-1_5.VMS] FILE.TMP;1 21-FEB-1998 20:46:42.65 21-FEB-1998 20:46:44.38 Total of 1 file. $ FILE_SET_DATE FILE.TMP "29-FEB-2000 12:34:56.78" $ DIRECTORY/DATE=(CREATED,MODIFIED) FILE.TMP Directory DKA100:[PYTHON.PYTHON-1_5.VMS] FILE.TMP;1 29-FEB-2000 12:34:56.78 29-FEB-2000 12:34:56.78 Total of 1 file. $ ------------------------------------------------------------------------ 23-MAY-1998 ZE. 10.1.7 HTML2RNO.PY - convert .HTML to .RNO HTML2RNO.PY is a Python program, that is used to convert a '.HTML' file to a '.RNO' file. The '.RNO' file is then to be run through the RUNOFF text formatter that is supplied with the OpenVMS operating system. HTML2RNO understands several HTML tags and tries to convert them to their RUNOFF 'equivalents'. There is, however a fundamental difference: Python for OpenVMS -General Manual PAGE 10-8 HTML2RNO.PY - convert .HTML to .RNO HTML describes the contents and the browser is supposed to decide how the output is rendered (e.g. lists). RUNOFF is a text formatter where the user has a high number of commands available that can be used to control the output. ------------------------------------------------------------------------ The following HTML tags are understood by HTML2RNO which can be mapped quite easily to RUNOFF commands:

+

through
+
are converted to '.header level' commands. 
 +
is converted to '.literal' and '.end literal' + is converted to '.subtitle "title-string"'. This intentionally done for the Python for OpenVMS documentation. '.title' defines the name of the document.
    +
is converted to '.list' and '.end list'. HTML2RNO tells RUNOFF the 'bullet character' to use. You can easily change that - look at the implementation of start_ul().
    +
is converted to '.list' and '.end list'. HTML2RNO tells RUNOFF to prefix the list elements with a decimal number.
  • is converted to '.list element' which works with both
      and
        .
        is just translated into a new paragraph
        The left margin is re-established.
        moves the left margin 8 characters to the right.
        is translated into a new paragraph. The left margin is re-established.
        is converted to '.break' Python for OpenVMS -General Manual PAGE 10-9 HTML2RNO.PY - convert .HTML to .RNO
        does a line break. Then a line containing dashes (-) is inserted as literal text into the RUNOFF file.

        starts a new line and puts a '.blank' on it.

        +
        is converted to '.center;text-to-center'. + enables bold printing in RUNOFF and inserts the control characters for begin or end into the RUNOFF file. After that bold printing is turned off again. + is usually displayed in italics within a browser. HTML2RNO tells RUNOFF to underline the embedded text. ------------------------------------------------------------------------ HTML2RNO uses the tag to pass additional data to RUNOFF. As far as I know is not a valid HTML tag and browsers should ignore it. The following 'attributes' (@@ is that the correct name?) are implemented: NOCONVERT is used to tell the procedure CVT__HTML.COM that the '.HTML' file need not be converted. This tag must be in the first line of the document. INLINE="data" inserts 'data' directly into the '.RNO' file. Example: aaabbb Such a construct can be used to suggest a possible line-break to RUNOFF. I'm not aware that a browser does right-justify a paragraph or that HTML contains directives to indicate possible line-break in words. INSERT_LITERAL="data" inserts 'data' as a separate line into the '.RNO' file which is included between '.end literal' and '.literal' lines. This prevents unnecessary empty lines from appearing if one uses the following technice instead: text
        
          Example:
          
                  text-1
          text-2more-text-1
          more-text-2
          
        

  Python for OpenVMS -General Manual                          PAGE 10-10
  HTML2RNO.PY - convert .HTML to .RNO


          The resulting output in the '.RNO' file looks like:

          Example:

          : .literal
          : 
          : text-1
          : text-2
          : .end literal
          : .test page 4
          : .literal
          : more-text-1
          : more-text-2
          : 
          : .end literal

          (There are currently superflowous  empty  lines  if  one  uses
          
         and 
        .)

  LINE="data"
          inserts 'data' as a separate line into the '.RNO' file.

          Example:
          
          This tells RUNOFF that there must be at least 10 free lines on
          the  current  page.   If  not,  RUNOFF  starts  a new page.  A
          browser has only one huge 'page' and the user scrolls  through
          that page.

  NEWLINE
          just starts a new line in the '.RNO' file.

  ------------------------------------------------------------------------
  A test procedure is  located  in  [.VMS.TEST]HTML2RNO-TEST.COM.   This
  file         converts         [.VMS.TEST]HTML2RNO-TEST.HTML         to
  [.VMS.TMP]HTML2RNO-TEST.RNO with  [.VMS.TOOLS]HTML2RNO.PY.   Then  the
  '.RNO'  file  is converted to a '.MEM' file by running the RUNOFF text
  formatter.

  [.VMS.TEST]HTML2RNO-TEST.HTML should contain a test case for each HTML
  tag that HTML2RNO.PY understands.
  @@ to be enhanced
  ------------------------------------------------------------------------
  28-JUL-1998 ZE.



  10.1.8  UNTAR2DATESET - create procedure to change dates

  Some old versions of the VMSTAR program did not set the  creation  and
  revision  dates  of  extracted file to those in the '.TAR' file.  Even
  with a current version the instructions to  build  Python  on  OpenVMS
  contain a command that changes the revision date of all files.

  Python for OpenVMS -General Manual                          PAGE 10-11
  UNTAR2DATESET - create procedure to change dates


  The UNTAR2DATESET.COM procedure reads the output of VMSTAR and creates
  a  new  procedure  that  changes  the  creation + revision date of the
  extracted file.  This procedure calls the FILE_SET_DATE program.

  Format:

      $ @UNTAR2DATESET inputfile outputfile

  Arguments:

  inputfile
          This is the file that  contains  the  verbose  output  of  the
          VMSTAR program.
  outputfile
          UNTAR2DATESET.COM creates this file  which  is  later  run  to
          change the extracted files' dates.

  Example:

      $! redirect output of VMSTAR
      $ DEFINE/USER_MODE SYS$OUTPUT name-UNTAR.LOG
      $! extract files from the TAR file
      $ VMSTAR xvf name.TAR
      $! read the output file and create command procedure
      $ @UNTAR2DATESET name-UNTAR.LOG name-DATESET.COM
      $! run the created procedure
      $ @name-DATESET.COM/OUTPUT=name-DATESET.LOG
      $! search for any errors
      $ SEARCH name-DATESET.LOG "%" /WINDOW=(1,4)

  ------------------------------------------------------------------------
  17-MAR-1998 ZE.



  10.1.9  VMSDEF2MAR - convert a VMSDEF .DAT file to macro

  On OpenVMS definitions of item codes, bitmasks or constants are stored
  in  several  modules.   E.g.   for 'Device and Volume Information' the
  module name is '$DVIDEF'.

  On OpenVMS, Python uses a similar construct that I call 'VMSDEF'.

  On OpenVMS there exist  different  files  for  each  language  -  e.g.
  DVIDEF.H  or DVIDEF.PAS (Caution!  some compilers store these files in
  a text library, now!).

  My first release of Python for OpenVMS (released on  16-FEB-1997)  did
  store item codes (and some more information that is not available in a
  native xxxDEF module of OpenVMS) in a  number  of  '.C'  source  files
  building huge arrays.

  This data, with some more information, has been moved into a number of
  text   files   with  names  like  VMSDEF_$DVIDEF.DAT.   The  procedure

  Python for OpenVMS -General Manual                          PAGE 10-12
  VMSDEF2MAR - convert a VMSDEF .DAT file to macro


  VMSDEF2MAR.COM translates the DAT file to the file  VMSDEF_$DVIDEF.MAR
  which  is  then run through the macro assembler by using the following
  command:
      $ @PYTHON_VMS:BLDRUN VMS_MACRO VMSDEF_$DVIDEF.MAR

  The resulting object file (VMSDEF_$DVIDEF.OBJ) is put into the  object
  library in VMS_MACRO.OLB in the directory PYTHON_EXEC_PREFIX_V:

  Look in the  table  of  contents  under  'Notes  about  implementation
  details' to see a sketch of the 'VMSDEF data structures'
  ------------------------------------------------------------------------

  Format:

      $ @VMSDEF2MAR inputfile

  Arguments:

  inputfile
          Text file that contains the VMSDEF  information.   The  output
          file  is  stored  in  the  same directory with the same name -
          except that the file type is '.MAR'.

  Example:

      $ @VMSDEF2MAR VMSDEF_$DVIDEF.DAT
      $ directory []VMSDEF_$DVIDEF.*;, PYTHON_EXEC_PREFIX_V:

      Directory PYTHON_DISK:[PYTHON.PYTHON2_1.VMS]

      VMSDEF_$DVIDEF.DAT;1

      Total of 1 file.

      Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1.VAX_DDDT]

      VMSDEF_$DVIDEF.MAR;1

      Total of 1 file.

      Grand total of 2 directories, 2 files.

  ------------------------------------------------------------------------
  28-APR-2001 ZE.



  10.1.10  VMSDEF_BLDDIR2MAR - build VMSDEF directory

  The 'pyvms' module provides access to all details of the 'VMSDEF' data
  structures.   The DCL procedure VMSDEF_BLDDIR2MAR.COM creates the file
  VMSDEF_DIRECTORY.MAR that contains a list of all existing structures.


  Python for OpenVMS -General Manual                          PAGE 10-13
  VMSDEF_BLDDIR2MAR - build VMSDEF directory


  That file is then  run  through  the  macro  assembler  by  using  the
  following command:
      $ @ PYTHON_VMS:BLDRUN VMS_MACRO VMSDEF_DIRECTORY.MAR

  The resulting object  file  (VMSDEF_DIRECTORY.OBJ)  is  put  into  the
  object library in VMS_MACRO.OLB in directory PYTHON_EXEC_PREFIX_V:

  How to access this data is described in the Examples  section  of  the
  'pyvms' module documentation.

  Look in the  table  of  contents  under  'Notes  about  implementation
  details' to see a sketch of the 'VMSDEF data structures'
  ------------------------------------------------------------------------

  Format:

      $ @VMSDEF_BLDDIR2MAR

  Arguments:
      This procedure does not have any arguments.

  Example:

      $ @VMSDEF_BLDDIR2MAR
      $ directory PYTHON_EXEC_PREFIX_V:VMSDEF_DIRECTORY.MAR

      Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1.VAX_DDDT]

      VMSDEF_DIRECTORY.MAR;1

      Total of 1 file.

  ------------------------------------------------------------------------
  28-APR-2001 ZE.



  10.1.11  VMSVER2MAR - build VMS version table

  A single executable image of 'Python for OpenVMS' provides support for
  multiple  versions  of  OpenVMS.   The 'VMSDEF' tables, which describe
  item-codes, bitmasks and constants have a minimum and maximum  version
  number encoded.
  @@ more explanation necessary?

  The DCL procedure VMSVER2MAR.COM converts the  file  VMSDAT_VMSVER.TXT
  to  the  file  VMSDAT_VMSVER.MAR  which  is then run through the macro
  assembler by using the following command:
      $ @PYTHON_VMS:BLDRUN VMS_MACRO VMSDAT_VMSVER.MAR

  The resulting object file (VMSDAT_VMSVER.OBJ) is put into  the  object
  library VMS_MACRO.OLB in the directory PYTHON_EXEC_PREFIX_V:

  Access to the  data  of  this  list  is  currently  (03-MAY-2001)  not

  Python for OpenVMS -General Manual                          PAGE 10-14
  VMSVER2MAR - build VMS version table


  implemented,   however   the   'pyvms'   module   provides   the  item
  'vms_version_number'.  Please  read  the  module's  documentation  for
  details.

  Look in the  table  of  contents  under  'Notes  about  implementation
  details' to see a sketch of the 'VMSDEF data structures'
  ------------------------------------------------------------------------

  Format:

      $ @VMSVER2MAR inputfile

  Arguments:

  inputfile
          Text file that contains the version information.

  Example:

      $ @VMSVER2MAR VMSDAT_VMSVER.TXT
      $ directory PYTHON_EXEC_PREFIX_V:VMSDAT_VMSVER.MAR;

      Directory PYTHON_DISK:[PYTHON.EXEC_PREFIX2_1.VAX_DDDT]

      VMSDAT_VMSVER.MAR;3

      Total of 1 file.
      $ @BLDRUN VMS_MACRO VMSDAT_VMSVER.MAR
      %MACRO_VMS-I-COMPILE, module: VMSDAT_VMSVER
      $

  ------------------------------------------------------------------------
  03-MAY-2001 ZE.



  10.2  not delivered with Python for VMS

  10.2.1  GZIP - (de)compress files to/from archive

  The GZIP program is required to  decompress  the  '.GZ'  file  of  the
  original  Python  distribution.   You  also need the VMSTAR program to
  extract the files from the '.TAR' file.

  This page only gives some sources where to get  GZIP  -  it  does  not
  explain  the  program!   Please read the documentation that comes with
  GZIP.
  ------------------------------------------------------------------------
  GZIP is available from several sources:


  Python for OpenVMS -General Manual                          PAGE 10-15
  GZIP - (de)compress files to/from archive


        -  the OpenVMS freeware CD
        -  DECUS SIG tapes
        -  FTP servers

  I have found sources at:
  ftp://ftp.tmk.com/vms-freeware/ or
  ftp://ftp.process.com/vms-freeware/

  ------------------------------------------------------------------------
  04-JUL-2001 ZE.



  10.2.2  UNZIP - decompress files from archive

  The UNZIP program  is  required  to  decompress  '.ZIP'  files.   This
  program is capable to restore RMS file attributes (e.g.  indexed) when
  files are restored on an OpenVMS system.

  This page only gives some sources where to get UNZIP  -  it  does  not
  explain  the  program!   Please read the documentation that comes with
  UNZIP.
  ------------------------------------------------------------------------
  UNZIP is available from several sources:

        -  the OpenVMS freeware CD
        -  DECUS SIG tapes
        -  FTP servers

  I have found executables at:
  ftp://ftp.tmk.com/vms-freeware/ or
  ftp://ftp.process.com/vms-freeware/

  ------------------------------------------------------------------------
  04-JUL-2001 ZE.



  10.2.3  VMSTAR - maintain TapeARchive file

  The VMSTAR program is required to extract all files  of  the  original
  Python  distribution  from  the  '.TAR'  file.  Because the archive is
  delivered in a compressed form you  also  need  the  GZIP  program  to
  extract the '.TAR' file from it.

  This page only gives some sources where to get VMSTAR -  it  does  not
  explain  the  program!   Please read the documentation that comes with
  VMSTAR.
  ------------------------------------------------------------------------
  VMSTAR is available from several sources:


  Python for OpenVMS -General Manual                          PAGE 10-16
  VMSTAR - maintain TapeARchive file


        -  the OpenVMS freeware CD
        -  DECUS SIG tapes
        -  FTP servers


  I have found sources at:
  ftp://ftp.tmk.com/vms-freeware/ or
  ftp://ftp.process.com/vms-freeware/

  ------------------------------------------------------------------------
  04-JUL-2001 ZE.












                                CHAPTER 11

                    The history of Python for OpenVMS



  11.1  reason for this chapter

  I always enjoy  reading  about  the  history  of  a  program  package.
  Python's  history is described in the file [.MISC]HISTORY.  If you are
  interested in the history of Python for OpenVMS, then read on.



  11.2  first contact + Python V1.3

  I first heard about Python when  reading  issue  3/96  of  the  German
  'LINUX MAGAZIN' (http://www.linux-magazin.de).  Then I found out about
  the port of Python V1.2 to VMS from Donn Cave, enhanced  and  upgraded
  it to Python V1.3 (released on 13 October 1995) which was available at
  that time.

  It took quite some work to get  it  running  with  DEC  C  and  GNU  C
  (problems with function prototypes and LINK).  A lot of functions were
  missing in POSIXMODULE.



  11.3  Python V1.4

  Python V1.4 was released on 25 October 1996.  I've ported one  or  two
  1.4betas  and  was  happy  that  I  had  to make less changes from one
  version to the other.  I stopped any work with GNU C about that time.

  This was  the  first  version  which  I've  released  under  the  name
  'PYVMS_970216'.  The number suggests the date of 16 February 1997.

  I've continued working with Python on OpenVMS  about  5  month  later.
  No, it wasn't a burn-out...

                                   ---

  I've invested some time to provide additional routines like utime() or
  readdir() which are missing on older VMS versions.  Item-code handling
  has been changed totally from arrays in 'C' source files  (*_TRNTBL.C)
  to  data files (VMSDEF_*.DAT) that are translated to macro sources (by

  Python for OpenVMS -General Manual                           PAGE 11-2
  The history of Python for OpenVMS


  VMSDEF2MAR.COM) and then run through the  MACRO  assembler  (with  the
  help of DMACRO_VMS.COM).

  A lot of routines to the  runtime  library  (LIB$,  LBR$)  and  system
  services  (SYS$)  have  been  added.   Please  note that some of these
  routines are not available in VMS V5.5-2 or 6.0.  The  oldest  OpenVMS
  releases I work with are OpenVMS VAX V6.1 and OpenVMS Alpha V6.2-1H3.
  When running under DCL, Python provides  a  (simple)  command  history
  that  has been implemented using the screen management library (SMG$).
  Note that Python is still line-oriented!

  The compile procedures have been somewhat enhanced - one can supply  a
  single file name as parameter_1 - I still don't use a make utility.



  11.4  Python V1.5

  I've moved the port to the beta releases of Python  V1.5  and  finally
  V1.5 which was released on 31 December 1997.  It took some time to get
  around the prefix handling.  Well,  I  still  have  no  VMS  compliant
  solution  -  I  just  created  2  dummy files in 2 directories to keep
  Python quiet and left it at that for the moment.

  Next I've started working with  callback-routines  while  implementing
  vms_lbr.output_help()      and      item-lists      while      writing
  vms_lib.set_logical().  It is amazing what one can do with Python!

  In the midth of January 1998 I've began moving the documentation  from
  a  set  of  simple  text files into HTML format.  Conversion to '.TXT'
  files was done with a (modified) Python  program  I've  found  in  the
  article  of  the  German  'LINUX  MAGAZIN',  that  got me started with
  Python.
  Great, eh?

  After some tests I've decided to change/ enhance the program to create
  output in RUNOFF format.  RUNOFF - aka DSR - Digital Standard Runoff -
  is a text formatter  that  is  supplied  with  the  OpenVMS  operating
  system.  The conversion program is now named HTML2RNO.



  11.5  Python V1.5.1

  Python V1.5.1 was released on 14-APR-1998.  I have moved the  port  to
  that  version  some  days  later and had applied almost all subsequent
  patches.  Some work has been  done  to  attack  the  'prefix  problem'
  (changed GETPATH.C), but it's not finished.

  Since then I have put  a  lot  of  work  into  the  documentation  and
  additional DCL routines to support the maintenance.

  The first snapshot (V1.5.1 V001P1) was put up on my private home  page
  on www.decus.de at ??-MAY-1998.

  Python for OpenVMS -General Manual                           PAGE 11-3
  The history of Python for OpenVMS


  The second snapshot (V1.5.1 V001P2) was put up on my private home page
  on www.decus.de at 30-JUL-1998.

  The third snapshot (V1.5.1 V001P3) was released on  20-AUG-1998.   The
  quadword   support  is  provided  by  using  Python's  "long  integer"
  datatype.

  The fifth snapshot (V1.5.1 V001P5) has never been officially released.

  The fourth snapshot (V1.5.1 V001P4) was released on 04-OCT-1998.

  The sixth snapshot (V1.5.1 V001P6) was released on 27-DEC-1998.

  The seventh snapshot (V1.5.1  V001P7)  was  released  on  17-JAN-1999.
  Octawords  are  represented as Python long integers, too.  The code of
  the interfaces has been cleaned up heavily.

  A set of 'VMS objects' has been created during JAN/MAR-1999  and  some
  RMS  calls  have  been implemented.  The first successfull SYS$GET was
  done on 11-FEB-1999.  During that  time  the  documentation  has  been
  split into 3 manuals.

  Version 1.5.1-V008 was released on 27/28-MAR-1999.
  Version 1.5.1-V009 (an update to V008) was released on 08-APR-1999.



  11.6  Python V1.5.2

  Version  1.5.2-V001  was  released   on   10-MAY-1999.    The   Python
  distribution  is available in a repackaged format to make installation
  easier.  Documentation is now in the following 3 manuals:

        -  installation
        -  general
        -  reference


  Version 1.5.2-V002 was released on 16-MAY-1999.
  Version 1.5.2-V003 was released on 13-JUN-1999.
  Version 1.5.2-V004 was released on 11-JUL-1999.
  Version 1.5.2-V005 was released on 24-AUG-1999.

  Version 1.5.2-V006 was released on 26-DEC-1999.
          The name 'PYVMS' is being removed, because "VMS" and "OpenVMS"
          are trademarks of Compaq Computer Corporation.


  Version 1.5.2-V007 was released on 14-AUG-2000.
          It includes interface routines for most  of  the  SMG$  calls,
          however  not  all  are  currently  tested  and  documented.  2
          snapshots (V007a + V007b) had been made available to a limited
          audience.

  Python for OpenVMS -General Manual                           PAGE 11-4
  The history of Python for OpenVMS


  11.7  Python V1.6

  An OpenVMS version of Python V1.6 was never released.



  11.8  Python V2.0

  An OpenVMS version of Python V2.0 was never released.



  11.9  Python V2.1

  An OpenVMS version of Python V2.1  was  never  released.   PREFIX  and
  EXEC_PREFIX have been implemented.  New exception handling for OpenVMS
  'errors'.  Broken bit mask handling on 'vmsobj' objects fixed.



  11.10  Python V2.1.1

  Version 2.1.1-V001 was released on ??-JUL-2001.

  ------------------------------------------------------------------------
  04-JUL-2001 ZE.












                                CHAPTER 12

                     The future of Python for OpenVMS



  What is planned / needs to be done for/in a future version  of  Python
  for OpenVMS:
  ------------------------------------------------------------------------
  Currently, everything is running from the 'development directory tree'
  ([PYTHON...]).   Access  to  the  library  is  just 'hacked to make it
  work'.  Multi-platform support (Alpha / VAX) is unclear.

  What needs to be done is:

        -  definition of a directory tree for a production environment
        -  multi-platform support (within a mixed architecture (Alpha  /
           VAX) and / or mixed version VMScluster) for:
            o  Python code (similar to [.LIB.PLAT-xxx])
            o  executables + shareable images
           within the directory tree mentioned above.


  24-JUN-2001:   and  have been implemented.
  ------------------------------------------------------------------------
  Changes to the development environment so that users can make  use  of
  the   building  instructions  without  privileges.   The  'development
  directory tree' ([PYTHON...]) should be  able  to  live  in  a  user's
  subdirectory.
  ------------------------------------------------------------------------
  Better navigation between web pages:
  It should be possible to go directly from one page to  the  other  (or
  the previous one) without returning to the table of contents.
  26-DEC-1998 - Work has been started some time ago by  using  a  single
  HTML  page  for each interface routine for the 'vms_lib' and 'vms_sys'
  modules.
  ------------------------------------------------------------------------
  A set of tests for OpenVMS specific extensions should be developed.

  There are always enhancements / changes to already  existing  routines
  and data structures which can break old functions (and it happened).
  ------------------------------------------------------------------------
  Some implementations of gmtime() in the  OpenVMS  C  run-time  library
  return  NULL  (to indicate they do not support timezones) which Python
  (in [.MODULES]TIMEMODULE.C) cannot cope  with.   A  workaround  is  in
  VMS__GMTIME.C which, however, returns just the local time.

  Python for OpenVMS -General Manual                           PAGE 12-2
  The future of Python for OpenVMS


  ------------------------------------------------------------------------
  24-JUN-2001 ZE.












                                CHAPTER 13

                                  Notes



  This chapter contains some notes about implementation details.



  13.1  Python for OpenVMS - notes

  This section contains comments and ideas ...
  ------------------------------------------------------------------------
  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.2-1   + DEC C V6.2

      - C++  : I have not tried any C++ compiler

    - 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

  Python for OpenVMS -General Manual                           PAGE 13-2
  Python for OpenVMS - notes


      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)
      .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.
      24-FEB-2001 PREFIX/ EXEC_PREFIX implemented - see 'environment' chapter.

    - 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 for OpenVMS 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.
   

  Python for OpenVMS -General Manual                           PAGE 13-3
  Python for OpenVMS - notes


      There are still some problems with the current format in the .DAT
      file. Expect changes in a future version!

    - octaword (128 bit) support
      Since Python for OpenVMS version 1.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!

    - 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  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

  Python for OpenVMS -General Manual                           PAGE 13-4
  Python for OpenVMS - notes


  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".


  This FAQ is archived in the following locations:
          comp.answers and news.answers newsgroups
          ftp://ftp.digital.com/pub/Digital/dec-faq/vms
          ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms
          CompuServe VAXFORUM, Library 0, VMSFAQ.TXT

  User-created HTML versions of the FAQ are located at:
          http://www.kjsl.com/vmsfaq
          http://eisner.decus.org/vms/faq.htm


   ------------------------------------------------------------

    - '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 Python for OpenVMS
                             (and some support DCL files)
        [.TEST]         - files to test out functions of Python for OpenVMS
        [.TMP]          - temporary directory
        [.TOOLS]        - some tools to maintain and build Python for OpenVMS
   

  ------------------------------------------------------------------------
  08-APR-2001 ZE.

  Python for OpenVMS -General Manual                           PAGE 13-5
  the VMSDEF data structures


  13.2  the VMSDEF data structures

  This section shows some of the VMSDEF  data  structures.   (Conversion
  from VMSDEF.TXT which was last updated on 04-JAN-1998 ZE.)

          06-SEP-1996
  data structure changed:
  - c_typ_lib to w_typ_lib and c_typ_sys to w_typ_sys
  - removed filler element
  - moved w_bufsiz to keep natural alignments

  ------------------------------------------------------------------------

  VMSDEF_DIRECTORY.MAR
    -- array of: pointer to item descriptor, pointer to bitmask/constants
        pointer descriptor, pointer to .ASCIZ name of DEFinition

  VMSDEF_GR_DIRECTORY::
      .address VMSDEF_GR_$QUIDEF       ; ar_itmtbl
      .address VMSDEF_GR_CB_$QUIDEF    ; ar_conmsktbl
      .address VMSDEF_T_DIRECTORY__3
      ...
      .long    0 ; terminate list
      .long    0

  VMSDEF_T_DIRECTORY__3:  .asciz '$QUIDEF'
      ...
      ; no termination necessary
  ;
      .end

  ------------------------------------------------------------------------
  VMSDEF_$QUIDEF.MAR
    -- array of item descriptors
  VMSDEF_GR_$QUIDEF::
      .word    0001                ; w_itmcod - QUI$_CANCEL_OPERATION
      .word    00000               ; w_bufsiz
      .word    05520               ; w_vmsvermin
      .word    32767               ; w_vmsvermax
      .address VMSDEF_T_$QUIDEF__1 ; at_itmnam_py
      .long    0                   ; ar_bitmsk
      .long    7                   ; l_flags
      .word    ITMTYP_K_LONG       ; w_typ_lib
      .word    ITMTYP_K_LONG       ; w_typ_sys
      ...
      .word    0133                ; w_itmcod - QUI$_MANAGER_STATUS
      .word    00004               ; w_bufsiz
      .word    06000               ; w_vmsvermin
      .word    32767               ; w_vmsvermax
      .address VMSDEF_T_$QUIDEF__75 ; at_itmnam_py
      .address VMSDEF_AR_QUI_QUEUE_MGR        ; ar_bitmsk
      .long    11                  ; l_flags
      .word    ITMTYP_K_LONG       ; w_typ_lib
      .word    ITMTYP_K_LONG       ; w_typ_sys

  Python for OpenVMS -General Manual                           PAGE 13-6
  the VMSDEF data structures


      ...
      .word     0       ; w_itmcod - end of list
      .word     0       ; w_bufsiz
      .word     0       ; w_vmsvermin
      .word     0       ; w_vmsvermax


    -- array of bitmask/constant descriptors for a given item code
        (if applicable)
  VMSDEF_AR_QUI_QUEUE_MGR:
      .long    0008   ; QUI_M_MANAGER_FAILOVER
      .address VMSDEF_T_$QUIDEF__250
      .word    05520
      .word    32767
      .long    0004   ; QUI_M_MANAGER_RUNNING
      .address VMSDEF_T_$QUIDEF__251
      .word    05520
      .word    32767
      ...
      .long    0
      .long    0
      .word    0      ; THIS 0 terminates the BITMASK list
      .word    0


    -- array of bitmask/constants pointer descriptor
       (pointer to descriptor amd defines it's type)
  VMSDEF_GR_CB_$QUIDEF::
      .address VMSDEF_AR_QUI_QUEUE_MGR
      .long    CONMSKTBL_K_BITMASK32
      ...
      .long    0       ; terminate const/bitmsk table
      .long    0

    -- ASCII List of item code names
  VMSDEF_T_$QUIDEF__1:
      .asciz 'QUI$_CANCEL_OPERATION'
      ...
  VMSDEF_T_$QUIDEF__75:
      .asciz 'QUI$_MANAGER_STATUS'
      ; no termination necessary
  ;
      .end

  ------------------------------------------------------------------------
  14-SEP-1998 ZE.

  Index                                                     PAGE INDEX-1
   


                                  INDEX



  files                                 compileall.py, 8-1
    BLDRUN.COM, 6-1, 10-1               getpass.py, 8-2
    CONFIG.C, 6-2                       site.py, 8-2
    CONFIG.DAT, 6-2                     tempfile.py, 8-2
      format, 6-3                       test_bufio, 8-3
    CONFIG.OPT, 6-2                     test_import, 8-3
    CONFIG_MODULES.DAT, 10-2            test_rgbimg, 8-4
    CONFIG_MODULES.TXT, 10-2            test_sax, 8-4
    CVT__HTML.COM, 10-3                 test_signal, 8-4
    CVT__RNO.COM, 10-5                  test_support.py, 8-4
    CVT_DOC.COM, 10-2                   user.py, 8-4
    FILE2URL.COM, 10-6                Python source modified
    FILE_SET_DATE.C, 10-6               exceptions.c, 9-1
    GETPATH.C, 4-1                      fcntlmodule.c, 9-1
    mod__METHODS.DAT                    fileobject.c, 9-2
      format, 6-5                       import.c, 9-2
    POSIXMODULE.C, 13-1                 _localemodule.c, 9-4
    PYTHONRC.PY, 8-4                    main.c, 9-2
    .pythonrc.py, 8-4                   marshal.h, 9-2
    PYTHONSTARTUP.PY, 13-3              pyerrors.h, 9-2
    PYVMS_READLINE.C, 4-3               python.c, 9-2
    SETUP.COM, 7-1, 8-3, 10-4           selectmodule.c, 9-2
    SMGSHR.EXE, 4-3                     signalmodule.c, 9-3
    TXT.FDL, 2-2                        socketmodule.c, 9-3
    UNTAR2DATESET.COM, 10-10            stringobject.c, 9-3
    VMS__CVT.C, 13-3                    timemodule.c, 9-3
    VMS__GETTIMEOFDAY.C, 13-2           timing.h, 9-3
    VMS__GMTIME.C, 13-2
    VMS__RMDIR.C, 13-3
    VMS__UTIME.C, 13-3
    VMSDAT_VMSVER.DAT, 10-2           software
    VMSDAT_VMSVER.MAR, 10-13            browsers, 2-1
    VMSDAT_VMSVER.TXT, 10-2, 10-13      HTTP servers, 2-1
    VMSDEF_$DVIDEF.DAT, 10-11
    VMSDEF_$DVIDEF.MAR, 10-12
    VMSDEF_DIRECTORY.MAR, 10-12,
        13-5                          tools
                                        BLDRUN, 10-1
  logical names                         CONFIG_INITTAB2MAR.COM, 6-2
    DECC$DEFAULT_LRL, 5-1               CVT__HTML, 10-3
    PYTHON_EXEC_PREFIX_P, 4-2           CVT__RNO, 10-5
    PYTHON_EXEC_PREFIX_V, 4-2           CVT_CONFIG_MODULES.COM, 10-2
    PYTHON_PREFIX_P, 4-2                CVT_DOC, 10-2
    PYTHON_PREFIX_V, 4-2                FILE2URL, 10-6
    PYTHON_TMP_P, 8-3                   FILE_SET_DATE, 10-6, 10-11
    SYS$SCRATCH, 8-3                    GZIP, 10-14 to 10-15
                                        MODULEMETHODS2MAR.COM, 6-4
  privileges                            UNTAR2DATESET, 10-6, 10-10
    SETPRV, 5-8                         UNZIP, 10-15
    Warning, 5-8                        VMSTAR, 10-6, 10-10, 10-14 to

  Index                                                     PAGE INDEX-2
   


  Python modules modified                   10-15