Porting Open Source to OpenVMS
| This page was transwikied from another project and needs to be bookified. This page either needs to be altered to become the main page of a book, or altered to fit the "local manual of style" of the book it is to be included in. Please remove {{bookify}} after the page is bookified. |
Porting open source (UNIX) software to OpenVMS edit
Preface edit
OpenVMS and Open source both started using the Open prefix some time ago. Before that, all we had were a lot of operating systems, one of which was VAX VMS. Each operating system came with its own possibilities, strong and weak points. If you wanted a application to run on your computer you would buy or build the application yourself for your computer. The efforts needed to get the thing going, were often so great that people sought methods to make the process of implementing applications on a different platform (so called porting) easier. Especially software meant to be implemented on many different platforms and software developed for platforms not yet known had to take measures to make implementations as easy as possible. Conformation to open or industry standards helped a lot. If software was delivered including the sources so the client could modify the software to suit his (changing) needs with the obligation to make his changes available to other users of this software the term open source software comes to mind. Although open source software and open standards are strictly speaking not necessarily related, they are often mentioned in one breath, because people benefit the most if both are optimally available: easy (and thus cheap) deployment of applications. The open in OpenVMS just means that people can rely on the conformation to open standards in the OpenVMS operating system. OpenVMS is available not only on VAX hardware but also on Alpha and since 2004 also on industry standard IA64 hardware.
Purpose edit
This guide will explain how to port opensource software to OpenVMS using the features introduced in the DII COE releases of OpenVMS (7.2-6C1 & 7.2-6C2). The guide does not specifically target these versions of OpenVMS but these were the first public versions of OpenVMS with some of these new UNIX features. To be more specific, OpenVMS versions 7.3 7.3- 1, 7.3-2 and up. The latest OpenVMS version (OpenVMS 8.4) has the most of these new features. Because the development of the porting tooling is progressing fast and more portability features will be added to OpenVMS in the future, we will regularly update this guide. Many open source projects use UNIX shell scripts to build and install. We will be looking on how to do the same thing on OpenVMS using the UNIX commands and utilities provided by the GNV kit. We will not look at porting open source software to older versions of OpenVMS, although some of these older versions are still supported. Porting to these older versions of OpenVMS can be done, but it is considerably more difficult.
Intended audience Basically everybody with interest in open source software. If everything was perfect this would be the only requirement, but alas, things are not perfect. In the current versions of open source software OpenVMS is seldom recognized or considered as a target platform. We think (and hope) this will change soon. In the meanwhile porters will benefit from some programming experience. C and/or C++ experience on OpenVMS or UNIX systems is a big plus. Other languages often used in open source world are bash, make and perl. System management experience is more a requirement because porting may require making adaptations to the porting environment on OpenVMS.
Acknowledgments edit
We would like to thank all the people who contributed in any form to this guide. There are many people who contributed material, thoughts or inside information. Without their contributions this guide wouldn't be as useful l as it is now.
Part I Open source, Unix and OpenVMS edit
Open source versus propriety software edit
This guide will not start with a in depth philosophic discussion about the difference between Open source, Freeware, shareware and propriety software. Instead we prefer to follow the definitions given in the following publication:
Title: The BUSINESS and ECONOMICS of LINUX and OPEN SOURCE Written by: Martin Fink Printed by: Prentice Hall ISBN: 0-13-047677-3
These definitions and the legal implications the various license agreements have, are for our purpose not relevant. We will concentrate on the technical aspects of the process of the port of open source software to OpenVMS.
Unix, Linux, Open Unix standard edit
As the majority of the open source software originates from a form of UNIX, we will have to know the characteristics of this type of platform and the differences between these platform and the target platform: OpenVMS. This is simpler said as done, as there are as many different implementations of UNIX as there are suppliers of hardware and operating system software. Starting in the early days of UNIX, when the universities not only had access to UNIX, but also had access to the source of the operating system, different solutions to common problems emerged. This resulted in a family of related operating systems commonly known as UNIX. Ownership of the UNIX brand name passed hands and the situation became rather confusing. Who had the one and only UNIX? So, people started to define standards (alas not one standard...) by which a "real" UNIX could be recognized. At <reference> is a comparison between the following UNIX standards with the OpenVMS features: XSI, POSIX Base, Unix 98, Unix 95, P96 P92, C99, C89, SVID3, BSD, LSB 1.3
LINUX is a very popular UNIX like operating system, available in many different distributions, each with slightly different characteristics.Making software for such a divers environment was a nightmare. But very inventive software developers found a solution. The solution was two fold:
- Define and enforce a minimum set of features through standardization, much like the RFC's for TCP/IP.
- Automate the build process by using a set of tools capable of finding and reacting (adapting) to differences between platforms. This led to the development of autoconf, automake and libtool. These tools are also known as the GNU autotools environment (http://sources.redhat.com/autobook/)
OpenVMS, open standards edit
OpenVMS on the other hand is a propriety operating system owned and maintained by HP. There are a few initiatives to make OpenVMS clones (for instance freeVMS (http://www.freevms.net)), but in this guide we will concentrate on the OpenVMS operating system from HP. As stated in the SPD (software product description) OpenVMS conforms itself to a set of Open Standards. Open standards means in this respect that a standardization organization is responsible for the exact text of a standard. Full conformation to this standard means in our opinion that a product will be adapted to the standard if a difference is found, not the other way around (adapting the standard to the behavior of a product, as is mostly the case with so-called industry-standards). The open standards that are most interesting for open source to OpenVMS porters are:
- Distributed Computing Environment (DCE) Support
- Support for OSF/Motif and X Window System Standards (X11R6 server and X11R5 client)
- ANSI X3.4-1986: American Standard Code for Information Interchange
- ANSI X3.41-1974: Code Extension Techniques for Use with 7-bit ASCII
- FIPS 1-2: Code for Information Interchange, Its Representations, Subsets, and Extensions
- ISO 646: ISO 7-bit Coded Character Set for Information Exchange
- ISO 2022: Code Extension Techniques for Use with ISO 646
- ISO 3307: Representations of Time of the Day
- ISO 4873: 8-Bit Code for Information Interchange - Structure and Rules for Implementation
- ISO 9660: Information Processing - Volume and file structure of CD-ROM for information exchange
Open source on OpenVMS edit
The question here is not, can we have open source software on OpenVMS, because you're already using some open source software. CDSA is an open source security framework that is now used on OpenVMS. You cannot install current releases of OpenVMS without it. There are two CDSA add-ons, SSL and Kerberos. Both are open source. In the TCP/IP package you'll find BIND and DHCP from the Internet Software Consortium. And what about the SMTP, POP, IMAP, SSH.... These are just some packages that are part of the standard OpenVMS distribution. But there's more, there's Apache, Mozilla, Samba, MySQL, Tomcat, Perl, Python. Then there's the business rationale of open source. Why should you, or your company use open source software. This is not as simple as many people think. The fact that open source is free does not necessarily mean that it is cheaper to run for you or your company. Because of the complexity of the subject we would like to point you to a good book on the subject:
Title: The BUSINESS and ECONOMICS of LINUX and OPEN SOURCE Written by: Martin Fink Printed by: Prentice Hall ISBN: 0-13-047677-3
OpenVMS-UNIX differences edit
The best way to compare UNIX and OpenVMS is probably by way of a table with a side by side comparison of the interesting aspects. <reference> is such a table.This is but a partial list. It is probably best to point you to some good books on the subject. From John Wisniewski, who was the driving force behind the OpenVMS Hobbyist program, is the excellent book:
Title: Linux and OpenVMS Interoperability Written by: John Wisniewski Printed by: Digital Press ISBN: 1-55558-267-2
The following book is written to make life easier for OpenVMS literate people new to the UNIX environment:
Title: UNIX for VMS Users Written by: Philip E. Bourne Printed by: Digital Press ISBN: 1-55558-034-3
Part II: build the open source porting environment on OpenVMS edit
Build the OpenVMS porting system edit
The first step in the porting process is getting a suitable OpenVMS system up and running. Although OpenVMS is available on three hardware platforms, only two of them are sufficiently equipped to do serious opensource porting: Alpha and IA64. The VAX platform lacks support for some important features in a stand-alone configuration. VAX OpenVMS for instance lacks support for native ODS5 and GNV. Because most people only have access to Alpha systems and because IA64 OpenVMS is for the most part, functionally equal to Alpha OpenVMS, all examples are based on Alpha OpenVMS. In the reference section of the www.oooovms.dyndns.org website are examples of steps involved in building a OpenVMS system. There are documents about upgrading firmware, initial installation of OpenVMS, first boot and initial configuration of OpenVMS.
Installation of OpenVMS 8.4 on an Emulator edit
+-------------+ V i r t u a l serial0
|F|r|e|e|A|X|P| A l p h a on emulator workshop (128 MB)
+-------------+ x64 version 2.4.3.533
ff.fe.fd.fc.fb.fa.f9.f8.f7.
ERROR: ISA table corrupt!
Initializing table to defaults
type >>>init to use these changes
f6.f5.
ef.df.ee.ed.ec.f4.eb.ea.
TIMER_TPS environment variable invalid
Defaulting to 1mS per tick
e9.e8.e7.e6.....e5.
V7.0-9, built on Mar 18 1999 at 13:25:37
>>>b dka100
(boot dka100.1.0.6.0 -flags 0)
block 0 of dka100.1.0.6.0 is a valid boot block
reading 1230 blocks from dka100.1.0.6.0
bootstrap code read in
base = 1f2000, image_start = 0, image_bytes = 99c00
initializing HWRPB at 2000
initializing page table at 1e4000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
OpenVMS (TM) Alpha Operating System, Version V8.4
© Copyright 1976-2010 Hewlett-Packard Development Company, L.P.
Installing required known files...
Configuring devices...
%EWA0, Twisted-Pair mode set by console
%EWA0, Link state: UP
****************************************************************
You can install or upgrade the OpenVMS ALPHA operating system
or you can install or upgrade layered products that are included
on the OpenVMS ALPHA distribution media (CD/DVD).
You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.
Please choose one of the following:
1) Upgrade, install or reconfigure OpenVMS ALPHA Version V8.4
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system
Enter CHOICE or ? for help: (1/2/3/4/5/6/7/8/9/?) 1
***********************************************************
This procedure will ask a series of questions.
() - encloses acceptable answers
[] - encloses default answers
Type your response and press the <Return> key. Type:
? - to repeat an explanation
^ - to change prior input (not always possible)
Ctrl/Y - to exit the installation procedure
There are two choices for installation/upgrade:
Initialize - Removes all software and data files that were
previously on the target disk and installs OpenVMS ALPHA.
Preserve -- Installs or Upgrades OpenVMS ALPHA on the target disk
and retains all other contents of the target disk.
* Note: You cannot use preserve to install OpenVMS ALPHA on a disk on
which any other operating system is installed. This includes
implementations of OpenVMS for other architectures.
Do you want to INITIALIZE or to PRESERVE? [PRESERVE] initialize
You must enter the device name for the target disk on which
OpenVMS ALPHA will be installed.
Enter device name for target disk: (? for choices) ?
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DKA0: Online 0
DKA100: Mounted wrtlck 2 ALPHA084 137373 83 1
DVA0: Offline 0
DAD0: Online 0
Enter device name for target disk: (? for choices) dka0
Enter volume label for target system disk: [ALPHASYS]
The target system disk can be initialized with On-Disk Structure
Level 2 (ODS-2) or Level 5 (ODS-5). (? for more information)
Do you want to initialize with ODS-2 or ODS-5? (2/5/?) 5
Hard links can be enabled on ODS-5 disks. (? for more information)
Do you want to enable hard links? (Yes/No/?) yes
You have chosen to install OpenVMS ALPHA on a new disk.
The target system disk, DKA0:, will be initialized
with structure level 5 (ODS-5).
Hard links WILL be enabled.
The disk will be labeled ALPHASYS.
Any data currently on the target system disk will be lost.
Is this OK? (Yes/No) yes
Initializing and mounting target....
Creating page and swap files....
You must enter a password for the SYSTEM account.
The password must be a minimum of 8 characters in length, and
may not exceed 31 characters. It will be checked and verified.
The system will not accept passwords that can be guessed easily.
The password will not be displayed as you enter it.
Password for SYSTEM account: password not echoed
Re-enter SYSTEM password for verification: password not echoed
Will this system be a member of an OpenVMS Cluster? (Yes/No) no
Will this system be an instance in an OpenVMS Galaxy? (Yes/No) no
For your system to operate properly, you must set two parameters:
SCSNODE and SCSSYSTEMID.
SCSNODE can be from 1 to 6 letters or numbers. It must contain at
least one letter.
If you plan to use DECnet, SCSNODE must be the DECnet Phase IV
node name, or the DECnet-Plus (Phase V) node synonym.
If you have multiple OpenVMS systems, the SCSNODE on each system
must be unique.
Enter SCSNODE: star
If you plan to use DECnet, SCSSYSTEMID must be set based on the
DECnet Phase IV address.
Do you plan to use DECnet? (Yes/No) [Yes] no
Please choose an SCSSYSTEMID between 1 and 65535. If you have multiple
OpenVMS systems, the SCSSYSTEMID on each system must be unique.
Enter SCSSYSTEMID: [65534]
Configuring the Local Time Zone
TIME ZONE SPECIFICATION -- MAIN Time Zone Menu "*" indicates a menu
0* GMT
1* AFRICA 17) EST 33) IRAN 49) PORTUGAL
2* AMERICA 18) EST5EDT 34) ISRAEL 50) PRC
3* ANTARCTICA 19* ETC 35) JAMAICA 51) PST8PDT
4* ARCTIC 20* EUROPE 36) JAPAN 52) ROC
5* ASIA 21) FACTORY 37) KWAJALEIN 53) ROK
6* ATLANTIC 22) GB-EIRE 38) LIBYA 54) SINGAPORE
7* AUSTRALIA 23) GB 39) MET 55) TURKEY
8* BRAZIL 24) GMT-0 40* MEXICO 56) UCT
9* CANADA 25) GMT 41* MIDEAST 57) UNIVERSAL
10) CET 26) GMT0 42) MST 58* US
11* CHILE 27) GMTPLUS0 43) MST7MDT 59) UTC
12) CST6CDT 28) GREENWICH 44) NAVAJO 60) W-SU
13) CUBA 29) HONGKONG 45) NZ-CHAT 61) WET
14) EET 30) HST 46) NZ 62) ZULU
15) EGYPT 31) ICELAND 47* PACIFIC
16) EIRE 32* INDIAN 48) POLAND
Press "Return" to redisplay, enter "=" to search or "?" for help, or
Select the number above that best represents the desired time zone: 20
EUROPE Time Zone Menu "*" indicates a menu
0* RETURN TO MAIN TIME ZONE MENU
1) AMSTERDAM 16) HELSINKI 31) MOSCOW 46) SOFIA
2) ANDORRA 17) ISLE_OF_MAN 32) NICOSIA 47) STOCKHOLM
3) ATHENS 18) ISTANBUL 33) OSLO 48) TALLINN
4) BELFAST 19) JERSEY 34) PARIS 49) TIRANE
5) BELGRADE 20) KALININGRAD 35) PODGORICA 50) TIRASPOL
6) BERLIN 21) KIEV 36) POLAND 51) UZHGOROD
7) BRATISLAVA 22) LISBON 37) PORTUGAL 52) VADUZ
8) BRUSSELS 23) LJUBLJANA 38) PRAGUE 53) VATICAN
9) BUCHAREST 24) LONDON 39) RIGA 54) VIENNA
10) BUDAPEST 25) LUXEMBOURG 40) ROME 55) VILNIUS
11) CHISINAU 26) MADRID 41) SAMARA 56) VOLGOGRAD
12) COPENHAGEN 27) MALTA 42) SAN_MARINO 57) WARSAW
13) DUBLIN 28) MARIEHAMN 43) SARAJEVO 58) ZAGREB
14) GIBRALTAR 29) MINSK 44) SIMFEROPOL 59) ZAPOROZHYE
15) GUERNSEY 30) MONACO 45) SKOPJE 60) ZURICH
Press "Return" to redisplay, enter "=" to search or "?" for help, or
Select the number above that best represents the desired time zone: 1
You selected EUROPE / AMSTERDAM as your time zone.
Is this correct? (Yes/No) [YES]: yes
Configuring the Time Differential Factor (TDF)
Default Time Differential Factor for standard time is 1:00.
Default Time Differential Factor for daylight saving time is 2:00.
The Time Differential Factor (TDF) is the difference between your
system time and Coordinated Universal Time (UTC). UTC is similar
in most respects to Greenwich Mean Time (GMT).
The TDF is expressed as hours and minutes, and should be entered
in the hh:mm format. TDFs for the Americas will be negative
(-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
will be positive (1:00, 2:00, etc.).
This time zone supports daylight saving time.
Is this time zone currently on daylight saving time? (Yes/No): no
Enter the Time Differential Factor [1:00]: 1:00
NEW SYSTEM TIME DIFFERENTIAL FACTOR = 1:00
Is this correct? [Y]: y
If you have Product Authorization Keys (PAKs) to register,
you can register them now.
Do you want to register any Product Authorization Keys? (Yes/No) [Yes] no
The following products are part of the OpenVMS installation;
they will be installed along with the OpenVMS operating system:
o Availability Manager (base) for OpenVMS Alpha
o CDSA for OpenVMS Alpha
o KERBEROS for OpenVMS Alpha
o SSL for OpenVMS Alpha
o Performance Data Collector (base) for OpenVMS Alpha
o HP Binary Checker for OpenVMS Alpha
You can also install the following optional products along with the
OpenVMS operating system:
o DECwindows Motif for OpenVMS Alpha
o DECnet-Plus for OpenVMS Alpha
o DECnet Phase IV for OpenVMS Alpha
o HP TCP/IP Services for OpenVMS
If you want to change your selections, you can do so later in the
installation by answering "NO" to the following question:
"Do you want the defaults for all options?"
Do you want to install DECwindows Motif for OpenVMS Alpha V1.7?
(Yes/No) [Yes] yes
Beginning with OpenVMS V7.1, the DECnet-Plus kit is provided with
the OpenVMS operating system kit. HP strongly recommends that
DECnet users install DECnet-Plus. DECnet Phase IV applications are
supported by DECnet-Plus.
DECnet Phase IV is also provided as an option.
If you install DECnet-Plus and TCP/IP you can run DECnet
applications over a TCP/IP network. Please see the OpenVMS
Management Guide for information on running DECnet over TCP/IP.
Do you want to install DECnet-Plus for OpenVMS Alpha V8.4?
(Yes/No) [Yes] no
Do you want to install DECnet Phase IV for OpenVMS Alpha V8.4?
(Yes/No) [Yes] no
Do you want to install HP TCP/IP Services for OpenVMS V5.7-13?
(Yes/No) [Yes] yes
The installation operation can provide brief or detailed descriptions.
In either case, you can request the detailed descriptions by typing ?.
Do you always want detailed descriptions? (Yes/No) [No] yes
The system was booted from a device containing the OpenVMS Alpha distribution.
Validation of signed kits is not supported in this restricted environment.
The following product has been selected:
DEC AXPVMS OPENVMS V8.4 Platform (product suite)
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
Configuring DEC AXPVMS OPENVMS V8.4: OPENVMS and related products Platform
This is a PLATFORM kit which installs OpenVMS Alpha, and,
optionally the following related products:
DECwindows Motif for OpenVMS Alpha
DECnet-Plus for OpenVMS Alpha
HP TCP/IP Services for OpenVMS Alpha
COPYRIGHT 1976, 21-APR-2010
HP Registered in U.S. Patent and Trademark Office.
in the United States and/or other countries.
Confidential computer software. Valid license from HP required for
possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and
Technical Data for Commercial Items are licensed to the U.S.
Government under vendor's standard commercial license.
HP shall not be liable for technical or editorial errors or
omissions contained herein. The information contained herein is
subject to change without notice.
Hewlett-Packard Development Company, L.P.
Houston Texas
Do you want the defaults for all options? [YES]
Availability Manager (base) for OpenVMS Alpha
This part installs the Data Collector files needed for the
Availability Manager (formerly DECamds).
CDSA for OpenVMS Alpha
This part installs CDSA for OpenVMS Alpha, which is the
Common Data Security Architecture.
KERBEROS for OpenVMS Alpha
This part installs KERBEROS for OpenVMS Alpha, which is a
network authentication protocol that provides authentication for
applications using secret-key cryptography.
SSL for OpenVMS Alpha
SSL (Secure Socket Layer) is a protocol that provides encryption
and authentication of TCP/IP data communications between a client
and a server.
Performance Data Collector (base) for OpenVMS Alpha
This part installs the run time portion of the Performance Data
Collector for OpenVMS Alpha.
HP Binary Checker for OpenVMS Alpha
This part installs the run time portion of the HP Binary Checker.
Alpha
Do you want to review the options? [NO] yes
DEC AXPVMS OPENVMS V8.4: OPENVMS and related products Platform
DEC AXPVMS VMS V8.4: OpenVMS Operating System
DECdtm Distributed Transaction Manager: YES
Support for DECnet-Plus or DECnet (Phase IV) for OpenVMS: YES
Programming Support: YES
Debugger Utility: YES
Image Dump Utility: YES
Macro libraries: YES
Macro-32 Migration Compiler: YES
TLB intermediary form of STARLET: YES
C Object Libraries: YES
C Header Files: YES
VMS text libraries of Ada declarations: YES
RMS Journaling Recovery Utility: YES
System Programming Support: YES
Delta Debugger: YES
System Dump Analyzer Utility: YES
Miscellaneous Symbol Table Files: YES
OpenVMS Management Station Software -- PC files: YES
Utilities: YES
Phone Utility: YES
Error Log Generator Utility: YES
XPG4 Internationalization Utilities: YES
World Wide PostScript Printing Subsystem: YES
Bliss Require Files: YES
Example Files: YES
Message Facility Files (HELP/MESSAGE): YES
Translated Image Support: YES
UETP Files: YES
DECwindows Server Support: YES
DEC AXPVMS DWMOTIF_SUPPORT V8.4: DECwindows Server Support
DECwindows workstation files: YES
video fonts: YES
100 dots-per-inch video fonts: YES
Euro base support: YES
Euro 100 dots-per-inch video fonts: YES
Delete any obsolete OpenVMS files: YES
Delete files archived by OpenVMS remedial kits: YES
Availability Manager (base) for OpenVMS Alpha
HP AXPVMS AVAIL_MAN_BASE V8.4: hp Availability Manager Base OS Drivers
CDSA for OpenVMS Alpha
CPQ AXPVMS CDSA V2.4-320
KERBEROS for OpenVMS Alpha
HP AXPVMS KERBEROS V3.1-152
SSL for OpenVMS Alpha
HP AXPVMS SSL V1.4-331: SSL for OpenVMS Alpha V1.4 (Based on OpenSSL 0.9.8h)
Run the installation verification procedure (IVP)?: YES
Performance Data Collector (base) for OpenVMS Alpha
HP AXPVMS TDC_RT V2.3-20: The Performance Data Collector (base) for OpenVMS
HP Binary Checker for OpenVMS Alpha
HP AXPVMS HPBINARYCHECKER V1.1: HP Binary Checker
DECwindows Motif for OpenVMS Alpha: YES
DEC AXPVMS DWMOTIF V1.7: DECwindows Motif
Install Low Bandwidth X (LBX) Support: YES
Install the DECwindows Motif Version 1.7 client software: YES
Install New Desktop: YES
Install Manual (reference) pages for the New Desktop: YES
Make the New Desktop the default desktop: YES
Install traditional DECwindows Desktop: YES
Programming Support for the C Language: YES
Programming Support for the Pascal Language: YES
Programming Support for the FORTRAN Language: YES
Programming Support for the New Desktop: YES
Programming examples: YES
Sound example files: YES
Programming examples for DECwindows: YES
Programming examples for the New Desktop: YES
Translated Image Support: YES
DECnet-Plus for OpenVMS Alpha: NO
DECnet Phase IV for OpenVMS Alpha: NO
HP TCP/IP Services for OpenVMS: YES
DEC AXPVMS TCPIP V5.7-13: HP TCP/IP Services for OpenVMS.
Applications: YES
Are you satisfied with these options? [YES] yes
Execution phase starting ...
The following products will be installed to destinations:
CPQ AXPVMS CDSA V2.4-320 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS DWMOTIF V1.7 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS DWMOTIF_SUPPORT V8.4 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS OPENVMS V8.4 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS TCPIP V5.7-13 DISK$ALPHASYS:[VMS$COMMON.]
DEC AXPVMS VMS V8.4 DISK$ALPHASYS:[VMS$COMMON.]
HP AXPVMS AVAIL_MAN_BASE V8.4 DISK$ALPHASYS:[VMS$COMMON.]
HP AXPVMS HPBINARYCHECKER V1.1 DISK$ALPHASYS:[VMS$COMMON.]
HP AXPVMS KERBEROS V3.1-152 DISK$ALPHASYS:[VMS$COMMON.]
HP AXPVMS SSL V1.4-331 DISK$ALPHASYS:[VMS$COMMON.]
HP AXPVMS TDC_RT V2.3-20 DISK$ALPHASYS:[VMS$COMMON.]
Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%
%PCSI-I-PRCOUTPUT, output from subprocess follows ...
% - Execute SYS$MANAGER:TCPIP$CONFIG.COM to proceed with configuration of
% HP TCP/IP Services for OpenVMS.
%
Portion done: 100%
The following products have been installed:
CPQ AXPVMS CDSA V2.4-320 Layered Product
DEC AXPVMS DWMOTIF V1.7 Layered Product
DEC AXPVMS DWMOTIF_SUPPORT V8.4 Layered Product
DEC AXPVMS OPENVMS V8.4 Platform (product suite)
DEC AXPVMS TCPIP V5.7-13 Layered Product
DEC AXPVMS VMS V8.4 Operating System
HP AXPVMS AVAIL_MAN_BASE V8.4 Layered Product
HP AXPVMS HPBINARYCHECKER V1.1 Layered Product
HP AXPVMS KERBEROS V3.1-152 Layered Product
HP AXPVMS SSL V1.4-331 Layered Product
HP AXPVMS TDC_RT V2.3-20 Layered Product
DEC AXPVMS OPENVMS V8.4: OPENVMS and related products Platform
HP AXPVMS KERBEROS V3.1-152
Configure and set up Kerberos
If Kerberos will be run on this system, but has not been
used previously, you need to perform the following steps.
o Run the Kerberos configuration procedure:
@SYS$STARTUP:KRB$CONFIGURE.COM
o Add the following line to SYS$MANAGER:SYSTARTUP_VMS.COM:
$ @SYS$STARTUP:KRB$STARTUP
o Add the following line to SYS$MANAGER:SYLOGIN.COM:
$ @SYS$MANAGER:KRB$SYMBOLS
Press RETURN to continue:
HP AXPVMS SSL V1.4-331: SSL for OpenVMS Alpha V1.4 (Based on OpenSSL 0.9.8h)
There are post installation tasks that you must complete
including the following items that are described in detail:
- ensuring SSL startup and logical names creation files
are executed
- updating or copying the necessary startup, shutdown and
configuration files from the installed template files
- running the Installation Verification Program (IVP)
Refer to the SSL release notes and the OpenVMS SSL documentation for
more information about activities that should be performed once the
installation has finished.
SSL has created the following directory structure and files in
PCSI$DESTINATION (which defaults to SYS$SYSDEVICE:[VMS$COMMON]):
[SSL] Top-level SSL directory
[SSL.ALPHA_EXE] Contains the images for the Alpha platform
[SSL.COM] Directory to hold the various command procedures
[SSL.DEMOCA] Directory structure to demo SSL's CA features
[SSL.DEMOCA.CERTS] Directory to hold the certificates and keys
[SSL.DEMOCA.CONF] Contains the configuration files
[SSL.DEMOCA.CRL] Contains revoked certificates and CRLs
[SSL.DEMOCA.PRIVATE] Directory for private keys and random data
[SSL.DOC] OpenSSL.org provided documentation & information
[SSL.INCLUDE] Contains the C Header (.H) files
[SSL.TEST] Contains the files used during the IVP
[SYS$STARTUP] Startup and shutdown templates and files
[SYSHLP] Release notes
[SYSHLP.EXAMPLES.SSL] SSL crypto and secure session examples
[SYSLIB] SSL shareable image files
[SYSTEST] SSL$IVP.COM test files
after upgrading from previous SSL versions
The SSL release notes provide information to verify the SSL startup,
shutdown, and configuration template files. Template files provide the
user with new features or changes, but do not overwrite existing command
procedures and configuration files. A product upgrade or re-installation
will not overwrite or create a new file version if the file has been modified.
It will only create the template files. It is suggested that you review
these files for any changes.
For more information, refer to the SSL Release Notes and other SSL
files using the system logical name definitions, or the subdirectory of
the PCSI destination device and directory.
including verifying startup command procedures and logical names.
Once the installation is complete, verify that SSL$STARTUP.COM is
located in SYS$MANAGER:SYSTARTUP_VMS.COM file. This will define the
SSL$ executive mode logical names in the SYSTEM logical name table,
and install the SSL shareable images in memory that reside in the
[SYSLIB] directory.
Also, add SSL$SHUTDOWN.COM to the SYS$MANAGER:SYSHUTDWN.COM file to remove
the installed images and deassign the SSL$ logical name definitions.
If you have customized the SSL command files for the site, it is
suggested that you compare the SSL provided template files with your
existing command procedures and take the appropriate action to update
your files. A product upgrade or re-installation will not overwrite
these files.
By default SYS$STARTUP: logical can be used to locate the SSL provided
startup files.
System managers should modify site-specific requirements in SSL files:
SSL$COM:SSL$SYSTARTUP.COM
SSL$COM:SSL$SYSHUTDOWN.COM
HP recommends that these site-specific SSL command procedures are utilized
to tailor the SSL installation specific to the reqirements of the system
or site. These files are located in the SSL$COM: directory.
Refer to SYS$HELP:SSL014.RELEASE_NOTES for more information.
The SSL product release notes contain up to date information regarding
bug fixes, known problems, and general installation information.
HP AXPVMS TDC_RT V2.3-20: The Performance Data Collector (base) for OpenVMS
Users of this product require the following privileges:
(CMKRNL,LOG_IO,WORLD,PHY_IO,SYSPRV,SYSLCK)
Users of this product require the following process resource limits:
WSQUO minimum 6000
A read-me file is available in SYS$COMMON:[TDC]TDC_README.TXT
Release notes are available in SYS$COMMON:[TDC]TDC_RELEASE_NOTES.TXT
or use PRODUCT EXTRACT RELEASE_NOTES
-------------------------------------------------------------------------------
HP AXPVMS HPBINARYCHECKER V1.1: HP Binary Checker
Release notes for HP Binary Checker available
The release notes for the OpenVMS HP Binary Checker are available in
the file SYS$HELP:HPBINARYCHECKER.RELEASE_NOTES.
DEC AXPVMS TCPIP V5.7-13: HP TCP/IP Services for OpenVMS.
Check the release notes for current status of the product.
The release notes for TCPIP Services for OpenVMS are available in the file
SYS$HELP:TCPIP*.RELEASE_NOTES.
The installation is now complete.
When the newly installed system is first booted, a special
startup procedure will be run. This procedure will:
o Configure the system for standalone or OpenVMS Cluster operation.
o Run AUTOGEN to set system parameters.
o Reboot the system with the newly set parameters.
You may shut down now or continue with other operations.
Process AXPVMS_INSTALL logged out at 23-DEC-2013 14:31:30.23
Press Return to continue...
****************************************************************
You can install or upgrade the OpenVMS ALPHA operating system
or you can install or upgrade layered products that are included
on the OpenVMS ALPHA distribution media (CD/DVD).
You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.
Please choose one of the following:
1) Upgrade, install or reconfigure OpenVMS ALPHA Version V8.4
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system
Enter CHOICE or ? for help: (1/2/3/4/5/6/7/8/9/?) 8
WARNING --
The normal OpenVMS startup procedure has not executed.
Some commands and utilities will not work as documented.
HP does not support PRODUCT INSTALL and other
PRODUCT operations in this environment.
Enter DCL commands -- Enter "LOGOUT" when done.
When you enter "LOGOUT" a message will be displayed saying
"Process SA_STARTUP_DCL logged out at <date> <time>",
and you will be returned to the menu.
$$$ show device d
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DKA0: Mounted alloc 0 ALPHASYS 16143120 1 1
DKA100: Mounted wrtlck 2 ALPHA084 137373 83 1
DVA0: Offline 0
DAD0: Online 0
$$$ show device dka0/full
Disk DKA0:, device type DEC RZ1DF-CB, is online, allocated, deallocate on
dismount, mounted, file-oriented device, shareable, available to cluster,
error logging is enabled.
Error count 0 Operations completed 113331
Owner process "SA_STARTUP" Owner UIC [1,4]
Owner process ID 00000024 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 2 Default buffer size 512
Total blocks 17713920 Sectors per track 128
Total cylinders 659 Tracks per cylinder 210
Logical Volume Size 17713920 Expansion Size Limit 4261348350
Volume label "ALPHASYS" Relative volume number 0
Cluster size 16 Transaction count 1
Free blocks 16143120 Maximum files allowed 16711679
Extend quantity 5 Mount count 1
Mount status Process Cache name "_DKA100:XQPCACHE"
Extent cache size 64 Max blocks in extent cache 1614312
File ID cache size 64 Blocks in extent cache 403152
Quota cache size 0 Maximum buffers in FCP cache 2935
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-5, subject to mount verification, file high-water marking,
write-through XFC caching enabled, write-back XQP caching enabled, hard
links enabled, special files enabled.
$$$ set volume/nohigh dka0
$$$ show device dka0/full
Disk DKA0:, device type DEC RZ1DF-CB, is online, allocated, deallocate on
dismount, mounted, file-oriented device, shareable, available to cluster,
error logging is enabled.
Error count 0 Operations completed 113430
Owner process "SA_STARTUP" Owner UIC [1,4]
Owner process ID 00000024 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 2 Default buffer size 512
Total blocks 17713920 Sectors per track 128
Total cylinders 659 Tracks per cylinder 210
Logical Volume Size 17713920 Expansion Size Limit 4261348350
Volume label "ALPHASYS" Relative volume number 0
Cluster size 16 Transaction count 1
Free blocks 16143120 Maximum files allowed 16711679
Extend quantity 5 Mount count 1
Mount status Process Cache name "_DKA100:XQPCACHE"
Extent cache size 64 Max blocks in extent cache 1614312
File ID cache size 64 Blocks in extent cache 403152
Quota cache size 0 Maximum buffers in FCP cache 2935
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-5, subject to mount verification, write-through XFC
caching enabled, write-back XQP caching enabled, hard links enabled,
special files enabled.
$$$ logout
Process SA_STARTUP_DCL logged out at 23-DEC-2013 14:41:28.17
****************************************************************
You can install or upgrade the OpenVMS ALPHA operating system
or you can install or upgrade layered products that are included
on the OpenVMS ALPHA distribution media (CD/DVD).
You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.
Please choose one of the following:
1) Upgrade, install or reconfigure OpenVMS ALPHA Version V8.4
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system
Enter CHOICE or ? for help: (1/2/3/4/5/6/7/8/9/?) 9
Shutting down the system
SYSTEM SHUTDOWN COMPLETE
halted CPU 0
halt code = 5
HALT instruction executed
PC = ffffffff80089a84
>>>
To make an optimal environment we need to give some attention to system parameters, some system file sizing and process quota and settings. Lets proceed with the system parameters.
System parameters edit
OpenVMS system parameters are very much like UNIX kernel parameters. System parameters take effect at system boot time, although there are system parameters that can be changed and have immediate effect on a running system. So, unless you want to reboot often, you should take some time to set the system parameters to their correct values for your system. New values for system parameters should be edited in the sys$system:modparams.dat. This file is node specific and should contain all changes you want to take effect to next time the system boots. This file is read by the autogen procedure. We recommend you comment on all changes in this file. CHANNELCNT should be set to a value at least as big as the UAF FILLM value. A good practice is to set the value to the biggest value of: the current value, the largest UAF FILLM value and 4096. Note that the SDK process will have the lower value of the UAF quota FILLM or the SYSGEN parameter CHANNELCNT.
Part of a modparams.dat:
. . ! Created during installation of OpenVMS AXP V7.3-1 26-JAN-2003 16:05:09.28 MIN_GBLSECTIONS=1000 ! ALLOCLASS=1 SHADOWING=2 SHADOW_SYS_DISK=1 SHADOW_SYS_UNIT=0 SHADOW_MAX_COPY=4 ! CHANNELCNT=8192 ! MAXPROCESSCNT=128 ! MIN_CTLPAGES=1536 ! SWAPFILE=0 !^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ . .
After you made the necessary changes to sys$system:modparams.dat invoke the autogen procedure:
$ @sys$update:autogen savparams setparams feedback
You can check the results of this procedure as follows:
$ set terminal/width=132
$ differences/parallel sys$system:setparams.dat
----------------------------------------------------------------------------------------
File SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;7 | File SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;6
-------------------- 11 ----------------------------------------- 11 -------------------
set SYSMWCNT 2102
set WSMAX 262144
set NPAGEDYN 4349952
set NPAGEVIR 19169280
set PAGEDYN 1794048
-------------------- 58 ----------------------------------------- 58 -------------------
set GBLPAGES 1118016 | set GBLPAGES 1105978
----------------------------------------------------------------------------------------
Number of difference sections found: 2 Number of difference records found: 6
DIFFERENCES /IGNORE=()/PARALLEL
SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;7
SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;6
If you are satisfied with the generated or changed system parameters, reboot the system when it suits you best:
$ @sys$update:autogen reboot
Other settings edit
PAGEFILESIZE When you increase the PGFLQUO UAF parameter, you should also increase the system's page file size as needed to accommodate the new PGFLQUO parameter. Autogen (see the system parameters section) also calculates new values for the swap, page and sysdump files, unless instructed not to do so by specifying a directive in sys$system:modparams.dat or by not specifying the genfiles phase. You can also use the sys$update:swapfiles.com procedure to set the pagefilesize manually:
$ @sys$update:swapfiles To leave a file size at its current value type a carriage return in response to its size prompt. Current file sizes are: Directory SYS$SPECIFIC:[SYSEXE] PAGEFILE.SYS;2 1056800 SYSDUMP.DMP;4 208583 SWAPFILE.SYS;3 16400 Total of 4 files, 1682393 blocks. There are 10110396 available blocks on SYS$SYSDEVICE. Enter new size for paging file: Enter new size for system dump file: Enter new size for swapping file: $
Installing GNV edit
Introduction edit
GNV stands for GNU is not VMS. It is a set of open source commands and utilities that are ported to OpenVMS. The GNV kit contains a port of the bash shell, the gnu diff utilities, the gnu file utilities, the gnu find utilities, gawk, grep, gzip, less, gnu make, man, sed, gnu shell utilities, gnu text utilities, (un)zip, a vi wrapper for tpu, vms(un)tar and wrappers for ar, cc, gcc and cpp. This list is not complete and more UNIX utilities become available with every new version of the GNV kit. GNV is an open source project with a web page http://gnv.sourceforge.net and several mailing lists. If you are planning to add tools to GNV, join the gnv developer list.
Installation: edit
First download the latest kit from the OpenVMS open source page at http://www.openvms.compaq.com/opensource or from the GNV project page at http://gnv.sourceforge.net. Print the installation instructions and use them to install the kit. Please read it carefully because it contains some important information. The requirements for installing and using GNV are:
- must install on an ODS-5 disk
- must use on an ODS-5 disk
To check the installation disk use the following command:
$ SHOW DEVICE DSA0: /FULL
Disk DSA0:, device type COMPAQ BB00911CA0, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled, device
supports bitmaps (no bitmaps active).
Error count 0 Operations completed 11118695
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1204 Default buffer size 512
Total blocks 17773524 Sectors per track 168
Total cylinders 5290 Tracks per cylinder 20
Logical Volume Size 17773524 Expansion Size Limit 17793024
Volume label "ALPHASYS" Relative volume number 0
Cluster size 3 Transaction count 1249
Free blocks 10110408 Maximum files allowed 2221690
Extend quantity 5 Mount count 1
Mount status System Cache name "_DSA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 1011040
File ID cache size 64 Blocks in extent cache 237132
Quota cache size 0 Maximum buffers in FCP cache 630
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-5, subject to mount verification, protected subsystems
enabled, write-through caching enabled, access dates enabled, hard links
enabled.
Disk $1$DKA600:, device type COMPAQ BB00911CA0, is online, member of shadow set
DSA0:, error logging is enabled.
Error count 0 Shadow member operation count 10118018
Allocation class 1
And this is not all the information but the important bit is at the bottom of the example text. Right after the Volume Status: header it says ODS-5 in this case. So this disk should be OK for use. Also note that hard links are enabled. For UNIX portability it is generally a good idea to have this enabled. It is also a good idea to enable access dates on a volume because this is a POSIX requirement. We also recommend using multi member shadow sets. First of all, shadow sets are more secure, i.e., you won't lose all your data when a disk breaks down, but also because shadow set names have no “$”-sign in them. The “$”-sign has a special meaning in UNIX shell scripts. To use a “$”-sign in a name you'll have to escape the “$”-sign with a “\”-sign.By the way you can and should at least use single member shadow sets to prevent this got-ya. To make a disk ODS-5 compatible use the following command:
$ SET VOLUME <device>: /STRUCTURE=5
To enable hard links and access dates use the following command:
$ SET VOLUME <device>: /VOLUME_CHARACTERISTICS=(HARDLINKS, ACCESS_DATES)
Be aware that enabling hard links can take a considerable amount of time! Everything you ever wanted to know about shadowing and a description on how you can mount your disks as shadow sets is described in the OpenVMS documentation: HP Volume Shadowing for OpenVMS. The “help” command can help you as well.
Another thing I would like to note here is high-water marking. This is another typical OpenVMS security feature that is on by default. High-water marking guarantees that a user cannot read data that was not written by the user, by destroying all data in the disk block after the EOF marker. There is a small performance penalty in doing this. Although the penalty is only marginal these days, many people will advice you to turn it off. You can do so by giving the following command:
$ SET VOLUME <device>: /NOHIGHWATER_MARKING
Disabling high-water marking is not mandatory for the installation of GNV or the UNIX portability.
To do a default install of the current GNV software, follow these steps also described in the documentation:
- Log in to the SYSTEM account (at the login prompt, enter user name SYSTEM and the appropriate password), or an account with equivalent privileges.
- At the DCL prompt ($), go to the directory where you saved the executable you downloaded from the Internet and extract the PCSI kit by running the executable:
$ RUN DEC-AXPVMS-GNV-V0106-002-1.PCSI_SFX_AXPEXE
- Type the following command, as shown:
$ PRODUCT INSTALL GNV
- When you enter the PRODUCT INSTALL command, the system responds with a display similar to the following:
The following product has been selected:DEC AXPVMS GNV V1.6 Layered Product Do you want to continue? [YES]
Continue the procedure by pressing the ENTER key for the default answer (YES). The procedure might take several minutes and numerous messages might be displayed on the screen. In response to each prompt displayed by the system, choose the default answer by pressing the ENTER key.
- To use GNV we need to do some system wide setup. To do this we start the following DCL command procedure:
$ @SYS$STARTUP:GNV$STARTUP.COM
To do this setup every time we boot our system we need to add the above command to the system startup procedure SYS$MANAGER:SYSTARTUP_VMS.COM. So fire up the editor:
$ EDIT SYS$MANAGER:SYSTARTUP_VMS.COM
Go to the bottom of the file (DO bottom) and enter the following lines before the $ EXIT:
$! $! GNV $! $ file := SYS$STARTUP:GNV$STARTUP.COM $ IF F$SEARCH(file) .NES. "" THEN @'file' $!
And exit the editor with <Crtl>Z. Note: The GNV$STARTUP.COM procedure uses the procedure sys$common:[sys$startup]gnv_destination.com to define the location where GNV was installed. You will have to modify this procedure if you move GNV to a different location by hand.
- There's also some user setup that we'll need to do. For our current login session do the following:
$ IF F$TRNLNM(“GNU”,"LNM$SYSTEM_TABLE") .NES. “” THEN @GNU:[LIB]GNV_SETUP.COM
And if we want this user setup to happen when you log in, we must add the above line to our SYS$LOGIN:LOGIN.COM. This counts for every user on your system who wants to use the GNV tools. If we want this to happen for every user on our system, we could add the line to the system wide login procedure SYS$MANAGER:SYLOGIN.COM ($ EDIT 'F$TRNLNM(“SYS$SYLOGIN”)'.COM). Just remember to add the line before the EXIT statement (login scrips usually do things depending on the current mode login (F$MODE), note that the gnv setup procedure must be made to work in interactive mode if you plan to use it on the command line). And of course, no reboot is needed.
Process quotas edit
Managing process quotas is another OpenVMS stronghold. It allows the system to manage the system resources and maintain an acceptable performance for all processes on the system. The following recommendation comes from the July 2003 issue of “Optimizing Java Technology Software Performance on HP OpenVMS”. You can find this document at the HP OpenVMS e- Business Technology page http://www.openvms.compaq.com/ebusiness/technology.html. Please note that the suggested quota's are a minimum requirement for UNIX compatibility. These quota's are specified for user accounts running JAVA applications, but in general its a good idea to give porters and users running ported open source software the same quota's. The look and feel (performance) on OpenVMS will more closely resemble the look and feel on other platforms.
Account quotas edit
Log is as user SYSTEM and go to the SYS$SYSTEM directory:
$ SET DEFAULT SYS$SYSTEM:
Start the account management program:
$ MCR AUTHORIZE
Show your account settings (in the example below the DEFAULT account is shown, this is a special account used for account creation):
UAF> sho default Username: DEFAULT Owner: Account: UIC: [200,200] ([DEFAULT]) CLI: DCL Tables: DCLTABLES Default: [USER] LGICMD: Flags: DisUser Primary days: Mon Tue Wed Thu Fri Secondary days: Sat Sun No access restrictions Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: 90 00:00 Pwdchange: (pre-expired) Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 100 Bytlm: 64000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 150 JTquota: 4096 Prclm: 8 DIOlm: 150 WSdef: 2000 Prio: 4 ASTlm: 250 WSquo: 4000 Queprio: 4 TQElm: 10 WSextent: 16384 CPU: (none) Enqlm: 2000 Pgflquo: 50000 Authorized Privileges: NETMBX TMPMBX Default Privileges: NETMBX TMPMBX UAF>
We are going to change the following minimum account quotas:
| Name | Value |
|---|---|
| Fillm | 4096 |
| Wsdef | 2048 |
| Wsquo | 4096 |
| Wsextent | 16384 |
| Wsmax | 16384 |
| Pgflquo | 2097152* |
| bytlm | 400000 |
| biolm | 150 |
| diolm | 150 |
| tqelm | 100 |
* Indicates the appropriate number for Pgflquo (2 x heap-size). For example, 128 MB (2*128*1024*1024)/512 = 524288. When you increase the Pgflquo parameter, you should always increase the system's page file size to accommodate the new Pgflquo parameter, if required.
To change the values of the parameters do the following:
UAF> MODIFY <account> /<parameter>=<value>
You can change multiple parameters in th same command just add another /= for each value you need to change. To change the WSDEF, WSQUO and WSEXTENT for the DEFAULT account you would enter the following command:
UAF> MODIFY DEFAULT /WSDEF=2048 /WSQUO=4096 /WSEXTENT=16384
You exit the AUTHORIZE utility by typing EXIT, or
<Ctrl>Z
(It may be possible that the terminal emulator you are using correctly maps the EXIT function to the F10 function key). As said before, the DEFAULT account is used as a template for the creation of new accounts. If you want to raise the default quotas for all new accounts you are going to create on your system, it may be a good idea to modify the DEFAULT account. Changing the default account will not change any setting for existing accounts. Check and modify existing accounts as needed.
Setting up porting accounts edit
So far we have set the correct environment for our porting attempts. Lets summarize the steps involved. To create porting accounts one has to follow a few steps:
- Setting up the OpenVMS porting system with the right system parameters
- Installing and starting GNV, compilers and other porting tools
- Setting up the default UAF account
- Creating additional porting accounts and/or modifying existing accounts.
- Creating and modifying home directories for porters.
After that, in order to use the changed account settings, you must log out and back in again.
Creating additional accounts edit
To create additional porting accounts, you can use the following commands:
$ mcr authorize
UAF> add 'user' /uic=['group','member'] /device='userdevice': /directory=['user'] /passw='secret'/flag=nodisuser/nopwdexp
UAF> exit
$ create/dir 'userdevice':['user'] /owner='user'
$ create/dir 'userdevice':['user'.temp]/owner='user'
$
$ create 'userdevice':['user']login.com
$! login.com for OpenOffice portingroup member
$
$ set term/dev=vt300
$ set term/line/insert
$! start gnv
$ @GNU:[lib]GNV_SETUP.COM
$!
$! setup tools
$ set proc/parse_style=extended
$ set process /case_lookup=(blind)
$ define/job decc$pipe_buffer_size 65000
$
$
$ scratch = f$trnlnm("sys$login") - "]" + ".temp]"
$ define/job sys$scratch 'scratch' $!
$ exit
<Ctrl>Z
$ create 'userdevice':['user'].bashrc
# .bashrc
#
PATH=$PATH:/usr/bin:/usr/local/bin
export PATH
export GNV_DISABLE_DCL_FALLBACK=1
<Ctrl>Z
$
A procedure for creating a number of porting users including a example run can be found in appendix 3
PART III: Hints and tips on using the porting environment and the GNV tools edit
Working with GNV edit
When you have installed GNV correctly you should be able to use UNIX commands like ls right from DCL. However if you have LSE installed the ls command will start the LSE editor instead. When you type bash at the DCL prompt. The bash shell is started and from that point on everything works as if you were using a UNIX box. There are however some minor but important differences. You may know that UNIX systems use a hierarchical file-system and OpenVMS does not. However some of the important hierarchy is mimicked under OpenVMS. By default the / directory points to the OpenVMS GNU:[000000] directory. The /bin directory points to the OpenVMS GNU:[bin] directory. Etc. In short the / directory is not the root of a disk! You can access other locations by typing /device-name or concealed device logical/directory. I.E. DSA50:[kits.gnu] becomes /dsa50/kits/gnu. When in bash you can enter most DCL commands, unless there is a name conflict like the ls - LSE problem. In that case you can enter the bash dcl command and enter the DCL command behind it. I.E. the DCL LS Readme command becomes dcl “ls Readme” in bash and opens the Readme file in LSE. If you don't want bash to “Fall Back” to DCL to execute commands, do the following in BASH:
bash$ export GNV_DISABLE_DCL_FALLBACK=1
We recommend putting this command in the .bashrc procedure in your login directory. See the example procedure in the “creating additional accounts” section. By the way you can always use the BASH dcl command to execute any DCL command!
Tips edit
- always work on ODS-5 disks
$ SET VOLUME <device>: /STRUCTURE=5
- always enable ODS-5 extended filename parsing
$ SET PROCESS /PARSE_STYLE=EXTENDED
(you can put this line in your LOGIN.COM)
- because of the way bash handles pipes at the moment we need to do the following
$ DEFINE/JOB DECC$PIPE_BUFFER_SIZE=65000
(you can put this line in your LOGIN.COM)
- the best way to handle UNIX symbolic links is to use hard links on the disk you are working from
$ SET VOLUME <device>: /VOLUME_CHARACTERISTICS=(HARDLINKS)
Please note that this can take a considerable amount of time.
- it may be necessary to support POSIX style access dates
$ SET VOLUME <device>: /VOLUME_CHARACTERISTICS=(ACCESS_DATES)
- when running configure scripts, it may be a good idea to disable DCL fall back
bash$ export GNV_DISABLE_DCL_FALLBACK=1
(you can put this in your .bashrc)
If you want to know more about using UNIX or bash, there is plenty of information available on the Internet. If you like books better, take a look at the offerings from O'Reilly http://www.oreilly.com/. I suggest you do take some time to learn the UNIX environment before continuing.
Part IV: Building open source software edit
Most of you probably know that open source means that the software is usually distributed in source form. To use the software on your system you need to build it yourself. To make this building much easier the GNU community developed the GNU build tools. These tools not only make your life much easier, they also make the life of the open source developers much easier. Now let's look at how you would build some open source software on a UNIX or Linux box.
- Download the source distribution from the Internet. Most of the time this will be a .tar.gz file but you'll also find .tgz, .tar.Z .tar.bzip2 or .zip files.
- Create a directory
% mkdir <name>
- Go to the directory you just created
% cd <name>
- Unpack the file (some options may not work on OpenVMS yet)
- .tar.gz
- or
% zcat <filename> | tar xvf
- or
% tar xvzf <filename>
- and
% gunzip <filename>
% tar xvf <filename - .gz>
- .tgz see .tar.gz
- .tar.Z see .tar.gz or
- and
% uncompress <filename>
% tar xvf <filename - .Z>
- .tar.bz2
- or
% bz2cat <filename> | tar xvf -
- and
% bunzip2 <filename>
% tar xvf <filename - .bz2>
- .zip
% unzip <filename>
- .tar.gz
- Look for the configure script. This script may be in the directory you're in, but it may also be in the directory that was created by unpacking the distribution file. I.e. If the file you downloaded from the Internet was called tar-1.2.4.tar.gz it is possible that you now have a directory named tar-1.2.4 in your current directory. Enter that directory to look for a configure file. If you don't find one look for files with uppercase names like README or INSTALL.
- When you found the configure script, run it
% ./configure
- When all go's well you can build the executable(s)
% make
- And install the package (usually you must first become the root user before you can install something)
% make install
And that's all folks.
Well, that was all when everything works the way it's supposed to. And even on a UNIX box things can go wrong. To analyze what went wrong do the following:
- read the files with uppercase names and find out if you meet the prerequisites, find out if you need to do something special for your UNIX (OpenVMS) version (after all UNIX (OpenVMS) != UNIX)
- try this may give you an idea about extra parameters you may have to specify with the ./configure command.
./configure --help
- check the files that were generated by the configure script: config.cache, config.log, config.status, config.h and Makefile(s)
If this didn't help you may need to make your hands dirty.
The GNU build system edit
Didn't I say before that the GNU build system would make your life much easier? Well it does. But let me first explain what may go wrong in the last example. The configure script and the Makefile.in file(s) may have been created before your UNIX (OpenVMS!) system or system version came into existence, so it doesn't know about your systems specifics. Thinking about OpenVMS for a moment, probably none of the configure scripts and make files out there, know anything about our GNV environment on OpenVMS. But let's get back to the problem at hand. To make the configure script and the Makefile.in file(s) aware of our systems specifics we will need to add some steps to our build example. The following steps come between steps 5 and 6:
a.
% aclocal
b.
% autoconf
c.
% automake -a
To make this work, your system should have these packages and GNU make, m4, texinfo and GNU tar readily installed. For most open source UNIX clones like Linux, FreeBSD, NetBSD and MacOS X, this is true. But for many commercial UNIX systems this isn't the case. As for OpenVMS, only GNU make is available at the moment. The best thing for most commercial UNIX systems is to check out if the manufacturer of your UNIX system made the missing tools available for download. If not check out the latest versions of the missing tools from the GNU web site. If nothing worked out, you are in the same position as us with our GNV environment on OpenVMS. At this point I think that it should be clear to us that we need all these tools a.s.a.p. If you want to know more about the gnu build system, take a look at the following web site(s): GNU Autoconf, Automake and Libtool: http://sources.redhat.com/autobook/
Recommendation for OpenVMS edit
Because of constant updates to GNV we recommend to get the latest GNV sources from the CVS repository and build the GNV kit yourself. See the build instructions on http://www.4ovms.dyndns.org. Don't forget to raise the pipe buffer size.
bash$ dcl “define/job DECC\$PIPE_BUFFER_SIZE 65000”
And don't forget to disable DCL fall back.
bash$ export GNV_DISABLE_DCL_FALLBACK=1
Always check the configure script for conftest.dir. Change the name of this file to something like conftest.ddd
bash$ mv configure configure.org bash$ sed 's/conftest\.dir/conftest\.ddd/g' configure.org > configure
Use the configure option --build=. For OpenVMS Alpha the configure option is --build=alpha-hp-vms. Because the GNV bash version is somewhat outdated, some shell scripts do not work. One of those scripts is called depcomp. This script is used to determine dependency's during compilation. To get rid of this dependency checking, you can add the --disable-dependency-tracking option to the configure command.
The OpenVMS C runtime library edit
The C Run Time Library or CRTL is an OpenVMS shared library containing most of the “standard” C functions. I quoted the word standard because a) there are a lot of standards and I didn't say which one. b) every standard is bit of a moving target.Since the DII COE initiative, HP intends to make the CRTL compliant to the latest X-Open standard. Because of the architectural differences between OpenVMS and UNIX this is not an easy task, especially if you also want to maintain backwards compatibility.The OpenVMS CRTL developers decided to add these new features gradually with every new OpenVMS and CRTL release.HP also decided that these new features will become available on both the Alpha and the new Itanium architecture. Some features may also become available on the VAX, but because ODS-5 extended filename support is not available on the VAX, the functionality that is essential to open source porting will probably never become available on the VAX.The new CRTL features can be categorized in two groups:
- existing functions with new and more standard functionality
- completely new functions to make the CRTL more standard (X-Open v.6) compliant.
For the functions in group one the classic behavior is standard and to use the new functionality you need to set feature switches (more on those later).The functions in group two can be divided in two more groups
- functions that should work the same in both the classic OpenVMS environment as in the new UNIX like environment
- functions that should not work the same in both environments
For this last group, think about functions that use or return a path. For this group the behavior of these functions is determined by the previously mentioned feature switches.
So what are these feature switches and how can I set them? edit
I will not explain what feature switches there are and what they do exactly because you can read all about them in the CRTL help, the CRTL release notes and the CRTL Reference manual. But I will show you some of the interesting new ones in OpenVMS 8.4. And I will show you how you can change their values. So let's first get to the most interesting new feature switch, especially when you're new to porting. It is DECC$UNIX_LEVEL. The text below is from the CRTL reference manual (CRTL 1-36):
With the DECC$UNIX_LEVEL logical name, you can manage multiple C RTL feature logical names at once. By setting a value for DECC$UNIX_LEVEL from 1 to 100, you determine the default value for groups of feature logical names. The value you set has a cumulative effect: the higher the value, the more groups that are affected. Setting a value of 20, for example, enables all the feature logicals associated with a DECC$UNIX_LEVEL of 20, 10, and 1.
The principal logical names affecting UNIX like behavior are grouped as follows:
1 General corrections
10 Enhancements
20 UNIX style filenames
30 UNIX style file attributes
90 Full UNIX behavior - No concessions to OpenVMS
Level 30 is appropriate for UNIX like programs such as BASH and GNV.
The DECC$UNIX_LEVEL values and associated groups of affected feature logical names are:
General Corrections (DECC$UNIX_LEVEL 1)
DECC$FIXED_LENGTH_SEEK_TO_EOF 1
DECC$POSIX_SEEK_STREAM_FILE 1
DECC$SELECT_IGNORES_INVALID_FD 1
DECC$STRTOL_ERANGE 1
DECC$VALIDATE_SIGNAL_IN_KILL 1
General Enhancements (DECC$UNIX_LEVEL 10)
DECC$ARGV_PARSE_STYLE 1
DECC$EFS_CASE_PRESERVE 1
DECC$STDIO_CTX_EOL 1
DECC$PIPE_BUFFER_SIZE 4096
DECC$USE_RAB64 1
UNIX style filenames (DECC$UNIX_LEVEL 20)
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION 1
DECC$EFS_CHARSET 1
DECC$FILENAME_UNIX_NO_VERSION 1
DECC$FILENAME_UNIX_REPORT 1
DECC$READDIR_DROPDOTNOTYPE 1
DECC$RENAME_NO_INHERIT 1
DECC$GLOB_UNIX_STYLE
UNIX like file attributes (DECC$UNIX_LEVEL 30)
DECC$EFS_FILE_TIMESTAMPS 1
DECC$EXEC_FILEATTR_INHERITANCE 1
DECC$FILE_OWNER_UNIX 1
DECC$FILE_PERMISSION_UNIX 1
DECC$FILE_SHARING 1
UNIX compliant behavior (DECC$UNIX_LEVEL 90)
DECC$FILENAME_UNIX_ONLY 1
DECC$POSIX_STYLE_UID 1
DECC$USE_JPI$_CREATOR 1
DECC$DETACHED_CHILD_PROCESS 1
Notes:
- Defining a logical name for an individual feature logical supersedes the default value established by DECC$UNIX_LEVEL for that feature.
- Future revisions of the C RTL may add new feature logicals to a given DECC$UNIX_LEVEL. For applications that specify that UNIX level, the effect is to enable those features by default.
Please note that not all the available feature switches are listed in the quote. The ones not listed are not part of any UNIX level! Read the CRTL help, release notes and documentation for a full list of supported feature switches and their intended use. You may already have noticed one way of setting these feature switches. You can define a logical with the same name and appropriate value. And because the feature switches alter the behavior at runtime, you don't have to recompile while playing with the switches. But when you are finished determining the appropriate values for the switches you may want to set their values from within your program. You can of course do this by setting the logical from within your program, but there is a much better way. The CRTL functions decc$feature_get_index, decc$feature_get_name, decc$feature_get_value, and decc$feature_set_value are specially designed for this task.
Below you'll see a small example program:
static int set_feature_default(char *name, int value)
{
int index = decc$feature_get_index(name);
if (index == -1 || decc$feature_set_value(index, 0, value) == -1)
{
perror(name);
return -1;
}
return 0;
}
static void my_init( void)
{
set_feature_default("DECC$POSIX_SEEK_STREAM_FILE" , TRUE);
set_feature_default("DECC$ARGV_CASE_PARSE_STYLE" , TRUE);
set_feature_default("DECC$EFS_CASE_PRESERVE" , TRUE);
set_feature_default("DECC$FILE_SHARING" , TRUE);
}
It is not too difficult to add code like this to a program, but there's a catch. Feature switches like DECC$ARGV_PARSE_STYLE need to be set before the arguments are being parsed and this happens somewhere between image activation and the call to the programs main function. The process of what happens before your program starts is documented in the OpenVMS Programming Concepts Manual. In chapter 18 you'll find a complete flow of what happens and when (see picture below).
'insert Picture'
The important thing to note here is the LIB$INITIALIZE function. What we are going to do is create a source file that defines a LIB$INITIALIZE function that points to a function that sets the feature switches to their appropriate values. Now let's go back to the example I used above. An enhanced version of the example is presented below:
#pragma extern_model save
#pragma extern_model strict_refdef "LIB$INITIALIZE" nowrt, long
#if __INITIAL_POINTER_SIZE
# pragma __pointer_size __save
# pragma __pointer_size 32
#else
# pragma __required_pointer_size __save
# pragma __required_pointer_size 32
#endif
/* Set our contribution to the LIB$INITIALIZE array */
void (* const iniarray[])() = {my_init, } ;
#if __INITIAL_POINTER_SIZE
# pragma __pointer_size __restore
#else
# pragma __required_pointer_size __restore
#endif
#pragma extern_model restore
/*
** Force a reference to LIB$INITIALIZE to ensure it
** exists in the image.
*/
int LIB$INITIALIZE();
globaldef int (*lib_init_ref)() = LIB$INITIALIZE;
Put both parts of the example in one source file. Compile and link with your program to make it work. The beauty of it is that you don't have to change the program you are porting to set the feature switches! If you want to see a more complete example, take a look at GNU:[src.GNV.CRTLSUP.SRC]]VMS_CRTL_INIT.C file. This file is used by some of the GNV tools.
Recommendation edit
A good starting point is UNIX level 30, but don't use the DECC$UNIX_LEVEL feature switch. Set the individual feature switches that make up UNIX level 30 and increase DECC$PIPE_BUFFER_SIZE to at least 8192. The reasons for not using the DECC$UNIX_LEVEL feature switch are compatibility with OpenVMS 7.3-1 and the simple fact that you may not need all the feature switches that make up level 30 or you want to use different values (see the recommendation for DECC$PIPE_BUFFER_SIZE).
Macros edit
Predefined macros edit
The list below is a list of predefined macros on OpenVMS 7.3-2 Alpha using the Standard DECC C compiler version 6.5.
These macros are in effect at the start of the compilation. ----- ------ --- -- ------ -- --- ----- -- --- ------------ __G_FLOAT=1 __DECC=1 vms=1 VMS=1 __32BITS=1 __PRAGMA_ENVIRONMENT=1 __CRTL_VER=70320000 __vms_version="V7.3-2 " CC$gfloat=1 __X_FLOAT=1 vms_version="V7.3-2 " __DATE__="Feb 7 2004" __STDC_VERSION__=199901L __DECC_MODE_RELAXED=1 __DECC_VER=60590001 __VMS=1 __ALPHA=1 VMS_VERSION="V7.3-2 " __IEEE_FLOAT=0 __VMS_VERSION="V7.3-2 " __STDC_HOSTED__=1 __TIME__="13:54:21" __Alpha_AXP=1 __VMS_VER=70320022 __BIASED_FLT_ROUNDS=2 __INITIAL_POINTER_SIZE=0 __STDC__=1 __LANGUAGE_C__=1 __vms=1 __alpha=1 __D_FLOAT=0
The following macros are important for porting:
| Macro | Remark |
|---|---|
| VMS, vms | Are the ones we can use for general OpenVMS specific stuff |
| ALPHA, Alpha_AXP, __alpha | Can be used for Alpha specific stuff |
| VAXC, VAX11C, vaxc, vax11c | Can be used for VAX specific stuff |
| IA64, ia64 | Can be used for Itanium (ia64) specific stuff |
| __VMS_VER | Can be used for OpenVMS version specific stuff (please use __CRTL_VER instead |
| __DECC_VER | Can be used for compiler version specific stuff |
| __CRTL_VER | Can be used for CRTL version specific stuff |
Please note that I only included the preferred format of the macros, most of them also exist without the two dashes in front.
Other macros edit
There are also numerous other macros that change the behavior of one or more CRTL functions.
| Macro | Remark |
|---|---|
| _XOPEN_SOURCE_EXTENDED | Makes visible XPG4-extended features, including traditional UNIX based interfaces not previously adopted by X/Open. Standard Selected: XPG4 V2. Other Standards Implied: XPG4, ISO POSIX-2, ISO POSIX-1, ANSI C |
| _XOPEN_SOURCE | Makes visible XPG4 standard symbols and causes _POSIX_C_SOURCE to be set to 2 if it is not already defined with a value greater than 2. Standard Selected: XPG4. Other Standards Implied: XPG4, ISO POSIX-2, ISO POSIX-1, ANSI C |
| _POSIX_C_SOURCE==199506 | Header files defined by ANSI C make visible those symbols required by IEEE 1003.1c-1995. Standard Selected: IEEE 1003.1c-1995. Other Standards Implied: ISO POSIX-2, ISO POSIX-1, ANSI C |
| _POSIX_C_SOURCE==2 | Header files defined by ANSI C make visible those symbols required by ISO POSIX-2 plus those required by ISO POSIX-1. Standard Selected: ISO POSIX-2. Other Standards Implied: ISO POSIX-1, ANSI C |
| _POSIX_C_SOURCE==1 | Header files defined by ANSI C make visible those symbols required by ISO POSIX-1. Standard Selected: ISO POSIX-1. Other Standards Implied: ANSI C |
| STDC_VERSION__==199409 | Makes ISO C Amendment 1 symbols visible. Standard Selected: ISO C Amendment 1. Other Standards Implied: ANSI C |
| _ANSI_C_SOURCE | Makes ANSI C standard symbols visible. Standard Selected: ANSI C. Other Standards Implied: None. |
| _POSIX_EXIT | To enable the ISO POSIX-1 compatible exit function. |
| _BSD44_CURSES | This macro selects the Curses package from the 4.4BSD Berkeley Software Distribution. |
| _VMS_CURSES | This macro selects a Curses package based on the VAX C compiler. This is the default Curses package. |
| _SOCKADDR_LEN | This macro is used to select 4.4BSD-compatible and XPG4 V2- compatible socket interfaces. These interfaces require support in your underlying TCP/IP software. Contact your TCP/IP vendor to inquire if the version of TCP/IP software you run supports 4.4BSD sockets. (HP TCP/IP supports this feature, as far as I can tell, Prosess Softwares Multinet and TCPware don't) |
| _LARGEFILE | The C RTL provides support for compiling applications to use file sizes and offsets that are two gigabytes (GB) and larger. This is accomplished by allowing file offsets of 64-bit integers. |
| __USE_LONG_GID_T | To compile an application for 32-bit UID/GID support. |
| _DECC_SHORT_GID_T | To compile an application for 16-bit UID/GID support |
Please read the CRTL help and/or CRTL Reference Manual for more information.
Recommendation edit
Please don't use general macros like VMS, vms , or __vms. Use CRTL_VER instead. The C Runtime Library is becoming more “standard” with every new version of the CRTL. Fixes may no longer be necessary in newer versions of the CRTL. In some cases program functionality has been crippled with #ifndef VMS in a way that is no longer necessary. Using CRTL_VER will allow us to control more precisely what needs to be changed for the many different versions of the CRTL. When the macro CRTL_VER doesn't exist, define it with the value of __VMS_VER.
# if defined(__VMS_VER) && !defined(__CRTL_VER)
# define __CRTL_VER __VMS_VER
# endif
When compiling open source programs in DCL, add the /DEFINE=_POSIX_EXIT to your CC command! This is the default when compiling under bash.
GCC wrapper edit
The GNV kit does not come with gcc but with a wrapper that uses HP C and C++ compilers to do its compilation work and it uses the standard OpenVMS Linker as a substitute for ld. By the way there is also a ar wrapper that uses the standard OpenVMS Librarian.The GCC wrapper does quite a good job, but it isn't perfect. Also note that the HP compilers are very strict. By this I mean that they complain immediately when something may not be entirely correct. So we'll see a lot of warnings when compiling open source software.You can see all the options the gcc wrapper supports by using the -h or -help option.I would like to note the following on the behavior of the GCC wrapper, the wrapper adds the /DEFINE=_POSIX_EXIT to the compile statement by default.The -Wc and -Wl gcc option may come in handy if you want to add a HP CC, CPP or LINK option to the gcc command line, that does not seem to be implemented.One gcc option you sometimes need is -names_as_is_short. This will make the compiler case sensitive and it allows function names with more than 32 characters.You may get into trouble with the gcc -g option in configure scripts. Many configure scripts use this option by default. This options is used to compile and/or link with debug information included in the program. The problem is that on UNIX systems a program compiled and linked with debug information doesn't start the debugger when executed. This is quite different from what we OpenVMS people are used to. If you see the debugger prompt pop up when running a configure script, either remove the -g option from the configure script or start configure with CFLAGS=””.
Fork() edit
The fork issue is quite high on the issue list because it is quite common to Open Source programs and we don't have this function on OpenVMS. We do have vfork() on OpenVMS, but the implementation of vfork() on OpenVMS is also not standard compliant. We can however use it to work around most of the fork() calls in opensource software. Before we dig into the workarounds, lets first determine what fork() is supposed to do. The fork() function is the UNIX standard way to create a new process. The new (child) process is an exact duplicate of the calling (parent) process except:
- the child process has a unique process ID
- the child process ID does not match any active process group ID
- the child process has a different parent process ID
- the child process has its own copy of the parent's open file descriptors
- the child process has its own copy of the parent's open directory streams
- the child process may have its own copy of the parent's message catalog descriptors
- the child process' values of tms_utime, tms_stime, tms_cutime and tms_cstime are set to 0
- the time left until an alarm clock signal is reset to 0
- all semadj values are cleared
- file locks set by the parent process are not inherited by the child process
- the set of signals pending for the child process is initialized to an empty set
- interval timers are reset in the child process
After fork(), both parent and child processes are capable of executing independently before either one terminates. The fork() function returns 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, -1 is returned to the parent process, no child process is created and errno is set to indicate the error. The vfork() function is on most systems identical to the fork() function. On some systems, child's created with vfork() can share data or code segments with their parent process. On OpenVMS the vfork() function only provides the setup necessary for a subsequent call to an exec function. No child process is create by a vfork call! When vfork is called:
- it saves the return address (the address of the vfork call) to be used later as a return address for the call to an exec function
- it saves the current context
- it returns the integer 0 the first time it is called (before the call to an exec function is made). After the exec call is made, the exec function returns control to the parent process, at the point of the vfork() call, and returns the process ID of the child as the return value.
Some of you may already see some similarities between fork() and OpenVMS vfork(). If fork() is closely followed by an exec call, we can use OpenVMS vfork() with a little work. If fork() stands on it's own, we're still screwed.
Example 1 (from GNU tar 1.15.1 lib/rmdir.c):
#ifndef __VMS
cpid = fork ();
#else /* VMS */
cpid = vfork ();
#endif /* VMS */
switch (cpid)
{
case -1: /* cannot fork */
return -1; /* errno already set */
case 0: /* child process */
execl ("/bin/rmdir", "rmdir", dpath, (char *) 0);
_exit (1);
default: /* parent process */
.
.
.
return 0;
}
Example 2 (from GNU tar 1.15.1 lib/rtapelib.c):
#ifndef __VMS
status = fork ();
#else /* VMS */
status = vfork ();
#endif /* VMS */
if (status == -1)
{
int e = errno;
free (file_name_copy);
errno = e;
return -1;
}
if (status == 0)
{
/* Child. */
#ifdef __VMS
save_stdin = dup (STDIN_FILENO);
save_stdout = dup (STDOUT_FILENO);
#endif /* VMS */
close (STDIN_FILENO);
dup (to_remote[remote_pipe_number][PREAD]);
close (to_remote[remote_pipe_number][PREAD]);
#ifndef __VMS
close (to_remote[remote_pipe_number][PWRITE]);
#endif /* VMS */
close (STDOUT_FILENO);
dup (from_remote[remote_pipe_number][PWRITE]);
#ifndef __VMS
close (from_remote[remote_pipe_number][PREAD]);
#endif /* VMS */
close (from_remote[remote_pipe_number][PWRITE]);
sys_reset_uid_gid ();
if (remote_user)
execl (remote_shell, remote_shell_basename, remote_host,
"-l", remote_user, rmt_command, (char *) 0);
else
execl (remote_shell, remote_shell_basename, remote_host,
rmt_command, (char *) 0);
/* Bad problems if we get here. */
/* In a previous version, _exit was used here instead of exit. */
error (EXIT_ON_EXEC_ERROR, errno, _("Cannot execute remote shell"));
}
/* Parent. */
#ifdef __VMS
{
int status;
status = dup2 (save_stdin, STDIN_FILENO);
if (status < 0)
{
error (EXIT_ON_EXEC_ERROR, errno, _("Error restoring stdin"));
}
status = dup2 (save_stdout, STDOUT_FILENO);
if (status < 0)
{
error (EXIT_ON_EXEC_ERROR, errno, _("Error restoring stdout"));
}
}
#endif /* VMS */
close (from_remote[remote_pipe_number][PWRITE]);
close (to_remote[remote_pipe_number][PREAD]);
This second example may look a little intimidating but remember that on OpenVMS the “Child” code is actually executed by the parent. The “Child” process is created by the execl() function call not by the vfork() function call.
Note 1: By default the OpenVMS exec call's use LIB$SPAWN to create child processes. In most cases this is what you want, however in some cases you may want the child processes to be a detached processes. To achieve this you can enable the DECC$DETACHED_CHILD_PROCESS feature switch. This has some implications. See CRTL Reference Guide chapter 5.
Note 2: On OpenVMS the execlp() and execvp() functions search VAXC$PATH and not the PATH environment variable to obtain the location of the file to execute. This can be quite problematic.
RMS edit
RMS stands for Record Management System. The OpenVMS filesystem is built on RMS and all the files on an OpenVMS system are RMS files. An RMS file is record oriented and can contain keys for keyed access (RMS indexed files). There are many different kinds of records and countless record attributes in RMS. As with most record oriented systems, locking of files and records is something to be very aware of. UNIX doesn't have these features and on UNIX systems it is possible for two programs to have the same file open for writing at the same position in the file. On OpenVMS this is impossible and you have to deal with this problem when you run into it.Another problem is the difference between stream-lf files and variable-length records. Both files contain records of variable length, but from a UNIX programs point of view Stream-lf files best resemble UNIX files. However very few OpenVMS programs know how to handle stream-lf files. OpenVMS programs typically handle files with the variable-length record type.
Known Porting Issues edit
Quite a few CRTL functions still don't quite work as their UNIX counterparts and some functions are still missing. To give you some examples:The vfork function does not behave exactly like its UNIX counterpart (read the section on vfork in the CRTL reference manual). If a program uses vfork it will probably check the existence of vfork during configure and this is also a situation where configure will hang. The solution to the hang is quite simple. Log in using a different session and look for the child process of your previous session. Kill it and the configure script continues.And while we're at it, OpenVMS unfortunately has no fork function yet, but there are many known workarounds available is only we know where.This is not a definitive guide on how to port open source to OpenVMS. Things are changing quite rapidly. We should continue to keep this document up to date with the current state of OpenVMS and the GNV kit.We found a list of known areas where compatibility problems occur when porting from UNIX to OpenVMS on comp.os.vms, This list is the basis for a list we maintain. This list can be found in appedix 2: List of known issues.