Home

Titanic

Free Software

C Course

C++ STL Course

VMS VAX VMS Systems Alpha VMS Systems BBC Micro :-) VMS Tutorial RWAST Windows NT Unix Yezerski Roper VMS Web Links Bibliography

Motif

Marian's Page

Links

E-Mail

© 1996-2005
Phil Ottewell

Phil's VMS Tutorial

Introduction

Just to answer two FAQs (Frequently Asked Questions) I will tell you right up front that

• VMS stand for Virtual Memory System, and
• OpenVMS is absolutely no different to VMS. It was just a marketing name change to reflect the Posix support in VMS. Hence I will sometimes say VMS, and sometimes say OpenVMS.
• In Alpha AXP the AXP does not stand for anything. It's just that you can't copyright a Greek letter, so DEC added AXP.
• VAX stands for Virtual Address eXtension.

Having followed the examples in this guide you should be able to start using VMS productively, and know enough to decide which FM to R (as in RTFM, or Read The Flipping Manual). However, it is essential to actually try the examples, and attempt the exercises (solutions at the end) in order to get firm grasp of the basics.

If you want to get a VMS system for hobbyist use, go to The OpenVMS Hobbyist site to get the free licenses, including VMS and layered products like C, C++, clustering, Fortran, Motif and much more. You should be able to pick up a cheap second hand VAX or Alpha by searching the internet, or get a brand new Alpha au series VMS compatible computer for for $599 from Island Computers under their "Specials" section. Ask for David Turner and tell him Phil sent you!

Nemonix Engineering also specialize in hardware, software and repair of VMS systems, maintenance, and hardware upgrades. They will diagnose any board for a flat fee of $50, plus you pay the freight. Business from hobbyist VMS systems is welcome. See Nemonix Engineering Web Site, ask for Roger Boyle and mention my web site.

This document refers to VMS V6.2 onwards for VAX and Alpha, making the few differences on behaviour clear as it goes along. In case you were wondering, VAX stands for Virtual Address eXtension. Alpha AXP doesn't actually mean anything, but you can't copyright Greek letters. I have described logging on to "dumb terminals" and to workstations, though the workstation is assumed to be using the "DECwindows Session" style screen rather than the "New Desktop" CDE interface.

The operating system documentation provides several excellent introductory guides to VMS, including the VMS Primer, and

• OpenVMS User's Manual
• Introduction to VMS
• The DCL Dictionary
• Guide to Using DCL and Command Procedures on VMS
• Extensible Versatile Editor Reference Manual
• OpenVMS Debugger Manual
• Compaq Fortran User Manual for OpenVMS Alpha Systems
• Compaq C Runtime Library Reference Manual
• Using Compaq C++ Manual

Most of these books are available on the Online Documentation CDs that your system manager should have made available to you. They are normally mounted so that they are visible from all machines in a VMS Cluster, and you can read them by using Bookreader on a workstation, or the freeware MGBOOK on a text terminal. A good book to get beginners going is The VMS User's Guide by James F. Peters and Patrick J. Holmay

The documentation is also available on the internet, courtesy of HP/Compaq at http://www.openvms.compaq.com:8000/

Other highly recommended books for Fortran, C and C++ programmers are Michael Metcalf and John Reid's Fortran 90/95 Explained, The C Programming Language (ANSI C edition) by Brian W. Kernighan and Dennis M. Ritchie, Expert C Programming - Deep C Secrets by Peter Van Der Linden The C++ Programming Language (3rd Edition) by Bjarne Stroustrup, Effective C++ and More Effective C++ by Scott Meyers.

In the following text, I shall use the symbols for the CONTROL (or similar) key on the terminal keyboard. It must be held down together with the additional character specified, i.e. means: hold down and keep it held down whilst you press and release the letter A . For carriage return, I shall use (not always specified). [...] means that the parameter in brackets is optional, and may be missed off. Things typed in by the user in response to system prompts are shown in bold letters LIKE THIS after the $ system prompt (which the computer sends to the screen). For example,

$ DIR 

means that after the $ prompt appears on the terminal, the user enters the letters D, I and R then presses the key.

§1 Hardware and Software

Since this tutorials is aimed at newbies, I'm going to talk about hardware and software. More experienced users should nip off for a coffee break and come back in a few minutes. The hardware is the actual electronics and physical devices like printers, disk drives, memory and so forth which comprise the computer system you are using. The software is the set of programs, or instructions, which are executed or run by the computer hardware.

A typical VMS cluster system will consist of Digital VAX and/or Alpha computers which communicate with each other via an Ethernet link (a standard type of network connection) to form a Local Area VMScluster. Whichever machine you log on to within the VMScluster, you will be left in your own personal file directory (directory in VMS-speak == folder in PC speak), and the software environment will be almost identical. In other words, on the whole, your files, commands and devices will look the same whichever member of the cluster you log on to. A list of the VMScluster machines can be obtained by entering the SHOW CLUSTER command. The machines on the DECnet network can be determined by typing SHOW NETWORK on a "routing node". If you aren't logged on to a routing node then this command will tell you what the routing node is for your machine, then you can try that.

In a development environment, system software would be likely to include:

• The VMS operating system, which looks after the machine's hardware, checks whether you are authorized to perform certain actions like accessing files and devices, and allows you to run programs, submit batch jobs and manage your files.
• DECnet
• TCP/IP (could be DEC's UCX, or 3rd party like Multinet or CMU/IP)
• DEC Fortran
• DEC C
• DEC C++
• X11 and Motif for graphical (GUI) applications, and maybe some freeware like XPaint and XV.
• DECForms or DEC FMS for terminal based applications
• A choice of text editors, like the built-in TPU, EDT and TECO, or freeware editors like VI and Emacs.

§2 How to login

This is important :-) You won't get far at all until you log in, which makes you known to the system as an authorized user. I'm assuming here that you have seen your system manager, that he or she has issued you with a valid username and password combination, and warned you not to reveal this information to anyone. Guard it like you would your credit card and PIN number !

2.1 Logging in via a Terminal Server

If using a "dumb terminal" like a VT420, this would typically be connected to a terminal server. This a box which allows your terminal to connect to any of the local computers, rather like a local telephone switchboard. Ideally, you should use a DEC VT type terminal, eg. a VT220, VT420, VT520 or compatible, which will make it much easier to use certain facilities on VMS.

First get the attention of the terminal server by pressing the key followed by a number of 's until you get the prompt Local> , to which you should reply CONNECT name_of_machine.

 (hold
for about a second)


Local> CONNECT YR1 

If you do not get the Local> prompt after pressing return a few times hold the <Break> key for another second and press a few more times until you are successful.

At this point, a welcome message of some sort should appear and you can proceed as if your terminal was directly connected, as described below, except that you should miss out the step, because the Username: prompt will already be there for you.

