This FAQ is archived in the following locations:
comp.answers and news.answers newsgroups ftp://ftp.digital.com/pub/Digital/dec-faq/vms ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms CompuServe VAXFORUM, Library 0, VMSFAQ.TXT
To make suggestions for changes or additions to this Frequently Asked Questions list, send mail to the editor at lionel@quark.zko.dec.com. Answers are especially appreciated.
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 newsgroup. 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 Digital Equipment Corporation, this posting is not an official statement from Digital Equipment Corporation.
AlphaGeneration, AlphaServer, AlphaStation, Alpha AXP, AXP, DEC, DECstation, DECsystem, OpenVMS, ULTRIX, VAX and VMS are trademarks of Digital Equipment 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.
The comp.os.vms newsgroup is the primary newsgroup for discussion of Digital's OpenVMS operating system and the computer systems on which it runs. Questions about layered products which run on OpenVMS are also welcome, though many of them (in particular, language compilers and database systems) have more specific newsgroups. If a question has some relationship to OpenVMS, it belongs here.
The vmsnet.* hierarchy, run by DECUS, contains several newsgroups of interest, including vmsnet.misc and vmsnet.alpha, the latter being mostly devoted to Alpha topics. There's also vmsnet.sources (and vmsnet.sources.d) to which sources for or pointers to freeware are posted. See the separate "What is VMSNET" monthly posting for further details. The comp.sys.dec newsgroup carries discussions about all Digital systems as well as about Digital itself.
INFO-VAX is a mailing list which is bidirectionally gatewayed to the comp.os.vms newsgroup. This means that postings to comp.os.vms get automatically sent to INFO-VAX subscribers and messages sent to the INFO-VAX list are automatically posted to comp.os.vms. INFO-VAX can be a useful way to participate in the newsgroup if you can't access the group directly through a news reader. 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.
The address for subscription requests, as well as notes intended for the moderator, is Info-VAX-Request@Mvb.Saic.Com. 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: SUBSCRIBE INFO-VAX (ADD is a valid synonym) UNSUBSCRIBE INFO-VAX (REMOVE, SIGNOFF, and SIGN-OFF are valid synonyms) SET INFO-VAX DIGEST (to receive in Digest format) SET INFO-VAX NODIGEST (to receive each message individually) Case is irrelevant and attempts to fetch a copy of the mailing list will be rejected (I consider the information to be confidential). Any message not understood by the mailserver will be forwarded to a human (allegedly) for manual processing. [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.
If you are using a news reader, post your question to comp.os.vms. If you want to submit through INFO-VAX, send the message to Info-VAX@mvb.saic.com. 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. When posting, please consider the following suggestions: 1. Include a valid e-mail address in the text of your posting or in a "signature" appended to the end. Reply-to addresses in headers often get garbled. 2. If you are submitting a question, please be as specific as you can. Include relevant information such as processor type, product versions (OpenVMS and layered products that apply) and a short, reproducible example of problems. Say what you've tried so far, so that effort isn't duplicated. Keep in mind that there's not yet a telepathy protocol for the Internet - the more detailed your description, the better people can help you. 3. If responding to a posting, include in your reply only as much of the original posting as is necessary to establish context. As a guideline, consider that if you've included more text than you've added, you've possibly included too much. Never include signatures and other irrelevant material. 4. Be polite. If the question isn't worded the way you think is correct or doesn't include the information you want, try to imagine what the problem might be if viewed from the poster's perspective. Requests for additional information are often better sent through mail rather than posted to the newsgroup. 5. If you have a problem with Digital (or any vendor's) product, use the appropriate support channel. Don't assume that newsgroup postings will get read or responded to by the appropriate developers.
DECUS, the Digital Equipment Computer Users Society, is a World Wide organization of Information Technology professionals interested in the products, services, and technologies of Digital Equipment Corporation and related vendors. Membership in the Chapter is free and provides participants with the means to enhance their professional development, forums for technical training, mechanisms for obtaining up-to-date information, advocacy programs, and opportunities for informal disclosure and interaction with professional colleagues of like interest. For further information, see the separate monthly "What is DECUS" posting, or refer to the US DECUS WWW server at http://www.decus.org or the Canadian DECUS WWW server at http://www.decus.ca .
Everything posted since 1990 is archived and available at: ftp://crvax.sri.com/info-vax/ The last few months posts can be searched and retrieved via the UGA LISTSERV. Send a mail with the content: DATABASE SEARCH DD=RULES //RULES DD * SEARCH sometopic IN INFO-VAX PRINT /* to the address LISTSERV@UGA.BITNET (the syntax is due to UGA being an IBM mainframe!) [ARNE@KO.HHS.DK]
OpenVMS, originally called VMS (Virtual Memory System), was first conceived in 1976 as a new operating system for Digital's new, 32-bit, virtual memory line of computers, eventually named VAX (Virtual Address eXtension). The first VAX model, the 11/780, was code-named "Star", hence the code name for the VMS operating system, "Starlet", a name that remains to this day the name for the system library files (STARLET.OLB, etc.). VMS version X0.5 was the first released to customers, in support of the hardware beta test of the VAX-11/780, in 1977. VAX/VMS Version V1.0 shipped in 1978, along with the first revenue-ship 11/780s. OpenVMS was designed entirely within 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 is a 32-bit, multitasking, multiprocessing virtual memory operating system. Current implementations run on Digital's VAX and Alpha computer systems. [winalski@gemgrp.enet.dec.com] For more details on OpenVMS and its features, read the OpenVMS Software Product Description at: ftp://ftp.digital.com/pub/Digital/info/SPD/25-01-XX.txt
VMS and OpenVMS are two names for the same operating system. Originally, the operating system was called VAX-11/VMS; it changed to VAX/VMS at around VAX/VMS V2.0. When the VMS operating system was ported to the Alpha platform, it was renamed OpenVMS, for both VAX and Alpha, in part to signify the high degree of support for industry standards such as POSIX, which provides many features of UNIX systems. An OpenVMS license allows you to install and run POSIX for OpenVMS at no additional charge; all you need is the media and documentation which can be found on the Consolidated Distribution and On-Line Documentation CD-ROMs. For more information on POSIX for VMS see question SOFT2 and: ftp://ftp.digital.com/pub/Digital/info/pr-news/92060311FS.txt 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".
You already did. Wasn't that easy? (See question VMS2.)
This question comes up periodically, usually asked by new subscribers who are long-time UNIX users. Sometimes, it is ignored totally; other times, it leads to a long series of repetitive messages that convince no one and usually carry little if any new information. Please do everyone a favor and avoid re-starting this perpetual, fruitless debate. [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. See also questions VMS2 and SOFT2 for information on POSIX for OpenVMS which provides significant UNIX functionality on OpenVMS. [lionel@quark.enet.dec.com]
People who ask this question, most recently, have read about the May 1995 announcement of an association between Digital and Microsoft to provide greater affinity between OpenVMS and Windows NT. Some trade publications interpreted this announcement as signalling that Digital was going to drop OpenVMS and move its customers onto Windows NT. Nothing could be further from the truth. For more information, see: http://www.openvms.digital.com/
What is the Year 2000 Problem? It stems from the common practice of using two digits instead of four when writing dates and having multiple internal time formats. When this practice is extended into computer hardware and software, it causes arithmetic operations, comparisons, and data sorting procedures to yield incorrect results when working with years beyond 1999. As Digital's customers begin to consider the readiness of their computing systems for the transition to the year 2000, many have begun asking what impact it will have on their OpenVMS systems. We are happy to answer that, because of insightful development by the engineers who created it, OpenVMS was born ready. The OpenVMS operating system base date uses a four digit format that is totally unaffected by the transition to the year 2000. Customers who have consistently used the system base date and the associated system services that provide the ability to input and retrieve four digit ASCII year strings, will make a seamless transition into the year 2000 when accessing their data. We are currently researching other "date sensitive" areas of the operating system where additional enhancements would provide more robust support and readiness. Our partner software groups, inside and outside of Digital are also looking into the "year 2000 compliance" of layered products, to ensure that they are tested and to provide consistent support for the turn of the century. In the coming months ahead, Digital Equipment will periodically provide all the information that needed regarding how the OpenVMS operating environment and other products deal with the transition to the year 2000. OpenVMS' overall position on the issue can be summarized as follows: * OpenVMS system base date will continue to be operational after the date changes from calendar year 1999 to 2000 to 2001. We are currently evaluating additional enhancements in specific "date sensitive" areas of the operating system. These enhancements will be included in upcoming releases of OpenVMS, available for use well in advance of the start of the year 2000. * While we know of no systematic way to ensure that all customer code will also continue to work across the year 2000 boundary, we do allow the clocks of our system to be set to times in the future to allow customer testing of their software (a reboot is suggested to ensure application time consistency). * We are evaluating the possibility of engaging in system integration contracts to support individual customers in reviewing their software for problems of this sort. * If we become aware of tools that seem generally applicable, we will work with the suppliers to offer them on our platforms. Customers can continue to depend on OpenVMS in the knowledge that it has been proven in the most demanding environments. We will continue to bring them enterprise system dependability, 24x365 availability, disaster tolerance, scalability and the best cluster technology in the industry for many years to come. Vittorio Mezzano OpenVMS Product Management
The following OpenVMS CD-ROM products are available from Digital: Package VAX Alpha Software Products Library QA-VWJ8A-A8 QA-4KL8A-A8 (Binaries of layered products - usually includes courtesy copy of latest OpenVMS distribution, but this is not the same as ordering an OpenVMS kit - see below.) Online Documentation Library QA-VYR8A-G8 QA-4KM8A-G8 (Bookreader documentation for OpenVMS and layered products) Software Library Package QA-YL48A-H8 QA-03XAA-H8 (Combines above two) Engineering Change Order Dist. (ECOs - "patch kits") QA-3CRAA-W8 QA-3CQAA-W8 OpenVMS binaries and documentation QA-XULAA-H8 QA-MT1AA-H8 (Includes Freeware CD) Combined OpenVMS VAX and Alpha QA-MT3AA-H8 Listings kit with license QB-001AB-E8 QB-MT1AB-E8 Many of these are available as a subscription service.
While there are many fanciful "definitions" which have circulated widely, the truth is that AXP is not an abbreviation nor an acronym; the letters do not mean anything. They are just three letters chosen to form a trademark. When it came time to chose a "marketing name" for the Alpha AXP line, Digital 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, a Digital 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". Despite all this, everyone went on calling the new line "Alpha". Digital has recognized this by coining a new "AlphaGeneration" trademark to apply to all products (hardware, software and services) related to the Alpha AXP line. Digital has phased out the use of the AXP name, using Alpha instead. For example, OpenVMS AXP is now called called "OpenVMS Alpha".
Very few. As of OpenVMS V6.1, the VAX and Alpha platforms are very close to "feature parity". Most applications can just be recompiled and run. Some differences to be aware of: - The default double-precision floating type on OpenVMS Alpha is VAX G_float, whereas on VAX it is usually D_float. D_float is available on Alpha, but D_float values are converted to G_float for computations and then converted back to D_float when stored. Because the G_float type has three fewer fraction bits than D_float, some applications may get different results. IEEE float types are also available on OpenVMS Alpha. - Data alignment is extremely important for best performance on Alpha. This means that data items should be allocated at addresses which are exact multiples of their sizes. Quadword alignment will offer the best performance, especially for character values and those smaller than 32 bits. Compilers will naturally align variables where they can and will issue warnings if they detect unaligned data items. - DEC C is the only C compiler Digital offers on OpenVMS Alpha. It is compatible with DEC C on OpenVMS VAX, but is somewhat different from the older VAX C compiler most people are familiar with. Read up on the /EXTERN_MODEL and /STANDARD qualifiers to avoid the most common problems. - The page size on Alpha systems is variable, but is at least 8K bytes. This can have some effect on applications which use the $CRMPSC system service as well as on the display of available memory pages. The page size is available from $GETSYI(SYI$_PAGE_SIZE). There are also a number of manuals which discuss migration to Alpha. - "A Comparison of System Management on OpenVMS AXP and OpenVMS VAX" - "Migrating to an OpenVMS AXP System: Planning for Migration" - "Migrating to an OpenVMS AXP System: Porting VAX MACRO Code" - "Migrating to an OpenVMS AXP System: Recompiling and Relinking" These are part of the "AXP Migration Kit" (which is part of the "Programming Kit" - which in turn is part of the "Standard Set" if ordering documentation.) Check out the "Overview of OpenVMS Documentation" book on the Bookreader-based doc set included on the OpenVMS AXP V6.1 distribution CD for part numbers of both assorted "kits" and/or individual manuals.
As of November 1, 1995, Digital's service of Internet-accessible Alpha "test drive" systems was suspended. A revised service may appear in the future. For more information, write to Jack Lucier at lucier@kacie.enet.dec.com.
The Association of Software & Application (ASAP) Partners is a Digital program designed to provide members with a broad base of development support, promotional tools, and services. The ASAP program is open to software partners throughout the U.S., Canada, Europe and selected countries in Asia Pacific. For more information about the Software Developer Kits and the Association of Software Application Partners (ASAP) Program, contact the ASAP Program Office as follows: Via phone: 1-800-332-4786 in the U.S. +353 91 754 299 in Europe Via E-Mail: alpha-developer@digital.com Via WWW: http://www.partner.digital.com/www-swdev/
Digital makes a wide range of performance documents available through its FTP and WWW Internet servers (see DOC2). The specific WWW subject page is http://www.digital.com/info/performance.html, for FTP look in ftp://ftp.digital.com/info/performance. Documents with "flash" in their names are short summaries with performance charts, those with "brief" are longer documents with more detail on the specific tests and configurations.
Firmware updates for Digital Alpha systems are available from: ftp://ftp.digital.com/pub/Digital/Alpha/firmware/ http://www.service.digital.com/alpha/server/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.3 firmware CD are located at: ftp://ftp.digital.com/pub/Digital/Alpha/firmware/v3.3/ 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.com
The AlphaStation series will boot without a keyboard attached. To use a serial terminal as the console, issue the console command SET CONSOLE SERIAL - after that, it will use the terminal. Older Alpha workstations generally can't be booted without a keyboard.
No. Not just an "unsupported" - it won't boot.
The cheapest system, sold by Digital today, that will run OpenVMS is the AlphaStation 255 4/233. Other companies sell Alpha-powered systems, some of which will run (and can be purchased with) OpenVMS. There are also many used DEC 3000 models available which are suitable.
The MicroVAX-series console bulkhead was used with the KA630, KA650, KA655 processors. There are three controls on the console bulkhead of these systems: Triangle-in-circle-paddle: halt enable. dot-in-circle: halt () is enabled, and auto-boot is disabled. dot-not-in-circle: halt ( ) 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. Those versions of the console bulkhead that do not have an MMJ have a 9-pin submini connector, and the pinout of this connector predates the PC 9-pin pinout -- the console pinout is consistent with the EIA232 pinout. For those bulkheads not equipped with an MMJ, use the H8575-B adapter to convert the console connector to MMJ. See MISC1 for further details. 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. [hoffman@xdelta.enet.dec.com]
The VAX floating point format is derived from one of the PDP-11 FP formats, which helps explain its strange layout. There are four formats defined: F 32-bit single-precision, D and G 64-bit double-precision and H 128-bit quadruple precision. For all formats, the lowest addressed 16-bit "word" contains the sign and exponent (and for other than H, some of the most significant fraction bits). Each successive higher-addressed word contains the next 16 lesser-significant fraction bits. Bit 15 of the first word is the sign, 1 for negative, 0 for positive. Zero is represented by a biased exponent value of zero and a sign of zero; the fraction bits are ignored (but on Alpha, non-zero fraction bits in a zero value cause an error.) A value with biased exponent zero and sign bit 1 is a "reserved operand" - touching it causes an error - fraction bits are ignored. There are no minus zero, infinity, denormalized or NaN values. 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) [lionel@quark.enet.dec.com]
Digital runs a VAX "InfoCenter" at: http://www.digital.com/info/vax Jim Agnew maintains a MicroVAX/VAXstation FAQ at: http://anacin.nsc.vcu.edu/~jim/mvax/mvax_faq.html James Lothian maintains a VAX-11/750 FAQ at: http://www.dcs.napier.ac.uk/~oose5002/750faq.html
Gunnar Helliesen maintains a NetBSD VAX FAQ at: http://www.bitcon.no/~gunnar/vaxbsd/FAQ.html
Digital's OpenVMS documentation is copyrighted and is not freely available on the net. 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 Bookreader, a viewer that is supplied with DECwindows Motif. MGBOOK, a viewer for Bookreader documents which is usable from character-cell terminals (eg. VTxxx) is available from the WKU VMS Freeware file server - see question SOFT1 for details. [lionel@quark.enet.dec.com] We are allowing interactive viewing of the Consolidated Distribution Documentation CDROMs (NOT copying, just reading). Currently available by: telnet://vtbook@condist.acornsw.com/ We're planning to leave this on the network indefinitely, but we MAY limit access in some way depending upon load. [munroe@dmc.com]
On your OpenVMS system, the HELP command can provide a wealth of information, not only on DCL commands but on system services (HELP System_Services) and Run-Time Library routines (HELP RTL_Routines). The introduction displayed when you type the HELP command with no additional keywords provides further pointers. In SYS$COMMON:[SYSHLP.VMSDOC] (OpenVMS V6.0 or later) you'll find the following three files: VMSDOC_GLOSSARY.TXT - Glossary of OpenVMS terminology VMSDOC_OVERVIEW.TXT - Overview of OpenVMS documentation VMSDOC_MASTER_INDEX.TXT - Master index of OpenVMS documentation These files are optionally installed; some system managers may have selected not to install them or to put them in another location. If you cannot locate them, ask your system manager. OpenVMS Marketing runs a WWW server at http://www.openvms.digital.com/ Here you'll find product information, strategy documents, the contents of the latest OpenVMS Freeware CD-ROM and much more. Product information for just about everything Digital 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, performance data, product infosheets, release notes and much more are available. In addition, http://www.digital.com/info/forms/search.html provides a handy method to search all of Digital's public web servers for information of any kind. Digital's Multivendor Customer Services organization also hosts an Internet server. If you have a software support contract you can obtain patches from here - even without a contract you can browse through the "readme" files for correction kits. The WWW URL is http://www.service.digital.com/ For ftp access use ftp://ftp.service.digital.com/ A WWW version of the DECdirect catalog is also available at http://www.service.digital.com/ddi/html/ddhome.html Digital's Electronic Connection, also called "E-store", provides product information, prices and even lets you order online. For free access, TELNET to order.sales.digital.com or connect via modem at 800-234-1998. If you're on TYMNET, connect to ECONN. If you need to get pricing for Digital software licenses for your configuration, this is the place to get them. Information on Digital and on Digital hardware, software, products and services is available through various telephone numbers: 1-800-DIGITAL : voice : DECdirect products, books and services 1-800-PCBYDEC : voice : Digital PC hardware and software 1-800-DECINFO : voice : General Corporate Information 1-603-884-0924 : voice : (alternate number for above) 1-800-234-1998 : modem : The Digital Electronic Connection 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
DEC Professional is alive and well. It's a monthly magazine that helps you manage your Digital systems in a multivendor environment. Subscriptions are free to qualified Digital sites. Digital Systems Journal is a bimonthly magazine that contains more in-depth, hands-on, how-to information. Subscriptions are paid. If you're interested in acquiring a subscription to DEC Professional or Digital Systems Journal, contact Omeda Communications: 800-306-6332 708-564-1385 They'll send you everything you need. [morrison@elvis.cardinal.com] Digital Press, an imprint of Butterworth-Heinemann, has a web site at: US & Canada URL http://www.bh.com/bh/dp UK & Europe URL http://www.butterworth.heinemann.co.uk
To extract all the text of a HELP topic (and its subtopics) to a text file for perusal with a text editor, printing out, etc., use the following command: $ 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.
Yes - if you can't get the answers to questions elsewhere, if you have comments or complaints about OpenVMS, send mail to openvms-info@digital.com. This is NOT a support channel, but an informal method to communicate with OpenVMS Marketing. Please be courteous and careful using this address so that it may continue to be of benefit to all.
http://www.openvms.digital.com/ (Sponsored by OpenVMS Marketing) http://www.montagar.com/ (Sponsored by DECUS - DFWLUG) http://www.hhs.dk/vms/ (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)
Digital is now providing many patches (correction kits) for OpenVMS and layered products on the Internet. The easiest way to search for and retrieve the patches is through: http://www.service.digital.com/html/patch_service.html You can also find the patches and the associated README files at: ftp://ftp.service.digital.com/public but you must know what you are looking for. See VMS7 for info on ordering a CD-ROM with patch kits.
After all this discussion about undocumented VMS features I started a collection of some documentation :-)) about them on http://axp616.gsi.de:8080/www/vms/qaa/undoc.htmlx [zinser@axp603.gsi.de]
Specifications for DECnet Phase IV can be found at: http://gatekeeper.dec.com/pub/DEC/DECnet/PhaseIV/index.html
The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here. 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.
Viruses are very common on PCs because the PC operating systems such as MS-DOS and MacOS do not implement any sort of scheme to protect the operating system or the file system against hostile action by programs. On these operating systems, any running program can subvert the operating system and take over the hardware, at which point it can do anything it wishes, including hiding copies of itself in other programs or in the file system. This is unlikely on VMS, Unix, MVS, and Windows NT, for two 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, VMS, Unix, MVS, and NT 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. It is possible for VMS, 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. [winalski@gemgrp.enet.dec.com] 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. Digital offers the following products in this area: DECinspect Intrusion Detector POLYCENTER Security Reporting Facility POLYCENTER Security Compliance Manager Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com). [Contributions to this list welcomed]
ISO-9660 support was added in the following releases: OpenVMS VAX V6.0 OpenVMS AXP V1.5 OpenVMS VAX V5.5, use F11CD kit from InfoServer CD, or Consolidated Distribution CD under InfoServer, or Digital Customer Support - CSCPAT #1071012 Here's how to do it: $ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label] Please refer to the OpenVMS MOUNT Utility Manual, especially the section regarding the MOUNT qualifier /UNDEFINED_FAT. From the OpenVMS release notes: Because ISO-9660 media can be mastered from platforms that do not support semantics of files containing predefined record formats, you may encounter ISO-9660 CD-ROMs with files that contain records for which no record format was specified. An example which works for most CD-ROMs is: $ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE This /UNDEFINED_FAT qualifier states, "For any file whose file attributes are 'undefined', return file attributes of 'stream', maximum record length 2048". [dunham@star.enet.dec.com]
A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits. 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=REFERENCE A PCSI kit file has a file specification of the following form: DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI In 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 in" to an OpenVMS system because you've forgotten the SYSTEM password, you need to have physical access to the system console and must be able to reboot the system. Here are the steps. 1. Halt the system (press halt button or ^P on console of some models) 2. Boot into the SYSBOOT prompt - the syntax for this varies by system - it typically involves a flag of 1, for example: B/1 B/R5:1 b -flags 0,1 (Recent Alpha systems) If your system has a hardware password (some VAXstations have this), you will need to know the password and enter it using the LOGIN command at the console. If you get an "Inv cmd" error trying to boot with a flag of 1, and can't LOGIN using the hardware password, you're stuck - call for hardware service to reset the hardware password. 3. At the SYSBOOT> prompt type: SET/STARTUP OPA0: SET WRITESYSPARAMS 0 C 4. Wait for the $ prompt. The system will now be accepting startup commands form the console. Type: SPAWN @SYS$SYSTEM:STARTUP This causes the system to complete the startup, but leaves you logged in. The SPAWN is necessary as without it you'll be logged out when the startup finishes. 5. Type: SET DEFAULT SYS$SYSTEM: ! or wherever SYSUAF.DAT resides RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT This changes the SYSTEM password to a new value. 6. Type: @SYS$SYSTEM:SHUTDOWN The system will now shut down. Reboot the system normally - the SYSTEM password should now be set as you specified in step 5. Some people will suggest a method using the UAFALTERNATE SYSGEN parameter. I don't recommend this as it is not reliable. [lionel@quark.enet.dec.com] Improvements by: [thomasgd@boat.bt.com] [newman@bklite.enet.dec.com]
Recently a number of people (myself included) have asked about postscript printers and how to connect them to VMS systems via TCP/IP. This, we were informed, is not yet possible but is hoped to be under the next release of DCPS (out about the turn of the year or first quarter '97). [SRR3@le.ac.uk]
Q: Trying to set the time with SET TIME on my system returns one of these messages: %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 time A: 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 DTSS This will shutdown DTSS$CLERK. You may then change the system time as usual. To restart the DTSS software, type @SYS$STARTUP:DTSS$STARTUP You'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]
There is no one answer to this question. Internet mail is built upon the TCP/IP protocols, which are not directly supported by VMS. A number of implementations of TCP/IP for VMS are available, from Digital, from a number of other vendors, and even in a free "support it yourself" form. The MAIL program that comes with VMS does not directly support the mail format used on the Internet, but various programs have been written that use MAIL's "foreign protocol" facility to provide such support. To send mail through a foreign protocol by using an address syntax like IN%"fred@fred-host.xxx.com". You _must_ include the quotation marks Between them is the address in the format used by mail programs that support the Internet directly. The IN% - short for INternet - names the foreign protocol. On some systems, you use MX% or SMTP% instead. (MX is a widely used, free, mail handler; see question SOFT1. SMTP% is used by Digital's UCX TCP/IP product) Other systems may use some other name. If none of these prefixes work, ask your system manager for assistance. [leichter@lrw.com] See also MAIL2
Get the MAILSHR_PATCH package (there's one each for VAX and Alpha) from the WKU FILESERV server (see question SOFT1.) 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".
OpenVMS 7.0 adds the ability to automatically append signature files - in MAIL, use the SET SIGNATURE command to specify a signature file name. For earlier versions, see the following paragraphs. 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','P2' $ ELSE $ COPY 'P2' $ ENDIF $ DEFINE/NOLOG SYS$INPUT SYS$COMMAND $ 'P2' $ EXIT Where is the name of the signature-file (including directory and disk) and is EDIT/EDT or EDIT/TPU (or your favorite editor). [ARNE@ko.hhs.dk]
Several Unix mailers have been ported to VMS, some by the vendors of specific TCP/IP packages, some by users who have made them freely available. See the documentation for your TCP/IP package, and refer to question SOFT1 for information about the availability of the free ports. [leichter@lrw.com]
You can use the SET FORWARD command within MAIL to specify where you want all your mail forwarded to. Use SHOW FORWARD to see your current forwarding. To cancel all forwarding, type SET NOFORWARD. 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". [leichter@lrw.com] 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.
VMS MAIL does not support forwarding a message to more than one address. (Older versions of MAIL allowed you to specify such forwarding, but it never worked correctly.) 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. [leichter@lrw.com]
The count of new mail messages is kept separately from your mail folder in SYS$SYSTEM:VMSMAIL_PROFILE.DATA. It sometimes happens that this count differs from what's in your mail folder. If this happens, go into MAIL and repeat the READ/NEW command until you see no new mail messages. Then enter the command one more time. This will resynchronize the counters.
If you are moving to another OpenVMS system, perhaps the best way is to select each folder and do (in MAIL) a: EXTRACT/APPEND/ALL/MAIL mymail.mai Move MYMAIL.MAI to the other system, then do this (in MAIL): SET FILE mymail.mai COPY/ALL foldername MAIL.MAI This 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.
If you've installed the DECwindows examples, you'll find DECW$CDPLAYER.C, .DAT, .EXE, .UIL, and .UID. Copy the .UID and .DAT files to DECW$USER_DEFAULTS: (typically SYS$LOGIN:), define the logical name DECW$CD_PLAYER to be the device name of your CD-ROM drive (eg. DKA400:), give yourself PHY_IO and DIAGNOSE privileges, and run the .EXE. You can also install the image with these privileges. See the source for additional details - note that the comments regarding the need for SYSGEN CONNECT are no longer applicable (at least as of VMS V5.5-2). There's also SYS$EXAMPLES:CDROM_AUDIO.C and .EXE, a non-Motif program.
The Digital Pathworks for OpenVMS product includes a utility called PCDISK that can read and write MS-DOS format diskette. A license for Pathworks is as little as US$99 (QM-2CLAA-AA, File and Print Access license). 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/erase files on DOS diskettes. Available for both VAX and Alpha. Contact ed@cityscape.co.uk for more information.
The new AlphaStation systems use a different sound board (Microsoft Sound System) than the earlier DEC 3000 AXP systems, and DECsound, as supplied by DECwindows Motif, doesn't support this board. Digital offers an optional product, Multimedia Services for OpenVMS (SPD 64.24.00), which provides a replacement DECsound for this card as well as many other features (an AVI and MPEG player, video capture support, etc.)
The RUN command does not accept arguments. To pass arguments to a program, you must use what is called a "foreign command". For example: $ uudecode :== $disk:[dir]uudecode.exe $ uudecode filespec The 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.COM Various 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. [hoffman@xdelta.enet.dec.com]
The DCL DEFINE/KEY command allows you to define function and keypad keys, but not control keys. Also, keys you define with DEFINE/KEY are not recognized inside applications. Many applications which use the SMG$ routines for input have a similar DEFINE/KEY feature. The terminal driver line-editing control keys, including the use of DEL for delete, are not modifiable.
The simplest way is TYPE/PAGE NL:
Your terminal must be enabled as an operator terminal before doing the REPLY/LOG, but a batch stream doesn't have a terminal. To make this work, use the following sequence to enable the console as the operator terminal; then the REPLY/LOG will be accepted: $ DEFINE SYS$COMMAND _OPA0: $ REPLY/ENABLE $ REPLY/LOG [ARNE@KO.HHS.DK]
Here's my random number generator for inclusion into the OVMS FAQ; just do a GOSUB RAND and the global symbol RANDOM will contain a randomly generated number. The user/programmer can feed the generator a ceiling value (__CEIL) or a new seed (__SEED). $! 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]
The MCR command runs the specified image, with a default filespec of SYS$SYSTEM:.EXE, and passes any (optional) command line arguments in the same manner as a foreign command. In other words: $ MCR FOO BAR is equivalent to: $ FOO :== $FOO $ FOO BAR It 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.
OpenVMS doesn't have an "undelete" function. However, if you are quick to write-protect the disk (or if you can guarantee that no new files get created or existing files extended), your data is still on the disk and it may be possible to retrieve it. The FLORIAN tool available from the WKU Fileserver claims to be able to do this (see question SOFT1.)
DIR/SIZE doesn't take into account the size of file headers which are charged to your quota. Also, unless you use DIR/SIZE:ALL, you'll see only the "used" size of the file, not the allocated size which is what gets charged against your quota. Also, you may have files in other directories. [lionel@quark.enet.dec.com] $ 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 disk If 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+1 If the diskquota is out of synch, then the system-manager can make a rebuild. [ARNE@ko.hhs.dk]
If your application must absolutely guarantee that data is available, no matter what, there's really no substitute for RMS Journalling. However, you can achieve a good degree of data integrity by issuing a SYS$FLUSH RMS call at appropriate times (if you're using RMS, that is.) If you're using a high-level language's I/O system, check that language's documentation to see if you can access the RMS control blocks for the open file. In C you can use fflush followed by fsync. Note that fsync, which was undocumented for VAX C but is documented for DEC C, takes a file descriptor as an argument, not a *FILE.
A file specification has an aggregate maximum size of 255 characters at present. The node and device specification may be up to 255 characters each - file name and file types may be up to 39 characters each. File versions are from 1 through 32767, though 0 (latest version), -0 (oldest version) and -n (n'th previous version) can be used in most contexts. A file specification may not have more than 8 directories and subdirectories - while it is possible to create subdirectories of greater depth, accessing them is problematic in most cases and this should be avoided. 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.
One Terabyte (2**31 blocks of 2**9 bytes). Prior to the release of V6.0, the OpenVMS file system was limited to disk volumes of 8.5 GB (2**24 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. [hoffman@xdelta.enet.dec.com]
Most OpenVMS system services and RTL routines pass string arguments by descriptor. Languages which support native string data types create descriptors automatically; those which do not (eg., C) require that you set them up explicitly. [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. The best references are: Your language's User Manual OpenVMS Programming Environment Manual OpenVMS Programming Concepts Manual OpenVMS Programming Interfaces: Calling a System Routine OpenVMS Calling Standard In addition, if you are a subscriber to the Digital Software Information Network (available to those with a software support contract), the DSIN database contains hundreds of worked examples of calling system services and RTL routines, including the one that seems to trip up almost everyone, SMG$CREATE_MENU. [lionel@quark.enet.dec.com] Arne Vajhøj has put together a collection of OpenVMS example programs. It can be found at: ftp://ftp.hhs.dk/ http://www.hhs.dk/vms/vms_sw_arne.html [arne@ko.hhs.dk]
If you're writing a program and want to accept arguments from a foreign command, you can use LIB$GET_FOREIGN to get the command line and parse it yourself, or if you're programming in C, use the normal argc/argv method. 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.
Use the SYS$PUTMSG system service with an action routine that stores the message line(s) in the variable of your choice. Be sure the action routine returns a "false" (low bit clear) function value so that SYS$PUTMSG doesn't then try to display the message (unless you want it to.) See the description of $PUTMSG in the System Services Reference Manual for an example of using an action routine.
LINK/SYSEXE is the OpenVMS Alpha equivalent of linking against SYS.STB.
The problem is that SYS$SETDDIR only changes the default directory - NOT the default disk. The default disk is determined by the logical SYS$DISK. If you want to change the default disk within a program, then call LIB$SET_LOGICAL to change the logical SYS$DISK. You will need to call both LIB$SET_LOGICAL and SYS$SETDDIR to change both default disk and the default directory! [ARNE@ko.hhs.dk]
This is something that was greatly simplified for OpenVMS Alpha. You don't need to create a separate transfer vector module; just use the SYMBOL_VECTOR statement in a linker options file. For example, if your shareable image has two routines named FOO and BAR, the linker options file should contain the following line: SYMBOL_VECTOR=(FOO=PROCEDURE, BAR=PROCEDURE) The Linker manual has more details on this.
You need to add SYMBOL_VECTOR=(=PSECT) to your options file. On OpenVMS VAX all OVR/REL/GBL psects were automatically exported into the shareable image's Global Symbol Table. On OpenVMS Alpha you have to tell the linker that you want this done by means of the PSECT keyword in the SYMBOL_VECTOR options file statement. 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.
In OpenVMS V6.1 there is a routine CVT$CONVERT_FLOAT, documented in the LIB$ Run-Time Library Reference Manual, which can perform conversions between any two of the following floating datatypes: VAX (F,D,G,H), little-endian IEEE (single, double, quad), big-endian IEEE (single, double, quad), CRAY and IBM System\370. 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.
On VAX, many programmers would use a MACRO routine which accessed the AP register of the caller to get the address of the argument list and hence the argument count. This was not guaranteed to work on VAX, but usually did. However, it doesn't work at all on OpenVMS Alpha, as there is no AP register. On Alpha systems, you must use a language's built-in function to retrieve the argument count, if any. In Fortran this is IARGCOUNT, which is also available in DEC Fortran on OpenVMS VAX. 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.
Many software developers desire to use a unique hardware ID to "lock" a given copy of their product to a specific system. Most Digital VAX and Alpha systems do not have a unique hardware-set "system ID" that can be used for this purpose. Digital does not use hardware IDs in its licensing methods and many users consider a hardware-based licensing scheme to be a negative attribute when considering software purchases. Digital 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. Digital sells the DEC LMF PAK Generator for OpenVMS (SPD 31.68.03) for use by software vendors. 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.partner.digital.com/www-swdev/files/OPENVMS/examples/ether/ether.c
On a workstation, you go into "Customize" menu of the session manager utility and select "Security". When the pop-up box appears, you can put node/user/tranport to allow who can launch an application to the display on that workstation. [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: 1) Make sure that you've specified the X-windows "display" correctly on the remote side. For DECNET it's something like NODE::0.0, for TCP/IP it's Node.Domain:0.0, etc. On a unix system, define the DISPLAY environment variable so: # setenv DISPLAY myvax.domain:0.0 2) If you've verified 1) and things still aren't working, make sure the Security settings on the VMS side will allow the connection: Pull down the "Options" menu in the Session Manager, select "Security..." near the bottom. If you don't find your host (and username) listed on the left under "Authorized Users", go to the right side of the menu and fill in the three fields, "Node", "Username", "Transport". Then click on the Add botton, then the Apply and OK buttons to add the new host to the security database. a) There are various transports: LOCAL, DECNET, LAT, TCPIP, etc. Select the one appropriate to the client machine's connection to the VMS machine. b) If the connection is DECNET, do *NOT* add :: to the node name! c) If the connection is TCPIP, "Username" _must_ be an asterisk (*) because the TCP/IP protocol used does not provide the remote username. d) If the connection is TCPIP, it's best to use a full domain name, e.g., Node.Subd.Domain. However, you _may_ have to use the IP address itself, rather than the domain name (EWS requires this). I generally add two entries for each TPCIP host, the first using the domain name, the second the IP address. e) There are a various 3rd party vendors who supply TCP/IP packages for VMS, including but not limited to TGV (Multinet) and Wollongong (Pathway ?). Multinet (and DEC's own UCX) call the transport "TCPIP", Wollongong, at least in some incarnations, uses "WINTCP". You need to use the appropriate vendor's package transport name in the "Transport" field. 3) If things _still_ aren't working, make sure the transport you want has been activated for DECwindows. This is a system manager job, but you can do the ground work yourself before bothering the sysmgr. Do the following: $ DIR SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM If that file exists, then do: $ SEARCH SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM - $_ DECW$SERVER_TRANSPORTS You sould find something like: $ 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. a) If you're wanting to use TCP/IP to connect, make sure TCP/IP is available on the VMS host. TCP/IP is _not_ native to VMS. You need to be running either Digital's UCX or a 3rd party vendor's TCP/IP product. If you're not, none of the above will help. [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_node for LAT the command might look like this: $ SET DISPLAY /CREATE /TRANSPORT=LAT /NODE=REMOTE_NODE for DECnet: $ SET DISPLAY /CREATE /TRANSPORT=DECNET /NODE=NODE for TCP/IP $ SET DISPLAY /CREATE /TRANSPORT=TCPIP /NODE=128.12.4.122 Note 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]
Use the undocumented SHOW DISPLAY/SYMBOL, and then reference the symbols DECW$DISPLAY_NODE, DECW$DISPLAY_SCREEN, DECW$DISPLAY_SERVER and/or DECW$DISPLAY_TRANSPORT. [Fairfield@Slac.Stanford.Edu]
If you are working from a Decterm, you can use the AutoPrint feature. Choose the "Printer..." menu item from the "Options" menu, set the printing destination to the name of the file you want, and set "Auto Print Mode". You are now free to continue. 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]
This has to do with Motif's virtual bindings. When a Motif application starts up, it looks at the vendor string returned in the display connection information and attempts to match the string to a table of virtual bindings. 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 :F11 \n\ osfLeft : Left \n\ osfUp : Up \n\ osfRight : Right \n\ osfDown : Down \n\ osfEndLine :Alt Right \n\ osfBeginLine :Alt Left \n\ osfPageUp : Prior \n\ osfPageDown : Next \n\ osfDelete :Shift Delete \n\ osfUndo :Alt Delete \n\ osfBackSpace : Delete \n\ osfAddMode :Shift F8 \n\ osfHelp : Help \n\ osfMenu : F4 \n\ osfMenuBar : F10 \n\ osfSelect : Select \n\ osfActivate : KP_Enter \n\ osfCopy :Shift DRemove \n\ osfCut : DRemove \n\ osfPaste : Insert To merge: $ xrdb :== $decw$utils:xrdb.exe $ xrdb -nocpp -merge decw$xdefaults.dat [kleinsorge@star.enet.dec.com]
Check for a GQ device by doing a SHOW DEVICE G at the DCL prompt. If there is no GQA0 device: a) VMS failed to find the appropriate IRQ information for the Compaq QVision and did not autoconfigure it. Run the correct ECU (for OSF and VMS) and reboot. b) You do not have a Compaq QVision video card. This card should have Compaq printed on it, and identifies itself as a CPQ3011 or a CPQ3111. If it is not one of these 2 devices (as of 7/1/94 and version 6.1) then VMS does not support it. If there is a GQA0 device: a) There may have been a severe error in the DECwindows startup. Type the contents of SYS$MANAGER:DECW$SERVER_0_ERROR.LOG for any information on errors starting the server. b) The sysgen parameter WINDOW_SYSTEM is not set to 1. This is a common way used by system managers to disable server startup. c) You may not have a valid Motif license. To check for the Motif license, type LICENSE LIST DW-MOTIF/FULL and examine the information displayed. Make sure that it is present, valid and active. [kleinsorge@star.enet.dec.com]
There are several modes of failure: a) Pressing 2 and 3 keys at the same time causes one key to autorepeat when released. Check the hardware revision level printed on the bottom of the keyboard. If the revision level is C01, the keyboard firmware is broken. Call field service to replace the keyboard with any revision level other than C01. b) Pressing certain keys is always broken. Typical sympypoms are: delete always causes a autorepeat, return needs to be pressed twice, etc. This is frequently caused by having keys depressed while the keyboard is being initialized. Pressing ^F2 several times or unplugging and replugging the keyboard frequently fix this problem. There is a patch available to fix this problem [contact the CSC for information - a CSCPAT number will be included here when available. - Ed.] c) A key that was working spontaneously stops working correctly. This may be either (a) or (b) or it may be bad firmware. Ensure that you have the most recent firmware installed on your CPU. An old version of the DEC 3000 firmware had a bug that could cause this symptom. [kleinsorge@star.enet.dec.com]
Check the firmware revision on the keyboard. Hardware revision B01 introduced an incompatability with the device driver which causes the keyboard to not be recognized correctly. There is a patch available to fix this problem: [AXPDRIV06_061] - the fix is also included in OpenVMS V6.2. The rev A01 keyboard, and the LK450 should work without problems. [kleinsorge@star.enet.dec.com] [inazu_k@ewbv21.enet.dec.com]
If you are creating a new DECterm window, check HELP CREATE /TERMINAL /WINDOW_ATTRIBUTES. If you want to change the title of an existing window, use the following control sequences, whereis the ANSI escape code, value decimal 27, and is what you want to display: To set the DECterm title, send ]21; \ To set the icon label, send ]2L; \ 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 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.TEMPLATE This 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. [hoffman@xdelta.enet.dec.com]
DECconnect DEC-423 MMJ pinout: 1 Data Terminal Ready (DTR) 2 Transmit 3 Transmit Ground 4 Receive Ground 5 Receive 6 Data Set Ready (DSR) 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 Numerous additional adapters and cables are available from the _OPEN DECconnect Building Wiring Components and Applications Catalog_, as well as descriptions of the above-listed parts. [hoffman@xdelta.enet.dec.com]
In the following,is decimal code 155 and can be replaced by the sequence " [" (without the quotes), SS3 is decimal code 143 and can be replaced by " O". VT1xx terminals don't accept and . PF1= P PF2= Q PF3= R PF4= S KP0= p KP1= q KP2= r KP3= s KP4= t KP5= u KP6= v KP7= w KP8= x KP9= y KPCOMMA= l KPMINUS= m KPPERIOD= n ENTER= M DNARROW= B UPARROW= A LFARROW= D RTARROW= C FIND= 1~ INSERT= 2~ REMOVE= 3~ SELECT= 4~ PREV= 5~ NEXT= 6~ F6= 17~ F7= 18~ F8= 19~ F9= 20~ F10= 21~ F11= 23~ F12= 24~ F13= 25~ F14= 26~ HELP= 28~ DO= 29~ F17= 31~ F18= 32~ F19= 33~ F20= 34~ These and other control sequences can be found in SYS$SYSTEM:SMGTERMS.TXT
An OpenVMS Freeware CD was distributed at US DECUS in May and December 1995 - this CD will also be included with future versions of the OpenVMS binaries CD-ROM distribution (note - not the Software Product Library CD-ROMs)for VAX and Alpha systems. The OpenVMS Freeware CD is available online at: http://www.openvms.digital.com/openvms/freeware/cd.html ftp://ftp.montagar.com/ http://www.montagar.com/dfwlug/ ftp://flash.acornsw.com/ gopher://gopher.acornsw.com/ http://www.acornsw.com/ ftp://ftp.tay.ac.uk/ It may also be ordered from DECUS (http://www.decus.org) as VS0185. This CD 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 often requested tools on the Freeware CD are: ZIP/UNZIP, MMK (make), PINE, PERL, TAR, UUENCODE/UUDECODE and XV. The montagar.com server, belonging to the DECUS Dallas/Fort Worth LUG, also provides "Almost 350,000 blocks of white papers, OpenVMS rebuttals, good articles, engineering information, and other assorted OpenVMS Positive 'Stuff'." You can also telnet to dfwlug.decus.org and log in as Info to access an "OpenVMS BBS" system there. Digital has a WWW page with pointers to freeware (mostly derived from this FAQ) but which also contains useful information on archive tools needed for extracting freeware kits. The URL is: http://www.digital.com/info/vms-freeware.html Hunter Goatley runs a VMS freeware fileserver at Western Kentucky University. If you're using a WWW browser, the URL is: http://www.wku.edu/www/fileserv/fileserv.html The FILESERV packages are also available via anonymous FTP from: ftp.wku.edu, under [.VMS.FILESERV]. ftp.spc.edu, under [.MACRO32.SAVESETS] and [.MX]. ftp.vms.stacken.kth.se, under [.WKU.VMS.FILESERV]. ftp.shsu.edu, under pub/vms/mx and pub/vms/utilities. nic.switch.ch, under /mirror/vms/spc. ftp.technion.ac.il, under /pub/unsupported/vms/spc. ftp.riken.go.jp or via e-mail from FILESERV@WKUVX1.WKU.EDU. Send the commands HELP and DIR ALL in the body of a mail message for more information. 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 this from: ftp://ftp.wku.edu/vms/unzip.exe ! VAX ftp://ftp.wku.edu/vms/unzip.alpha_exe ! Alpha or you can request the FILESERV_TOOLS package from the e-mail server. 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.hhs.dk/vms/ Kermit is available at: http://www.columbia.edu/kermit/ or ftp://kermit.columbia.edu/ ZMODEM is available at: ftp://ftp.cs.pdx.edu/pub/zmodem See 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) [lionel@quark.enet.dec.com] 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; 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.html Chris Higgins's VMS Software List II http://csvax1.ucc.ie/www/vms_sw_list/sw_list.html DECUS SIG Tape collections are available on Mark Berryman's system, ftp://mvb.saic.com David 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] DECwindows Motif V1.2-3 includes NCSA Mosaic 2.4 built for UCX. V1.2-4 will include Spyglass Enhanced Mosaic which supports many "Netscape" enhancements. 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 [lionel@quark.enet.dec.com] 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.html PGP (Phil Zimmerman's "Pretty Good Privacy") is available from the standard distribution sites as listed in the PGP FAQ. Information on compiling PGP for OpenVMS can be found at http://zifi.genetics.utah.edu/ An archive of DECwindows and Xwindows software can be found at the following sites: ftp://axp.psl.ku.dk/decwindows ftp://ftp2.cnam.fr/decwindows ftp://ftp.et.tudelft.nl/decwindows ftp://ftp.ctrl-c.liu.se/decwindows http://axp616.gsi.de:8080/wwwar/cena/decwindows/cena.html (See also Freeware CD) [pmoreau@cena.dgac.fr] 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 3.10 is available from: ftp://ftp.cis.upenn.edu/pub/xv ftp://ftp.digital.com/pub/graphics/xv (Also on Freeware CD) GHOSTSCRIPT and GHOSTVIEW are available from: ftp://ftp.digital.com/pub/VMS/ghostview Version 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.contrib.andrew.cmu.edu/usr/dn0o/xpdf/xpdf.html 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 [pmoreau@ad.cena.dgac.fr] Good news: ada.cenaath.cena.dgac.fr anonymous ftp server is reopen. However, we always have a rather slow Internet link, but some mirror sites are available (they are listed in AAA_MIRROR_SITES.TXT file): List of FTP Mirror Sites for the DECWINDOWS archive: =================================================== AXP.PSL.KU.DK (Multinet) Mirror of CENA DECW archive FTP.ET.TUDELFT.NL (MadGoat) Mirror of CENA DECW archive FTP2.CNAM.FR (MadGoat) Mirror of CENA DECW archive ftp.x.org (in /contrib/vms) not really a mirror, but I try to put all my new ports at this site. List of HTTP Mirror Sites for the DECWINDOWS archive: ==================================================== http://axp616.gsi.de:8080/wwwar/cena/decwindows/cena.html Some X clients from the OpenVMS Freeware CDROM are located in [.DECWINDOWS.CDFREEWARE] directory. [pmoreau@cena.dgac.fr] 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 >14 GB of VMS software. The most useful commands are LIST, which generates a list of scanned ftp servers, and FIND, 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.htmlx and 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]
POSIX: POSIX-compliant, Digital-supported versions of POSIX routines and utilities: lex, yacc, grep, tar, uuencode, uudecode, rcs, man, cpio, make, awk, ar, mail, etc., the POSIX shell, the POSIX C programming interface, etc. POSIX utilities can be used from within the POSIX shell, and via the DCL `POSIX/RUN POSIX$BIN:tool.' command. 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. 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 Digital-supported X Windows utilities: xwd, xev, mosaic WWW browser, xrdb, bmtoa and atobm, xpr, ico, etc. In DECW$UTILS: in DECwindows Motif V1.2-3 and later. Also see DECW$EXAMPLES: for example X and C programs. Miscellaneous tools and examples: Various unsupported OpenVMS tools and code examples: DWAUTH (X Windows SYSUAF authorize-like tool), various versions of grep, fgrep, yacc, vmstar, uuencode, gawk, etc. html tools, the mx SMTP mail exchange package, X windows flight simulator, the mxrn X windows news reader, the OSU HTTPD WWW server, a WWW gopher browser, etc. are all on the FreeWare V2.0 CD-ROM. IP tools: DEC TCP/IP (UCX) contains tools such as ping, uuencode, smtp, snmp, rcp, nfs, tnfs, etc. OpenVMS V6.2 and UCX V3.3 and later can be used together in support of the /FTP, /RCP, /RLOGIN, /TELNET, and /TN3270 qualifiers on various DCL commands. Also see the various C examples in UCX$EXAMPLES: [hoffman@xdelta.enet.dec.com] GNU tools: Information on the GNU on VMS Project, which aims to port GNU software to VMS, is available at: 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: The Progis company in Germany claim to be porting GCC 2.7.2 for VMS on VAX and Alpha platforms. http://www.progis.ac-net.de/gccaxp.htm 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/ [otis@magna.com.au]