This file is intended to give the new-commer an overview of VMS, Digtial Equipment Corporation (DEC) operating systems that run on VAX hardware. The information in this file is not complete, balanced or exhausive. It's just stuff that I think would be of value to a person new to VMS. My goal was to give an overview and direct the reader to sources of information. I included some 'survival' commands so one could login and do a few things. This file is broken into sections which start with !== so you can use an editor or word processor and jump to the next section. Since Digital has made VMS an open operating system, it's official title is really 'OPENVMS', but we still refer to it as 'VMS'. ULTRIX, Digital's version of UNIX (which also runs on the VAX) is not covered. For a new-commer to VMS, the best place to start is the "VMS User's Guide", (Digital number AA-LA98B), which starts you off with how to log in to the system, explains the file and directory system, device names, what a process is, how to program command procedures, how to use the editors (EDT and TPU), common utilities such as mail and phone. "VMS User's Guide" does not cover layered software (applications). A good place to read up on VMS in general is the VMS Handbook, available gratis from DECdirect (1-800-DIGITAL) or the VMS SPD (Software Product Description) which your VAX system manager should have. You should understand that VAX is the hardware, VMS is the operating system. and application programs are called Layered Products. There is an old saying that 'A VAX is a VAX' and 'VMS is VMS'. Regardless of which VAX (hardware platform) you are on, the operating system, VMS, is the same and the commands are consistent from one release to the next. There are no O/S variants as in UNIX. To login, you will need to get a Username and password from the system manager or user support group. They should also explain how to access the VAX (or cluster) where your account is set up. Once you get logged in, especially if you are in a small shop, and no one seems to know anything about the VAX, check your process privs: use the command <$ sho proc/priv>. If you get a long string of privs, do yourself and everyone else a favor by turning them off with the following command: $ set proc/priv=(noall,netmbx,tmpmbx) Otherwise, in your blissful ignorance you could do immeasureable damage, especially if they do not do regular backups. In this file, the convention <$ command> means to type the command 'command' at the DCL prompt and press return. You don't type the <> braces. For someone just getting started the most useful command is HELP. <$ help> The command <$ help instructions> will give you help on using help and explain how you can capture help displays in a file for printing. For groups of commands arranged by topic, <$ HELP HINTS>. Enter ctrl/z at any time to exit help. BTW, ctrl/z and exit are widely used DEC conventions for gracefully exiting most layered products and programs. You can also use ctrl/Y, which is an interrupt and not a proper way to exit a program; use ctrl/y in an emergency. !============================== DCL FUNDAMENTALS ===========================! You interact with VMS using DCL (Digital Command Language), which is an English-like command interpreter. The DCL prompt is the '$' dollar sign. DCL is a programming language in itself, complete with error trapping, control constructs such as simple and block IF statements and subroutine calling, file handling, and ability to call system services. DCL does not do floating point. You write DCL command procedures ('scripts') using an editor. DCL is interpretive, like Basic, and essentially case insensitive. It is forgiving and considerate enough to give meaningful, error messages in English. Since DCL is command line oriented (not point and click!), you probably should see <$ help line_edit> for tips on using the command line; up arrow to recall previous 20 lines; The Digital default is overstrike; I prefer insert. Use one of the following to enable line_editing so you can use the arrow keys to recall commands and correct typo's. $ set terminal /insert /line_edit $ set terminal /over /line_edit The dcl prompt is a dollar sign '$', but can be changed with the set prompt command; there is no easy way to make the prompt reflect the default directory as in DOS. You can abbreviate DCL commands and qualifiers to the first 3 or 4 characters. DCL variable names (symbols) must start with an alphabetic character and can be 255 charters long and use A-Z, 0-9, the underscore '_' and the dollar sign '$'; The comment character is the exclamation point: '!' and can be placed anywhere on the line; i.e., it can follow a valid dcl statement. DCL command procedures (scripts) have the file extention .COM and are executed using the '@': thus $ @MYPROC executes the command procedure MYPROC.COM. LOGIN.COM is the command procedure which is executed automatically when you login, if present in your default directory. You can define frequently used symbols and logicals in your login.com and they will be created for you at login. !=========================== Logicals and Symbols =========================! Logical names and symbols are widely used in DCL. A logical name associates a name with a character string. Logicals are sort of nick-names for things. Symbols are integer or string variables; a symbol can also be an abbreviated command. -- As an example of when you would use a LOGICAL NAME, say that you often use the file $18$DUA118:[CORPORATE.DATA.FISCAL.1992]SMITHCO.DAT. You could define a logical like SMITHCO and use it in all commands and programs: $ define smithco $18$DUA118:[CORPORATE.DATA.FISCAL.1992]SMITHCO.DAT $ type smithco ! display contents of file on screen -- trivial example of using a SYMBOL as a command, $ TS := type smithco $ TS ! symbol TS types the file pointed to by logical smithco -- a more useful symbol used to display text or symbols $ say :== write sys$output $ say "Hello world" Hello world -- To display a symbol within a string literal, encase the symbol in single quotes as shown below. The paired single quote forces symbol substitution; the trailing single quote turns off substitution. $ greeting == "Hello world" $ say "This is my greeting: ''greeting'. " This is my greeting: Hello world. -- with numeric symbols, you can use the command <$ Sho symbol>, which will display the value in decimal, hex and octal $ num1 = 33 $ sho sym num1 NUM1 = 33 HEX = 00000021 OCTAL = 00000000041 -- if you want to really get fancy in your displays, use the f$fao() lexical for formatted ascii output: say f$fao(" Greeting: !AS. I wish I were still !UL ....") Greeting: Hello world. I wish I were still 33 .... See <$help lexicals f$fao> for more information on using f$fao (Note that the command is "Help lexicals" not "Help f$fao"). !============================ The File System ==============================! Specifiy VMS file names using the following pattern: device:[directory.subdir.subdir]name.extension;version_number dua1:[mystuff]myfile.dat;1 The device name is followed by a colon ':'. The directory name is encased in square brackets or in angle brackets. A period separates the file name and extension. A semicolon ';' or another period spearates the file version number from the file extension. VMS makes use of file versions so that you can have multiple copies of a file with the same name; thus if you edit a file twice then do a directory, you would see something like the following: myfile.dat;3 myfile.dat;2 myfile.dat;1 The number of versions of a file can get quite large: over 30,000; when you create a new version of a file, the new version has a version number one higher than the the previous version. A variant of the delete command (for removing files from the directory) is the PURGE command. Purge deletes all but the most recent version of the file. You can also use PURGE /KEEP=n to keep the latest n copies of the file. You can specify file versions relatively. Use a trailing ';' to specify the latest version of the file. Most useful when you have a directory full of multiple versions and the listing is long and you just want to see names of the files: < $ DIR *.DAT; > would show the highest version of all *.dat files. Use *.*;0 to specify the earliest version of the file. Thus if there were 10 versions of myfile.dat, the command < $ type myfile.dat;0 > would type the oldest (earliest) version. Use *.*.-1 to specify the previous (next most current) generation of the file. You can step through the versions, using negative version numbers which are always interpreted relatively: *.*;-2 File-Related commands: $ COPY file1.ext file2.ext ! make a copy of the file $ DIRECTORY [file.ext] ! lists the files $ DELETE file1.ext ! get rid of it; there is no UNdelete! $ PRINT file1.ext ! print the file $ PURGE file1.ext ! delete all but latest version of the file $ RENAME file1.ext file2.ext ! give it a new name $ TYPE file1.ext ! display on screen; be sure it's ascii or you could 'lock' your terminal! Wildcards: There are several wildcards associated with files '*' matches any number of characters $ dir red*.dat matches any file starting with red and with the extension .dat '*' can be embeded so that the command $ dir *VMS*.TXT would match any file containing VMS in the name, like FIRST_VMS_BOOK.TXT MYVMS.TXT VMS.TXT VMSZ.TXT '%' matches a single character in a file name $ dir red%%%.dat would match any six character file, the name of which started with red with the extension .DAT, so that REDMAN.DAT would be displayed but not REDHEAD.DAT and not REDDEN.LIS '...' the elipsis is used to specify recursion thru subdirectories $ DIR [MYSTUFF...] would give you list of files in the directory [MYSTUFF] and all files in all sub-directories under the main directory Directory Used by itself, the directory command produces a multiple column report of file names (unless the file names are very long) but does not show size of the files or creation date, etc You can customize the directory command using DCL symbols: $ DIR :== DIRECTORY/SIZE/DATE/WIDTH=FILE=40 With this command, you would get a single column list of file names, along with their size (in blocks) and the file creation date and this display occupies the width of my screen without wrapping Under VMS, the size of a file is displayed in disk blocks, at 512 bytes per block. A file of size 4 is actually using 1024 bytes. You can see both allocated and used blocks with the /size=all qualifier. By way of a summary, the directory command gives the total number of blocks occupied by the specified files; it also gives the file count. !================================= EDITORS =================================! Several editors are bundled with VMS, but EDT and EVE are the ones that most people use. EVE is a memory hog and has a steeper learning curve, but is very powerful and well worth the effort to learn. To edit a file using EVE, enter a command similar to the following. $ EDIT/TPU login.com The edt editor is probably easier to get started with. To edit a file using EDT, use the a command similar to the following. $ EDIT/EDT file_name.ext $ EDIT/EDT login.com Once in EDT, you can get help at the command line prompt. While in the editor, if you have a '*' on line 23, you are in command line mode; type 'C' to enter full screen mode; if you are in full screen mode, ctrl/z will take you to the command line. '*exit' exits the editor and saves the file; '*quit' quits without saving. In full screen mode, you have advantage of the 'edt keypad' for text manipulation and navigation. This keypad is a standard set of key bindings which have become very popular in the VAX programming community. To see a map of the keypad, press PF2 key on the keypad (top row, 2nd key). Yes, there is a learning curve associated with the edt keypad, but it is well worth the effort because it is well thought out and consistent and both EDT and EVE use it. EDT is the old style editor (there are older ones) which has been around since VMS 3.0 (I think). EVE is written in TPU which is is the newer style editor which has a callable interface and is widely used in application software and utilities. Technically, EVE is an implementation of TPU. The relationship between TPU and EVE can be a little confusing to a new user. TPU (Text Processing Utility) is sort of like a programming language for writing editors. EVE (Extensible Versatile Editor) is an editor written in TPU; you invoke eve with the command $ EDIT/TPU/SECTION=SYS$SHARE:EVE$SECTION file_to_edit.ext Since the EDT keypad was so popular, Digital has emulated the EDT keypad in the EVE editor, although EVE has it's own standard keypad. After you learn how, you can customize the editor to suit yourself. Note: there are two large manuals dedicated to TPU programming. Effective programming in TPU is not trivial. In fact both the VMS editors (TPU and EDT) are so popular that there are PC-based emulations. Boston Business Computing, makes a PC-based EDT emultator which is first class and sells for $200+. Another firm, a/Soft Development, Inc makes a TPU emulator, nu/TPU, that sells for around $300. I have used BBC's EDT and can recommend it; I have not used nu/TPU. !============================= LOGICAL NAMES ===============================! An important use for logicals is to help make programs device independent. As an example, say your program references a file by the logical name MYDATA and you have defined MYDATA to reference DUA1:[MYDIR]MYDATA.DAT. If DUA1 crashes and your data is restored to DUA2, all you would change is the logical name; you would not have to recompile the program. Do not make the mistake of trivializing the importance of the use of logicals in the VMS world becuase of the simplicity of the following example: Here are the steps you would take to make a programm using mydata.dat device independent. -- create a logical name using the define command: $ DEFINE mydata dua1:[mydir]mydata.dat -- better yet, define your directory as a logical name, then define logical names of all your data files in terms of the directory logical name: $ define mydir dua1:[mydir] $ define mydata mydir:mydata.dat $ define stuff mydir:myjunk.dat using this approach, if dua1 crashed and your data were restored to to DUA2, you would have to change only one logical: mydir. The same approach works for sub-directory trees; if you are like me and are addicted to organizing using sub-directories, you can use logicals to great advantage: $ define mydisk dua1: $ define mydir mydisk:[mydir] $ define myroot "''f$trnlnm("mydisk")'[mydir.]" /trans=(conc,term) $ define mysub myroot:[sub] ! where sub is dua1:[mydir.sub] $ define substuff mysub:stuff.dat ! dua1:[mydir.sub]stuff.dat -- in this example, if you moved to another disk, you need change only the logical MYDISK to point to the new disk; everything else would work unmodified; -- Note the different way in which the logical MYROOT is defined. This 'rooted logical' is used as a device name to address sub-directories nested under [mydir]. Logical names are kept in logical name tables. Commonly used logical name tables are Process, Group and System name tables. Although you can define your own tables, the default tables mentioned here are nearly always sufficient. When you create a logical name it is inserted in a logical name table. The non-privileged logicals that you define are inserted by default in the process logical name table. These logicals go away when you logout. However, the group and system logicals are permanent (as long as the machine is up); they are usually created at boot time. Process logicals can be defined in your login.com so they will be created when you login. Concerning privileges and logical names: You can define your own logical names (and logical name tables) at the process level. However, to define system-level or group-level logicals, you must have the privileges SYSNAM and GRPNAM, respectively. -- to see what logicals are 'out there' use a command similar to one of the following (output can be voluminous!), then type the .lis file. -- $ sho logical /process /out=process_logicals.lis -- $ sho logical /system /out=system_logicals.lis -- to delete a logical name, use the DEASSIGN command $ deassign MYDIR One important characteristic of logical names is their ability to 'mask' each other. If a group or system logical name exists and you define the same logical name at the process level, the process level logical will mask the group logical name. For example, say the group level logical CORPORATE_STUFF is defined to point to dua12:[corporate]stuff.dat. But you are testing a program and want to use test data, so you $ define CORPORATE_STUFF mydir:my.stuff Then use the following commands: $ sho logical CORPORATE_STUFF ! shows both logicals (group and process) $ dir corporate_stuff ! show mydir:my.stuff, the process level When dealing with a logical name defined at multiple levels, the command <$ show trans corporate_stuff> will show which of the logical name translations will be used by your program. !================================ SYMBOLS ==================================! Symbols are created using one of four assignment operators: "=", ":=", "==", and ":==". Use of double equal signs creates global symbols. Use of a single equal sign creates a local symbol. A local symbol will mask a global symbol of the same name. = defines a symbolic name for a character string or integer := defines a symbolic name for a character string. Examples $ one = 1 ! a local symbol with an arithmetic value of one $ one == 1 ! a global symbol with an arithmetic value of one $ one = "One or the other" ! one is now a character string $ one :== One more to go ! is global $ one := One final thing ! one can also be defined this way Note that the symbol "ONE" is of whatever data type required. If you get confused, you can always use the lexical f$type() to find out whether a literal is an integer or a string. You can get with < $ help lexical f$type >. For the most part, when defining character string symbols, it does not seem to matter whether you use the '=' or the ':=' assignment operator. However, if you want to overlay character string values, use the := assignment operator. If you want to overlay bit fields in an arithmetic symbol, use the '=' operator. See the manual DCL concepts for more info. You can do math using symbols at the dcl prompt: $ A = 1 $ B = 2 $ write sys$output A + B 3 Define the escape symbol: $ ESC[0,8] == %X1B Define booleans $ true == ( 1 .EQ. 1) $ false == ( .not. true) !========================== PRINT AND BATCH QUEUES =========================! The VMS User's Manual has a good introduction to using print and batch queueus. The VMS System Manager's Manual contains information on setting up queues. There are three kinds of queues under VMS: -- print queues which direct printout to a specific print device -- batch queues which execute programs (a.k.a. execution queues) -- generic queues which send jobs to print or batch queues generic queues feed other queues; an example would be in a large VAX cluster which had many execution queues on several nodes; the generic queue (SYS$BATCH) would direct jobs to an empty execution queue on some machine; if all queues were full, it would hold the job until a place could be found for it; users would submit their batch job to the generic queue (sys$batch) and not even need to know the names of other queues Print Queues And Printing Print queues are used to direct output to a print device. A separate queue is associated with each physical device. By specifying a particular queue name, the print job is directed to that printer. By default, the queue SYS$PRINT is associated with the default system printer, which on multi-user VAX's is (usually) a high-speed line printer. Print queues are a way of sharing hardware among multiple users and of having the operating system control certain aspects of the prining process, such as timing. To print a file, use a command similar to the following: $ PRINT file.ext [/queue=que_name ] If you are in a larger shop with several printers, you can direct the job to a specific queue using the /queue=queue_name qualifier where queue_name would be the name of the specific queue you wanted your job to print on. To see which queues are available for printing: < $ SHO QUE /DEVICE > If you use a particular queue frequently, you may want to assign sys$print to that queue; then you won't have to specify the queue each time you want to print a job. The job will automatically go to that queue, in this case print_10 is the queue name. $ define sys$print print_10 Batch Queues Batch queues are used to execute DCL command procedures non-interactively in a separate process. Batching allows you to schedule a job for execution at times when it would be inconvenient for you to execute the job interactively; or to execute a large job without tying up your terminal. For example, an engineer would use batch to execute a long-running simulation. An accountant would use batch to run general ledger at a specific time. When you are very busy batch is handy for doing two things at once, one interactively and the other batch. To create a batch job, create a DCL command procedure which contains the commands exactly as you would type them at the terminal if you were executing interactively. Create the command procedure using a text editor. Each command must be preceeded by a '$' dollar sign, usually in col 1, but position is not a requirement. The '!' exclamation point is a comment character; everything appearing to the right of ! is a comment and is ignored. As an example, say that you entered the following into the file BIGJOB.COM. $ set verify ! display commands in log file as they execute $ run simulation ! simulation is name of the executable pgm $ print simulate.lis ! print results You would then $ SUBMIT BIGJOB /queue=sys$batch /log /after=21:00 which would tell VMS to execute the job starting at nine p.m., create a log file (which goes in your default directory (SYS$LOGIN)). At the appointed time, VMS would login to the system as you and execute your command file BIGJOB. All output from the execution (what you would see on your screen had you executed interactively) would be captured in the log file SYS$LOGIN:BIGJOB.LOG. Unless you specify otherwise, the default location of batch logs is your default (home) directory, a.k.a. SYS$LOGIN. You can then type the log and view the results. Of course, the example is trivial and is just intended to get you started. You can include all kinds of conditional control, error trapping, etc in your batch job; you can make the job dependent upon the successful completion of other jobs, or on the presence (or absence) of certain critical files. See the DCL manual (part of VMS Systems Documentation) for further information on writing DCL command procedures. To see which batch queues are available on the system, $ sho que /batch Queue Entries When you submit a batch or print job, VMS creates a queue entry and displays a unique entry number for that job. You can manipulate the job using the job number with the following commands: $ sho entry ! shows any of your jobs (batch or print) in the system $ sho entry /full nnn ! more detail on job number nnn $ delete /entry nnn ! get rid of the job before or during execution !============================= THE VMS PROCESS =============================! This section explains the concept of a VMS Process Understanding Process Context Although a VAX is a single computer, one of its most important features is its ability to permit multiple users simultaneous access, to handle multiple processes at the same time, and give everyone the impression that they have (almost) exclusive use of the machine. When you login to a VAX, a new process is created and you do your work within the context of this process. It appears to you that you have exclusive use of the machine. If 20 users are logged into node BOSTON, each user has the impression that he has exclusive use of the machine because the operating system switches context from one process to the other, in round robin fashion, 'giving everyone a turn'. Each process has address space in memory, a hardware and a software context. The operating system protects each process from actions of other processes. When you logout, the process is destroyed and allocated resources (memory, etc) are returned to the operating system for other use. -- To see all process on your particular node: < $ show system > this will show both system and user processes -- to see your process: < $ show process > or < $ show process /all > -- to see other users on the system: < $ sho users > Understanding Process Privileges and Resources: The VMS operating system controls utilization of system resources at the process level. When an account is set up for you on a VAX, you are granted the right to use a certain amount of system resources and privilges to do certain things. For example, if the system manager has implemented quotas on CPU time, you can consume only a limited number of CPU minutes. If you run a CPU hog and consume all your time, you are logged out. CPU time is a resource. On the other hand, you may need to edit a large file but if your PGFLQUO (virtual memory) is too small, you may not be able to. You may consume up to a limit, but won't be logged out. You may want to look at the payroll files and check out other people's salary. Unless you have been granted the BYPASS privilege, you can't look at files that don't belong to you. BYPASS is an example of a privilege. Most user's are not given BYPASS because you can destroy the system and user files with it... i.e., delete the operating system. !=============================== VMS SECURITY =============================! VMS security is implemented using two basic mechanisms: UIC protection masks (the original method) and ACL's UIC Code A uic (user id code) is a two part number assigned to every account on the VAX. In numeric form, the number is expressed as a pair of comma-separated digits, enclosed in brackets: [113,12]. The first number specifies the group the second number specifies the member within the group. If accounts are set up properly, the UIC codes are unique, i.e. no two accounts have the same UIC. The UIC number is the basis for recording accounting information in the accounting file and for security and audit tracability. Normally, you do not see the UIC code in its numeric format; you see it in a translated string format. To see your UIC, < $ show proc >. The field titled "User Identifier" is your UIC. The first member of the pair is your Group, the second member of the pair is your Username. UIC-based Protection Originally, VMS security was implemented via UIC protection masks. This discussion will focus on how UIC protection is implemented on files, although other objects (such as batch and print queues) can also have UIC-based protections. Every file has an owner, normally the person who created it. To see ownership of files in your directory: <$ directory/owner *.*> UIC based-access is controlled in terms of how other users are 'related' to the file owner by their UIC codes. Relationships to the owner are expressed in terms of Owner, Group, World and System. Any user with same group uic is in your group. Everyone else is world. System is any uic in the group range 1-10 (this range can be changed by the system manager). There are four kinds of file access: Read, Write, Execute, and Delete. Each type of access is expressed as a mask for the System, Owner, Group, and World, in that order. To see file protection: <$ directory/prot > The protection mask is displayed in four masks, with various combinations of R, W, E, and D. You may see something like MYFILE.COM (R,RWED,RWE,E) This means that System (the first mask) has Read priv on the file. The second mask is owner who has Read, Write, Execute and Delete privilege. The third mask is the group and has Read, Write and Execute priv, but not Delete. The fourth mask has Execute only priv. To change protection, use the set file /protection command: $ set file /prot=(o:rwe,g:re,w:re) This would remove the owner's delete priv and remove write access to the group and grant read access to the world. ACL-based Protection ACL-based protection is more complex and more flexable than UIC- based protection. Let's take a simple example. Say that you are in the manufaturing group and you need to see the Approved Vendor file maintained by the purchasing group. Since manufacturing and purchasing are in separate groups, under UIC-based security, you cannot see each other's files. In order for you to see the Approved Vendor file, purchasing would have to grant 'world-read' access to the file; but then everyone could see it. By taking advantage of VMS's using ACL-based protection, purchasing can grant read access to you specifically. How does ACL-based protection work? When your account is created on the VAX, you are assigned a unique rights-identifier, sort of like an id-number, or social security number. When you login to the VAX, this rights-id is automatically associated with your process. Nearly every VMS system object (files, queues, etc) can have associated a list of identifiers with associated with it; this list is the ACL for that object, or ACL The ACL grants privileges to users who attempt to access the object. Privileges are similar to those under UIC-based protection, only more extensive: Read, Write, Execute, Delete, Control, etc. To grant you privilege to see the Approved Vendor list, purchasing adds your rights-id to the ACL of the file with read access. Your id and it's associated privileges are termed an ACE or Access Control Entry. The ACL is the list of all ACE's associated with a particular object, in this case the Approved Vendor file. When you attempt to read a file, VMS checks to see if you have an ACE in the ACL, it then grants you access to the file based on that ACE. You can read the file. If there are many people who need read access to the Approved Vendor file, purchasing could take a different approach. They could have the security manager create a specific identifier for their file. Say APVEND_READ. They would then create an ACE for APVEND_READ in the Approved Vendor file ACL. Then the security manager could grant you and any other users who needed read access to the file the APVEND_READ identifier. Anyone who had the APVEND_READ identifier could read the file. This approach would keep the number of ACE's in the ACL small and reduce system overhead. !============================ PERFORMANCE MONITERING =======================! To examine performance on a running system, see System Manager's doc set. To monitor processes, io, memory, locks, etc, check out the Monitor utility: <$ help monitor>. To determine how system resources have been used on a by-user or by-image basis, check out the accounting utility <$ help accounting>; this is how you can tell which images a particular user runs. how much CPU time they use, number of batch or print jobs, etc. If you need info on how the o/s is performing check out VPA <$ help advise> and SPM <$ help perform>. Note that VPA and SPM are being replaced by DECps in the very near future. Use the show command <$ help show> to examine the current state of system objects: show memory, sho system, sho process, sho users, etc. Use the analyze command <$ help analyze> for info on how to analyze various system objects: files, disks, the system, crash dumps, process dumps, images, objects, etc. If your VAX shop has Software Support, you can phone the Customer Support Center anytime day or night (24 x 7 x 52) with questions. The folks at CSC are excellent, well trained professionals. With Software Support, you also have free access to DSNlink. With DSNlink, you can reasearch problems or questions in the various databases, which are specific to each product (i.e., VMS, fortran, etc). You can also submit service requests and recieve responses via electronic mail. Check with the system manager and see if you can access DSNlink. !============================ VMS DOCUMENTATION ============================! This Section gives an overview of some of the more important documentation that is available for the VAX. In 1992, Digital made substantial changes in their hardware product lines and made VMS an open operating system. Consequently, some of the document titles mentioned here may be changed. The staff at DECdirect 1-800-344-4825 can assist you in getting the appropriate documentation. VMS User's Manual AA-LA98B Introduces the concepts, procedures and commands necessary to get started using VMS. It explains how to login, what a process and privileges are, introduces logical names, symbols, and the file and directory system, explains how to use the EDT and EVE editors, and the more common utilities such as RUNOFF, MAIL, PHONE, SORT. VMS System Manager's Manual AA-LA00B Explains the fundamentals of VMS system management (administration), how to set up and maintain a system. VMS System Documentation This is the so called 'Gray Wall'. You can purchase the whole doc set or sub-kits (below) or individual manuals. The 'Gray Wall' does not include documentation for layered products which must be purchased separately. -- VMS Extended Doc Set QA-001AA $ 2,244 Consists of the three sub kits listed below; -- VMS General User Sub Kit: QA-001A1 $536 - six volumes (10 manuals) - Intro to VMS, Guide to using VMS, Guide to Files and Devices - Mail, Phone and sort utilities, - The two primary editors, EDT and EVE - The DCL manual and guide to writing DCL procedures - The System Messages and Recovery Manuals which help interpret error messages from the system; -- VMS Programming Sub Kit: QA-001A3 $1,122 - ten volumes (18 manuals) - The Run-time Library (math, general purpose, parallel processing, strings, screen management, etc) - System Routines, Utility Routines, System Services - The File System, Rms and I/O User's Guide - The Linker, The Librarian, The Debugger - Guide To Programming Resources and Guide to Modular Procedures which are sort of the intro to how program on the VAX; -- VMS System Management SubKit: QA-001A2 $434 - ten volumes (16 manuals) DecDirect DECdirect is Digital's Direct Mail Service. You can purchase all of the documentation mentioned from DECdirect; many items are available gratis. The voice line is 1-800-344-4825, then select item 2 for 'Pre-purchase information' who are the folks help you figure out what to order. They will also send you free-bee's (listed below) for the asking. Digital also has an Electronic Store where you can login remotely and computer shop, the number is 1-800-234-1998 and you need a VTxxx (i.e, DEC) terminal. The following items can be obtained from DECdirect, gratis. Some of the names may have changed slightly because of Dec's switch to a more 'open' approach. -- VMS Handbook Describes VMS operating system features and integrated software products. The 'official' bird's eye view of VMS. -- VMS Architecture Handbook Technical description of the VMS operating system. -- VMS Hardware Handbook Technical overview and description of members of the VAX family of computers. -- VMS Software Handbook Describes the VMS operating system, system services and routines, and optional SIP (System Integrated Products). -- Harware Catalog, a slick glossy which has most of the current hardware offerings; VAX's, workstations, PC's, printers, disks, tapes, memory, cables, bridges, routers servers, etc. -- Software Catalog: another slick glossy with most of the software offerings, including some third party stuff. -- Ed Services Catalog, a slick glossy, with courses covering everything from soup to nuts; on-site and off-site seminars as well as self-paced materials -- Network and Communication Buyer's Guide: A technical catalog of network related items. -- VAX VMS Software Source Book: (Technical) Abstract-like descriptions of products; includes both Digital and Third Party software; listed by application and by industry -- Digital Systems and Options Catalog: the technical hardware catalog for processors and accessories; Alphas, VAX's, PC's workstations, CRAY's, Cluster and networking options, controllers, servers, disks, tapes, terminals, printers -- US Software Price List (Technical) Helpful publications from Digital Press Many of these items can be found at larger bookstores. All can be ordered thru DECdirect: -- VMS User's Guide $30 -- VAX/VMS Operating System Concepts $45 -- Beginner's Guide to VAX/VMS Utilities and Applications $30 -- VAX VMS Writing Real Programs in DCL $30 -- VAX/VMS Internals and Data Structures $ 125 -- VMS File System Internals $ 50 -- VAXcluster Principles $50 -- Alpha Architecture Reference Manual $35 -- alpha is DEC's 64-bit risc architecture -- VMS for Alpha Platforms, 3 vols $ 30 /ea -- Digital Network Architecture (Phase V) General Description (part of a larger series on DNA) Other Publications: -- Introduction to VAX/VMS, 3rd Ed by Bynon and Shannon -- Mastering VMS also by Bynon !============= Overview of VAX Software and Associated Services ============! VAX software falls into one of two catagories: bundled with the operating system or layered onto the operating system. The layered products are things like compilers, specialized network software and applications. Layered products are purchased separately from the operating system. The most common and useful utilities come bundled with VMS: two excellent editors (edt and tpu), a text formatting utility (RUNOFF) the linker, debugger, disk and file analysis utilities, system dump analyzer and the native mode assembler (MACRO). The file sub system is RMS (Record management system) and provides sequential, relative and indexed files, as well as directory management features. Each of these utilities have their own separate manual; some, like TPU and MACRO, have multiple manuals and even commercial books written about them. Digital has a large number of layered products (thousands?) which it supports. There is also a large community of third-party software (and hardware) vendors whose products run on DEC platforms. DEC grew up supplying VAX's to the scientific / engineering community, like IBM grew up supplying crunch power to the business community. The U.S. Navy and NASA are big VAX users; so are the major oil and energy exploration companies. I vaguely recall hearing somewhere that the New York Stock Exchange runs on fault-tolerent VAX's. The point is Digital-supported and third-party supported software covers just about every type of application now. VMS supports many programming lanugages: Ada, Fortran VAXC, COBOL, Pascal, Macro, BASIC, Bliss: Browse through Volume one of the programmer's doc set, titled something like 'Programming Resource Guide', which shows you how to accomplish various programming tasks under VMS. For example: how to do task-to-task communication on the local node or with a process on a remote node. How to access VAXmail from within an application. How to create and maintain files. It also has examples of how to access system services, run-time libraries, callable utilities, etc from within the various programming languages. With the exception of MACRO (the native mode assembler), VMS programming languages are layered products (don't come with the basic o/s) and have their own documentation sets. If you are into commercial applications, the two database implementations are DBMS (that's the name of the product) and RDB/VMS. DBMS is being edged out by RDB but both are fully supported by DEC. They have just announced DBMS 6.0 which will have SQL support (RDB/VMS already does). RDB has API's for ms-dos, sun, etc. To see what layered products are installed on your system, scan the help display. For an overview of software available to run on the VAX, see the "VAX Software Handbook", the "Software Catalog" and the "VAX VMS Software Source Book"; all available gratis from DECdirect (1-800-DIGITAL). -- Software which runs on the VAX have are several associated items: a license, distribution media, documentation, software support, and documentation upgrades. These items can be purchased as a unit or separately. The only thing you must purchase to actually run the software is the license. -- All DEC software is licensed. You don't actually purchase the software, you purchase a license which gives you the right to use the software. separate VMS software licenses are purchased for each processor or node. The cost of the license depends on the size of the CPU, or in the case of a cluster, the total power of the cluster (Measured in VUPS, or the processing power of an 11/780 ... the first VAX). The software license is a one-time expense. If a software product requires a license, the O/S will not allow that product to run if the license is not loaded. -- Layered Product Support Service is DEC's telephone support, billed by the month. Software upgrades and patches are included in the service and come automatically. Another feature of this service DSNlink, an electronic link with the Customer Support Center (CSC) which enables you to log service requests and recieve responses by e-mail (thus avoiding phone-tag). On-line databases are also available to you for research. If you have DSNlink, you can download patches electronically. In fact, if you have DSNlink, you can have Digital automatically notify you about bugs or problems they discover. -- Software Documentation: these are the manuals associated with each product and can be purchased separately from the license and media. Note: you can get a kit consisting of the license, documentation, and installation media (the tape with the binaries). This is a one-time expense as the license allows you to use the software indefinitely. -- Documentation update service: A subscription service associated with each product which updates the documentation. The updates range from replacement pages to whole new sets of manuals, depending on the product and update. When a new version of the software comes out, you get a new set of manuals with this service. Billed by the month. -- Software License A Digital software license consists of encrypted information which must be loaded into the system before the software will run. When you purchase a software license from DEC or a third party, you generally recieve a fancy piece of paper and have to enter license information into the LMF (License Management Facility) database. Although DEC gives you some utilities to manage the license database with, having to manage licenses can be a headache. Naturally the primary reason for licensing software is to protect Digital's financial interests, but users also benefit in that DEC now distributes most of their software on CDROM because they can control it's use thru use of licenses. -- Consolidated Distribution (CONDIST) Subscription to this service brings (nearly) all new software releases to you on CD-ROMs on a quarterly basis. If you have a CDROM reader, you can read the release notes, spd's etc on new products. You can also get a temporary license and test drive the software before you purchase it.