2.2 Logging in from a directly connected terminal

If the terminal you are using is directly connected to the VMS machine, rather than a terminal server, then you will get a brief site-specific welcome message (probably accompanied by dire threats about unauthorized access) followed by the Username: prompt after your first Break-Return.

*** BigCorp VMS Cluster *** Node TINY, a VAXstation 4000-VLC on VMS V7.2 - No Unauthorized Access Username: FRED Password: [enter your password here - you won't be able to see it]

Just try again if you see that, but be aware that if you have more than three or four failures in a row you may need to see the system manager, because VMS might suspect that you are an intruder!

2.3 Logging in to a VMS Graphics Workstation

If you are using a VMS workstation you should see a login box, similar to the one on the right, inviting you to enter your username and password. If you can't see such a box, check that the workstation base unit and the monitor are switched on (being careful not to switch them off in the process of looking), and try moving the mouse to wake up the screensaver, which may have cut in to blank the screen during idle periods. If you still can't see the login box, get help before proceeding any further. Once you have the login box, enter your username and password as described below.

Type in your username in the Username: box (workstation) or after the Username: prompt (dumb terminal). Press the key after entering your username. The terminal should then prompt for your password, and the workstation will move the flashing input cursor down to the password box. Type in your password. You will notice that your password is not displayed on the screen, even though the computer is receiving the letters that you are typing. This is a security feature to prevent other people obtaining your password by looking over your shoulder. I will say more about choosing passwords later.

Alpha machines may use the CDE, or Common Desktop Environment rather than the old style DECwindows one, so the login screen will look slightly different (I'll add a picture of that when I get chance) but the username and password are entered in much the same way. The CDE environment is fairly different though, so you should look at the Common Desktop Environment: User's Guide on the Compaq web site. Once you have a DECterm up though, the commands in this tutorial all work exactly the same as they do in the older environment.

Username SHADRACK 
Password BILLYLIAR  (not echoed)

The session proper will then start. If you have correctly entered everything, you will receive certain messages about the system as logging in proceeds, and the system manager will most likely have provided you with a personal login file, probably called LOGIN.COM. Your LOGIN.COM file is executed automatically by the system whenever you log in. The computer will most likely gives you a welcome message identifying itself (take note of these details in case you have to ask for help), and possibly tell you who else is currently logged on to the same computer. When login is complete, a text terminal will display a "command prompt" something like this

$

If the system manager has set the prompt to be the machine name you might see something like

BIGVAX>

or

ALPHA1$

Ask your system manager what the DCL prompt should be for your system.

If you are using a workstation, then you will need to bring up a DECterm (a program on the workstation that emulates (looks a bit like) a terminal. If you don't see one, then bring up the "Session Manager" box by double-clicking on the Session Manager icon, which has a Yale-type key on it. When you've got the Session Manager, click on the "Applications" menu to bring that up, then click on "DECterm". After a few seconds, this will bring up a DECterm "terminal" and if you click on the face of it, you will be able to enter command just like you would on a physical terminal.

When you see the correct prompt, it means that DCL, Digital Command Language, the VMS command line interpreter, is ready to accept commands from you. As I've said already, the DCL prompt will generally be the $ dollar sign, or the node name (the name by which the computer is known to the network) followed by a dollar or > sign. The first time you ever log in, and every few months you are forced to change your password as you log in. Use the SET PASSWORD command if you wish to change it in between.

Important: You may log in more than once under the same username. Normally you would not do this (it is rather antisocial, since more users slow down the machine), but it might be useful if, for example, you wanted to STOP a program that was stuck in an infinite loop. Having more than once is not so antisocial if you are using a workstation, and generally you would create several DECterms from the Session Manager's Applications menu, and switch between them by either clicking on the DECterm you want, or using (that is, pressing and releasing the Tab key whilst holding down the "Alt Function" key next to the space bar) to cycle round the windows on your "desktop". The term "desktop" here refers to your computer monitor's screen, not your actual desktop :-)

Now you've logged in, you're probably exhausted with excitement, and want to log off again and have a lie down before continuing. How do you log out ? To log out on a text terminal, enter

$ LOGOFF 

or simply

$ LO 

If you are on a workstation and you type this command into one of your DECterms, then that particular DECterm will disappear, but you will still be "logged on to the desktop" as it were. To completely log out of the workstation, bring up the session manager (remember, double click on the key icon if you can't see the session manager), then choose the "Session" menu. Click on "End Session". A box will pop up to confirm that you really do want to end the session (because you might lose work if you ended it accidentally), so click on the "Yes" button to completely log off the workstation. On the new CDE desktop, the little "Exit" button on the icon bar does the same thing.

Security Warning: never leave your terminal unattended whilst you are logged on, even if it is only for five minutes. Always log off if you are not actually using the computer. You should change your password occasionally, choosing some combination of letters which would not be easy for someone else to guess: do NOT use your own or your girl/boyfriend/wife/dog's name or anything to do with your home address etc., or any of these reversed. Try to include a number (not your age or house number) at the beginning or end of your password too. To change your password from the one given to you by the system manager just enter

$ SET PASSWORD 

and follow the prompts. Type HELP SET PASSWORD before you try the command and this will explain exactly what to do.

§3 The VMS Operating System

The VAX and Alpha machines run an operating system called VMS. Other operating system that you may have heard of include Windows NT and Unix. The operating system can be thought of as a special collection of programs which run on the VMS machines all the time, providing a more user friendly way to communicate with the computer. For example, if you want to save your program as a file on the computer's disks, you just specify the file name - you let the operating system worry about where, physically, to put the data on the disk. Similarly, when you retrieve a file, VMS knows where to find it given only the file specification. Another job done "behind the scenes" by VMS is switching between different `tasks' or `processes'. The Central Processing Unit ( CPU - the chip that carries out the instructions in a program) can actually only do one task at a time. So how come that on machines with only one CPU (you can have more) several people can be `logged on', things can be printing out and several programs can all apparently be running simultaneously ? The answer is that the VMS operating system is running the tasks in sequence, spending a short period of time on each one, then moving on to the next, and so on through all the tasks that are "runnable", then back round to the original task, and so on. It does this so fast that each task give the illusion of continuously running. Its a bit like a plate spinner running from plate to plate, giving each stick a shake to keep the plate going, continuously checking all the plates to see which ones need a spin next. The difference is that VMS processes, although they do occasionally fall over, rarely fall out of the machine and make a mess on the floor ;-|

The amount of time each process gets relative to the others depends, among other things, on the priority of the process. You can see what your priority is by entering

$ SHOW PROCESS/ALL 

which gives information about your process (you may have to use the Hold screen key key to stop the information scrolling off the screen). Normal user priority is 4, but certain system tasks have higher priority, and user batch jobs always have lower priority (1, 2 or 3 for long, medium or normal batch jobs) so that they use up spare CPU time with very little inconvenience to interactive users. Normal users can only set their priority, or that of their batch jobs, up to the base limit of 4. VMS also manages the batch job queues, allows the different VAX and Alphas in the cluster to talk to each other, and many other tasks of this nature. How do you talk to VMS ?

We tell VMS what to do using an English-like command language. The command language is called DCL. The user runs interactively, but may also submit batch jobs (see chapter 8). This means that normally you enter VMS commands (in the DCL language) from your terminal. If you start a program, or a system task, you have to wait for its execution to terminate. However, it is possible to interrupt a running program, execute something else, and then continue the previous one (see SPAWN command under Miscellaneous). The output will normally appear at the terminal. A list of all DCL commands can be found in reference 3.

The system prompts with a "node_name>" (eg. YRL>) sign if it is ready for the next command. You can type ahead, but the text will not appear at the terminal before VMS catches up. In general, the mode is full duplex, i.e. you can type in while output is written at your terminal.

One of the nice features of VMS is the HELP facility, which in many cases saves you having to consult the manual. In DCL, and most of the utility programs (see later), you can type HELP and will be presented with a list of further topics, like DCL commands. You can specify the command you want to know more about at the command line, thus:

$ HELP DIRECTORY 

HELP HINTS is probably a good start for the beginner, because it categorizes commands and features, e.g Contacting_people . In VMS, go for the most obvious command when looking up help. For example, if you want to know how to delete a file, HELP DELETE is the thing to type. VMS doesn't go for obscure names, like some Unix systems do. You are encouraged to make heavy use of the HELP facility.

Help Tip: when inside HELP, it will ask you for topic?, subtopic? or the like. To get out again, type for each level. Feel free to experiment and explore the system using the HELP command.

§4 Terminal Input and Output, DCL Commands

4.1 Line Editing

The terminal key which deletes the character immediately to the left of the cursor (flashing block or line) is an installation parameter. Under VMS it is , not Backspace or . To delete a complete line before you have pressed , use which deletes ALL the characters on the line to the left of the cursor position. Another useful `line editing' feature is . Pressing toggles the line between overwrite mode and insert mode, eg. you are trying to type in

$ SET DEF SYS$LOGIN 

but instead you type

$ SET DF SYS$LOGIN 

so to correct the line, BEFORE you press press the key until the cursor is over the "F" in "DF", press and then the letter "E" - the letters to the right of the cursor all move one space to the right to fit the "E" in. You can then press and your default directory will be set to your login directory.

To skip through output to your screen (while the program continues running !), type to continue again do another (but you will lose the output that has been produced in the meantime).

Output at your terminal will be in SCROLL mode. If you want to stop the program producing your output, in order to read it at leasure, type which will suspend the program output until you type to continue. Attention: after your commands will no longer be echoed!

On terminals where the key exists, it can be used to toggle between no scroll/scroll mode (equivalent to / ).

To abort any program (including system tasks), use . (This can be done with out risk). actually suspends the execution of the current program. When you type CONTINUE directly following, it will do so. The start of a new program then aborts the previous one (see, however, SPAWN).

4.2 DCL Commands

DCL commands are the main way you will communicate with the VMS operating system. You must be "at the DCL command prompt", normally the $ sign to enter a DCL command. Here are a few commpnly used commands.

$ SHOW TIME 
$ SET DEFAULT SYS$LOGIN: 
$ SHOW DEFAULT 
$ DIRECTORY 
$ HELP SHOW 
$ HELP SET 

The SET and SHOW commands have many options and are widely used. As there names suggest, SHOW is a "readonly" type of command that display something, whereas SET is used to change something, provided you have the privilege to do so, e.g. only privileged user can change the system time. As stated earlier, HELP will have information on all the built-in VMS commands, and you should get used to consulting the HELP system to find your way around.

DCL commands need normally not be spelled out entirely, any unambiguous abbreviation is allowed, so FOR will suffice for FORTRAN, R instead of RUN, and so on. However, if you type L hoping to LINK, you'll see the message

%DCL-W-ABVERB, ambiguous command verb - supply more characters
 \L\

When writing command files, however it is good practice to always use the full form of the commands. This will save many problems later on !

§5 Security

Some people regard it as an intellectual challenge to log on to a computer system which they are not authorized to use. These hackers can do a lot of damage to the system software, and may delete or corrupt all the users' files. If this happens it can take the system manager up to a week to restore the system and the user files, and even then some work may be lost, so it is very important to heed some basic principles of system security.

Change your password every month or so, taking note of the guidelines given earlier. When you log in, messages report the time of your last interactive log in, when your last batch job logged in, and whether there have been any unsuccessful attempts to log in to your account. If any of these look odd, like logins when you were definitely not there, or several unsuccessful login attempts which weren't due to you mis-typing your password, then change your password and contact the system manager (username SYSTEM) by MAIL and in person immediately if possible. Similarly if you suspect some of your files have been changed or deleted without your knowledge, or if you see a strange batch job or unfamiliar username logged on, inform the system manager as soon as possible.

It might be that there are perfectly innocent explanations - don't worry if this turns out to be the case - the system manager will not mind so long as you had genuine concern for security.

Another important thing to remember is NEVER put your password in a file on the VMS system, no matter how well you think it is protected, eg. never mention it in a MAIL or command file. This applies to passwords for other machines too. If you must write down your password on paper, do not write it in a form that is recognisable as a VMS password. Finally, under no circumstances should you reveal your password (or even username to outsiders) to anyone other than the system support people, and even then you should not mail or transmit it to them over the computer. Remember that hackers often pose as system support people or field engineers, so make sure that you know who you are really speaking to.

Finally, do not allow anyone else to use your account. The account has been created for your use and your use only. Anyone requiring the use of the VMScluster should come and see the system manager, who will decide if they have a reasonable case. Unauthorized use of your account could deprive legitimate users of resources and slow them down, and your password could end up known to anyone, creating a potentially disastrous security breach for which you could be responsible. Anyone allowing such use of their account, or attempting unauthorized actions on files belonging to the system or other users may have their account removed.

Following these guidelines will safeguard legitimate users, and benefit all of us in the long run.

§6 VMS Files and File Management

6.1 VMS File Specification

A VMS file specification consists of three parts:

1. physical or logical device name, like PDS$DISK:
2. directory or sub-directory, like [USER], or [USER.TEX]
3. the file name itself, which has the form: name.type;version

where name is an alphanumeric string of up to 40 characters, type is the file type (up to 40 characters), and v is the version number between 1 and 32767, e.g.

PROG.EXE;17, or TEST.TXT.1

The device and directory part are known as the pathname, and may be prefixed by nodename:: if they are on a different computer. It is very important to understand this scheme correctly, so read the following carefully.

Each user has defaults for the device name, and the directory. You may find out your current defaults by typing

$ SHOW DEFAULT 

This shows you the device and directory which VMS will assume if you specify a file name only. You may change the default, separately for the device name and the directory, using

$ SET DEF new_default 

If you enter a file name in any command without items 1 and 2, e.g. simply TEST.TXT , the system will precede the name by the default internally, and take the highest version number of the file.

6.2 Logical and Physical Devices

The physical devices are disks (or other devices, like tapes, not treated here), where the different files reside. The user need normally not know the name of these devices. Instead, he or she should always use logical device names, DEV$DISK:, SYS$LOGIN etc., which are accepted equally well in all file name specifications. The system may, however, prompt with the physical name. The advantage of using the logical names for devices is that if the device should be changed for any reason, the system manager will alter the logical name and the change will not affect those users sensible enough to use that logical name.

Any logical names which you ASSIGN or DEFINE are placed in a separate name table for your process only. These will disappear once you log off, so frequently used logical names should be assigned in your LOGIN.COM command file, adding a line of the form

$ ASSIGN/NOLOG DEV$DISK:[HORACE.MCARLO] MONTE$DIR: 

for example. Files in the DEV$DISK:[HORACE.MCARLO] directory could then be referred to as MONTE$DIR:filename.type;v . This is shorter, and has the advantage that if you move your files for any reason, you need only change one logical name and everything will work in the new directory.

The system logical names, for disks etc., are placed in the system logical name table which is created when the system is booted. These remain defined permanently.

To see what logical names are defined for you enter

$ SHOW LOGICAL 

(no surprises there !) or

$ SHOW LOGICAL SY* 

to see only the logical names beginning with th letters "SY", for example.

6.3 File type, and file assignment

The file type consists of any 40 alphanumeric characters. The system supports certain default file types - the complete list can be found in reference 3. Below is a list of common file types you should know:

It is highly recommended that you use these defaults to avoid confusion.

6.4 Why Use the Default File Types ?

The system expects certain default file types as I/O files to system tasks and user programs. These types are automatically appended to the file name if not specified. Therefore the answer is: standardization, and less typing.

Example:

The FORTRAN compiler expects file type FOR on input, and puts output on files LIS (listing), and files OBJ (object module). Suppose your source is on file TUT.FOR;1 (being the highest version number of that file). Then the command

$ FORTRAN/LIST TUT 

This command, equivalent to

$ FORTRAN/LIST=TUT.LIS/OBJECT=TUT.OBJ TUT.FOR

will compile file TUT.FOR , create a listing in file TUT.LIS, and the compiled output in file TUT.OBJ . Similarly, the linker will use a file of type OBJ as input, and produce an output file of type EXE, whereas the command RUN will expect a file type EXE as input.

Therefore, to compile and execute the above program, you type

$ FORTRAN TUT 
$ LINK TUT 
$ RUN TUT 

and off you go. If you do not happen to have a FORTRAN program of that name, do

$ COPY SYS$EXAMPLES:TUT.FOR TUT.FOR 

beforehand (and consider what this command might actually do).

In order to assign a file name to a FORTRAN logical unit, use

$ ASSIGN filename logical_unit 

as in the following example

$ ASSIGN DEV$DISK:[BOB]POSFILE.DAT FOR015 

where FORnnn is the "external" logical unit name for a program using unit nnn. To check which FORTRAN streams have been assigned you can enter

$ SHOW LOGICAL FOR* 

Dynamic allocation of files at run time is of course possible as well, e.g. in FORTRAN with the OPEN statement, but it makes the program more portable if you ASSIGN and DEASSIGN logical units in a command file which runs the program.

If you omit a specific assignment, the running FORTRAN program will get default file names assigned, which are FORnnn.DAT for each unit nnn. It is strongly advised that you write only to logical unit numbers, keeping the convention of ODD units for INPUT, and EVEN units for OUTPUT. Avoid using PRINT or WRITE(*,...) since these are system-dependent. It is better to use a private error logical unit assigned to an error log file, for example

$ ASSIGN INDATA.DAT FOR003 
$ ASSIGN RESULTS.LIS FOR006 
$ ASSIGN ERRORS.LIS FOR008 

then your FORTRAN program might be of the form

        .
      READ(3,'(6F10.4)',END=999) (ARRAY(I),I=1,6)
        .
        .
  999 WRITE(8,1001) IERR
 1001 FORMAT(1X,'End of file detected on unit 3, Error Number:',I4)

which would separate error messages from your program output.

6.5 Manipulating files, and WILD cards

In general, it is useful to look at all your files now and then, using the command

$ DIR 

You can delete a file by typing (after having run the above example)

$ DEL TUT.EXE;1 

(the ; is always necessary, but the version number may be omitted if you mean the highest version number) which will do it, and tell you so if your LOGIN.COM file defaults are set correctly.

A useful command is PURGE, e.g.

$ PURGE TUT.OBJ 

(without version number or ; ) which will delete all files TUT.OBJ except the highest version number. A qualifier allows you to specify how many versions to keep, counting from the top, e.g.

$ PURGE/KEEP=3 name.type 

will keep the three highest version numbers of the file specified. The system manager may occasionally purge everyone's files after a suitable warning, so early version numbers of files which you actually want to keep should be renamed with a different name and/or filetype, eg.

$ RENAME VITALFILE.FOR;2 VITALFILE.BAC 

Another nice concept is that of asterisks "*" and percent signs "%" in connection with file names, where an asterisk stands for "any alphanumeric string" and a "%" for "any alphanumeric character". A command containing this type of name specification is called a WILD card.

Examples:

$ PURGE *.* 

or just

$ PUR 

will delete all but the highest version number of all your files (it is good practise to do this from time to time).

The command

$ DIR *.COM 

will list all your files of file type COM,

$ DIR MY*.%%A 

will list all your files starting with `MY' and having a file type of three characters, the last one being `A'.

The asterisk does not replace full stops, so to check all of your sub-directories (enter HELP CREATE/DIR to find out how to create sub-directories) you type

$ DIR [...] 

which lists all of the files in ALL subdirectories of your account ( the number of full stops, three, is significant).

As you may have guessed by now, no file is ever deleted or replaced by the system, but a higher version is created instead. This makes the PURGE command so necessary if you are to avoid using up all of your disk space allocation, or `disk quota'.

§7 Editing

7.1 EDT

One of the full-screen editors available under VMS is called EDT. It works only on VT (i.e. DEC) series compatible terminals. To make it work properly on VT52-like terminals like the Pericom PA, you have to type SET TERMINAL NOSCROLL inside EDT as first command. Zenith and Cifer T5 terminals emulate VT100's.

To enter EDT, type

$ EDIT filespec 

and you should get the first page of text on the screen. If you only get a "*" prompt (the command mode), type CHANGE. To finish your edit type which will get you into command mode again. Type EXIT to save the file, QUIT to leave EDT without saving the file.

EDT is most useful if your terminal has function keys, which will actually allow the use of 32 different functions like `delete word' or `cut' and `paste' and so on.

Single corrections are particularly easy in full-screen mode, but for global changes it is more convenient to issue line-mode commands. See the EDT Reference Manual for more details.

It is possible to have certain line-mode commands executed automatically every time you enter the EDT editor. An example file of `editor startup' commands is SYS$MANAGER:EDTINI.EDT, which you might like to copy to your own directory using

$ COPY SYS$MANAGER:EDTINI.EDT SYS$LOGIN:* 

then in `interactive' part of your LOGIN.COM put the line

$ ED:==EDIT/EDT/COMMAND=SYS$LOGIN:EDTINI.EDT

then re-execute your login file by entering

$ SET DEF SYS$LOGIN: 
$ @LOGIN 

If you now enter the editor with ED filename it will automatically put you into the full screen mode.

Exercise :

Enter a small FORTRAN program with EDT, save it with the correct default file type, compile it with default name listing, link and run it. The program should print some output, which will appear on the screen.

7.2 TPU

TPU is a `Text Processing Utility', actually a language for writing text processing applications. Pressing the `DO' key and entering `SET KEYPAD EDT' makes TPU emulate EDT in many respects while allowing the user to define and compile additional procedures using TPU, rather than EDT commands. The important differences between `real' EDT and the TPU EDT Keypad Emulator are

1. TPU procedures.
2. TPU may be run from batch jobs.
3. may invalidate the journal file in TPU.
4. Different key definition syntax in TPU.
5. Only a subset of EDT line editing commands in TPU.

$ EDIT/TPU 

or else define a symbol, say `TPU', in your LOGIN.COM for this. It is recommended that most users change to the TPU editor as this will be the one that is supported in future releases of VMS.

§8 More File Manipulation

8.1 Printing files

To print a file on the default printer enter

$ PRINT filename 

from VMS. The command

$ TYPE filename 

will actually output the file to the screen, it being a hangover from the days of lineprinter terminals !

There is a DEC LN03 PLUS laser printer in the same room as the line printer. This has a large number of options, including graphics output, but entering

$ PRINT/FORM=1/QUEUE=SYS$LASER filespec 

is useful for general-purpose printing. Other form codes are available - type HELP FORM for details. You can check on the status of your print jobs using the command

$ SHOW QUEUE/ALL queue_name 

where queue_name is LASER for the laser printer, or SYS$PRINT for the line printer. Do not attempt to change the paper on the printers unless you know what you are doing, and always leave other peoples' output in a tidy state in the printer basket after collecting your own. This might sometimes mean stopping the printer, sorting out the mess of paper the re-starting it. Leave the printer in RUN mode, not STOP mode, i.e. online not offline.

8.2 File transfer between different VMS machines

When VAX and Alphas are clustered transfer is trivial. Certain disks on the different machines are available to all members of the cluster, and they have names of the form node_name$disk, eg. YR9$DKA300, YRL$DKA100, YRE$DKA400. You can see which disks are available using the SHOW DEVICE D command. To copy a file from user MORRISSEY's directory on DEV$DISK to use MARR's directory on PDS$DISK without changing the filename you would enter

Example:

$  COPY DEV$DISK:[MORRISSEY]TCM.TEX PDS$DISK:[MARR] 

There is usually no need for this sort of transfer, since you can access all the main disks from every cluster member anyway, though you might want your own copy of a file to modify.

When VAX or Alphas are not clustered, but are linked by DECnet as is often the case, file transfer over DECnet is achieved by a simple copy command, which looks like this:

$ COPY node_name1::from_file node_name2::to_file 

Note that the remote file specification must contain the DECnet node name in addition to the disk and directory name. The node name is followed by ::.

Example:

To copy a file called COMMAND.COM from directory DISK$USERS:[TEST] on a VAX or Alpha called VMS1, to your current default directory you would enter

$ COPY VMS1::DISK$USERS:[TEST]COMMAND.COM [] 

Try to avoid DECnet activity when there are a lot of interactive users on our system, because it can slow things down. Do your copying in an overnight batch job, for example.

Usually the system managers of the machines you use will have set up what is know as a DECnet proxy entry to allow you to copy easily, as in the above example. If this isn't the case, then you may have to specify your remote username and password when you do the copy. Imagine you were copying a local file called REPORT.TXT to a remote machine, DAKOTA, on which you had an account with username FARGO and password UBETCHAYAH. You place the username and password in quotes, between the username and the :: .

$ COPY REPORT.TXT DAKOTA"FARGO
UBETCHAYAH"::USER$DISK:[REPORTS] 

If you were to miss out the USER$DISK:[REPORTS] part of the destination specification, then the file would end up in FARGO's default login directory. It's quite easy to lose track of where files are going during a COPY, so it's a good idea to add the /LOG qualifier to the copy command so that you are told exactly where the file ended up ! You can probably see that specifying your password on the command line isn;t exactly the most secure way of doing things, so in general talk to your system manager about setting up a proxy if you need to do this sort of thing often. Remember to clear your terminal (e.g. turn it off then on again after you've logged out) when you've done so that you don't leave a copy of your remote password lying around for all to view.

8.3 File transfer using FTP

VMS machines usually come with a TCP/IP stack, either DEC's own UCX (sometimes called Digital TCP/IP Services for OpenVMS), or a third party product like Multinet, or the FreeWare CMU/IP. These provide FTP and other commands which work in the usual way, often taking VMS-like command qualifiers, e.g.

$ FTP
ftp.bigcorp.com/USER="anonymous"/PASSWORD="me@my.mail.address"&nbs
p;

§9 The VMS Debugger

The VMS debugger supports all DEC compilers and many third party languages too. It allows breakpoints, watchpoints and interactive run-time program debugging, either at the command line as described below, or with the graphical version of the debugger.

In order to be able to use the debugger when running a program, you must to compile and link with the /DEBUG qualifier, which you can abbreviate to /DEB, like this:

$ FORTRAN/NOOPT/DEB filename 

and

$ LINK/DEB filename 

The /NOOPTIMIZATION qualifier is recommended, since this ensures that all variables are entered in the symbol reference tables. Otherwise some of them (typically loop indices) will be "optimized away".

When you run the program, VMS will automatically enter the debugger. To run without debugger even when you linked with /DEBUG, use

$ RUN/NODEBUG filename 

The debugger will stop at the start of the main program, and will ask for instructions, prompting you with DBG$. There are many possible commands - see the online documention OpenVMS Debugger Manual, use BookReader or BNU, or try "HELP" within the debugger. Some of the most commonly used commands are:

• SET MODE SCREEN Switches to full screen display mode
• SET MODULE routine_name[ ,routine_name] makes routine symbol tables (variable names, FORTRAN line numbers, etc.) to the debugger
• SET SCOPE routine_name references (variable names, TYPE commands etc.) are assumed to refer to the routine specified, causes SET MODULE for that routine
• SET BREAK routine_name stops at top of routine whenever it is called
• SET WATCHPOINT variable_name stops every time the variable is modified, displaying old and new value (SET W will do)
• EXAMINE variable_name prints value of this variable
• EX variable_name1:variable_name2 prints current values of all variables between variable_name1 and variable_name2
• SEARCH/STRING/ALL 1:100 name displays, for the routine currently in scope, all lines between lines 1 and 100, containing string "name" (if the source file is accessible)
• CANCEL BR name cancels break point at routine name
• CAN W name cancels watchpoint name
• CAN BR/ALL cancel all breakpoints
• CAN W/ALL cancel all watchpoints
• SHOW CALL shows the routine names in the calling tree, displays the source line number in the routine for which MODULE is set.
• DEPOSIT name=FORTRAN expression puts a new value in variable
• CALL routine_name call and execute routine then return here
• TYPE n1:n2 type (on screen) lines n1:n2 of your source file (the line numbers as displayed by SHOW CALL) Note: this requires the source file to be available in the same directories they were in when being compiled. There is a way around this - try HELP SET SOURCE within the debugger.
• STEP advance to the next executable statement. If the corresponding source file is still available, the next line to be executed is displayed.
• GO continue execution

In the above, "variable_name" may be just the name, like N, ABC etc., in which case the existing SCOPE is used to localize it, or specifies directly where to find it, e.g. MAIN\ABC (back slash !), meaning "variable ABC in routine MAIN".

You can inspect watchpoints, break points etc. by the SHOW command, e.g. SHOW W will show all watch points set.

You can abort the debugger, like any other program, by typing . If you then type DEB immediately afterwards, it will re-enter your program where you aborted it, stop there waiting for instructions, and continue to execute correctly if you type GO.

Breakpoints can be set at source line numbers, or at statement numbers, or routines. See the Debugger Manual for more details.

At correct termination of your program, the debugger will stop and tell you so. Type

       DBG$ EXIT

in order to terminate correctly.

The above list is far from complete, the HELP facility, which you can invoke from inside the debugger, will give more details.

Problems:

The most common one is probably the message

       `routine_name\variable_name is not in the symbol table'

in which case there are three explanations possible:

1. You mis-typed the name,
2. The variable was "optimized away",
3. You haven't SET MODULE or SET SCOPE to the current routine.

Another frequent error is

       `routine_name\variable_name is not unique'

This generally means that there is another variable with the same name in an outer scope. This can be cured by a SET SCOPE to the routine containing the instance of the variable which you want to see.

Finally, the cryptic message

       `symbol r_n\v_n not active or not in active scope'

simply means that it is a formal routine parameter which you try to inspect before you have entered the routine. Normally VMS sets the scope dynamically when you break in a routine.

Exercise :

Get the file SYS$EXAMPLES:SDEB.FOR and look at it (very tricky program, contains one obvious bug), list it possibly, then compile,link and execute it with the debug option.

When the debugger asks you for instructions, you are at the top of the main program, named SHOW_DEBUG, with the SCOPE set to this routine as default.

Now enter

    DBG$ SET MODE SCREEN

    DBG$ SET WATCH Q(10)

    DBG$ GO

and the debugger will stop inside the do loop 10.

Try the following commands

    DBG$ EXAMINE A,B,C

    DBG$ EX N(1,1):SS

    DBG$ GO

(Displaying a range over different variables as above is only possible when they are in the same common block, of course).

The debugger will stop with an arithmetic error (not surprising, since we divide by zero. Note here: all variables are initialized with zero automatically, unfortunately).

To find out where you are, type

  DBG$ SHOW CALL

and then

  DBG$ EX SS

and there you are. Now let us assume you expected SS = 1. here, so the correct result in this routine will be obtained by setting SS to 1., i.e.

  DBG$ DEP SS=1.0

(not always that simple !), and then

  DBG$ GO

and the program will terminate correctly, therefore enter

  DBG$ EXIT

§10 Command Files

10.1 General Information

These are files containing a series of DCL commands, just as you would enter them from a terminal. They can either be executed interactively, or submitted for batch execution - see the later section on batch jobs. A command file which you have executed already, perhaps without realising it, is your LOGIN.COM . This is executed automatically every time you log in, although you can stop it from being executed (if you have made some sort of mistake in it that causes a loop, say) by adding /NOCOM after your user name when you log in.

The default file type for command files is .COM , so if you just type @MYCOMMANDS then VMS will assume that you mean MYCOMMANDS.COM.

Each command must be preceeded by a $ sign; lines without this are interpreted as input to procedures called from the command file, and are otherwise skipped, with an error message. Continuation lines are indicated by a "-" (hyphen = minus sign) at the end of the line, and simple continuation in the next line, e.g.

$ SHOW -
    SYSTEM  ! This would be a silly place to split a line, but you
get the idea

Example:

Try this !

Create the file TESTCOM.COM and try to predict its action. The exclamation mark is a comment character in DCL, like * in FORTRAN, // in C++.

$ CREATE TESTCOM.COM ! Whatever you type now goes into the file
TESTCOM.COM 
$ WRITE SYS$OUTPUT "Hello World" ! Ever original 
$ EXIT

The terminates the input to the CREATE command. If you

$ TYPE TESTCOM.COM 

It should look like this:

$ WRITE SYS$OUTPUT "Hello World" ! Ever original
$ EXIT

To execute the file, you have to enter

$ @TESTCOM 

I don't think the output will come as a great shock to anyone. You can do quite a lot of interesting stuff from DCL. A lot of information about the system and your processes can be obtained using the DCL so called lexical functions. Use HELP Lexicals to get up to date information. See the Guide to Using DCL and Command Procedures on VMS for further information on writing and using command procedures, and have a look at your LOGIN.COM to get some ideas.

10.2 DCL Symbols

Symbols are useful for defining shorthand for frequently used commands, and for use as "variables" in DCL command procedures. Using the single "=" sign you can define symbols which are local to a command file, ie. they disappear at exit from it, or you can define global symbols which remain valid until you logoff, using "==".

Examples:

 three = 3
 file := SYS$EXAMPLES:TUT.FOR

can be used inside the command file, e.g. setting up the files for a batch job. Please note that "=" assigns a value, ":=" assigns a string to a symbol. Placing the string in double quotes " is also acceptable.

 three == 3
 file :== SYS$EXAMPLES:TUT.FOR
 string1 :==The whole of this line will end up in STRING1
 string2 == "This is a string too"

All these symbols will however remain valid even after the execution of the command file, because the "==" was used

DCL is case-insensitive for the most part, so it doesn't matter whether your symbols are uppercase or lowercase. Having said that I tend to use lowercase for my own symbols, and uppercase for built in DCL commands, just to make it easier to read and tell them apart. To invoke a symbol, put it between quotes, e.g. 'file', as in

$ file := MYDATA.DAT  ! Local symbol
$ COPY 'file' FARVAX::SCRATCH$DEVICE:

Note that it is the right-hand single quote ' both before and after the symbol. If you use the symbol within a quoted string, you need two quotes before it and one after, like this:

$ file :== TESTCOM.COM ! Global symbol
$ WRITE SYS$OUTPUT "Copying ''file' to the remote system." ! Two '
$ COPY 'file' FARVAX::SCRATCH$DEVICE:                      ! One '

Since symbols can be defined directly, without command files, try the above definition of file followed by the command

$ TYPE 'file'

and you will understand.

Symbols are often used to provide a shorthand way of specifying a frequently used command with several qualifiers. For example, instead of having to type

$ DIRECTORY/SINCE=TODAY/SIZE=ALL ! Get all files created
today, show their size

you could define a symbol in your LOGIN.COM like this:

$! Get all files created today, show their size
$ SDIR:==DIRECTORY/SINCE=TODAY/SIZE=ALL

then you need only type

$ SDIR

to get the same information. It is considered bad practise to define symbols that clash with built-in DCL commands, because it can lead to all sorts of confusion regarding the expected behaviour of commands. To see what symbols you already have defined you can type

$ SHOW SYMBOL *

This assumes that someone hasn't defined a symbol called SHOW to do something else ! If you suspect that they have, you can get rid of symbols by typing

$ DELETE/SYMBOL symbol_name

You could guarantee that DELETE would give you the DCL DELETE functionality by doing

$ DELETE:=DELETE

and indeed you will occasionally see this done in command files, to insulate them from the effects of any users who have been foolish enough to define symbols that clash with DCL commands.

Example

An example command file called FORTCLG.COM which compiles, link and runs the program TUT.FOR (which it assumes is in your top level directory) can be found in SYS$EXAMPLES: . It can easily be adapted to run one of your own programs by changing the parts indicated. You might not understand what everything does at first, but you should be able to work it out using the HELP facility. (Hint: any DCL function beginning with F$ can be found under HELP LEXICAL). Have a go at EDITing it to work with another FORTRAN file in your own directory.

§11 Binary Libraries

The output from the FORTRAN (or any other) compiler is kept in files of default type .OBJ (these contain binary VAX or Alpha instructions). The LINK command accepts more than one of these files, creating a `load module' (a self contained program which the machine can RUN) containing all of the routines in all the specified files,e.g.

$ LINK filename1,filename2,filename3

will create a file filename1.EXE combining all code from filename1.OBJ, filename2.OBJ and filename3.OBJ.

The linkage editor scans the modules (eg. subroutines) in the .OBJ files to see which routines are called from within them. It then manipulates these so that they know where to find the called routines, and places the modified code in the .EXE file, adding some `header' information which the VMS machine needs to run the code.

Even the simplest piece of code must be `linked' before it can be run since it will have `hidden' calls; printing things to the screen or calling trigonometrical functions like SIN or COS, for example, all require calls to routines in the VMS system libraries.

Having written several useful FORTRAN subroutines or functions, you might well want to use them in your new programs. This can be done without having to literally include the FORTRAN, and without having to recompile them or link to the .OBJ files every time. It is easiest if you collect the routines together as one large .FOR file, and compile it to obtain a .OBJ file (though you might want to compile the routines separately and get several .OBJ files).

If you want to load ONLY the routines referenced in (called from) a new program, you can create an "object library". This is done by typing

$ LIBRARY/CREATE library_name
object_file_1[,object_file_2,...] 

which expects input files with default type OBJ and produces a file of type OLB. To update an already existing library with modified or new routines, type

$ LIBRARY/REPLACE library_name new_object_file 

To link from libraries only those routines which are called you simply type e.g.

$ LINK file1,file2/LIB 

where file1 should be compiler output of default type OBJ (from the compilation of your new program), and file2 should be a library of default type OLB. As usual, one can force loading non-referenced routines like main programs, or BLOCK DATA, with an INCLUDE command, e.g.

$ LINK file1/INCL=(MAIN,OTHER)/LIB 

which will force the routines MAIN and OTHER to be loaded, and then satisfy their references.

Exercise :

Copy the files LIBTEST1.FOR and LIBTEST2.FOR from the SYS$EXAMPLES: directory to one of you own directories and call them VAXLIB1.FOR and VAXLIB2.FOR respectively.

Compile both files, convert VAXLIB2 into a library called MYLIB, inspect the library contents with LIB/LIST/FULL MYLIB, link VAXLIB1 with this library and and RUN the resulting EXE file.

§12 Running Batch Jobs

12.1 What is a Batch Job ?

Before reading this section, you should have read and understood chapter 10 on command files. Using a batch job is a way of running a command file to do some job for you whilst you are not logged on to the computer interactively. You collect the commands together into a command file, then "SUBMIT'' the command file to one of the batch job queues on the system, where they will run at slightly lower priority than interactive users (1, 2 or three for long, medium or normal (short) batch jobs). Hence quite complicated tasks can run in the `background', only using the CPU when it is not required by people logged on interactively. Having submitted the batch job, you can get on with something else, or log off and go home with a warm, fuzzy glow since your batch job will still be working hard :-)

A system, queue manager task allows a certain number of jobs on each queue to run at any single time; other jobs in the same queue have to wait in turn to run. On the YRL cluster there are some special batch queues known as SYS$BATCH, SYS$MEDIUM, SYS$LONG and SYS$TAPE.

These are called generic queues, and if a job is submitted to one of them, it automatically picks the first machine which becomes free to run the job, so you get your output back quicker. On the YRL cluster jobs can be submitted to the queue on a specific machine by specifying the queue as YRx_SYSBAT, YRy_SYSBAT or YRz_SYSBAT, where YRwhatever is the node name of the particular machine which you want to run the job on. Obviously the system managers will have set up different queue names on the systems you use. To find out the names of all available queues, and their time limits, enter

$ SHOW QUEUE/FULL 

For further information on the generic batch queues type HELP GENERIC .

12.2 How do you submit a Batch Job ?

This is simple - just enter

$ SUBMIT [/NOTIFY] 

where the /QUEUE modifier may be omitted for the moment. The output log file will be named

   [your_default_login_directory]command_file-name.LOG

The /NOTIFY option will send a message to your terminal when the job has finished. /NOPRINT has the effect that your output is stored on disk in your default directory (the one which is active when you log in). The default /PRINT will send it to the line printer. If you wanted the job to wait until a certain time (say after 6pm when most users have gone, to be social !) then you use the /AFTER qualifier, eg. /AFTER=18:00:00 .

Warning: whereas NOLIST is the FORTRAN command default when running interactively, LIST is the default when running in batch mode. This admittedly user-friendly feature can fill up your disk space very quickly (to avoid it you should specify FORTRAN/NOLIST in command file, or delete the .LIS and .OBJ files if the link editor successfully creates the .EXE file with no errors).

In order to find the queue position of your job, type

$ SHOW QUEUE queue/ALL 

where "queue'' is again one of the above names.

Occasionally it is necessary for the machines to be shut down to allow maintenance or software upgrades. When this happens all executing batch jobs are stopped. In order to let you close your job down gracefully (eg. save histograms or data) a special FORTRAN logical function SHUTDN has been provided. Type HELP SHUTDOWN for more details.

§13 Communicating With Other Users

13.1 Find out who else is logged on

To find out who is logged on to the machine enter

$ SHOW USERS 

or

$ SHOW USERS/FULL 

To look at all processes on your machine

$ SHOW SYSTEM 

The official way to talk to other users is to use the PHONE facility.

$ PHONE username 

or

$ PHONE node_name::username 

which works over DECnet to any properly configured VMS machine on your local network.

Always bear in mind that your message will appear somewhere in the middle of a screen of text which may be scrolling rapidly or in the middle of someone's edit - just enter (the "R" stands for "Refresh the screen") to clear the message if this happens to you - and that there will no permanent record. Some sites have additional software to allow chatting between users, so ask your system manager.

13.2 MAIL

The MAIL utility has many facilities for sending and receiving messages such as forwarding, sorting into folders, distribution lists, keypad commands, and more. To use it just type

$ MAIL 

and then

MAIL> HELP 

to find out what you can do, or

MAIL> DIR/NEW 

to see what new mail you have received. To read your new mails, enter

MAIL> READ/NEW 

and press
to move through the message(s). To delete the message you are currently `reading', enter

MAIL> DELETE 

This does not actually delete the message until you EXIT from mail. It puts it in a special folder (try HELP DIR/FOLDER) called WASTEBASKET. You can find out what is in the WASTEBASKET by typing

MAIL> SELECT WASTEBASKET 
MAIL> DIR 

Enter the number of the message you are interested in, and if you realise that you did not want to delete it, you can put it back in your mail folder (or any other folder) by entering

MAIL> FILE MAIL 

or

MAIL> FILE foldername 

where foldername is whatever you want (up to 31 characters). To send a message, just type

MAIL> SEND 

and follow the prompts. If you want to send a message without typing errors in it, use EDT to create file, called say message.txt, edit it and correct the spelling and grammar then

MAIL> SEND message.txt 

and follow the prompts. Normally the mail system puts all off your mail files in your top level directory, which can lead to a large number of files with names of the form MAIL$burble.MAI cluttering up your directory. It is much neater to ask the system to put them all in a MAIL sub-directory, and move all your current mails into the same sub-directory. To do this just enter

MAIL> SET MAIL_DIRECTORY [.MAIL] 

Another thing you might like to do is to set a "personal name'' which will go on the header of all your mails to other users. An example of this is

MAIL> SET PERSONAL_NAME "James Bond (Tel. 007)" 

To check on all the things you have set up type

MAIL> SHOW ALL 

These parameters are remembered even after you log off, and normally only need to be set once.

To exit from mail enter

MAIL> EXIT 
$ ! Back at DCL

You may want to use the EDT editor from within MAIL, in which case you should define the symbol MAIL to be MAIL/EDIT in your LOGIN.COM file, by adding a line like

$ MAIL:==MAIL/EDIT

When you re-execute your login file with @LOGIN, and re-enter mail, it will use the EDT editor automatically when you SEND a mail. Try to specify a meaningful Subject: when sending a mail, since this will help the recipient when scanning through the mail.

§14 Miscellaneous

As mentioned before, only suspends the execution of the running program. After having interrupted it in this way, when you then enter the command SPAWN, you will create a new 'sub-process' inside which you can now work as if you had logged in on a different terminal. You may SPAWN again in this sub-process, etc. When you enter LOGOFF, you will return to the next higher process, which will be in the state after the , i.e. when entering CONTINUE the program interrupted initially will continue. Do not spawn more than one subprocess, and then only for brief periods of time, since this does use up certain system resources.

There are several useful DCL commands which display the user and system status. To find out which users are logged in, type

$ SHOW USERS 

To display your process logical name assignments

$ SHOW LOGICAL/PROCESS 

and for your disk file space

$ SHOW QUOTA 

$ SEARCH *.FOR string 

which (in the above case) will copy all lines containing "string" from all files of type .FOR to the screen, or onto an output file if you specify the /OUTPUT=filename option after SEARCH.

RECALL/ALL will give you the last 20 command(s) which you have typed to the DCL command interpretor. On terminals with arrows to move the cursor (e.g. VT100, VT200, Pericom), typing the upper arrow will go backwards through your commands, and you may edit them with the arrows and the delete key before re-submitting them with RETURN.

There are a number of options , often called qualifiers, for most system commands, which are specified after "/" as you may have noticed. To find out about them, the HELP facility or the manual should be consulted.

§15 Final Remarks

Since this tutorial is meant to encourage and help users to make good use of their VMScluster or workstation, comments, corrections, and proposals for improvements are highly welcome. Mail your comments to <phil@XZYpottsoft_REMOVEXYZ.com >, with subjectVMS Tutorial.

Familiarizing yourself with DCL and the physical resources of the VMS machines and writing clear, well commented code in standard FORTRAN, C or C++ will not only speed up your own jobs, but will improve the computers' response for everyone.

Solutions to Exercises

Exercise 1:

$ EDIT EXAMP1.FOR 

      PROGRAM TEST
C     Very very simple test program
      WRITE(6,2001)
 2001 FORMAT(//' TEST OUTPUT'/)
      STOP
      END
      <Ctrl>Z     ( to stop input to EDT)
      EXIT

FORT EXAMP1
LINK EXAMP1
RUN EXAMP1

DEL EXAMP1.*;

Exercise 2

COPY SYS$EXAMPLES:SDEB.FOR *.*
TYPE SDEB.FOR

FORT/NOOPT/DEB SDEB
LINK/DEB SDEB
RUN SDEB

Exercise 3

EXAMP :== "SYS$EXAMPLES:"
COPY 'EXAMP'LIBTEST1.FOR VAXLIB1.FOR
COPY 'EXAMP'LIBTEST2.FOR VAXLIB2.FOR
FORT VAXLIB1
FORT VAXLIB2
LIB/CREATE MYLIB VAXLIB2
LINK VAXLIB1,MYLIB/LIB
RUN VAXLIB1

Bibliography