Top |
This is the Frequently Asked Questions (FAQ) posting for the comp.os.vms and vmsnet.misc newsgroups. (comp.os.vms is bidirectionally-gatewayed to the INFO-VAX mailing list - see INTRO3 for further details.) It contains answers to frequently asked questions about Compaq's OpenVMS operating system and the computer systems on which it runs. (Please see INTRO5 before posting.)
Other internet FAQs are generally available in these locations:
comp.answers and news.answers newsgroups ftp://rtfm.mit.edu/pub/usenet/...
User-created HTML versions of the OpenVMS FAQ are located at:
http://www.kjsl.com/vmsfaq http://eisner.decus.org/vms/faq.htm
This FAQ is archived in the following locations:
http://www.openvms.digital.com/wizard/openvms_faq.html ftp://ftp.digital.com/pub/Digital/dec-faq/OpenVMS.txt ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms comp.answers and news.answers newsgroups
World-Wide Web Universal Resource Locator (URL) notation is used for FTP addresses.
Many people have contributed to this list, directly or indirectly. In some cases, an answer has been adapted from one or more postings on the comp.os.vms. Our thanks to all of those who post answers. The name (or names) at the end of an entry indicate that the information was taken from postings by those individuals; the text may have been edited for this FAQ. These citations are only given to acknowledge the contribution.
Although the editor of this FAQ is an employee of Compaq Computer Corporation, this posting is not an official statement of Compaq.
AlphaGeneration, AlphaServer, AlphaStation, Alpha AXP, AXP, DEC, DECstation,
DECsystem, OpenVMS, ULTRIX, VAX and VMS are trademarks of
Compaq Computer Corporation. Compaq
and the names of Compaq products are trademarks and/or
registered trademarks and/or service marks of Compaq Computer Corporation.
OSF/1 is a registered trademark of the Open Software Foundation.
UNIX is
a registered trademark in the United States and other countries, licensed
exclusively through X/Open Company Ltd. Other names are properties of their
respective owners.
Top |
The comp.sys.dec newsgroup carries discussions about Compaq systems acquired from Digital Equipment Corporation.
An important point to keep in mind is that propagation delays vary, both within the newsgroup and with INFO-VAX mailings. It's possible that postings may not be delivered for several days and some may appear out of order.
Subscription requests are handled automatically by a mail server. This mail server ignores the subject line and processes each line of the message as a command. The syntax for subscribing and unsubscribing and setting digest or non-digest modes is:
[Mark.Berryman@Mvb.Saic.Com]If you are on Bitnet, send a mail message containing the text SUBSCRIBE INFO-VAX to LISTSERV@(nearest listserv system). To unsubscribe, send a message containing the text SIGNOFF INFO-VAX to the same listserv address.
If you are on the Internet in the UK, send a message containing the word SUBSCRIBE (or UNSUBSCRIBE) to info-vax-request@ncdlab.ulcc.ac.uk.
Before posting, please use available local resources, such as the manuals, HELP and this FAQ first. Also make a point of reading the release notes for the product you're using, generally placed in SYS$HELP. Often you'll find the answer, and will save time and effort for all concerned. (And you won't "annoy the natives"...)
When posting, please consider the following suggestions:
ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/primer/part1 ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/faq/part1 ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/emily-postnews/part1 ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/writing-style/part1 ftp://rtfm.mit.edu/pub/usenet/news.answers/usenet/posting-rules/part1This information will document the etiquette of newsgroups, as well as providing you with the knowledge the vast amount of newsgroup-related information that is readily available to you, and where to find it...
[Arne Vajhøj]
Top |
OpenVMS was designed entirely within Compaq (Digital Equipment Corporation.) The principal designers were Dave Cutler and Dick Hustvedt. OpenVMS was conceived as a 32-bit, virtual memory successor to Digital's RSX-11M operating system for the PDP-11. Many of the original designers and programmers of OpenVMS had worked previously on RSX-11M, and many concepts from RSX-11M were carried over to OpenVMS.
OpenVMS VAX is a 32-bit, multitasking, multiprocessing virtual memory operating system. Current implementations run on VAX systems from Compaq and other vendors.
OpenVMS Alpha is a 64-bit multitasking, multiprocessing virtual memory operating system. Current implementations run on Alpha systems from Compaq and other vendors.
[Paul Winalski] [Arne Vajhøj]For more details on OpenVMS and its features, read the OpenVMS Software Product Description at:
http://www.digital.com/info/SP2501/Additional information on the general features of various OpenVMS releases, release dates, as well as the development project code names of specific releases, is available at:
http://www.openvms.digital.com/openvms/os/openvms-release-history.htmlAdditional historical information - as well as pictures and a variety of other trivia - is available in the VAX 20th anniversary book:
http://www.openvms.digital.com/openvms/20th/vmsbook.pdf
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".
[Arne Vajhøj]
[leichter@lrw.com]Seriously, OpenVMS and the better implementations of UNIX are all fine operating systems, each with its strengths and weaknesses. If you're in a position where you need to choose, select the one that best fits your own requirements, considering, for example, whether or not the layered products or specific OS features you want are available.
[Steve Lionel]
Active development of new OpenVMS releases is underway, as well as the continuation of support.
Please see the following URLs for details, roadmaps, and related information:
http://www.compaq.com/openvms/ http://www.openvms.digital.com/OPENVMS/strategy.html http://www.openvms.digital.com/openvms/roadmap/index.htm http://www.openvms.digital.com/openvmstimes/ http://www.compaq.com/inform/
For information on the available part numbers and current products (OpenVMS distribution kits, media, documentation, etc) and associated licensing information, please see the OpenVMS Software Product Description (SPD), available at:
http://www.digital.com/info/SP2501/ http://www.digital.com/info/SP4187/The following CD-ROMs contain just the OpenVMS Alpha operating system. These are bootable, and can be used to run BACKUP from CD-ROM.
The following are the consolidated ECO distribution kit subscriptions, and these provide sites with eight updates of the current ECO kits per year:
OpenVMS VAX and OpenVMS Alpha source listings CD-ROM sets include the source listings of most of OpenVMS, and these CD-ROM sets are invaluable for any folks working directly with OpenVMS internals, as well as folks interested in seeing examples of various programming interfaces.
In no particular order, OpenVMS components are implemented using Bliss, Macro,Ada, PLI, VAX and DEC C, Fortran, UIL, VAX and Alpha SDL, Pascal, MDL, DEC C++, DCL, Message, and Document. And this is certainly not a complete list. However, the rumor is not true that an attempt was made to write pieces of OpenVMS in every supported language so that the Run-Time Libraries could not be unbundled. (APL, BASIC, COBOL and RPG are just some of the languages not represented!)
There are a large variety of small and not-so-small tools and DCL command procedures that are used as part of the OpenVMS build, and a source code control system capable of maintaining over a hundred thousand source files across multiple parallel development projects, and overlapping releases.
If you are a DECUS member and are considering acquiring and using a VAX or Alpha system for hobbyist use, (free) licenses for OpenVMS VAX and OpenVMS Alpha are available to DECUS members. In addition to the license, VAX and Alpha distribution CD-ROM kits are available with OpenVMS, DECwindows Motif, DECnet and TCP/IP networking, compilers, a variety of layered products, and an OpenVMS Freeware kit for a nominal fee. The OpenVMS Freeware is also available separately.
For further information, link to:
http://www.montagar.com/hobbyist/Further information on DECUS and on DECUS membership is available at:
http://www.decus.org/To transfer a commercial OpenVMS license from one owner to another, or to purchase a commercial license, you can contact Compaq Computer Corporation at 1-800-DIGITAL (in North America), or your local or regional sales office.
[Stephen Hoffman] [Scott Snadow]
http://www.openvms.digital.com/euro/
Because there is a belief that there would be no market to justify the effort and the expense involved in porting OpenVMS to systems using the Intel IA32 architecture. (Each maintainer of a product or package for OpenVMS would have to justify the port to "OpenVMS IA32", akin to a port from OpenVMS VAX to OpenVMS Alpha. The effort involved in porting OpenVMS from VAX to Alpha was huge.)
Because every one of the core applications would have to be ported from Alpha to IA32, and then customer and third-party applications would also have to be ported.
Because there are design features that required by OpenVMS that are not available on IA32, features that would require redesigning OpenVMS to operate in the environment, making ports rather more difficult. ASTs and interlocked operators are obvious prerequirements.
Because Alpha is faster than Intel IA32 systems - if OpenVMS is to be ported, a port to a slower system is more difficult to sell.
Because Intel is expecting to replace IA32 processors with IA64.
Because hobbyists have been easily able to acquire OpenVMS systems and the DECUS hobbyist OpenVMS licenses.
Because OpenVMS already operates on Compaq and third-party Alpha systems; specific features in support of third-party vendor-customized bootstrap capabilities for use on third-party systems are present in OpenVMS Alpha V7.1-2 and later releases.
Because there are assumptions that some of the stability of OpenVMS arises from the stability of the underlying VAX and Alpha hardware, and systems based on components such as ISA and random memory SIMMs might not be as stable.
But yes, it would be nice to have.
[Stephen Hoffman]
If you would like an account on Hobbes, please email to:
hobbesthevax@hotmail.comThe following information is required: Name, address, telephone number, and what you expect to use it for.
This system is strictly for non-commercial use.
[Scott Squires]
http://www.testdrive.compaq.com/galaxy/
Top |
When it came time to chose a "marketing name" for the Alpha AXP line, the company was in a quandary. The internal "code name" for the project, Alpha, was widely known and would seem the ideal choice, but it was already in common use by a number of other companies and could not be trademarked. A well-known "name search" firm was hired and was asked to come up with two lists of possible names. The first list was intended to evoke the feeling of "extension to VAX", while the second list was to suggest "not a VAX". Unfortunately, none of the choices offered were any good; for example, "VAX 2000" was found on the first list while the second list contained "MONDO" (later to be used for a kids' soft drink).
Shortly before announcement, a decision was made to name the new line ARA, for Advanced RISC Architecture. However, an employee in Israel quickly pointed out that this name, if pronounced in the "obvious" manner, sounded very much like an Arabic word with decidely unfortunate connotations. Eventually, AXP was selected; the architecture would be referred to as "Alpha AXP" whereas products themselves would use just "AXP".
Use of the AXP term has been phased out in favour of using Alpha. For example, OpenVMS AXP is now called called "OpenVMS Alpha".
http://www.compaq.com/csa/CSA provides members with discounts on hardware, porting assistance, and many other benefits.
http://www.intercontent.com/compaq/
The following contain information on current Alpha and VAX products:
http://www.digital.com/alphaserver/products.html http://www.digital.com/alphaserver/vax/The following sites contain information on various retired VAX and Alpha products:
http://www.compaq.com/products/workstations/digital/retired/index.html http://www.digital.com/alphaserver/archive/index.html http://www.digital.com/alphaserver/performance/perf_tps.html
Also see CPU2000:
http://www.spec.org/osg/cpu2000/ http://www.spec.org/osg/cpu2000/results/cpu2000.html
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/The files are structured similiar to those on the firmware CD, and are separated by CD release. For example, the contents of the V3.7 firmware CD are located at:
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/v3.7/The latest and greatest firmware (if released since the last firmware CD) is located at:
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/Please send your comments and feedback to :
alpha_server@service.digital.comFor information on creating bootable floppies containing the firmware, and for related tools, please see the following areas:
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt
http://www.openvms.digital.com/freeware/multia/
Instructions are included IN the kits. READ THE INSTRUCTIONS.
Some of the restrictions involved when running OpenVMS on the Multia
system include (but may well not be limited to) the following:
This means, of course, that you will not see and cannot use any PCMCIA cards on a Multia.
The Multia images are not included on the OpenVMS Freeware V4.0 CD-ROM kit, the kit that was distributed with OpenVMS V7.2. (These images became available after Freeware V4.0 shipped.)
Other sources of information for OpenVMS on Multia include:
http://home.earthlink.net/~djesys/vms/hobbyist/multia.html http://home.earthlink.net/~djesys/vms/hobbyist/mltianot.html http://home.earthlink.net/~djesys/vms/hobbyist/support.html http://www.netbsd.org/Ports/alpha/multiafaq.html [Stephen Hoffman] [David J. Dachtera]
Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at:
http://www.digital.com/info/SP2501/ http://www.digital.com/info/SP4187/When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the CD-ROM drive is supported or is closely compatable and that it also specifically supports 512 byte block transfers, and particularly ensure that video controller is supported. Use of supported Compaq hardware will generally reduce the level of integration effort involved.
A CD-ROM drive is required for OpenVMS Alpha installations.
[Stephen Hoffman]
http://www.digital.com/alphaserver/Alpha Technical information and documentation is available at:
http://www.digital.com/alphaserver/technical.html ftp://ftp.digital.com/pub/DEC/Alpha/systems/Alpha motherboard products and Alpha microprocessor documentation:
http://www.digital.com/alphaoem/alpha.htmCompaq OEM Website:
http://www.digital.com/oem/Information on Multia hardware is available at:
http://www.netbsd.org/Ports/alpha/multiafaq.html [Stephen Hoffman]
>>> BOOT -FL root,flags
bit | description |
0 | Conversational bootstrap |
1 | Load SYSTEM_DEBUG.EXE (XDELTA) |
2 | Stop at initial system breakpoints if bit 1 set (EXEC_INIT) |
3 | Diagnostic bootstrap (loads DIAGBOOT.EXE) |
4 | Stop at bootstrap breakpoints (APB and SYSBOOT) |
5 | Secondary bootstrap does not have an image header |
6 | Inhibit memory test |
7 | Prompt for secondary bootstrap file |
8 | Halt before transfer to secondary bootstrap |
9 | Boot from shadow set |
10 | LAD/LAST bootstrap |
11 | Unused |
12 | Transfer to intermediate primary bootstrap |
13 | Mark CRD pages bad |
14 | Report unaligned data traps in bootstrap |
15 | Unused |
16 | Enable verbose boot messages in EXEC_INIT |
17 | Enable subset of verbose boot messages (user messages) |
>>> SET BOOT_OSFLAGS 0,1
The specific environment variables differ by platform and by firmware version - the baseline set is established by the Alpha Architecture:
AUTO_ACTION ("BOOT", "HALT", "RESTART"
, any other value assumed to be HALT
)
BOOT_DEV
BOOTDEF_DEV
BOOTED_DEV
BOOT_FILE
BOOTED_FILE
BOOT_OSFLAGS
BOOTED_OSFLAGS
BOOT_RESET ("ON","OFF")
DUMP_DEV
ENABLE_AUDIT ("ON", "OFF")
LICENSE
CHAR_SET
LANGUAGE
TTY_DEV.
LP_*
and HP_*
, and each particular
console implementation can (and often does) have various sorts
of platform-specific extensions beyond these variables...
The contents of a core set of environment variables are accessable from OpenVMS using the f$getenv lexical and the sys$getenv system service. (These calls are first documented in V7.2, but have been around for quite a while.) Access to arbitary console environment variables is rather more involved, and not directly available.
[Stephen Hoffman]
Top |
There are three controls on the console bulkhead of these systems:
Triangle-in-circle-paddle: | halt enable. |
dot-in-circle: |
halt (BREAK) is enabled, and auto-boot is disabled. |
dot-not-in-circle: |
halt (BREAK) is disabled, and auto-boot is enabled. |
Three-position-rotary: | power-up bootstrap behaviour |
arrow: | normal operation. |
face: | language inquiry mode. |
t-in-circle: | infinite self-test loop. |
Eight-position-rotary: |
console baud rate selection select the required baud rate; read at power-up. |
Also present on the bulkhead is a self-test indicator: a single digit. This matches the final part of the countdown displayed on the console or workstation, and can be used by a service organization to determine the nature of a processor problem. The particular countdown sequence varies by processor type, consult the hardware or owner's manual for the processor, or contact the local hardware service organization for information the self-test sequence for a particular processor module. Note that self-tests 2, 1 and 0 are associated with the transfer of control from the console program to the booting operating system.
[Steve Hoffman]
For all formats, the fraction is normalized and the radix point assumed to
be to the left of the MSB, hence 0.5 <= f < 1.0. The MSB, always being 1,
is not stored. The binary exponent is stored with a bias varying with
type in bits 14:n of the lowest-addressed word.
Type | Exponent bits |
Exponent bias |
Fraction bits (including hidden) |
F | 8 | 128 | 24 |
D | 8 | 128 | 56 |
G | 11 | 1024 | 53 |
H | 15 | 16384 | 113 |
The layout for D is identical to that for F except for 32 additional fraction bits.
Example: +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased exponent of 129)
[Steve Lionel]
http://www.digital.com/alphaserver/vax/Jim Agnew maintains a MicroVAX/VAXstation FAQ at:
http://anacin.nsc.vcu.edu/~jim/mvax/mvax_faq.htmlJames Lothian maintains a VAX-11/750 FAQ at:
http://www.dcs.napier.ac.uk/~oose5002/750faq.htmlThe VAXstation 3100 Owner's Guide:
http://www.whiteice.com/~williamwebb/intro/DOC-i.htmlA field guide to PDP-11 (and VAX) Q-bus and UNIBUS modules can be found at:
http://metalab.unc.edu//pub/academic/computer-science/history/pdp-11/hardware/field-guide.txt
System disks larger than 1.073 gigabytes (GB) - 1FFFFF hexidecimal blocks - are not supported on any member of the VAXstation 3100 series and on certain older members of the MicroVAX 3100 series, and are not reliable on these affected systems. (See below to identify the affected systems - the more recent members of the MicroVAX 3100 series systems are not affected.)
Various SCSI commands used by the boot drivers imbedded in the console PROM on all members of the VAXstation 3100 series use "Group 0" commands, which allow a 21 bit block number field, which allows access to the first 1FFFFF hexidecimal blocks of a disk. Any disk references past 1FFFFF will wrap - this wrapping behaviour can be of particular interest when writing a system crashdump file, as this can potentially lead to system disk corruptions should any part of the crashdump file be located beyond 1.073 GB.
More recent systems and console PROMs use "Group 1" SCSI commands, which allow a 32 bit block number field.
There was a similar limitation among the oldest of the MicroVAX 3100 series, but a console boot PROM was phased into production and was made available for field retrofits - this PROM upgrade allows the use of the "Group 1" SCSI commands, and thus larger system disks. There was no similar PROM upgrade for the VAXstation 3100 series.
Systems that are affected by this limit:
[Steve Hoffman]
VAX systems maintain an interval clock, and a hardware clock.
The VAX hardware clock is called the TOY ("Time Of Year") clock. The register associated with the clock is called the TODR ("Time Of Day Register").
The TOY clock - as used - stores time relative to January first of the current year, starting at at 00:00:00.00. It is a 100 Hz, 32-bit counter, incremented every 10ms, and thus has a capacity of circa 497 days.
OpenVMS (on the VAX platform) stores system date information - and in
particular, the current year - in the system image, SYS$SYSTEM:SYS.EXE
.
The TOY is used, in conjunction with the base date that is stored and
retrieved from the system image, to initialize the interval clock value that
is stored in EXE$GQ_SYSTIME
.
Once the interval clock is loaded, the system does not typically reference the TOY again, unless a SET TIME (with no parameters) is issued. The interval clock value is updated by a periodic IPL22 or IPL24 (depending on the specific VAX) interrupt. (When these interrupts are blocked as a result of the activity of higher-IPL code - such as extensive driver interrupt activity or a hardware error - the clock will "lose" time, and the time value reported to the user with appear to have slowed down.)
Because the TOY has a resolution of 497 days, you need to issue a SET TIME (with no parameters) at least once between January 1st and about April 11th of each year. The SET TIME is issued during various OpenVMS procedures such as SHUTDOWN, and can be issued directly. Issuing SET TIME resets the value stored in the TOY, and updates the current year saved in the system image.
This usage is the reason that OpenVMS installation kits explicitly prompt for
the time during bootstrap, and why the time value can "get weird" if the
system crashes outside the 497 day window (if no SET TIME was issued to update
the saved values), and why the time value can "get weird" if a different
SYS$SYSTEM:SYS.EXE
is used (alternate system disk, standalone BACKUP, etc).
On most (all?) VAX systems, the battery that is associated with the TOY clock can be disconnected and replaced if (when) it fails - TOY clock problems in VAX systems do regularly get tracked back to a failed nicad or lithium battery pack.
[Steve Hoffman]
The exact syntax is console-specific, recent VAX consoles tend
to use the following:
>>> BOOT/R5:flags
Bit | Meaning |
---|---|
0 | RPB$V_CONV Conversational boot. At various points in the system boot procedure, the bootstrap code solicits parameter and other input from the console terminal. If the DIAG is also on then the diagnostic supervisor should enter "MENU" mode and prompt user for the devices to test. |
1 | RPB$V_DEBUG Debug. If this flag is set, VMS maps the code for the XDELTA debugger into the system page tables of the running system. |
2 | RPB$V_INIBPT Initial breakpoint. If RPB$V_DEBUG is set, VMS executes a BPT instruction immediately after enabling mapping. |
3 | RPB$V_BBLOCK Secondary boot from the boot block. Secondary bootstrap is a single 512-byte block, whose LBN is specified in R4. |
4 | RPB$V_DIAG Diagnostic boot. Secondary bootstrap is image called [SYSMAINT]DIAGBOOT.EXE. |
5 | RPB$V_BOOBPT Bootstrap breakpoint. Stops the primary and secondary bootstraps with a breakpoint instruction before testing memory. |
6 | RPB$V_HEADER Image header. Takes the transfer address of the secondary bootstrap image from that file's image header. If RPB$V_HEADER is not set, transfers control to the first byte of the secondary boot file. |
7 | RPB$V_NOTEST Memory test inhibit. Sets a bit in the PFN bit map for each page of memory present. Does not test the memory. |
8 | RPB$V_SOLICT File name. VMB prompts for the name of a secondary bootstrap file. |
9 | RPB$V_HALT Halt before transfer. Executes a HALT instruction before transferring control to the secondary bootstrap. |
10 | RPB$V_NOPFND No PFN deletion (not implemented; intended to tell VMB not to read a file from the boot device that identifies bad or reserved memory pages, so that VMB does not mark these pages as valid in the PFN bitmap). |
11 | RPB$V_MPM Specifies that multi-port memory is to be used for the total EXEC memory requirement. No local memory is to be used. This is for tightly-coupled multi-processing. If the DIAG is also on, then the diagnostic supervisor enters AUTOTEST mode. |
12 | RPB$V_USEMPM Specifies that multi-port memory should be used in addition to local memory, as though both were one single pool of pages. |
13 | RPB$V_MEMTEST Specifies that a more extensive algorithm be used when testing main memory for hardware uncorrectable (RDS) errors. |
14 | RPB$V_FINDMEM Requests use of MA780 memory if MS780 is insufficient for booting. Used for 11/782 installations. |
<31:28> | RPB$V_TOPSYS Specifies the top level directory number for system disks with multiple systems. |
The TOY value is used in conjunction with a year value stored in SYS.EXE - the TOY clock resolution is circa 497 days, meaning that a SET TIME must be issued early each year in order to keep the SYS.EXE and TOY clock values synchronized, and must also be issued whenever a new or different SYS.EXE image is in use.
The VAX Interval Time is used to keep the running time, and this has a specified accuracy of .01%. This is a drift of approximately 8.64 seconds per day.
Any high-IPL activity can interfere with the IPL 22 or IPL 24 (this depends on the VAX implementation) clock interrupts - activities such as extensive device driver interrupts or memory errors are known to slow the clock.
To help keep more accurate system time, NTP, DECdtss, and other techniques are commonly used. If you do not have IP access to a time-base, then you could use dial-up access to NIST or other authoritative site. (There exists code around that processes the digital-format time that is available via a modem call into the NIST clock, and code that grabs the time off a GPS receiver digital link.)
The web sites:
http://www.eecis.udel.edu/~ntp/ http://www.nist.gov/ http://www.bldrdoc.gov/timefreq/faq/faq.htmare good time-related resources.
Top |
The Y2K readiness kits for specific OpenVMS releases prior to V7.1 are currently available to customers with an OpenVMS prior version support software support contract, and can also be purchased separately. The V7.1 Y2K readiness kits are presently available at the service area website:
http://search.service.digital.com/ http://www.compaq.com/support/For the official, most complete, and most current information on the status of Y2K compliance of Compaq hardware and software products, including that of OpenVMS and various OpenVMS layered products, please see:
http://www.compaq.com/year2000/ http://www.openvms.digital.com/openvms/products/year-2000/Information on the customer testing procedures recommended by OpenVMS Engineering are also accessable via the second URL above. Failure to follow the recommended Y2K testing procedures - particularly around the necessity for performing a disk BACKUP and restoration around any Y2K testing - can and has led to various problems at customer sites.
The C epoch typically uses a longword (known as time_t) to contain the number of seconds since midnight on 1-Jan-1970. At the current rate of consumption of seconds, this longword is expected to overflow (when interpreted as a signed longword) circa 03:14:07 on 19-Jan-2038 (GMT), as this time is circa 0x7FFFFFFF seconds since the C base date.
One could see this longword time value used in any C program that manipulates time using the standard C library routines, regardless of the particular operating system platform.
There is currently no standard mechanism for dealing with this overflow (short of promoting all longword integers to quadwords), as the format of the time_t value is implementation-specific. Some implementations and applications will treat time_t as an unsigned longword value, while others treat it as a signed longword value - the format of time_t is specifically left up to the C compiler implementation by the C standards.
Applications written in C will likely have to revisit something similar to the current Year 2000 evaluation process sometime prior to 2038.
The OpenVMS Y2K evaluation does not extend into 19-Jan-2038, or later.
For information on OpenVMS and 2038, please see the OpenVMS Y2K website.
[Steve Hoffman]
The year 2000 is a leap year. (That is, the year 2000 is a leap year in the Gregorian calendar, the calendar that is currently used in most parts of the world.)
The leap year algorithm that was created by Aloysius Giglio, Father Christopher Clavius, and the Coucil of Trent for the Gregorian Calendar dates back to the 16th Century. The algorithm is simple, but effective: the years that are evenly divisible by 4 are leap years, while the years that are divisible by 100 are not, while the years that are divisible by 400 are. Thus, 1800, 1900, and 2100 are not leap years, while 2000 is.
And whenever working with dates, please determine what the local calendar, timezone, and daylight savings time rules are: the Gregorian calendar was adopted in 1698 in some areas of the world, in 1752 in others, and in 1918 in yet others. The specific rules vary both by geography and by date.
For further details on this, please see the DECwindows Calendar Help, or the answer to SPR number 11-60903, dated 13-Oct-1983.
All supported components of OpenVMS are covered by the OpenVMS Y2K evaluation, including the language run-time libraries and the OpenVMS system-integrated products such as shadowing and RMS journaling.
For information on other Compaq products, or for additional details on the OpenVMS Y2K evaluation, please see http://www.digital.com/year2000/
It is quite possible to create an entirely a Y2K safe environment from tools and products that are not Y2K ready, just as it is also possible to have serious Y2K problems in an environment based entirely on Y2K ready products. In other words - short of knowing that the product has catestrophic Y2K failures, and short of learning where specific known Y2K problems lurk in the products - you cannot really determine with any certainty that your site is Y2K ready.
The only way to tell for certain that your site is Y2K safe is to test your systems and your applications. For some suggested testing procedures, please see the OpenVMS Y2K website.
The OpenVMS operating system is in good shape in regard to Y2K, but there are a few small areas of OpenVMS that do require an update for Y2K readiness - if you are certain that no local software is using any these areas OpenVMS, then you will likely not require the update. If you are not certain, then you have will likely need to test for Y2K problems at your site, and you will also likely want to acquire and install the update. For details on the update process and on what was found in OpenVMS, please see the information in the Y2K kits.
And you will obviously need to consider software products other than OpenVMS when making your Y2K readiness determination, as well.
Versions of INIT.EXE and MTAACP.EXE from VAX/VMS releases prior to V5.1-1 will potentially have problems properly processing ANSI magnetic tapes when Y2K and later dates are involved - the DCL INITIALIZE command is known to encounter access violation (ACCVIO) errors.
[Hoffman, Dachtera]
Top |
HTML format on-line product documentation sets for specific Compaq OpenVMS products are presently available at:
http://www.openvms.digital.com:8000/ http://www.openvms.digital.com/doc/Documentation is offered in CD-ROM form through a subscription to the Consolidated On-Line Documentation (ConOLD) product (see VMS7.) ConOLD manuals are readable with BNU, a viewer that is supplied with the documentation distribution. BNU can display HTML, Bookreader, and documentation in other formats.
MGBOOK, a viewer for Bookreader-format documentation is available for character-cell terminals (eg. VTxxx) via the WKU VMS Freeware file server - see question SOFT1 for details.
[Steve Lionel] [Stephen Hoffman]
OpenVMS Marketing runs a WWW server at http://www.compaq.com/openvms/ (http://www.openvms.digital.com/). Here, you will find product information, strategy documents, the contents of the latest OpenVMS Freeware CD-ROM and much more.
Product information for just about everything Compaq sells is available from Digital's Internet servers. If you're using a World-Wide-Web (WWW) browser, use http://www.digital.com/info.html For anonymous FTP access, log in to ftp.digital.com. Software Product Descriptions (SPDs) (http://www.digital.com/info/SPHOME/), system performance data (see ALPHA5), product infosheets, release notes and much more are available.
In addition,
http://www.digital.com/info/forms/search.htmlprovides a handy method to search all of Compaq's public web servers for information of any kind.
Compaq's Customer Services organization also hosts an Internet server. Various contract-access and non-contract access ECO (patch) kits are available at the URL:
http://search.service.digital.com/For ftp access use
ftp://ftp.service.digital.com/The Compaq Systems and Options Catalog (SOC) and the Interactive Catalog are available at:
http://www.digital.com/info/SOHOME/SOHOMEHM.HTM http://www.systems.digital.com/The Systems and Options Catalog is being replaced by Compaq QuickSpecs.
Compaq's Business Link provides product information, prices and permits online ordering:
http://www.businesslink.digital.com/Information on Compaq hardware, software, products and services is available through various telephone numbers:
1-800-AT-COMPAQ : voice : Compaq (including DIGITAL and Tandem) products and services 1-800-DIGITAL : voice : DIGITAL products and services 1-800-DEC-2717 : voice : The DECchip Hotline 1-508-568-6868 : voice : (alternate number for above)David Mathog offers two HTML documents which contain useful information about OpenVMS.
http://seqaxp.bio.caltech.edu:8000/www/vms_sheet.html http://seqaxp.bio.caltech.edu:8000/www/vms_beginners_faq.html
http://www.levitte.org/~ava/vms_book.htmlxThe Butterworth-Heinemann Digital Press imprint offers a number of OpenVMS books. A website is available at:
http://www.bh.com/Information on specific OpenVMS books is also available at:
http://www.openvms.digital.com/openvms/books.html
$ HELP/OUT=filename.txt help-topic [help-subtopic]If the help text you want is not in the standard help library (for example, it's help for a utility such as MAIL that has its own help library), add /LIBRARY=libname after the HELP verb. To see the names of help library files, do a directory of SYS$HELP:*.HLB.
http://www.openvms.digital.com/ (Sponsored by OpenVMS Marketing) http://www.montagar.com/ (Sponsored by DECUS - DFWLUG) http://www.levitte.org/~ava/ (Sponsored by Arne Vajhøj) http://www.saiga.com/ (Sponsored by Saiga Systems) http://www.tachyon.com/ (Sponsored by Wayne Sewell) http://www.progis.de/openvms.htm (Sponsored by proGIS Software) http://www.jcameron.com/vms/ (Sponsored by Jeff Cameron)
The following web site is sponsored by "The Beave", and provides information that is directly relevent to system managers, security managers, and others interested in ensuring the continued security of OpenVMS systems:
http://www.vistech.net/users/beave/hack-vms-faq
Suggestions (indirectly) provided by the above include disabling the port 11 and 15 stats provided by IP packages such as Multinet.
http://www.service.digital.com/html/patch_service.htmlYou can also find the patches and the associated README files at:
ftp://ftp.service.digital.com/publicbut you must know what you are looking for. See VMS7 for info on ordering a CD-ROM with patch kits.
For a list of OpenVMS ECO kits recently released, you can use:
http://Eisner.DECUS.org/conferences/OpenVMS-patches_new_1.HTMLYou can also sign up for ECO kit email notifications (Digest or individual notifications) directly from Compaq at:
http://www1.service.digital.com/patches/mailing-list.html
http://axp623.gsi.de:8080/www/vms/qaa/undoc.htmlx [zinser@axp603.gsi.de]Also see the following:
http://www.levitte.org/~ava/vms_tip.htmlx [Arne Vajhøj]Various examples of undocumented features are also available on the OpenVMS Freeware:
http://www.openvms.digital.com/freeware/
http://gatekeeper.dec.com/pub/DEC/DECnet/PhaseIV/index.html
The OpenVMS Internals and Data Structure book explains how the OpenVMS executive works. The book covers the operating system kernel: process management; memory management; the I/O subsystem; and the mechanisms that transfer control to, from, and among these. It gives an overview of a particular area of the system, followed by descriptions of the data structures related to that area and details of the code that implements the area.
The first edition of the OpenVMS Alpha internals book describes Version 1.5. Although there have been several releases of OpenVMS Alpha since Version 1.5 (V6.1, V6.2, V7.0, and V7.1) and many details in the book are no longer accurate, it continues to provide a strong conceptual description of OpenVMS internals.
This book has been split into five pieces, each to be updated separately. The first such volume, published in early 1997, was OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control, which covers the Version 7.0 implementation of true multithreading and the changed scheduling model it implies.
The internals books are available through Digital Press, an imprint of Butterworth-Heinemann. You can order by phone (from US and Canada, 1-800-366-2655, or from elsewhere, 781-904-2500). You can also fax an order to 1-800-446-6520 or 781-933-6333. The order form and additional information are available on their web site www.bh.com .
ISBN | Title |
1 55558 156 0 | OpenVMS Alpha Internals: Scheduling and Process Control |
1 55558 120 X | OpenVMS AXP Internals and Data Structures: Version 1.5 |
1 55558 059 9 | VAX/VMS Internals and Data Structures: Version 5.2 |
[Ruth Goldenberg]
Various introductory manuals are available in the OpenVMS documentation set, including the OpenVMS User's Guide. The OpenVMS manuals - including the OpenVMS User's Guide - are available at:
http://www.openvms.digital.com:8000/Some of the OpenVMS books available from the Butterworth-Heinemann Digital Press imprint ( http://www.bh.com) include:
Introduction to OpenVMS, 5th Edition, Lesley Ogilvie Rice ISBN 1 55558 194 3 The OpenVMS User's Guide, Second Edition Patrick Holmay ISBN 1 55558 203 6 Introduction to OpenVMS David W Bynon ISBN 1 878956 61 2 OpenVMS System Management Guide Richard Berry ISBN 1 55558 143 9 Using DECwindows Motif for OpenVMS Margie Sherlock ISBN 1 55558 114 5 Writing Real Programs in DCL, Second Edition Hoffman and Anagnostopoulos ISBN 1 55558 191 9For various features OpenVMS books, please see: http://www.openvms.digital.com/openvms/books.html Various user-maintained websites are also available, including a beginner's FAQ, various user-written FAQs, a bibliography of books on OpenVMS, and information on various other hardware and software topics:
http://www.montagar.com/openvms_class/Compaq offers training information and Technical Resource Kits (TRKs) for OpenVMS at:
http://www.compaq.com/training/home.html
Top |
http://www.compaq.com/support/Various hardware and system documentation is available at:
http://www.digital.com/lists/QB_archive_HD.html http://www.europe.digital.com/info/CUHOME/BACK_ISSUES.HTM http://www.compaq.com/support/techpubs/user_reference_guides/
http://www.digital.com/info/DAHOME/
Top |
The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function.
The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.)
It's important to note that there is no such thing as installing a shareable image with privileges. The INSTALL utility will let you do it, but the privileges you specify will be ignored. To have a callable routine run with enhanced privileges that are not available to its caller, you must construct your routines as user-written system services and install the shareable image with the /PROTECT qualifier. See the OpenVMS Programming Concepts Manual for more information on user-written system services. Note also that in many cases the need to grant privileges to an image can be replaced with the use of the "Protected Subsystems" feature that grants a rights identifier to an image. See the OpenVMS Guide to System Security for information on Protected Subsystems.
This is unlikely on OpenVMS, Unix, and MVS for three reasons. First, the operating system runs in a privileged mode in memory that is protected against modification by normal user programs. Any old program cannot take over the hardware as it can on PC operating systems. Secondly, OpenVMS, Unix, and MVS have file systems that can be set up so that non-privileged programs cannot modify system programs and files on disk. Both of these protection schemes mean that traditional PC virus schemes don't work on these OSes. Third, typical applications and configurations tend to prevent the uncontrolled execution of untrusted code as part of email messages or web access.
It is possible for OpenVMS, etc., to be infected by viruses, but to do so, the program containing the virus must be run from a user account that has amplified privileges. As long as the system administrator is careful that only trusted applications are run from such accounts (and this is generally the case), there is no danger from viruses.
[Paul Winalski] [Stephen Hoffman]To protect against viruses and other attempts at system interference or misuse, follow the recommendations in the OpenVMS Guide to System Security. You may also want to consider optional software products which can monitor your system for intrusion or infection attempts. Computer Associates (CA) offers various products in this area.
Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com).
[Contributions to this list welcomed]
By default, OpenVMS senses the specific type of media. If you
are working with dual-format media - media that uses both the
ODS-2 and ISO-9660 formats on the same CD-ROM - then MOUNT will
first detect and then default to the ODS-2 format. If you wish
to override this and explicitly mount the media using ISO-9660,
use the command:
$ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label]
In most circumstances, you will not need nor will you want to
include an explicit /MEDIA_FORMAT
specification. For further
information, please refer to the OpenVMS MOUNT Utility Manual.
Particularly note the information on the MOUNT/MEDIA_FORMAT
and /UNDEFINED_FAT
qualifiers.
The MOUNT/UNDEFINED_FAT
qualifier is of interest because
ISO-9660 media can be mastered on a wide variety of operating
system platforms, and these platforms do not necessarily support
the semantics needed for files containing predefined record formats.
The /UNDEFINED_FAT
allows you to specify the default attributes for
files accessed from volumes using the ISO-9660 format.
An example which works for most CD-ROMs is:
$ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE
This particular MOUNT
command forces access to the CD-ROM media
using the ISO-9660 volume structure, and the use of the
MOUNT/UNDEFINED_FAT
qualifier causes any file whose file attributes
are "undefined" to be returned with "stream" attributes with a
maximum record length 2048.
On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS.
[dunham@star.enet.dec.com] [Stephen Hoffman]
If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command:
$ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCEA PCSI kit file has a file specification of the following form:
DEC-VAXVMS-FORTRAN-V0603-141-1.PCSIIn this example, FORTRAN is the prodname. PCSI will expand the kit files into the directory you specify and subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the eventual destination of files found there. Most of the actual product files (images, etc.) will be in the subdirectories. In the top-level directory will be a file with the file type PCSI$DESCRIPTION that specifies where various files should go. For more details, see the POLYCENTER Software Installation Developer's Guide for OpenVMS, which can be found in the OpenVMS documentation on the Consolidated Online Documentation CD-ROM.
If you need to break into an OpenVMS system because you do not have access to any privileged passwords, such as the password to the SYSTEM username, you will need physical access to the system console, and you will need to perform a conversational reboot. Here are the steps:
B/1 B/R5:1 @GENBOO
b -flags 0,1
B/E0000001 B/R5:E0000001 @<console media procedure name varies widely>
b -flags e,1
SET/STARTUP OPA0: SET WINDOW_SYSTEM 0 SET WRITESYSPARAMS 0 CONTINUE
SPAWN @SYS$SYSTEM:STARTUP
If necessary, you can skip the invocation of the system startup temporarily, and perform tasks such as registering license PAKs or various other "single-user" maintenance operations.
SET DEFAULT SYS$SYSTEM: ! or wherever SYSUAF.DAT resides RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT
You can also use the conversational bootstrap technique shown above (the steps through Step 3) to alter various system parameters. At the SYSBOOT> prompt, you can enter new parameters values:
SHOW MAXPROCESSCNT SET . 64 CONTINUE
[Steve Hoffman]
$ INITIALIZE/QUEUE/ON="123.456.789.101:9100"/PROCESSOR=UCX$TELNETSYM - my_ip_queueThe port number of 9100 is typical of HP JetDirect cards but may be different for other manufacturers cards.
As a better alternative, DCPS Version 1.4 and later support IP queues using either Compaq TCP/IP Services for OpenVMS software or Cisco Multinet for OpenVMS. The usage of this type of interface is documented in the Release Notes and the DCPS$STARTUP.TEMPLATE file.
[Steve Reece] [Arne Vajhøj]
%SET-E-NOTSET, error modifying time -SYSTEM-F-IVSSRQ, invalid system service request %SET-E-NOTSET, error modifying time -SYSTEM-E-TIMENOTSET, time service enabled; enter a time service command to update the timeA: This occurs if the time on the local system is controlled by a time service software, for example the distributed time service software (DTSS) provided as part of the DECnet/OSI installation. The DTSS software communicates with one or more time servers to obtain the current time. It entirely controls the local system time (for DECnet/OSI, there is a process named DTSS$CLERK for this); therefore, the usage of the SET TIME command (and the underlying $SETTIM system service) is disabled.
The first message is displayed on systems running DECnet/OSI V6.1 and earlier. On systems with newer DECnet/OSI (DECnet-Plus) software, the second (and more informative) message is given.
You shouldn't have to change the time manually - you should be doing this through the time server - but if you insist... you'll have to shutdown DTSS:
$ MCR NCL NCL> DISABLE DTSS NCL> DELETE DTSSThis will shutdown DTSS$CLERK. You may then change the system time as usual. To restart the DTSS software, type
@SYS$STARTUP:DTSS$STARTUPYou'll need a lot of privs : CMKRNL,SYSPRV,OPER,SYSNAM,PRMMBX,NETMBX,LOG_IO,ALTPRI and must be granted the NET$MANAGE identifer to shutdown and restart DTSS.
[bol@adv.magwien.gv.at]If you wish to "permanently" disable DTSS on a system running DECnet-Plus, the above NCL sequence must be performed each time the system is bootstrapped.
If DTSS is running and no time servers are configured, you can (and will) see the following messages at regular intervals:
%%%%%%%%%%% OPCOM 2-SEP-1999 19:41:20.29 %%%%%%%%%%% Message from user SYSTEM on UNHEDI Event: Too Few Servers Detected from: Node LOCAL:.mynode DTSS, at: 1999-09-02-19:41:20.296-04:00Iinf Number Detected=0, Number Required=1 eventUid 5FA70F4F-616E-11D3-A80E-08002BBEDB0F entityUid DE9E97DE-6135-11D3-8004-AA000400BD1B streamUid D6513A46-6135-11D3-8003-AA000400BD1BYou can either configure the appropriate number of time servers, or you can disable DTSS, or you can ignore it and (if OPCOM is set to write to the log via via the logical names in SYLOGICALS.COM/SYLOGICALS.TEMPLATE) clean out OPERATOR.LOG regularly.
To change the timezone differential and the time when the change to/from Daylight Saving Time (DST) occurs, use SYS$MANAGER:UTC$CONFIGURE_TDF.COM. To use this as batch job, please note:
P1 = SET, set the time. P2 = signed timezone differential from UTC in minutes. -360 for standard time (for Chicago) -300 for DST (for Chicago) P3 = signed time change in minutes. If +, enclose in quotes. -60 to go from DST to standard time "+60" to go from standard time to DST
Going from standard time to DST (for Chicago):
$ SUBMIT/AFTER="<date>+02:00" SYS$MANAGER:UTC$CONFIGURE_TDF - /PAR=(SET,-300,"+60")
Going from DST to standard time (for Chicago):
$ SUBMIT/AFTER="<date>+02:00" SYS$MANAGER:UTC$CONFIGURE_TDF - /PAR=(SET,-360,-60)
If you use this com file interactively, the times are given as signed hour:minute, so that -360 minutes is given as -6:00.
Before and after the com file runs, check the system time and the logical SYS$TIMEZONE_DIFFERENTIAL. The logical has the offset from UTC in seconds.
Current DST rules for some countries:
[Dale Dellutri]
Changing the node name involves a number of steps - the node name tends to be imbedded in a number of different data files around the system.
There are likely a few other areas where the nodename will be stored.
If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID - but not both values - then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)
To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478)
I expect I may have missed one or two configuration tools (or more!) that are needed at your site - the node name tends to get stored all over the place, in layered products, and in local software...
[Steve Hoffman]
On each OpenVMS node in a VMScluster, one sets two values in SYSGEN: VOTES, and EXPECTED_VOTES. The former is how many votes the node contributes to the VMScluster. The latter is the total number of votes expected when the full VMScluster is bootstrapped.
Some sites erroneously attempt to set EXPECTED_VOTES too low, believing this will allow when only a subset of voting nodes are present in a VMScluster. It does not. Further, an erroneous setting in EXPECTED_VOTES is automatically corrected once VMScluster connections to other nodes are established, meaning user data is at risk of severe corruption only during the initial system bootstrap.
One can operate a VMScluster with one, two, or many voting nodes. With any but the two-node configuration, keeping a subset of the nodes active when some nodes fail can be easily configured. With the two-node configuration, one must use a primary-secondary configuration (where the primary has all the votes), a peer configuration (where when either node is down, the other hangs), or (preferable) a shared quorum disk.
Use of a quorum disk does slow down VMScluster transitions somewhat - the addition of a third voting node that contributes the vote(s) that would be assigned to the quorum disk makes for faster transitions - but the use of a quorum disk does mean that either node in a two-node VMScluster configuration can operate when the other node is down.
In a two-node VMScluster with a shared storage interconnect, typically each node has one vote, and the quorum disk also has one vote. EXPECTED_VOTES is set to three.
Using a quorum disk on a non-shared interconnect is unnecessary - the use of a quorum disk does not provide any value, and the votes assigned to the quorum disk should be assigned to the OpenVMS host serving access to the disk.
For information on quorum hangs, see the OpenVMS documentation. For information on changing the EXPECTED_VOTES value on a running system, see the SET CLUSTER/EXPECTED_VOTES command, and see the OpenVMS system console documentation for the processor-specific console commands used to trigger the IPC (Interrrupt Priority Level %x0C; IPL C) handler. The IPC handler can be used to clear a quorum hang, and to clear disk mount verification hangs.
[Steve Hoffman]
$ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACKThis AUTOGEN command will reset various system parameters based on recent system usage (FEEDBACK), and it will reset the value for the PHYSICALPAGES parameter to the new value. It will also reboot the OpenVMS system.
PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately lower the amount of memory available for use by OpenVMS. This ability can be useful in a few specific circumstances, such as testing the behaviour of an application in a system environment with a particular (lower) amount of system memory available.
PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1, to indicate that all available memory should be used.
[Steve Hoffman]
How to do this correctly was described at DECUS a long time ago. On the
node with the tape drive, create SAVE-SET.FDL:
RECORD FORMAT fixed SIZE 8192
Then create BACKUP_SERVER.COM:
$ ! $ ! BACKUP_SERVER.COM - provide remote tape service for BACKUP. $ ! $ set noon $ set rms/network=16 $ allocate mka500 tapedev $ mount/nounload/over:id/block=8192/assist tapedev $ convert/fdl=SAVE-SET sys$net tapedev:save-set. $ dismount/unload tapedev $ stop/id=0
On the node where you want to do the backup, do:
$ backup - srcfilespec - node"user pwd"::"task=backup_server"/block=8192/saveThe only thing that doesn't completely work here is multi-reel savesets. Since the tape is being written through RMS and the magtape ACP, BACKUP won't see the reel switch and will split an XOR group across the reel boundary. As far as I remember, BACKUP will be willing to read such a multi-reel save set (directly, not over the net) since the XOR blocks are simply ignored on read, but it definitely wouldn't be able to do a recovery across the reel boundary.
Unfortunately BACKUP can't read tapes over the network because the RMS file attributes on a network task access look wrong (variable length records).
[Steve Hoffman]
The OpenVMS DCL commands SET HOST/DUP and SET HOST/HSC are used to connect to
storage controllers via the Diagnostics and Utility Protocol (DUP). These
commands require that the FYDRIVER device driver be connected. This device
driver connection is typically performed by adding the following command(s) into
the system startup command procedure:
On OpenVMS Alpha:
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> IO CONNECT FYA0/NOADAPTER/DRIVER=SYS$FYDRIVER
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT FYA0/NOADAPTER
Alternatives to the DCL SET HOST/DUP command include the console >>> SET HOST command available on various mid- to recent-vintage VAX consoles:
Access to Parameters on an Embedded DSSI controller:
>>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number PARAMS
Access to Directory of tools on an Embedded DSSI controller:
>>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number DIRECT
Access to Parameters on a KFQSA DSSI controller:
>>> SHOW UQSSP ! to get port_controller_number PARAMS >>> SET HOST/DUP/UQSSP port_controller_number PARAMS
These console commands are available on most MicroVAX and VAXstation 3xxx series systems, and most (all?) VAX 4xxx series systems. For further information, see the system documentation and - on most VAX systems - see the console HELP text.
EK-410AB-MG, DSSI VAXcluster Installation and Troubleshooting, is a good resource for setting up a DSSI VMScluster on OpenVMS VAX nodes. (This manual predates coverage of OpenVMS Alpha systems, but gives good coverage to all hardware and software aspects of setting up a DSSI-based VMScluster - and most of the concepts covered are directly applicable to OpenVMS Alpha systems. This manual specifically covers the hardware, which is something not covered by the standard OpenVMS VMScluster documentation.)
[Steve Hoffman]
On OpenVMS V7.1, all DECnet binaries were relocated into separate installation kits - you can selectively install the appropriate network: DECnet-Plus (formerly known as DECnet OSI), DECnet Phase IV, and Compaq TCP/IP Services (often known as UCX).
On OpenVMS versions prior to V7.1, DECnet Phase IV was integrated, and there was no installation question. You had to install the DECnet-Plus (DECnet OSI) package on the system, after the OpenVMS upgrade or installation completed.
During an OpenVMS V7.1 installation or upgrade, the installation procedure will query you to learn if DECnet-Plus should be installed. If you are upgrading to V7.1 from an earlier release or are installing V7.1 from a distribution kit, simply answer NO to the question asking you if you want DECnet-Plus. Then - after the OpenVMS upgrade or installation completes - use the PCSI PRODUCT INSTALL command to install the DECnet Phase IV binaries from the kit provided on the OpenVMS software distribution kit.
If you already have DECnet-Plus installed and wish to revert, you must
reconfigure OpenVMS. You cannot reconfigure the live system, hence you must
reboot the system using the V7.1 distribution CD-ROM. Select the DCL
($$$ prompt) option. Then issue the commands:
$$$ DEFINE/SYSTEM PCSI$SYSDEVICE DKA0: $$$ DEVINE/STSTEM PCSI$SPECIFIC DKA0:[SYS0.] $$$ PRODUCT RECONFIGURE VMS /REMOTE/SOURCE=DKA0:[VMS$COMMON]The above commands assume that the target system device and system root are DKA0:[SYS0.]. Replace this with the actual target device and root, as appropriate. The RECONFIGURE command will then issue a series of prompts. You will want to reconfigure DECnet-Plus off the system, obviously. You will then want to use the PCSI command PRODUCT INSTALL to install the DECnet Phase IV kit from the OpenVMS distribution media.
Information on DECnet support, and on the kit names, is included in the OpenVMS V7.1 installation and upgrade documentation.
[Steve Hoffman]
The text translations of the numeric User Identification Code (UIC) are based on identifiers present in the OpenVMS rightslist. Documentation on this area is included in the Guide to OpenVMS System Security manual.
To control the identifiers shown for a user's UIC, you use AUTHORIZE. Each user has an associated group identifier, and an identifier specific to the user. And each user should have a unique UIC.
To alter the text of a user or group identifier, use commands such as:
$ RUN SYS$SYSTEM:AUTHORIZE UAF> rename/ident oldgroupid newgroupid UAF> rename/ident olduserid newuseridIf you should find yourself missing an identifier for a particular user, you can add one for the user's UIC using a command such as:
UAF> add/ident/value=uic=[group,user] newuseridThe UIC user identifier text is assigned when the username is created, and is the text of the username. The UIC group group identifier is assigned when the first username is created in the UIC group, and the text is based on the account name specified for the first user created in the group. The value of this identifier is [groupnumber, 177777]. To add a missing group identifier, use an asterisk as follows:
UAF> add/ident/value=uic=[group,*] newgroupidYou may find cases where an identifier is missing from time to time, as there are cases where the creation of a UIC group name identifier might conflict with an existing username, or a user identifier might conflict with an existing group identifier. When these conflicts arise, the AUTHORIZE utility will not create the conflicting group and/or user identifier when the username is created.
You can can add and remove user-specified identifiers, but you should avoid changing the numeric values associated with any existing identifiers. You should also avoid reusing UICs or identifiers when you add new users, as any existing identifiers that might be present on objects in the system from the old user will grant the same access to the new user. Please see the security manual for details.
Note: See the OpenVMS Alpha Terminology section, below.
OpenVMS Alpha release upgrade paths:
From : | one can upgrade to : |
1.0 | 1.5 |
V1.5, or V1.5-1H1 | V6.1 |
V6.1 | V6.2 |
V6.2 | V6.2-1H1, V6.2-1H2, or V6.2-1H3 |
V6.1 or V6.2 | V7.0 |
V6.1, V6.2, V6.2-1H(1,2,3) or V7.0 | V7.1 |
V7.1 | V7.1-1H(1,2) , V7.1-2, V7.2, V7.2-1 |
Some typical OpenVMS Alpha upgrade paths are:
V1.0 | -> | V1.5 | -> | V6.1 | -> | V6.2, V7.0, or V7.1 |
V6.2 | -> | V6.2-1H3 | ||||
V1.5-1H1 | -> | V6.1 | -> | V6.2, V7.0, or V7.1 | ||
V6.2-1H(1,2,3) | -> | V7.1 | ||||
V6.2-1H(1,2,3) | -> | V7.2-1 | ||||
V7.1 | -> | V7.1-1H(1,2) | ||||
V7.1 | -> | V7.1-2 | ||||
V7.1 | -> | V7.2-1 | ||||
V7.1-1H(1,2) | -> | V7.2-1 |
Note that OpenVMS Alpha V7.0 does not include support for hardware and/or configurations first supported in OpenVMS Alpha V6.2-1H1, V6.2-1H2, or V6.2-1H3; one must upgrade to OpenVMS VAX V7.1.
One cannot update directly to a V6.2-1Hx Limited Hardware Release (LHR) from any release prior to the baseline V6.2 release. The same prohibition holds for performing updates directly to V7.1-1Hx from any release prior to V7.1 - this is not supported, and does not produce the expected results. The LHR kits can, however, be directly booted and can be directly installed, without regard to any operating system that might be present on the target disk.
OpenVMS Alpha updates for LHRs (through V7.1-1Hx) require the use of VMSINSTAL for the update. These LHR releases use PCSI for the installation, but not for the update. Non-LHR releases use PCSI for installs and upgrades.
OpenVMS Alpha V7.1-2 and later use PCSI for LHRs and for OpenVMS upgrades and for all OpenVMS ECO kit installations. VMSINSTAL OpenVMS ECO kits are not used on OpenVMS Alpha V7.1-2 and later. Prior to V7.1-2, VMSINSTAL-based ECO kits are used for OpenVMS.
OpenVMS VAX release upgrade paths:
From : | one can upgrade to : |
V5.0 through V5.4-3 inclusive | V5.5 |
V5.5, V5.5-1, or V5.5-2HW | V5.5-2 |
V5.5, V5.5-1, or V5.5-2 | V6.0 |
V5.5-2, V5.5-2H4, or V6.0 | V6.1 |
V6.0, or V6.1 | V6.2 |
V6.1, or V6.2 | V7.0 |
V6.1, V6.2, or V7.0 | V7.1 |
V6.1 (with VAXBACK ECO for V6.1) | V7.2 |
Some typical OpenVMS VAX upgrade paths are:
V5.x | -> | V5.5 | -> | V6.0 | -> | V6.2 | -> | V7.0, or V7.1 |
V5.5-2, or V5.5-2H4 | -> | V6.1 | -> | V6.2, V7.0, or V7.1 | ||||
V6.1 | -> | VAXBACK V6.1 ECO | -> | V7.2 | ||||
V6.2 | -> | V7.2 |
Note that OpenVMS VAX V6.0 does not include support for hardware and/or configurations first added in OpenVMS VAX V5.5-2H4, one must upgrade to OpenVMS VAX V6.1.
Note that OpenVMS VAX V5.5-2HW is a pre-release version of V5.5-2. Any system running it should be upgraded to V5.5-2, or later.
VMScluster Rolling Upgrades:
Rolling Upgrades require multiple system disks. Rolling upgrades
permit the VMScluster to remain available while individual systems
are being upgraded to a new OpenVMS release.
VMScluster rolling upgrades for both OpenVMS VAX and OpenVMS Alpha may (will) have different, or additional upgrade requirements, and have requirements around which versions of OpenVMS can coexist in a VMScluster than what is listed here.
See the OpenVMS <platform> Version <Version> Upgrade and Installation Manual, and the OpenVMS Software Product Description
http://www.digital.com/info/SPHOME/)for further details on the rolling upgrade, and for support information. The documentation for older releases of OpenVMS VAX includes various platform-specific manuals, manuals that include instructions that are specific to installing and upgrading on the platform.
Layered Product and Support Information:
For information on Prior Version support, see:
http://www.compaq.com/services/software/ss_mature.html
For information on supported versions of layered products, and
minimum required layered product versions, see:
http://www.openvms.digital.com/openvms/os/swroll/index.htmlFor information on the release history of OpenVMS, including information on the code names of various releases and the major features:
http://www.openvms.digital.com/openvms/os/openvms-release-history.htmlAdditional release history information, as well as a variety of other trivia, is available in the VAX 20th anniversary book:
http://www.openvms.digital.com/openvms/20th/vmsbook.pdfOpenVMS Alpha Terminology:
Seeing a negative number in the reservable pages portion of the SHOW MEMORY/FULL command can be normal and expected, and is (even) documented behaviour. A pagefile with a negative number of reservable pages is overcommitted, which is generally goodness assuming that every process with reserved pages does not try to occupy all of the reserved pagefile space at the same time.
To understand how the pagefile reservation process works, think about how a traditional bank operates when accepting customer deposits and making loans. It's the same idea with the pagefile space. There is less money in the bank vault than the total deposits, because much of the money has been loaned out to other customers of the bank. And the behaviour parallels that of the pagefile down to the problems that a "run on the bank" can cause for banking customers. (Though there is no deposit insurance available for pagefile users.)
If all of the running applications try to use the reserved space, the system manager will need to enlarge the pagefile or add one or more additional pagefules.
To determine if the pagefile is excessively overcommitted, watch for "double overcommitment" - when the reservable space approaches the negation of the available total space - and watch that the total amount of free space available in the pagefile remains adequate. If either of these situations arises, additional pagefile storage is required.
Additional pagefile information: Additional pagefiles can typically be created and connected on a running OpenVMS system. New processes and new applications will tend to use the new pagefile, and existing applications can be restarted to migrate out of the more congested pagefiles. Pagefiles are generally named PAGEFILE.SYS, and multiple pagefiles are generally configured on separate disk spindles to spread the paging I/O load across the available disk storage. When multiple pagefiles are present on recent OpenVMS versions, each pagefile file should be configured to be approximately the same total size as the other pagefiles.
For additional information on pagefile operations and related commands, see the system management and performance management manuals in the OpenVMS documentation set.
[Steve Hoffman]
Comprehensive Public Rollout Information, listing previous product versions as well as currently shipping versions, has been compiled into a separate set of reports. The product information is grouped to show Operating System support.
You may or may not be able to use older versions of local applications,
third-party products, and various Compaq layered products with more recent
versions of OpenVMS. User-mode code is expected to be upward compatible.
Code executing in a privileged processor mode - typically either executive or
kernel mode - may or may not be compatible with more recent OpenVMS versions.
These reports are updated monthly.
Please see:
http://www.openvms.digital.com/openvms/os/swroll/index.html [Steve Hoffman]
$ PRODUCT REGISTER VOLUME <old-label> <device>To reset the label information stored in the PCSI database to reflect the new disk volume label.
[Stephen Hoffman]
If you have problems with the BACKUP savesets after unzipping them or after an FTP file transfer, you can try restoring the appropriate saveset attributes using the tool:
$ @RESET_BACKUP_SAVESET_ATTRIBUTES.COMThis tool is available on the OpenVMS Freeware (in the [000TOOLS] directory). The Freeware is available at various sites - see the Freeware location listings elsewhere in the FAQ - and other similar tools are also available from various sources.
In various cases, the following command might work:
$ SET FILE/ATTRIBUTES=(RFM:FIX,MRS:32256,LRL:32256,RAT:NONE) file.bckAlso see the SITE VMS, /FDL, and various other file-attributes options available in various FTP tools. (Not all available FTP tools support any or all of these options.)
[Stephen Hoffman]
The following also shows how to set up a resource identifier, which further allows the disk resources to be charged to the specified identifier rather than each individual user. (If you don't want this, then omit the attributes option on the identifier creation and omit the entry added in the disk quota database.
Add an identifier using AUTHORIZE:
ADD/IDENTIFER/ATTRIBUTES=RESOURCE groupidentifierGrant the identifier to each user in the group using AUTHORIZE:
GRANT/IDENTIFIER groupidentifier usernameIf disk quotas are in use, add an entry via SYSMAN for each disk:
DISKQUOTA ADD groupidentifier/PERMQUOTA=pq/OVERDRAFT=od/DEVICE=ddcu:Set the shared directory to have an ACL similar to the following using the SET SECURITY (V6.0 and later) or SET ACL (versions prior to V6.0) command:
(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) (IDENTIFIER=groupidentifier,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=groupidentifier,ACCESS=READ+WRITE+EXECUTE+DELETE) (CREATOR,ACCESS=READ+WRITE+ACCESS+DELETE)If there are files already resident in the directory, set their protections similarly. (The OPTIONS=DEFAULT, DEFAULT_PROTECTION, and CREATOR ACEs apply to directories.)
The default protection mask is used to establish the default file protection mask, this mask does not prevent the users holding the specified groupidentifier from accessing the file(s), as they can access the file via the explicit identifier granting access that is present in the ACL.
For further information, see the OpenVMS Guide to System Security Manual, specifically the sections on ACLs and identifiers, and resource identifiers.
[Stephen Hoffman]
http://www.openvms.digital.com/wizard/ http://www.openvms.digital.com/wizard/wiz_1020.htmlThere are a variety of discussions of this and of related printing topics in the Ask The Wizard.
[Stephen Hoffman]
On OpenVMS Alpha V7.1-2 and V7.2, acquire the appropriate GRAPHICS PCSI kit, and all prerequisite OpenVMS ECO kits:
VMS72_GRAPHICS-V0100 or later VMS712_GRAPHICS-V0100 or laterOn OpenVMS Alpha V7.2-1, the files necessary for this graphics controller are located in the distribution CD-ROM directory:
DISK$ALPHA0721:[ELSA.KIT]Also check for any available (later) ECO kits.
ALP4D20T01_071
) (for V7.1, V7.1-1H1, and V7.1-1H2)
was once available, but has been superceded and is not recommended.
Use of V7.1-2 or later (and use of one the above GRAPHICS
kits as
required) is typically the best approach.
[Stephen Hoffman]
http://search.service.digital.com/ ftp://ftp.service.digital.com/public/vms/ http://ftp.digital.com.au/pub/ecoinfo http://ftp/digital.com.au/cgi-bin/grepYou can subscribe to an email notification list at:
http://www.service.digital.com/patches/mailing-list.htmlA quarterly distribution is also available on CD-ROM:
http://www1.service.digital.com/svctools/decevent/md5-frame.html [Stephen Hoffman]
From OpenVMS:
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT FYA0/NOADAPTER SYSGEN> ^Z $ SET HOST/DUP/SERV=MSCP$DUP/TASK=PARAMS <DSSI-NODE-NAME> ... PARAMS> STAT CONF <The software version is normally near the top of the display.> PARAMS> EXIT ...From the console on most 3000- and 4000-class VAX system consoles...
Integrated DSSI:
>>> SET HOST/DUP/DSSI[/BUS:[0:1]] dssi_node_number PARAMS
KFQSA:
>>> SET HOST/DUP/UQSSP port_controller_number PARAMSFor information on how to get out into the PARAMS subsystem, also see the >>> HELP at the console prompt for the SET HOST syntax, or see the HELP on SET HOST /DUP (once you've connected FYDRIVER under OpenVMS).
Once you are out into the PARAMS subsystem, you can use the FORCEUNI
option to force the use of the UNITNUM value and then set a unique
UNITNUM inside each DSSI ISE - this causes each DSSI ISE to use the
specfied unit number and not use the DSSI node as the unit number.
Other parameters of interest are NODENAME and ALLCLASS, the node name
and the (disk or tape) cluster allocation class.
Ensure that all disk unit numbers used within an OpenVMS Cluster disk allocation class are unique, and all tape unit numbers used within an OpenVMS Cluster tape allocation class are also unique.
[Stephen Hoffman]
To move the queue database:
$ mcr JBC$COMMAND JBC$COMMAND> DIAG 0 7
$STOP/QUEUE/MANAGER/CLUSTER
$ backup SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* DISK:[DIR]
$ CREATE/DIR fast_disk:[qman]
$ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* fast_disk:[qman]
$DELETE SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$*
$START/QUEUE/MANAGER fast_disk:[qman]
[Dave Sweeney]
$ TCPIP SET ROUTE/GATE=x.x.x.x/DEF/PERMor
$ UCX SET ROUTE/GATE=x.x.x.x/DEF/PERM
Most Alpha systems support loading both the AlphaBIOS/ARC console and the SRM console at the same time, but systems such as the AlphaStation 255 are "half-flash" systems and do not support the presence of both the AlphaBIOS/ARC and SRM console firmware at the same time. If you have a "half-flash" system, you must load the SRM firmware from floppy, from a network download, or from a firmware CD-ROM. Following the normal AlphaBIOS or ARC firmware update sequence to the APU prompt, and then explictly select the target console. In other words, power up the system to the AlphaBIOS or ARC console, use the supplementary options to select the installation of new firmware (typically from CD-ROM), and then rather than using a sequence which updates the current firmware:
Apu-> update -or- Apu-> update ARC Apu-> verify Apu-> quitPower-cycle the system
Apu-> update SRM Apu-> verify Apu-> quitPower-cycle the system
>>> b -fl 0,A0 ddcu BOOTFILE: firmware_boot_file.exe Apu-> update ARC Apu-> verify Apu-> quitPower-cycle the system
If you have a "full-flash" system and want to select the SRM console from the AlphaBIOS or ARC console environment, select the "Switch to OpenVMS or Tru64 UNIX console" item from the "set up the system" submenu. Then power-cycle the system. If you have a "full-flash" system with the SRM conssole and want to select AlphaBIOS/ARC, use the command:
>>> set os_type NTand power-cycle the system.
For information on acquiring firmware, see ALPHA6.
For information
on OpenVMS license PAKs (for hobbyist use) see VMS9.
For information
on the Multia, see ALPHA8.
These undeletable jobs typically become of interest because they are holding onto a particular resource (eg: tape drive, disk drive, communications widget) that you need to use... If the particular device supports firmware, ensure that the device firmware is current - TQK50 controllers are known for this when working with old firmware. (That, and the infamous MUA4224 firmware bug.) If this device has a driver ECO kit available, acquire and apply it... If the particular relevent host component has an ECO, acquire and apply it.
Useful tools include SDA (to see what might be going on) and DECamds
(which increase and thus potentially fix quota-related problems).
NB: Applications with quota leaks will obviously not stay fixed.
If the stuck application is BACKUP, ensure you have the current BACKUP ECO and are directly following the V7.1 or (better) V7.2 process quota recommendations for operator BACKUP accounts.
If the firmware and ECO levels are current, the best approach is to take a system crashdump, and pass a copy of the dump file it along to whomever is maintaining the device driver for the particular device/widget/driver involved, with any details on how you got into this situation. (The reboot involved with taking the crashdump will obviously clear the problem.)
There was some kernel-mode code (typically for OpenVMS VAX) that can reset the device ownership field, but that is rather obviously only an interim solution - the real fix is avoiding the loss of the IRP, the process quota leak, or whatever else is "jamming up" this particular process.
[Stephen Hoffman]
As for an unsupported approach - and be aware of the potential for causing a system crash...
To reset the error count, one needs to determine the system address of the error count field. For a device, this is at an offset within the device's UCB structure. On VAX, the field is at an offset symbolically defined as UCB$W_ERRCNT. On Alpha, this field's offset is symbolically defined as UCB$L_ERRCNT. The former is a word in size; the latter is a longword. (Could it be that Alpha devices are more error prone? ;)
You now need to locate the system address of the UCB$%_ERRCNT field of the device you wish to reset. Enter SDA. In the following, you will see designations in {} separated by a |. The first item in braces is to be used on the VAX and the second item should be used on an Alpha. (ie. {VAX|Alpha})
$ ANALYZE/SYSTEM SDA> READ SYS${SYSTEM|LOADABLE_IMAGES}:SYSDEF.STB SDA> SHOW DEVICE <ddnc:> ! device designation of device with error SDA> EVALUATE UCB+UCB${W|L}_ERRCNT Hex = hhhhhhhh Decimal = -dddddddddd UCB+offsetRecord the hexadecimal value "hhhhhhhh" returned.
You can now exit from SDA and $ RUN SYS$SHARE:DELTA or do what I prefer to do, issue the following:
SDA> SPAWN RUN SYS$SHARE:DELTAOn both VAX and Alpha, the DELTA debugger will be invoked and will identify itself. On Alpha, there will be an Alpha instruction decoded. For those unfamiliar with DELTA, it does not have a prompt and only one error message - Eh? (Well, for sake of argument, there might be another error produced on the console if you're not careful - aka. a system crash!)
If you are on a VAX, enter the command: [W
If you are on Alpha, enter the command: [L
These set the prevailing mode to word and longword respectively. Remember the UCB${W|L)_ERRCNT differences?
Now issue the command 1;M
DELTA will respond with 00000001
You're now poised to ZAP the error count field. To do so you need to enter the system address and view its contents. The format of the command to do this is of the form:
<IPID>:<hhhhhhhh>/For an IPID, use the IPID of the SWAPPER process. It is always: 00010001
Thus, to ZAP the error count, you would enter:
00010001:hhhhhhhh/When you enter the / SDA will return the content of the address hhhhhhhh.
00010001:80D9C6C8/0001 ! output on VAX 1 error 00010001:80D9C6C8/00000001 ! output on Alpha 1 errorYou can now ZAP the error count by entering a zero and typing a carriage return. For example:
00010001:80D9C6C8/0001 0<cr> ! output on VAX 1 error 00010001:80D9C6C8/00000001 0<cr> ! output on Alpha 1 errorNow type the command EXIT and a carriage return.
[Brian Schenkenberger]
$ Devpend2 = F$GETDVI("$n$MKcxxx:","DEVDEPEND2") $ Comp_sup = %X00200000 $ Comp_ena = %X00400000 $ IF (Devdpend2.AND.Comp_sup).EQ.Comp_sup THEN - WRITE SYS$OUTPUT "Compression supported" $ IF (Devdpend2.AND.Comp_ena).EQ.Comp_sup THEN - WRITE SYS$OUTPUT "Compression enabled"
The same basic steps necessary for moving RIGHTSLIST and SYSUAF files to another node are rather similar to the steps involved in merging these files in an OpenVMS Cluster - see the appendix of the OpenVMS Cluster documentation for details of merging files. (You might not be merging the contents of two (or more) files, but you are effectively merging the contents of the files into the target system environment.)
Considerations:
If you encounter a collision, changing both of the identifier binary values (or names) involved in the collision to new and unique values can prevent security problems if you should miss a couple of identifiers embedded somewhere on the target system during the whole conversion process - rather than the wrong alphanumeric value for the identifier being displayed, you'll simply see the binary format for the identifier displayed, and no particular access will be granted. And any DCL commands or such that reference the old alphanumeric name will fail, rather than silently (and potentially erroneously) succeeding.
Similar requirements exist for UIC values, as these too tend to be scattered all over the system environment. Like the binary identifier values, you will find UIC values associated with disks, ACLs, queues, and various other structures.
For a list of the various files shared in an OpenVMS Cluster and that can be involved when relocating an environment from one node to another (or merging environments into an OpenVMS Cluster), please see the SYLOGICALS.TEMPLATE file included in OpenVMS V7.2 and later releases.
[Stephen Hoffman]
Top |
That said, there is no one answer to this question. Internet mail is built upon the TCP/IP protocols, which are not directly supported by OpenVMS - support requires the installation of a package that understands TCP/IP and specifically one that provides the Simple Mail Transport Protocol (SMTP).
A number of implementations of TCP/IP are available for OpenVMS - from Compaq, from third parties, and even a free "support it yourself" form. The MAIL program that comes with OpenVMS does not directly support the mail protocol used on the Internet (though it does recognize SMTP addresses in V6.2 and later), but various programs have been written that use MAIL's "foreign protocol" facility to provide such support - these tools are called transports. To send mail through a transport, place the transport specifier at the front, and (typically) quote the address.
For example, IN%"hoffman@bogushost.compaq.com" - you must include the quotation marks - indicates that IN transport will be used to send the mail to the address hoffman@bogushost.compaq.com. Common names for the transport are IN%, MX%, and SMTP%. (MX is a widely used, free, mail handler; see question SOFT1. SMTP% is used by Compaq's TCP/IP Services product.) Other systems may use some other name. If none of these prefixes work, please ask your system manager for assistance.
[leichter@lrw.com] [Stephen Hoffman]See also MAIL2
As of OpenVMS V6.2, this is not necessary - if the address has an @ in it (not in a quoted string), MAIL will look to see if the logical name MAIL$INTERNET_TRANSPORT is defined. If it is, it will use the translation as the transport protocol, otherwise it will use SMTP (as is used by UCX). For example, if you wanted IN% added, you'd define MAIL$INTERNET_TRANSPORT as "IN".
The basic MAIL utility which is shipped with VMS does not have an intrinsic mechanism for adding signature files. If you're using an enhanced mail handling package (e.g PMDF), however, it may have provisions for adding signature files to all messages it handles - check the documentation for details. In addition, it's common practice to use an editor to handle addition of quotation marks (e.g. ">") and signature files to mail messages and news postings. There are several implementations of this for different editors available on the net; for one example, see the MAIL_EDIT package available at:
ftp://narnia.memst.edu/mail_edit_v1-4.zip [bailey@genetics.upenn.edu]Define the logical MAIL$EDIT to a COM-file, which looks something like the following:
$ IF P1 .NES. "" $ THEN $ COPY 'P1',[signaturefile] 'P2' $ ELSE $ COPY [signaturefile] 'P2' $ ENDIF $ DEFINE/NOLOG SYS$INPUT SYS$COMMAND $ [editorname] 'P2' $ EXITWhere [signaturefile] is the name of the signature-file (including directory and disk) and [editorname] is EDIT/EDT or EDIT/TPU (or your favorite editor).
[Arne Vajhøj]
[Jerry Leichter]
You can forward your mail to an Internet address, but you have to be careful because of the way MAIL handles special characters, such as quotation marks. First, determine the address you would use to send mail to the place you want to forward to - say, IN%"fred@fred-host.xxx.com". Take that string and double all the quotation marks, producing IN%""fred@fred-host.xxx.com"". Finally, wrap quotation marks around the outside and use the the result with SET FORWARD:
MAIL> SET FORWARD "IN%""fred@fred-host.xxx.com"""If you do SHOW FORWARD, you should now see:
Your mail is being forwarded to IN%"fred@fred-host.xxx.com". [Jerry Leichter]Note that the MAIL$INTERNET_TRANSPORT feature doesn't yet work with SET FORWARD in that you'll still have to use the syntax above with the quotation marks.
Many of the TCP/IP mail packages support forwarding to mailing lists, as does the free MX mail handling system and the DELIVER mail "extender". See the documentation of your TCP/IP package and question SOFT1.
[Jerry Leichter]
EXTRACT/APPEND/ALL/MAIL mymail.maiMove MYMAIL.MAI to the other system, then do this (in MAIL):
SET FILE mymail.mai COPY/ALL foldername MAIL.MAIThis will place a copy of all of your messages in the given folder. If you wanted to maintain the separate folders, do separate EXTRACT commands (above) specifying different .MAI files, then repeat the SET FILE, COPY for each one.
If you are moving to a non-OpenVMS system, the EXTRACT command above can be used to create a file which you can then copy - how you import it into your mailer is an exercise left to the reader.
Not directly with the OpenVMS MAIL facility, but there are several other options:
http://www.innosoft.com/ http://www.agh.cc.kcl.ac.uk/files/vms/pine-vms/ ftp://ftp2.kcl.ac.uk/pub/vms/pine-vms/
To read a MIME mail message, open it in MAIL, extract it to a file, then use MUNPACK to break out and decode the attachments.
[David Mathog]
Top |
There's also SYS$EXAMPLES:CDROM_AUDIO.C and .EXE, a non-Motif program.
The Compaq Advanced Server (formerly known as PATHWORKS) for OpenVMS product includes an unsupported and undocumented utility called PCDISK, and this tool can read and write various MS-DOS format diskettes.
ProGIS in Germany sells a product called VMove which supports DOS files on many different device types. For more information, send mail to info@progis.rmi.de.
Engineering Software has a product called VAKSAT which will read, write,
and erase files on DOS diskettes. Available for both VAX and Alpha.
Contact ed@cityscape.co.uk for more information.
MadGoat PC Exchange (PCX) is a utility for copying files to and from MS-DOS format diskettes under VMS, using an RX23 (3.5"), RX26 (3.5"), or RX33 (5.25") diskette drive. For 3.5" diskettes, high-density disks can be read or written; double-density disks are read-only. Only high-density disks are supported on the RX33.
http://www.madgoat.com
http://www.digital.com/info/SP6424/which provides a replacement DECsound for this card as well as many other features (an AVI and MPEG player, video capture support, etc.)
Top |
$ uudecode :== $disk:[dir]uudecode.exe $ uudecode filespecThe leading $ in the symbol definition is what makes it a foreign command. If the device and directory is omitted, SYS$SYSTEM: is assumed.
Under OpenVMS V6.2 and later, DCL supports automatic foreign command definition via the logical name DCL$PATH:. An example of a definition of this logical name is:
$ DEFINE DCL$PATH SYS$DISK:[],ddcu:[mytooldir],SYS$SYSTEM:DCL will first look for a command in the DCL command table, and if no match is found and if DCL$PATH is defined, it will then look for command procedures and executable images with filenames matching the command specified, in the directories specified via DCL$PATH. The first match found is invoked, and under OpenVMS, the DCL$PATH support will cause a command procedure to be activated in preference to an executable image.
For more information on foreign commands or on automatic foreign command support, see the OpenVMS User's Manual.
See also question PROG2.
If you want to create a detached process that takes arguments from a command line, it must be run under the control of a command line interpreter (CLI) (typically DCL). This is done by placing the command line in a file, specifying SYS$SYSTEM:LOGINOUT.EXE as the image to run and the command file as the input. For example:
$ OPEN/WRITE CMD TEMP_INPUT.COM $ WRITE CMD "$ MYCOMMAND arguments" $ CLOSE CMD $ RUN/DETACHED SYS$SYSTEM:LOGINOUT /INPUT=TEMP_INPUT.COMVarious OpenVMS library calls (such as lib$spawn(), cli$dcl_parse(), and the C library system() call) require access to a command line interpreter such as DCL to perform requested actions, and will not operate if a CLI is not available.
When a CLI is not available, these calls typically return the error status SS$_NOCLI. And as mentioned above, invoke the image LOGINOUT to cause a CLI (such as DCL) to be mapped into and made available in the context of the target process.
[Steve Hoffman]
The terminal driver line-editing control keys, including the use of DEL for delete, are not modifiable.
$ CLS :== TYPE/PAGE NLA0:
$ DEFINE/USER SYS$COMMAND _OPA0: $ REPLY/LOG $ DEFINE/USER SYS$COMMAND _OPA0: $ REPLY/ENABLETo disable the system console terminal (OPA0:) as an operator terminal, use the following command:
$ DEFINE/USER SYS$COMMAND _OPA0: $ REPLY/DISABLEAlso see SYLOGICALS.COM (and SYLOGICALS.TEMPLATE) for information on configuring the behaviour of OPCOM, including the use of the system console (OPA0:) as an operator and the specific contents and behaviour of the system operator log file OPERATOR.LOG.
[Stephen Hoffman] [Arne Vajhøj]
$! RAND - returns a positive random number ("RANDOM") between 0 and $! __CEIL - 1. $ RAND: $ $ IF F$TYPE(__SEED) .EQS. "" $ THEN $ ! seed the random number generator, ... $ __NOW = F$CVTIME() $ __HOUR = 'F$EXTRACT(11,2,__NOW)' $ __MINUTE = 'F$EXTRACT(14,2,__NOW)' $ __SECOND = 'F$EXTRACT(17,2,__NOW)' $ __TICK = 'F$EXTRACT(20,2,__NOW)' $ $ __SEED == __TICK + (100 * __SECOND) + (6000 * __MINUTE) + - (360000 * __HOUR) $ ! the generator tends to do better with a large, odd seed, ... $ __SEED == (__SEED .OR. 1) $ ! clean up, ... $ DELETEX/SYMBOL __NOW $ DELETEX/SYMBOL __HOUR $ DELETEX/SYMBOL __MINUTE $ DELETEX/SYMBOL __SECOND $ DELETEX/SYMBOL __TICK $ ENDIF $ $ IF F$TYPE(__CEIL) .EQS. "" THEN __CEIL = %X3FFFFFFF $ $ __SEED == __SEED * 69069 + 1 $ $ RANDOM == (__SEED.AND.%X3FFFFFFF)/(%X40000000/__CEIL) $ $ RETURN [sharris@sdsdmvax.fb3.noaa.gov]
$ MCR FOO BARis equivalent to:
$ FOO :== $FOO $ FOO BARIt derives from the RSX operating system from which VMS evolved and is still often used as a shortcut for activating images. The MCR command is different from the MCR command line interpreter, which is provided as part of the optional VAX-11 RSX product that provides RSX emulation under VMS.
You can use the SET PROMPT command for this purpose. SET PROMPT sets the DCL prompt to the specified string.
When you want to display variable information, you will need to establish a tie-in that provides the information to the SET PROMPT command as required.
If you wish to display the default directory for instance, you will have to establish a tie between the SET DEFAULT command and the SET PROMPT commands, as there is no direct way to get the default directory as the DCL prompt. You can easily acquire or create a set of DCL command procedures that perform the SET DEFAULT and SET PROMPT for you. These DCL command procedures often use a command such as:
$ set prompt='f$env("default")'More advanced users could implement a system service or other intercept, and use these tools to intercept the directory change and reset the prompt accordingly. (This approach likely involves some kernel-mode programming, and requires write access to various undocumented OpenVMS data structures.)
There are related tools available from various sources, including the following web sites:
[Steve Hoffman]
Yes, you can do this with DCL.
The OpenVMS DECnet documentation shows various simple examples using the task object and the TYPE command to trigger the execution of a DCL command procedure on a remote node. A slightly more advanced example of using DCL for DECnet task-to-task - a procedure that acts as both the client and as the server as appropriate, and that uses a basic form of half-duplex communications - is included:
$! x.com $ $! This procedure must be in the user's login directory. $! Requires a self-referential (not reverential :-) proxy: $! UAF> add/prox <LocalNode>::<CurrentUser> <CurrentUser>/default $! Author: Stephen Hoffman, OpenVMS Engineering, Compaq $ $ goto 'f$mode()' $INTERACTIVE: $ open/read/write chan 0::"task=x" $ write chan "Hello" $ read chan parameter $ close chan $ write sys$output parameter $ exit $BATCH: $OTHER: $NETWORK: $ open/read/write chan sys$net $ read chan parameter $ write chan "''parameter' yourself!" $ close chan $ exitAn example of a run of the above procedure:
$ @x Hello yourself! $DCL does not include support asynchronous I/O, thus a predetermined protocol or a predetermined "turn-around" command sequence must be implemented in order to avoid protocol deadlocks - cases where both tasks are trying to write or both tasks are trying to read. The task that is writing messages to the network must write (or write and read) a predetermined sequence of messages, or it must write a message that tells the reader that it can now start writing messages. (This is the essence of a basic half-duplex network protocol scheme.)
[Steve Hoffman]
Top |
If you are setting up a user environment for yourself or for others, it
is quite easy to use DCL to intercept the DELETE command, using a symbol:
$ DEL*ETE :== @SYS$LOGIN:MYDELETE.COMThe DELETE symbol will cause the procedure to be invoked whenever the user enters the DELETE command, and it can copy the file(s) to a trashcan subdirectory before issuing a real DELETE on the files. Other procedures can retrieve the file(s) from the trashcan subdirectory, and can (and should) clean out the trashcan as appropriate.
[Steve Hoffman]
[Steve Lionel] $ DIR/SIZ=ALL/GRAND [username...] Grand total of D1 directories, F1 files, B1/B2 blocks. $ DIR/SIZ=ALL/GRAND [-]username.DIR Grand total of 1 directory, 1 file, B3/B4 blocks. $ SHOW QUOTA User [username] has B5 blocks used, B6 available, of B7 authorized and permitted overdraft of B8 blocks on diskIf the user has no files in other directories and all file-headers are only 1 block, then the following should apply:
B5=B2+B4+F1+1If the diskquota is out of synch, then the system-manager can do a rebuild.
Also be aware that the DIRECTORY/SIZE command can report larger values than might otherwise be expected when used to evaluate files and/or directories that are alias links - such as the system roots on OpenVMS system disks - as the command reports a total that is cumulative over all of the files and directories examined, without regard for which ones might be alias entries and which are not. (In other words, a DIRECTORY/SIZE of an entire OpenVMS system disk will report a disk useage value larger than the (usually more accurate) value reported by the SHOW DEVICE command. This as a result of the alias entries linking each SYS$SYSDEVICE:[SYSCOMMON]SYS*.DIR directory file and the SYS$SYSDEVICE:[000000]VMS$COMMON.DIR file together.)
[Arne Vajhøj]
Application developers should use OpenVMS-supplied routines for parsing
file specifications - this ensures that changes in what is allowable will
not tend to break your application. Consider that various parts of the
file specification may contain quoted strings with embedded spaces and
other punctuation!
Some routines of interest are SYS$FILESCAN, SYS$PARSE and
LIB$TRIM_FILESPEC.
For further information, see the OpenVMS Guide to File Applications.
Prior to the release of V6.0, the OpenVMS file system was limited to disk volumes of 8.5 GB (224 blocks) or less.
On some systems, there are restrictions in the console program that limit the size of the OpenVMS system disk. Note that data disks are not affected by console program limits. For example, all members of the VAXstation 3100 series are limited to a system disk to 1.073 GB or less due to the console, though larger data disks are possible.
Some SCSI disks with capacities larger than 8.6 gigabytes (GB) will
require the use of an OpenVMS ECO kit (eg: ALPSCSI04_062 or later) for
new SCSI device drivers. Failure to use this ECO can cause "rounding
errors" on the SCSI disk device capacity - OpenVMS will not use nor
display the full capacity of the drive - and give
"%SYSINIT-E-ERROR, Mounting system device status equals 000008C4"
(8C4 -> "%SYSTEM-?-FILESTRUCT, unsupported file structure level")
errors during bootstrap. (One
workaround for the bootstrap when the bitmap is located far into the
disk is the use of INIT/INDEX=BEGIN.) The problem here involves the
particular extensions and fields used for larger capacity disks within
the SCSI specifications and within the various intepretations of same.
[Steve Hoffman]For IDE disk drives:
NOTE: All IDE-related disk sizes listed in this section are stated in units of "disk (base 10) gigabytes" (1GB = 109 bytes) and not in units of "software (base 2) gigabytes" (1GB = 230 (1073741824.) bytes.
[Atlant Schmidt]
231 * 512 bytes = one terabyte (1 TB.)
The RMS formats - sequential, relative, and indexed - are limited by the one terabyte maximum volume size. RMS relative files are further limited to a number of records that will fit in 32 bits - 4 billion records. Sequential and indexed formats do not have a record limit.
Also see PROG14.
[Steve Hoffman]
OpenVMS has no integrated support for recording CD-R media.
OpenVMS can read both ODS2 and ISO9960 format CD-ROMs.
InfoServer hardware configurations are no longer availble from Compaq, but may potentially be acquired through other means.
The CDWRITE13_VMS package is one example of a host-based package that can be used to create CD-R media. The contact for CDWRITE13_VMS is Dr. Eberhard Heuser-Hofmann. One website that discusses this package is located at:
http://www.geocities.com/SiliconValley/Lakes/9999/vmscdwri.htmlAlso see the newest linux-cdwrite package, XCDROAST.
Additional information is available via David J. Dachtera at:
http://home.earthlink.net/~djesys/vms/cdrom.html
Also see:
http://www.cd-info.com/CDIC/Technology/CD-R/vms.html http://www.faqs.org/faqs/cdrom/cd-recordable/part1/preamble.html [Steve Hoffman]
The maximum size of a device I/O request is limited by the value in UCB$L_MAXBCNT, which is set by the device driver based on various factors. (Also check the setting of the MAXBUF system parameter for buffered I/O transfers, and check the process quotas.)
Currently, SCSI drivers limit I/O transfers to FE00(16) bytes, 65024 bytes (decimal). The reasons for this transfer size limitation are largely historical. Similarly, DSSI devices are limited to the same value, this for hardware-specific reasons. Transfers to HSC and HSJ device controllers via the CI are limited to 1,048,576 bytes. Client MSCP-served devices are limited to 65535 bytes - to help ensure that the I/O fragmentation processing happens on the client and not on the server system.
Parts of the OpenVMS I/O subsystem are optimized for data transfers less
than 64KB, because (obviously) most I/O operations are (substantially)
less than that. OpenVMS can handle larger transfers, if the driver and
the device can handle it.
Also see FILE4, FILE5
[John Croll]
Top |
[eric@tardis.HQ.ileaf.com]There is a lot of information available on how to call system services and Run-Time Library routines, including examples in numerous languages.
[Steve Lionel]Arne Vajhøj has put together a collection of OpenVMS example programs. It can be found at:
[Arne Vajhøj]Additional information and examples for OpenVMS are available via:
[Steve Hoffman]
To write an application which uses the normal DCL verb/qualifier/parameter syntax for invocation, see the description of the CLI$ routines in the OpenVMS Callable Utility Routines Reference Manual.
It is possible to write an application which can be used both ways; if a DCL verb isn't used to invoke the image, the application parses the command line itself. One way to do this is to call CLI$GET_VALUE for a required parameter. If it is not present (or you get an error), call LIB$GET_FOREIGN to get the command line and do the manual parse.
See also question DCL1.
[Arne Vajhøj]
SYMBOL_VECTOR=(FOO=PROCEDURE, BAR=PROCEDURE)The Linker manual has more details on this.
This has several advantages over OpenVMS VAX. First, you don't have to worry about the address of the psect when you try to create a new, upwardly compatible version of the shareable image. Second, you can control which psects, if any, are made visible outside the shareable image.
By default, COMMON PSECTs in DEC Fortran for OpenVMS Alpha (as well as most other OpenVMS Alpha compilers) are NOSHR. On VAX, the default was SHR which required you to change the attribute to NOSHR if you wanted your COMMON to be in a shareable image but not write-shared by all processes on the system. If you do want write-sharing, use: CDEC$ PSECT common-name=SHR in the Fortran source code (the CDEC$ must be begin in column 1) or a linker options file PSECT_ATTR statement to set the COMMON PSECT attribute to SHR.
For further information, see the Linker manual.
DEC Fortran (all platforms) has a feature which will perform automatic conversion of unformatted data during input or output. See the DEC Fortran documentation for information on "non-native data in I/O" and the CONVERT= OPEN statement keyword.
For further floating-point related information, see:
ftp://ftp.hhs.dk/pub/vms/collection/ieee.zip
Note that omitting arguments to Fortran routines is non-standard and is unsupported. It will work in many cases - read the DEC Fortran release notes for additional information.
Compaq OpenVMS uses a software-based system called the License Management Facility or LMF. This provides for software keys (Product Authorization Keys or PAKS) which support capacity and user-based license checking. Compaq offers an LMF PAK Generator to CSA members - See ALPHA4.
However, if a hardware-based method is required, the most common method is
based on an Ethernet adaptor hardware address. Sample source code for
implementing this is available at:
http://www.openvms.digital.com/wizard/
Executable images are programs that can be directly executed. These images can grant enhanced privileges, with an INSTALL of the image with /PRIVILEGE, or can grant enhanced access with the specification of a subsystem identifier on the ACL associated with the image.
Shareable images contain code executed indirectly, these images are referenced from executable images and/or from other shareable images. These images can not grant enhanced privileges, even with the use of INSTALL with /PRIVILEGE or a subsystem identifier. These shareable images can be dynamically activated (a LINK that occurs at run-time) via the LIB$FIND_IMAGE_SYMBOL run-time library (RTL) routine. (See "protected images" for information on "privileged shareable images".)
System images are intended to run directly on the VAX or Alpha hardware - these are normally used for the kernel code that comprises an operating system.
Protected images - also refered to as User-Written System Services (UWSS), or as privileged shareable images - are similiar in some ways to a standard shareable images, but these images include a "change mode" handler, and execute in an "inner" processor mode (privileged mode; executive or kernel), and code executing in inner modes has implicit SETPRV privilege. Must be INSTALLed with /PROTECT. Note that inner-mode code has restrictions around calling library routines, around calling various system services, and around calling code located in other protected or shareable images.
Loadable images and device drivers are images that can be used to add code into the OpenVMS kernel. Pseudo-device drivers are a particularly convenient way to add executable code, with associated driver-defined data structures, into the kernel. The pseudo-device driver includes the UCB and DDB data structures, and a calling interface with support for both privileged and unprivileged access to the driver code via sys$qio[w] calls.
A cookbook approach to creating OpenVMS shareable images is
available at the (admittedly overly long) URL:
http://www.openvms.digital.com/wizard/
[Steve Hoffman]
There are several options available for copying files from within a program. Obvious choices include using lib$spawn(), system(), sys$sndjbc() or sys$creprc() to invoke a DCL COPY command. Other common alternatives include using the callable convert routines and the BACKUP application programming interface (V7.1 and later).
[Steve Hoffman]
A descriptor is a data structure that describes a string or an array. Each descriptor contains information that describes the type of the data being referenced, the size of the data, and the address of the data. It also includes a description of the storage used for the data, typically static or dynamic. Descriptors are passed by reference.
The following are examples of creating and using descriptors in C:
#include <descrip.h> #include <lib$routines.h> #include <stsdef.h> int RetStat; char TxtBuf[TXTSIZ] struct dsc$descriptor StaticDsc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, NULL }; struct dsc$descriptor DynDsc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D, NULL }; int DynDscLen = 255; $DESCRIPTOR( ConstDsc, "This is a string" ); /* finish setting up a static descriptor */ StaticDsc.dsc$w_length = TXTSIZ; StaticDsc.dsc$a_pointer = (void *) TxtBuf; /* finish setting up a dynamic descriptor */ RetStat = lib$sget1_dd( &DynDscLen, &DynDsc ); if ( !$VMS_STATUS_SUCCESS( RetStat ) ) return RetStat; /* release the dynamic storage */ RetStat = lib$sfree1_dd( &DynDsc ); if (!$VMS_STATUS_SUCCESS( RetStat )) return RetStat;
Static descriptors reference storage entirely under application program control, and the contents of the descriptor data structure can be modified as required (by the application). OpenVMS routines do not modify the contents of a static descriptor, nor do they alter the address or length values stored in the static descriptor. (The term "static" refers to the descriptor data structure, and not necessarily to the storage referenced by the descriptor.)
Dynamic descriptors reference storage under the control of the run-time library, and the contents of a dynamic descriptor data structure - once initialized - can only be modified under control of run-time library routines. The dynamic storage referenced by the dynamic descriptor is allocated and maintained by the run-time library routines. Various OpenVMS routines do alter the contents of the descriptor data structure, changing the value for the amount and the address of the storage associated with the dynamic descriptor, as required. Routines can obviously access and alter the contents of the storage referenced by the descriptor.
OpenVMS languages that include support for strings or arrays are expected to use descriptors for the particular structure. Most OpenVMS languages, such as Fortran and BASIC, use descriptors entirely transparently. Some, like DEC C, require the programmer to explicitly create and maintain the descriptor.
For further information on string descriptors, see the OpenVMS Programming Concepts manual, part of the OpenVMS documentation set.
[Steve Hoffman]
Under OpenVMS VAX and OpenVMS Alpha, the disk volume block size is consistent, with each block containing 512 bytes.
The minimum disk allocation granularity actually permissible (in the ODS-2 and ODS-5 volume structures commonly used on OpenVMS) is determined on a per-volume basis, and is typically based on a combination of the total number blocks on the disk volume and the total size of the volume storage bitmap. The allocation granularity is known as the volume cluster factor - the cluster factor is the number of blocks in a disk cluster, and it is the smallest number of blocks that can be allocated on a particular disk volume.
Prior to OpenVMS V7.2, the maximum permissible size of the bitmap requires larger cluster factors as volume sizes increase. Starting with V7.2, the bitmap can be larger, and cluster factors as small as one block can be used.
The number of bytes in a file can be determined by multiplying the number of blocks allocated for the file times the number of bytes in a block. For sequential files (only), the FFB (XAB$W_FFB, in the File Header XAB) value can be used to find out how much of the last (XAB$L_EBK) block is used. FFB and EBK are meaningful only for sequential files, and only in a limited context - partial block allocations are not permitted. For other file formats, the EOF marker is not meaningful.
Disk allocations always occur only in units of the cluster factors, which can be from one block up to (potentially) clusters of eighteen blocks or more, depending on the volume cluster factor.
OpenVMS assumes that the device driver and the underlying storage device will present the file system with addressable units of storage of 512 bytes in size, or the appearance of same. Various third-party CD-ROM devices, for instance, support only 2048 byte blocks, and such devices are incompatible with the standard OpenVMS device drivers.
To determine the number of bytes required for a file from DCL, one option uses the F$FILE_ATTRIBUTES item EOF, multiplied by the size of a block in bytes (512). This does not account for the unused space in the last block of a sequential file, but it also does not have to differentiate sequential files from other files.
[Steve Hoffman]
A memory page is the minimum unit of memory allocation in OpenVMS. With OpenVMS VAX, the memory page size matches the disk block size: it is always 512 bytes.
With OpenVMS Alpha, the memory page size is variable, and it can range from 8192 bytes (8 kilobytes) up to 64 kilobytes. The current system page size can be determined using the sys$getsyi or f$getsyi PAGE_SIZE item. Programs with hardcoded constants for the memory page size (or page alignment) should always assume a page size of 64 kilobytes.
On OpenVMS Alpha, a 512 byte area of memory - equivAlent in size to an OpenVMS VAX memory page - is refered to as a pagelet.
[Steve Hoffman]
Many server processes can operate within the context of the target user using privileges, using calls such as SYS$CHKPRO and (more commonly in this context) SYS$CHECK_ACCESS as needed to determine if access would be permitted for the specified user within the current security model.
With OpenVMS V6.2 and later, the persona system services SYS$PERSONA_* can be used to assume the persona of the specified user - these allow the server to operate as the specified user, in a controlled fashion. The persona services can be used as a "wrapper" around a SYS$CREPRC process creation call, as well - this will create a seperate process entirely under the assumed persona.
Information on the persona system services is included in the OpenVMS V6.2 new features documentation, and in the OpenVMS V7.1 and later system services documentation. These system services exist and are supported in OpenVMS V6.2 and later releases.
Typical mechanisms for creating a process under another username include:
[Steve Hoffman]
Detached processes typically do not have a CLI present.
In place of lib$spawn, sys$creprc can often be used. The context of the parent process (symbols and logical names) will not be propagated into the subprocess when sys$creprc is used, though when there is no CLI present in the process this (lack of) propagation is moot.
To create a detached process with a CLI, you must specify LOGINOUT as the target image as discussed elsewhere in the FAQ, or only use these calls (and any other calls requiring a CLI) from images that are running in an "INTERACTIVE", "BATCH", or "OTHER" mode process.
[Stephen Hoffman]
Bliss language source code that contains the following statement:
LIBRARY 'SYS$LIBRARY:STARLET.L32';or similar requires the presence of the Bliss libraries. These libraries are created on the target system using the Bliss require files, and are built using the following Bliss commands:
STARLET.L32 contains the public interfaces to OpenVMS:
$ BLISS /LIBRARY=SYS$COMMON:[SYSLIB]STARLET.L32 - SYS$LIBRARY:STARLET.REQLIB.L32 contains both the public and private interfaces to OpenVMS:
$ BLISS /LIBRARY=SYS$COMMON:[SYSLIB]LIB.L32 - SYS$LIBRARY:LIB.REQ+SYS$LIBRARY:STARLET.REQThe equivilent files for Bliss64 are created with:
$ BLISS/A64/LIBRARY==SYS$COMMON:[SYSLIB]LIB.L64 - SYS$LIBRARY:LIB.R64+STARLET.REQ+STARLET.R64 $ BLISS/A64/LIBRARY==SYS$COMMON:[SYSLIB]STARLET.L64 - SYS$LIBRARY:STARLET.R64Some Bliss code may also require the OpenVMS VAX architecture flags. The following is the equivilent of the Alpha ARCH_DEFS.BLI module:
! ! This is the OpenVMS VAX version of ARCH_DEFS.BLI, and ! contains the architectural definitions for conditionally ! compiling OpenVMS Bliss sources for use on VAX systems. ! MACRO VAXPAGE = 1%; MACRO BIGPAGE = 0%; MACRO VAX = ! = 1 if compiled BLISS/VAX %BLISS(BLISS32V)%; ! = 0 if not compiled BLISS/VAX MACRO EVAX = ! = 1 if compiled BLISS/E* ! ! A more appropriate definition can only be used with versions ! of the Bliss compilers that understand the 32E/64E flags. ! %BLISS(BLISS32E) OR %BLISS(BLISS64E)%; ! = 0 if compiled /VAX NOT %BLISS(BLISS32V)%; ! = 0 if compiled /VAX MACRO ADDRESSBITS = %BPADDR%; ! = 32 or 64 based on compiler used [Stephen Hoffman]
A C source example that demonstrates how to do this is available in topic 2867 in the OpenVMS Ask The Wizard area:
http://www.openvms.digital.com/wizard/Depending on the environment, you may need to use C calls such as fsync and fflush, and - in specific cases - the setvbuf(_IONBF) call.
[Stephen Hoffman]
Top |
[raspuzzi@mrlat.enet.dec.com]Yah, but this doesn't seem to work with non-VMS systems. What do I put in for the transport? I tried TCPIP just for kicks, but it didn't work.
You need a checklist of sorts:
# setenv DISPLAY myvax.domain:0.0
$ decw$server_transports == "DECNET,LOCAL,LAT,TCPIP"If the transport you want, e.g., TCPIP, isn't listed, have your system manager make the appropriate changes and restart DECwindows. If the file doesn't exist, the sysmgr will have to create it by copying the corresponding .TEMPLATE file to .COM and uncommenting the line that defines DECW$SERVER_TRANSPORTS.
[Fairfield@Slac.Stanford.Edu]There is a log file created in SYS$MANAGER which tells you which transports are loaded, and also tell you what connect attempts were rejected, including showing what the presented credentials were. This file is SYS$MANAGER:DECW$SERVER_0_ERROR.LOG, although the 0 could be another number if you have multiple servers on the workstation. I have found this file to be very useful for tracking down what needs to be put in the Session Manager Security entries.
[rabinowitz@bear.com
$ SET DISPLAY /CREATE /TRANSPORT=net_transport /NODE=remote_nodefor LAT the command might look like this:
$ SET DISPLAY /CREATE /TRANSPORT=LAT /NODE=REMOTE_NODEfor DECnet:
$ SET DISPLAY /CREATE /TRANSPORT=DECNET /NODE=NODEfor TCP/IP
$ SET DISPLAY /CREATE /TRANSPORT=TCPIP /NODE=128.12.4.122Note that LAT is typically used for X terminals but can be used from OpenVMS to OpenVMS systems on OpenVMS Alpha V6.1 (if you have setup the X server to allow the LAT transport - check the docs). LAT will be supported on OpenVMS VAX as a transport for DECwindows in a future OpenVMS VAX release.
[raspuzzi@mrlat.enet.dec.com]There is a log file created in SYS$MANAGER which tells you which transports are loaded, and also tell you what connect attempts were rejected, including showing what the presented credentials were. This file is SYS$MANAGER:DECW$SERVER_0_ERROR.LOG, although the 0 could be another number if you have multiple servers on the workstation. I have found this file to be very useful for tracking down what needs to be put in the Session Manager Security entries.
[rabinowitz@bear.com]
[Fairfield@Slac.Stanford.Edu]An example of calling the underlying (and also undocumented) sys$qio programming interface for the WSDRIVER (WSAn:) is available at:
http://www.openvms.digital.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/
It should be noted that ALL the characters and escape sequences are captured, but if you display the log file on a DECterm you will get EXACTLY what you had.
[fenster@star.enet.dec.com]
You can override the default bindings in your decw$xdefaults.dat file. Here is the entry you would make to get the default VMS bindings.
*defaultVirtualBindings:\
osfCancel | : | <Key>F11 | \n\ |
osfLeft | : | <Key>Left | \n\ |
osfUp | : | <Key>Up | \n\ |
osfRight | : | <Key>Right | \n\ |
osfDown | : | <Key>Down | \n\ |
osfEndLine | :Alt | <Key>Right | \n\ |
osfBeginLine | :Alt | <Key>Left | \n\ |
osfPageUp | : | <Key>Prior | \n\ |
osfPageDown | : | <Key>Next | \n\ |
osfDelete | :Shift | <Key>Delete | \n\ |
osfUndo | :Alt | <Key>Delete | \n\ |
osfBackSpace | : | <Key>Delete | \n\ |
osfAddMode | :Shift | <Key>F8 | \n\ |
osfHelp | : | <Key>Help | \n\ |
osfMenu | : | <Key>F4 | \n\ |
osfMenuBar | : | <Key>F10 | \n\ |
osfSelect | : | <Key>Select | \n\ |
osfActivate | : | <Key>KP_Enter | \n\ |
osfCopy | :Shift | <Key>DRemove | \n\ |
osfCut | : | <Key>DRemove | \n\ |
osfPaste | : | <Key>Insert |
$ xrdb :== $decw$utils:xrdb.exe $ xrdb -nocpp -merge decw$xdefaults.dat [kleinsorge@star.enet.dec.com]
[kleinsorge@star.enet.dec.com]
[kleinsorge@star.enet.dec.com]
[kleinsorge@star.enet.dec.com] [inazu_k@ewbv21.enet.dec.com]
HELP CREATE /TERMINAL /WINDOW_ATTRIBUTES.If you want to change the title of an existing window, use the following control sequences, where <ESC> is the ANSI escape code, value decimal 27, and [Text] is what you want to display:
To set the DECterm title, send <ESC>]21;[Text]<ESC>\ To set the icon label, send <ESC>]2L;[Text]<ESC>\
For example, DCL to display "My DECterm" in title bar:
$ ESC[0,8]=27 $ WRITE SYS$OUTPUT "''ESC']21;My DECterm''ESC'\" [p_lee@decus.ch]You can also change the title and the icon using the Options-Window... menu.
To customize various DECwindows Motif characteristics including the defaults used by the SET DISPLAY command, the DECwindows login screen background logo used (the default is the Digital or Compaq logo), various keymaps, the FileView defaults, session manager defaults, the DECwindows login processing, DECwindows log file processing, and various other DECwindows attributes, see the example file:
SYS$STARTUP:DECW$PRIVATE_APPS_SETUP.TEMPLATEThis example template file is typically copied over to the filename SYS$COMMON:[SYS$STARTUP]DECW$PRIVATE_APPS_SETUP.COM and then modified to meet site-specific requirements.
Additionally, various X tools such as xsetroot, bitmap and xrdb -- some these can be useful in customizing the appearance of an application or of the DECwindows Motif display - are provided in the DECW$UTILS: area.
When using DECwindows V1.2-4 and later on OpenVMS Alpha, the default desktop is the Common Desktop Environment (CDE). You can select your prefered desktop (CDE or DECwindows Motif) when logging in, or you can change the default to the DECwindows Motif desktop using the DCL symbol decw$start_new_desktop in the DECwindows private application setup command procedure. See SYS$STARTUP:DECW$PRIVATE_APPS_SETUP.TEMPLATE for further details, and how to create DECW$PRIVATE_APPS_SETUP.COM.
Note that with DECwindows CDE, the root window is no longer visible by default. The root window is hidden behind the "backdrop" window of the current CDE workspace. To make the root window visible, use the CDE style manager selection backdrop none, and use information such as that in the OpenVMS FAQ to set the root window.
To add a new backdrop to the DECwindows CDE environment, the backdrop
must first be in or be converted into X11 pixmap format. (This conversion
is often possible using tools such as xv.) Then (if necessary) create
the default backdrop directory SYS$COMMON:[CDE$DEFAULTS.USER.BACKDROPS].
Place the X11 pixmap file containing the desired image into the backdrops
directory, ensure that it has a filename extension of .PM. (The xv
default filename extension for the X11 pixmap file is .XPM, while CDE
expects only to see files with .PM.) Now invoke the CDE style manager
and select a new backdrop. You will find your image will be placed at
the end of the list of backdrops available.
[Stephen Hoffman]
On platforms where C is the typically the primary programming language for the platform, the file descriptor mask is one of the arguments to the XtAppAddInput() call.
On OpenVMS, the platform-specific arguments to this call include an event flag and an IOSB, as these are the traditional OpenVMS constructs used to synchronize the completion of asynchronous operations. While it would be easier to port non-OpenVMS C code that calls XtAppAddInput() over to OpenVMS if the arguments included the C file descriptor, this would make the call unusable from other OpenVMS languages, and would make it extremely difficult to use OpenVMS features such as ASTs and sys$qio calls.
One restriction on the event flag: the event flag chosen must be from event flag cluster zero. When using the traditional lib$get_ef and lib$free_ef calls to allocate and deallocate event flags, you must first explicitly call lib$free_ef to free up some event flags in event flag cluster zero. Please see the event flag documentation for specific details on these calls and for specific event flags that can be freed in event flag cluster zero.
Here is some example code that covers calling this routine on OpenVMS:
m->InputID = XtAppAddInput( m->AppCtx, m->InputEF, m->InputIosb, the_callback, 1 ); if ( !((int) m->InputID )) { XtAppErrorMsg( m->AppCtx, "invalidDevice", "XtAppAddInput", "XtToolkitError", "Can't Access Device", (String *) NULL, (Cardinal *) NULL ); ... [Steve Hoffman]
Top |
The PC-compatible DB9 connector pinout follows:
The BC16-E-nn cross-over wiring looks like this:
Terminal MMJ | Host MMJ | |
---|---|---|
DTR 1 | --->-------->--- | 6 DSR |
TXD 2 | --->-------->--- | 5 RXD |
3 | ---------------- | 4 |
4 | ---------------- | 3 |
RXD 5 | ---<--------<--- | 2 TXD |
DSR 6 | ---<--------<--- | 1 DTR |
http://www.partner.digital.com:9003/public/cheat_sheets/cables/padapters.html http://www.networks.digital.com.au/dr/npgc/opdec-mn.htmlFor adapters and connectors, see MISC4.
[Stephen Hoffman] [Mike Thompson]
Specific details on the escape and control sequences supported by a particular serial device are typically found in the documentation provided with the specific device. Information on the sequences supported by DECwindows DECterm terminal emulator are included in the DECwindows documentation.
Examples of common escape and control sequences - those typically used by the OpenVMS screen management package - can be found in the OpenVMS system file SYS$SYSTEM:SMGTERMS.TXT.
The following refers to the function keys on the VTxxx series terminals,
and compatibles.
In the following, <CSI> is decimal code 155 and can be replaced by the
sequence "<ESC>[" (without the quotes), <SS3> is decimal code 143 and can be
replaced by "<ESC>O", particularly for seven-bit operations. Older VT1xx terminals
and any other terminals operating with seven-bit characters
should not be sent eight-bit operators such as <CSI> and <SS3>.
PF1=<SS3>P | PF2=<SS3>Q | PF3=<SS3>R | PF4=<SS3>S |
KP0=<SS3>p | KP1=<SS3>q | KP2=<SS3>r | KP3=<SS3>s |
KP4=<SS3>t | KP5=<SS3>u | KP6=<SS3>v | KP7=<SS3>w |
KP8=<SS3>x | KP9=<SS3>y | ||
KPCOMMA=<SS3>l | KPMINUS=<SS3>m | KPPERIOD=<SS3>n | |
ENTER=<SS3>M | |||
DNARROW=<CSI>B | UPARROW=<CSI>A | LFARROW=<CSI>D | RTARROW=<CSI>C |
FIND=<CSI>1~ | INSERT=<CSI>2~ | REMOVE=<CSI>3~ | |
SELECT=<CSI>4~ | PREV=<CSI>5~ | NEXT=<CSI>6~ | |
F6=<CSI>17~ | F7=<CSI>18~ | F8=<CSI>19~ | |
F9=<CSI>20~ | F10=<CSI>21~ | F11=<CSI>23~ | |
F12=<CSI>24~ | F13=<CSI>25~ | F14=<CSI>26~ | |
HELP=<CSI>28~ | DO=<CSI>29~ | ||
F17=<CSI>31~ | F18=<CSI>32~ | F19=<CSI>33~ | F20=<CSI>34~ |
These and other control sequences can be found in SYS$SYSTEM:SMGTERMS.TXT
Newer Compaq keyboards (those with with PC-style DIN plugs, and Compaq or Digital logo), newer Compaq mice (with PC-pin DIN plugs, and Compaq or Digital logo), and newer video monitors (multi-synch) are often interchangeable with industry standard PC systems, and can often be used with most PC peripheral device controllers. LK461, LK471, PC7XS-CA, VRC16, VRC21, etc., are compatible with most PC systems.
Rule of thumb: if the peripheral device component was sold for use with the DEC 2000 (DECpc 150 AXP), an AlphaServer series, an AlphaStation series, or more recent Alpha system, it will probably work with a PC peripheral controller. If the peripheral device component was sold for use with an VT420 or older terminal, most VAX, most VAXstation, and most Alpha systems with names in the format "DEC <four-digit-number>", it probably won't work on a PC.
Note that the above is a general guideline, and should not be read to indicate that any particular peripheral device will or will not work in any particular configuration, save for those specific configurations the device is explicitly supported in.
[Steve Hoffman]
Software Integrators sells a video adapter card called Gemini P1 which will
drive many of the older Compaq (Digital-logo) fixed-frequency monitors on a PC.
http://www.si87.com
More recent Compaq (Compaq or Digital logo) systems will use either the DECconnect MMJ wiring or (on all recent system designs) the PC-compatible DB9 pinout.
DECconnect MMJ adapters:
Part: | Converts BC16E MMJ male to fit into: |
---|---|
H8575-A | EIA232 25 pin female (common) |
H8575-B | EIA232 9 pin male (MicroVAX II console) |
H8571-D | EIA232 25 pin male (modem-wired) |
H8571-J | PC/AT 9 pin male (PC serial port) |
H8572-0 | 0BC16E MMJ male (MMJ extender) |
BC16E-** | MMJ cable, available in various lengths |
The H8571-A and H8575-A are MMJ to DB25 (female).
Also see:
http://www.partner.digital.com:9003/public/cheat_sheets/cables/padapters.html http://www.networks.digital.com.au/dr/npgc/opdec-mn.htmlFor wiring and pinouts, see MISC1
Jameco offers a USB-A to PS/2 Mini DIN 6 Adapter (as part 168751), for those folks wishing to (try to) use PS/2 Keyboards via USB-A connections.
[Stephen Hoffman] [Eric Dittman]
http://www.digital.com/alphaserver/archive/index.html
Use the DECNET_REGISTER mechanism (on the destination node) to register or modify the name(s) and the address(es) of the source node. Check the source node namespace, as well.
Typically, the nodes involved are using a LOCAL namespace, and the node name and address settings are not coherent across all nodes. Also check to make sure that the node is entered into its own LOCAL namespace. This can be a problem elsewhere, however. Very rarely, a cache corruption has been known to cause this error. To flush the cache, use the command:
NCL> flush session control naming cache entry "*"
Also check to see that you are using the latest ECO for DECnet-Plus for the version you are running.
DECnet-Plus can use the following namespaces:
[Steve Hoffman]
The system console power-up messages on a number of VAX and Alpha systems will display the hardware address, particularly on those systems with an integrated Ethernet network adapter present.
If you cannot locate a sticker on the system, if the system powerup message is unavailable or does not display the address, and if the system is at the console prompt, start with the console command:
>>> HELPA console command similar to one of the following is typically used to display the hardware address:
>>> SHOW DEVICE >>> SHOW ETHER >>> SHOW CONFIGOn the oldest VAX Q-bus systems, the following console command can be used to read the address directly off the (DELQA, DESQA, or the not-supported-in-V5.5-and-later DEQNA) Ethernet controller:
>>> E/P/W/N:5 20001920Look at the low byte of the six words displayed by the above command. (The oldest VAX Q-bus systems - such as the KA630 processor module used on the MicroVAX II and VAXstation II series - lack a console HELP command, and these systems typically have the primary network controller installed such that the hardware address value is located at the system physical address 20001920.)
If the system is a VAX system, and another VAX system on the network is configured to answer Maintenance and Operations Protocol (MOP) bootstrap requests (via DECnet Phase IV, DECnet-Plus, or LANCP), the MOM$SYSTEM:READ_ADDR.EXE tool can be requested:
>>> B/R5:100 ddcu Bootfile: READ_ADDRWhere ddcu is the name of the Ethernet controller in the above command. The primarly local DELQA, DESQA, and DEQNA Q-bus controllers are usually named XQA0. An attempt to MOP download the READ_ADDR program will ensue, and (if the download is successful) READ_ADDR will display the hardware address.
If the system is running, you can use DECnet or TCP/IP to display the hardware address with one of the following commands.
$ MCR NCP SHOW KNOWN LINE CHARACTERISTICS ! DECnet Phase IV $ MCR NCL SHOW CSMA-CD STATION * ALL STATUS ! DECnet-Plus $ UCX SHOW INTERFACE/FULL ! TCP/IP versions prior to V5.0 $ TCPIP SHOW INTERFACE/FULL ! TCP/IP versions V5.0 and laterA program can be created to display the hardware address, reading the necessary information from the network device drivers. An example C program for reading the Ethernet hardware address (via sys$qio calls to the network device driver(s)) is available at the following URL:
http://www.openvms.digital.com/wizard/swdev/ethernVMS.htmlTo use the DECnet Phase IV configurator tool to watch for MOP SYSID activity on the local area network:
$ NCP SET MODULE CONFIGURATOR KNOWN CIRCUIT SURVEILLANCE ENABLEDLet the DECnet configurator run for at least 20 minutes. Then issue the following commands:
$ NCP SHOW MODULE CONFIGURATOR KNOWN CIRCUIT STATUS TO filename.txt $ NCP SET MODULE CONFIGURATOR KNOWN CIRCUIT SURVEILLANCE DISABLEDThe resulting file (named filename.txt) can now be searched for the information of interest. Most DECnet systems will generate MOP SYSID messages identifying items such as the controller hardware address and the controller type, and these messages are generated and multicast roughly every ten minutes.
Information on the DECnet MOP SYSID messages and other parts of the maintenance protocols is included in the DECnet network architecture specifications referenced in section DOC9.
A BREAK is a deliberately-generated serial line framing error.
When a serial line device such as a terminal powers up (or sometimes when powering down) it can generate framing errors. These framing errors are indistingushable from a BREAK signal.
When a BREAK is received on a serial line console for various VAX systems - including most VAXstation, MicroVAX, and VAX 4000 series - it is typically interpreted as a HALT. Alpha systems will also often process a BREAK in a similar fashion, halting the system.
There is no uniform or generally-available way to disable this behaviour on every VAX or Alpha system. On some systems, BREAK processing can be disabled in favor of [CTRL/P], or [CTRL/P] is the only way to halt the processor.
The most common way to avoid these halts is to disable the serial line console or to simply not power-cycle the console terminal. There is certain important system state information that is displayed only on the console, OpenVMS expects to always have access to the system console.
[Stephen Hoffman]
[Stephen Hoffman]
You will also need to determine if the video monitor or graphics controller requires the 3 BNC signaling with the synchronization signals on the green wire, or the 5 BNC signalling common on many PCs, or other connections such as the DB15 video connector or USB connector used on various systems.
If there are no matches, you will likely need to change the hardware at one or both ends of the video cable.
The refresh frequencies for many devices have been posted to comp.os.vms and/or other newsgroups. Search the archives for details. Also see:
http://www.repairfaq.org/ http://plop.phys.cwru.edu/repairfaq/REPAIR/F_monfaq.html http://www.mirage-mmc.com/faq/Also see MISC3.
http://theref.aquascape.com/
DECprint (DCPS) requires more than just the simple handshaking provided by the LRA0: port, therefore DCPS does not work with the LRA0: port.
[Paul Anderson]
Tape media is different than disk media, as disks have a known and pre-determined fixed capacity. Modern disks also appear logically perfect, based on bad block revectoring support and the extra blocks hidden within the disk structure for these bad block replacements.
The capacity of tape media is not nearly as pre-determined, and the capacity can vary across different tape media (slightly different media lengths or different foil markers or other variations, for instance) and even on the same media over time (as bad spots in the media arise). Tapes can vary the amount of recording media required, depending on the remaining length of the tape, the numbers of correctable and uncorrectable media errors that might occur, the numbers and sizes of the inter-record gaps and related tape structure overhead, the particular media error recovery chosen, the tape density, the efficiently of any data compression in use, and the storage overhead required by BACKUP, tar, and other similar commands.
BACKUP using with the default settings results in approximately 15% overhead, in terms of saveset size. (eg: Assuming a 500 KB input, the total size would be 575 KB.)
The compression algorithms used on various devices are generally not documented - further, there is no way to calculate the effective data compression ratio, the tape mark overhead, and similar given just the data to be stored on tape - short of actually trying it, of course.
A typical compression ratio found with "everyday" data is somewhere around 1:1.8 to 1:2.
NB: OpenVMS often uses the term COMPACTION for compression control, as in the qualifier /MEDIA_FORMAT=COMPACTION.
[Hoffman, Froehlin, Williams]
The typical wisdom for getting into supervisor access mode (from user mode) is to execute a routine in executive mode (via a call to SYS$CMEXEC and the appropriate privilege) and then issue a SYS$DCLAST with the ASTADR parameter pointing to your routine entry point and the ACMODE parameter specified as PSL$C_SUPER.
Alternatively, you can reset mode in the call stack return path and unwind from executive or kernel out into supervisor mode.
[Brian Schenkenberger]
RamPage (Ergonomic Solutions) is one of the available packages that can generate and transmit messages to radio pagers. Target Alert (Target Systems; formerly the DECalert product) is another. Networking Dynamics Corp has a product called Pager Plus. The System Watchdog package can also send pages. PMDF can route specific email addresses to a paging service, as well.
Many commercial paging services provide email contact addresses for their paging customers - you can simply send email directly to the pager.
See SOFT1 for information on the available catalog of products.
In ASCII, XON is the [CTRL/Q] character, and XOFF is the [CTRL/S].
XON/XOFF flow control is typically associated with asynchronous serial line communications. XON/XOFF is an in-band flow control, meaning that the flow control is mixed in with the data.
CTS/RTS is another type of flow control, and is sometimes called hardware flow control. Out-of-band means that seperate lines/pins from the data lines (pins) are used to carry the CTS/RTS signals.
Both kinds of flow control are triggered when a threshold is reached in the incoming buffer. The flow control is suppose to reach the transmitter in time to have it stop transmitting before the receiver buffer is full and data is lost. Later, after a sufficient amount of the receiver's buffer is freed up, the resume flow control signal is sent to get the transmitter going again.
DECnet Phase IV on OpenVMS VAX supports the use of asynchronous serial communications as a network line. The communication devices (eg. modems, and drivers) must not be configured for XON/XOFF flow control. The incidence of these (unexpected) in-band characters will corrupt data packets. Further, the serial line device drivers might normally remove the XON and XOFF characters from the stream for terminal applications, but DECnet configures the driver to pass all characters through and requires that all characters be permitted. (The communication devices must pass through not only the XON and XOFF characters, they must pass all characters including the 8-bit characters. If data compression is happening, it must reproduce the source stream exactly. No addition or elimination of null characters, and full data transparency.
An Ethernet network is rather different than an asynchronous serial line. Ethernet specifies the control of data flow on a shared segment using CSMA/CD (Carrier Sense Multiple Access, with Collision Detect) An Ethernet station that is ready to transmit listens for a clear channel (Carrier Sense). When the channel is clear, the station begins to transmit by asserting a carrier and encoding the packet appropriately. The station concurrently listens to its own signal, to permit the station to detect if another station began to transmit at the same time - this is called collision detection. (The collision corrupts the signal in a way that can reliably be detected.) Upon detecting the collision, both stations will stop transmitting, and will back off and try again a little later. (You can see a log of this activity in the DECnet NCP network counters.)
DECnet provides its own flow control, above and beyond the flow control of the physical layer (if any). The end nodes handshake at the beginning to establish a transmit window size - and a transmitter will only send that much data before stopping and waiting for an acknowledgement. The acknowledgement is only sent when the receiver has confirmed the packet is valid. (A well-configured DECnet generally avoids triggering any underlying (out-of-band) flow control mechanism.)
[David Rabahy]
LANCP> SET DEVICE/DEVICE_SPECIFIC=FUNCTION="CCOU" devname
Power | Prefix | Abbreviation |
10-18 | atto | a |
10-15 | femto | f |
10-12 | pico | p |
10-09 | nano | n |
10-06 | micro | µ |
10-03 | milli | m |
10-02 | centi | c |
10-01 | deci | d |
10+01 | deca | da |
10+02 | hecto | h |
10+03 | kilo | k |
10+06 | mega | M |
10+09 | giga | G |
10+12 | tera | T |
10+15 | peta | P |
10+18 | exa | E |
An OpenVMS Cluster does not operate over DECnet, nor over IP.
No SCS protocol routers are available.
Many folks have suggested operating SCS over DECnet or IP over the years, but SCS is too far down in the layers, and any such project would entail a major or complete rewrite of SCS and of the DECnet or IP drivers. Further, the current DECnet and IP implementations have large tracts of code that operate at the application level, while SCS must operate in the rather more primitive contexts of the system and particularly the bootstrap - to get SCS to operate over a DECnet or IP connection would require relocating major portions of the DECnet or IP stack into the kernel. (And it is not clear that the result would even meet the bandwidth and latency expectations.)
The usual approach for multi-site OpenVMS Cluster configurations involves FDDI, Memory Channel (MC2), or a point-to-point remote bridge, brouter, or switch. The connection must be transparent, and it must operate at 10 megabits per second or better (Ethernet speed), with latency characteristics similar to that of Ethernet or better. Various sites use FDDI, MC2, ATM, or point-to-point T3 link.
Top |
http://www.partner.digital.com/www-catalog/An OpenVMS Freeware CD is distributed with OpenVMS, and is also available seperately as part of the OpenVMS hobbyist program. The OpenVMS Freeware CD is available online at:
Submissions to the OpenVMS Freeware can be made via:
http://www.openvms.digital.com/openvms/freeware/cd.htmlTo order the Freeware, you can order an OpenVMS distribution from Compaq, or you can order the Freeware itself via the OpenVMS hobbyist website:
http://www.montagar.com/hobbyist/The Freeware CD-ROM set contains a large assortment of freeware, and is a good starting point if looking for utilities. Many of the packages listed below are also on the Freeware CD. Some of the most oft-requested OpenVMS tools on the Freeware CD include ZIP and UNZIP, GZIP, MMK (make), PINE, PERL, TAR, UUENCODE and UUDECODE. Many other tools are available on the Freeware.
Compaq also has a separate area containing various OpenVMS software tools located at:
http://ftp.digital.com/pub/VMS/Hunter Goatley runs a VMS freeware fileserver:
http://www.madgoat.com/The FILESERV packages are also available via anonymous FTP from:
If you get the packages via WWW or FTP, they're in ZIP format which requires the UNZIP (note: this is not Gnu gunzip!) tool to unpack. You can get ZIP and UNZIP from the following areas:
ftp://ftp.wku.edu/vms/unzip.exe for VAX ftp://ftp.wku.edu/vms/unzip.alpha_exe for Alpha ftp://ftp.wku.edu/vms/fileserv/UNZIP.ZIP http://www.decus.de:8080/www/vms/sw/zip.htmlx http://home.earthlink.net/~djesys/zip.html http://home.earthlink.net/~djesys/unzip.htmlor you can request the FILESERV_TOOLS package from the e-mail server.
[Beware: The [000TOOLS...] pre-built versions of ZIP on the OpenVMS Freeware V4 CD-ROM will erroneously return BILF errors on OpenVMS V7.2 and later. Use of the source on the Freeware V4 to rebuild the ZIP image(s), or acquiring a pre-built ZIP image from one of the above areas can avoid this. The pre-built version of ZIP on the Freeware V4 kit is older than the included ZIP sources, and it contains a latent bug.]
Another source of free software is the vmsnet.sources newsgroup (and the corresponding vmsnet.sources.d discussion group). See the monthly posting "vmsnet.sources archives" for a list of sites which archive submissions to vmsnet.sources.
CompuServe users should check out the libraries of the VAXFORUM forum.
Arne Vajhøj runs an OpenVMS WWW page, with software and other pointers, at:
http://www.levitte.org/~ava/
Kermit is available at:
http://www.columbia.edu/kermit/ or ftp://kermit.columbia.edu/ZMODEM is available at:
ftp://ftp.cs.pdx.edu/pub/zmodemSee the FILES file in that directory for further details. Note that this freeware version of ZMODEM will interoperate only with ZMODEM software that is licensed from Omen Technology. (Also on Freeware CD)
[Steve Lionel]A good source of software for DEC boxes (and anything else pretty much) is the DECUS library. online catalogs are available as well as some software via ftp.decus.org; there's a gopher server
gopher://gopher.decus.org/an FTP server:
ftp://ftp.decus.org/and a WWW server:
http://www.decus.org/Some DECUS library CD-ROMs are available online at:
http://www.acornsw.com/www/acorn/cdrom-via-www.html or gopher://gopher.acornsw.com/ [munroe@dmc.com]Phone for orders is 508 841 3502. Lots of good stuff from lots of good folks, and copies on media (tapes, CDs) are cheap.
[Everhart@Arisia.gce.com]MPJZ's Hyper-Software-List for OpenVMS is Martin P.J. Zinser's list of additional software.
http://axp616.gsi.de:8080/www/vms/sw.htmlChris Higgins's VMS Software List II
http://csvax1.ucc.ie/www/vms_sw_list/sw_list.htmlDECUS SIG Tape collections are available on Mark Berryman's system,
ftp://mvb.saic.comDavid Jones's DECthreads-based HTTP_SERVER World-Wide Web server for VMS.
http://kcgl1.eng.ohio-state.edu/www/doc/serverinfo.html [goathunter@WKUVX1.WKU.EDU]Secure Shell SSH Server for OpenVMS:
http://kcgl1.eng.ohio-state.edu/~JONESD/ssh/DOC/Secure Shell SSH Client for OpenVMS:
http://www.free.lp.se/fish/Information on OpenSSL SSLeay for OpenVMS:
http://www.free.lp.se/openssl/ [Leo Demers]Information on OpenSSL (SSLeay) and OSU Webserver interoperation:
http://www.levitte.org/~byerra [Robert Alan Byer]DECwindows Motif V1.2-3 includes NCSA Mosaic 2.4 built for UCX. V1.2-4 includes Spyglass Enhanced Mosaic, which supports many "Netscape" enhancements. Netscape Navigator is also available for OpenVMS. A port of Mosaic 2.7-4 which supports UCX, Multinet and SOCKETSHR/NETLIB is available from:
ftp://wvnvms.wvnet.edu/mosaic/Lynx (a character-cell World-Wide-Web reader) is available from
ftp://ftp2.cc.ukans.edu/pub/lynx [Steve Lionel]Netscape Navigator will be available as part of the OpenVMS Internet Product Suite. For further details, see:
http://www.openvms.digital.com/openvms/products/ips/index.htmlPGP (Phil Zimmerman's "Pretty Good Privacy") is available from various distribution sites, including those listed in the PGP FAQ. Information on an OpenVMS download of PGP is available at
http://www.pgpi.com/. http://zone.pspt.fi/pgp/platforms/vms/. http://www.yrl.co.uk/~phil/pds/pds.html.
An archive of DECwindows and X Windows software can be found at the following sites:
[Patrick Moreau]ImageMagick is an X11 package for display and interactive manipulation of images. The package includes tools for image conversion, annotation, compositing, animation, and creating montages. ImageMagick can read and write many of the more popular image formats (e.g. JPEG, TIFF, PNM, XPM, Photo CD, etc.).
ftp://ftp.x.org/contrib/vms/ImageMagick/ImageMagick-3.3.zip(Also on Freeware CD)
[cristy@dupont.com]XV is available from:
ftp://ftp.cis.upenn.edu/pub/xv ftp://ftp.digital.com/pub/graphics/xv http://www.sanface.com/(Also on Freeware CD)
GHOSTSCRIPT and GHOSTVIEW are available from:
ftp://ftp.digital.com/pub/VMS/ghostviewVersion 2.3 of GhostView-VMS is now available from:
ftp://iphthf.physik.uni-mainz.de/pub/vms/ [plass@dipmza.physik.uni-mainz.de]XPDF, a viewer for PDF (Adobe Acrobat) files, is available from:
http://www.foolabs.com/xpdf/ [Ki Suk Hahn]A Java-based PDF viewer is available from Adobe, and is known to operate on recent OpenVMS Alpha releases:
http://www.adobe.com/Various OpenVMS-related tools - both freeware and shareware - such as txt2pdf - are available from at:
http://www.sanface.com/The MPEG library version 1.1 is available for OpenVMS VAX and Alpha at
ftp://ftp.x.org/contrib/vms/mpeglib-11-vms.readme ftp://ftp.x.org/contrib/vms/mpeglib-11-vms.zip [Patrick Moreau]List of FTP Mirror Sites for the DECWINDOWS archive:
List of HTTP Mirror Sites for the DECWINDOWS archive:
http://axp616.gsi.de:8080/wwwar/cena/decwindows/cena.htmlSome X clients from the OpenVMS Freeware CDROM are located in [.DECWINDOWS.CDFREEWARE] directory.
[Patrick Moreau]I have written and installed on INFO.CS.PUB.RO an "Archie" clone for VMS software. Telnet to that machine, and login as VMSARCI. It contains now listings for over 30 ftp servers with more than 14GB of VMS software. The most useful commands are LIST, which generates a list of scanned ftp servers, and FIND <string>, whichs looks for a file containing "string" in the name; the search modes are only "substring" [default] and "exact", and regex search is not supported (so FIND EMACS will work, but FIND *EMACS* or FIND *EMACS*.* will not). The search is case-insensitive. Those of you that know other ftp servers with VMS software that I haven't found, please let me know. (The program that build the databases can recursively scan whole servers- as FTP.WKU.EDU, or just some directories- as NIC.SWITCH.CH/pub/vms) Sorry, this service is VERY SLOW [by Western standards], because it runs on a quite-busy oldie-but-goodie VAXStation 3400 with 20Mb and a RF71, and the Internet link is only 256 Kpbs (sometimes unavailable).
[stfp@roipb.cs.ipb.ro]Perl 5 (object oriented, blah blah) is available for VMS. The primary development ftp site is:
ftp://genetics.upenn.edu/perl5/But this site is mirrored by more than 47 CPAN sites around the world. Each CPAN site is accesible via a cgi-bin script at the perl homesite:
http://www.perl.com/CPAN/(PERL can also be found on the OpenVMS Freeware CD)
Charles Lane maintains a web page on how to write cgi-bin scripts in perl 5 for VMS at:
http://duphy4.physics.drexel.edu/duphy4/cgi_info.htmlxand I maintain a web page on how to obtain and compile perl5 for VMS at:
http://w4.lns.cornell.edu/~pvhp/perl/VMS.html [pvhp@lns62.lns.cornell.edu]MadGoat Software Archives:
http://www.madgoat.com/Western Kentucky University OpenVMS archives:
ftp://ftp.wku.edu/vms/fileserv/The Levitte (extended :-) Family (and OpenVMS) website:
http://www.levitte.org/ http://www.levitte.org/~ava/ http://www.levitte.org/~byerra/CalTech Software Archives:
http://seqaxp.bio.caltech.edu/pub/SOFTWARE/AAA_CONTENTS.TXTDJE Systems Website (David J. Dachtera)
http://home.earthlink.net/~djesys/freeware/vms/Web servers:
http://www.openvms.digital.com/openvms/products/ips/apache/ http://www.er6.eng.ohio-state.edu/~jonesd/apache/1_3_9/
http://www.er6.eng.ohio-state.edu/www/doc/serverinfo.html http://www.kjsl.com/archives/ email list: VMS-WEB-daemon-Request@KJSL.COM
CD-R (CD-Recordable) media tools:
please see FILE7Grace (WYSIWYG 2D plotting tool)
http://plasma-gate.weizmann.ac.il/Grace/POV-Ray ("Persistance of Vision" Raytracer) ray-tracing graphics package:
http://www.lp.se/~byerra/povray/povray_contents.html [Peter Langstoeger]Majordomo mailing list handler:
http://www.openvms.digital.com/openvms/products/ips/majordomo/PINE (OpenVMS tools for sending and receiving MIME mail):
ftp://ftp2.kcl.ac.uk/pub/vms/pine-vms/ http://www.agh.cc.kcl.ac.uk/files/vms/pine-vms/Menufinder (menu-driven system management environment) (currently free on OpenVMS VAX)
http://www.itre.com/mf/ (Italian) http://www.itre.com/mf/index_en.html (English)
POSIX is a separately-installed package, and is licensed with OpenVMS V5.5 later. The POSIX installation kit is included on the consolidated distribution CD-ROM kit, and installation kits are also available separately.
The POSIX package is no longer supported on OpenVMS, components of the POSIX standard such as parts of the POSIX API are being added into OpenVMS. Versions of POSIX generally do not operate on V7.x OpenVMS VAX and OpenVMS Alpha releases.
C:
Common C system and library routines are present in the DEC C run-time
library, which is available for V5.5 and later, and is shipped in V6.1
and later. DEC C is the upgrade for VAX C, DEC C and VAX C can coexist
on the same system OpenVMS VAX system, and both compilers can be enabled
via the "C" license PAK.
Also see SYS$EXAMPLES:, and (if either is installed) the DECW$EXAMPLES: and UCX$EXAMPLES: areas.
X Windows:
Various Compaq X Windows utilities:
Miscellaneous tools and examples:
Various unsupported OpenVMS tools and code examples:
IP tools:
DEC TCP/IP (UCX) contains tools such as:
Also see the various C examples in UCX$EXAMPLES:
[Stephen Hoffman]vi clones
The current version of vile is 7.1
It's available at
http://www.clark.net/pub/dickey/vile/vile.html ftp://ftp.clark.net/pub/dickey/vile ftp://id.wing.net/pub/pgf/vile [Thomas Dickey]GNU tools:
http://vms.gnu.ai.mit.edu/ ftp://vms.gnu.ai.mit.edu/gnu-vms/Software info:
http://vms.gnu.ai.mit.edu/software/Software archive:
ftp://vms.gnu.ai.mit.edu/gnu-vms/software/GCC:
http://www.progis.de/The latest (known to me) GCC version for VAX/VMS (binaries only) is 2.7.1 from Pat Rankin's site.
ftp://ftp.caltech.edu/pub/rankin/ [Jason Armistead]Some of the available console management options for OpenVMS:
[Kerry Main]If you need to change the file modification date and are looking for a utility such as the UNIX touch tool, look at DFU on the OpenVMS Freeware (DFU SET or simular), or use an existing DCL commands such as:
SET FILE/PROTECT=(current_protection_mask) [...]*.*
Mozilla.org has announced that it will release a beta version of its browser in mid-Autumn 1999. Soon after, Netscape may/will release a beta version of Netscape Communicator based on the mozilla.org browser. We expect the beta version of Netscape Communicator to be available on OpenVMS about 1 month after its release by Netscape. A customer quality version of this browser is scheduled for release by mozilla.org in late December 1999; soon after, Netscape will release a customer quality version of Netscape Communicator. We expect to release a customer quality version of Netscape Communicator on OpenVMS in early 2000.
The mozilla.org browser schedule is available at:
http://www.mozilla.org/project/The latest information and current downloads are available at:
http://www.openvms.digital.com/openvms/products/ips/
Please be aware that various certificates for V3.003 Netscape Navigator are presently expired, or are starting to expire. This can potentially cause problems for certificate-based access pending the acquisition of new certifcates.
[Sue Denham] [Stephen Hoffman]
Java is not available on OpenVMS VAX. As for why: the Java language definition requires a floating point format (IEEE) that is not native to VAX, and this would require the emulation of all floating point operations within Java applications. Further, the C source code used to implement for Java itself is heavily dependent on passing IEEE floating point values around among the many internal subroutines, and adding support for VAX would entail changes to the Compaq C compiler for OpenVMS VAX - and specifically to the VAX VCG code generator that is used by Compaq C on OpenVMS VAX systems - in order to add support for passing IEEE-format floating point doubles around. Alternatively, extensive changes to the Java source code to remove the assumption that the double is an IEEE floating point value.
There are currently no plans to make a version of Java available for OpenVMS VAX. (A prototype version of Java was created for OpenVMS VAX, and performance was found to be inadequate at best.)
If Java2 or other environment lifts the requirements for IEEE floating point as part of the language definition, this decision may be revisited.
For additional information on Java for Alpha systems, please see the OpenVMS documentation (V7.2 and later), and the following site:
http://www.digital.com/java/alpha/index.html
Both compilers can be installed at the same time on the same OpenVMS VAX system, allowing a migration from VAX C to DEC C, and allowing the same DEC C code to be used on OpenVMS VAX and OpenVMS Alpha. In 1999, the C compiler version is Compaq C V6.0.
The system manager can choose the system default C compiler when Compaq C is installed on a system with VAX C, and a C programmer can explicitly select the required compiler for a any particular compilation.
A current "C" license PAK allows access to both VAX C and Compaq C on the same OpenVMS VAX system.
Various Compaq C versions can be installed on OpenVMS VAX V5.5-2 and later. OpenVMS VAX releases such as V5.5-2 and V6.0 will require the installation of a Compaq C RTL kit, a kit that is included with the Compaq C compiler. OpenVMS VAX versions V6.1 and later do not require a seperate RTL kit, but Compaq C RTL ECO kits are available to resolve problems found with the C RTL on various OpenVMS releases.
With Compaq C, for automatic resolution of the standard C library routines by the LINKER utility, use the /PREFIX qualifier, such as PREFIX=ALL_ENTRIES. If a particular application program replaces an existing C library routine, use /PREFIX=(ALL_ENTRIES,EXCEPT=(...)). VAX C required explicit specification of an RTL shareable image or C object library during the link.)
When the /PREFIX is requested, the compiler generates a "decc$" prefix on the specified symbols. This prefix allows the LINKER to resolve the external symbols against the symbols present in the DECC$SHR library. The DECC$SHR library is included in the IMAGELIB.OLB shareable image library, and IMAGELIB is searched by default when any program (written in any language) is LINKed. Because the standard C library routine names are very likely to match application routines written in other languages, a prefix "decc$" is added to the C symbol names to assure their uniqueness; to prevent symbol naming conflicts. C programs, however, can sometimes have private libraries for various purposes, and the external routines share the same names as the library routines. This is not recommended, but there are applications around that use this technique.) Thus the need to explicity specify whether or not the "decc$" prefix should be prepended to the external symbol names by the compiler.
The qualifiers, and most (all?) with associated pragmas, that may be of interest when migrating VAX C code to Compaq C include:
Permit structure members to be naturally aligned whenever possible, and avoid using /NOMEMBER_ALIGNMENT. If you need to disable member alignment, use the equivilent #pragma to designate the specific structures. The alignment of structure members normally only comes into play with specific unaligned data structures - such as the sys$creprc quota itemlist - and with data structures that are using data that was organized by a system using byte or other non-member alignment.
Versions of Compaq C such as V6.0 include the capability to extract the contents of the standard header libraries into directories such as SYS$SYSROOT:[DECC$LIB...], and provide various logical names that can be defined to control library searches. With Compaq C versions such as V6.0, the default operations of the compiler match the expectations of most OpenVMS programmers, without requiring any definitions of site-specific library-related logical names. (And logical names left from older DEC C versions can sometimes cause the compiler troubles locating header files.)
Example C code is available in SYS$EXAMPLES:, in DECW$EXAMPLES (when the DECwindows examples are installed), in UCX$EXAMPLES (when Compaq TCP/IP Services is installed), on the Freeware CD-ROMs, and at web sites such as
http://www.openvms.digital.com/wizard/
If you use the POST method, then you need to read the form data from stdin. For a DCL CGI script running under the Netscape FastTrack web server, you can read the data using the following READ command:
$ READ SYS$COMMAND postdatato read the information in.
[Colin Blake]The following describes the use of DCL command procedures as CGI scripts with the OSU web server:
http://www.levitte.org/~ava/cgiscripts_other.htmlx [Leif Jansson]
$ Entry = F$GETQUI("DISPLAY_ENTRY", - "entry_number","display_entry","this_job")Remember that the entry numbers issued by the OpenVMS Job Controller are opaque longword values. Don't assume you know the format of the number, nor the range of numbers you might see...
[Peter Weaver]
To perform the "conversion", issue the following commands for each CMS library present:
$ RENAME disk:[directory]00CMS.* 01CMS.* $ COPY NLA0: disk:[directory]00CMS.CMSThe new file 00CMS.CMS must have the same security settings as the 01CMS.CMS file, and is created solely to ensure continued compatibility with tools that expect to find a 00CMS.CMS file (eg: various versions of the Language-Sensitive text editor LSEDIT).
[Ken Chaney]To update certificates in Netscape Navigator V3.03 on OpenVMS, use the following:
Thawte Server certificate which expired in 1998:
VeriSign/RSA Server certificate which expired Dec 31, 1999:
[Vance Haemmerle]
In this case, use of a file containing nolinemode commands or other techniques might be useful - you will want to ensure that the text editor you use does not attempt to use screen mode or similar, as this is not generally considered adventageous within a command procedure.
Tools such as FTP have alternatives: COPY/FTP.
DCL symbol substitution occurs in two passes, using the ampersand and the apostrophe. In most cases, only the apostrophe is necessary. In a few cases - such as the DCL PIPE command - you will may need to use the ampersand to get the substitution to work. The following example uses ampersand substitution to transfer the contents of the header into a logical name:
$ PIPE CC/VERSION | (READ SYS$PIPE hdr ; DEFINE/JOB/NOLOG hdr &hdr )A logical name (in the job logical name table; shared by all processes in the current job) was used as DCL symbols cannot be returned back out from a DCL PIPE or other spawned subprocess.
Top |