textfiles/hacking/VMS/newtov.txt

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.