Release Notes and Installation Instructions for EXECSYMB V3.6.1, 14-Jul-1994
  ============================================================================

Highlights
----------

This version of EXECSYMB will work with VMS V6.1 on both the VAX and AXP
platforms, and with VAX VMS V6.0, while retaining compatibility with 
VAX VMS V5.x and AXP VMS V1.5.

*.EXE files are no longer supplied.

One new queue parameter flag added, to simplify queue processing where jobs
are aborted and then put on hold while being modified and requeued.

Contents
--------

The following files have been updated or added between V3.5.2 and V3.6.1:

(Object files are not listed, as they are recreated for each release, whether 
 or not the source files were changed.)

NOTE: VAX .OBJ's were created using VAX Fortran V5.9;
      AXP .OBJ's were created using DEC Fortran V6.2.

	AAAREADME.TXT	-- added release notes for V3.6.1 (reproduced below)

	EXECSYMB.BLD	-- EXECSYMB build procedure; version checking modified,
			   provision for link-only build

	EXECSYMB.FOR	-- several changes to EXECSYMB code from V3.5 to V3.6

	EXECSYMB.LINK	-- EXECSYMB link procedure; version checking modified

	EXECSYMB_KM.LINK -- link command file for all versions of EXECSYMB_KM

	EXECSYMB_KM.MAR	-- bug fixed in VAX vs. AXP conditionalization

	EXECSYMB_V3.PS	-- updated documentation in PostScript format

	EXECSYMB_V3.TXT	-- updated documentation in plain ASCII format

Installation
------------

I am no longer supplying .EXE files, mainly because I would have to keep too
many versions of various system and library files (.EXE, .STB, etc.) to make
all of the necessary combinations.  Instead, I've made it easy to link the 
.EXE's from the supplied .OBJ's.

To link the .EXE's from supplied .OBJ's:  type "@EXECSYMB.BLD LINK".
(On an AXP, you'll first have to rename the *.OBJ_ALPHA files to *.OBJ.)

To rebuild from sources: type "@EXECSYMB.BLD" with no parameters.

Next, copy EXECSYMB.EXE to SYS$COMMON:[SYSEXE], and EXECSYMB_KM.EXE to 
SYS$COMMON:[SYSLIB].  EXECSYMB_KM.EXE should have its protection set for no 
world access.  Add the following command to your startup file, *before* any 
EXECSYMB queues are started:

	INSTALL ADD SYS$SHARE:EXECSYMB_KM/SHARE/PROT

Then, type the above command on your running system (if you want to use
EXECSYMB before the next time you reboot).

If you are running VMS V4, the kernel-mode code is not supported.  If you want 
to try it anyway, you'll have to relink EXECSYMB_KM.EXE, modify EXECSYMB.LINK 
to remove the reference to SETUSER and add the reference to EXECSYMB_KM (see 
the V5 section of the file for an example), rebuild EXECSYMB, and install the 
shareable image.  I don't have a VMS V4.x system and I don't recall what user-
written system service support in V4 might be like -- so you're pretty much on 
your own.  If you get it to work, please let me know so I can share the good 
news with others who might be in the same boat.

The new source files should replace any previous versions of the same files.

*** NOTE ***  If, for some reason, you do *not* want to use the EXECSYMB_KM
shareable image, you can build EXECSYMB without it, by including SETUSER among 
the object modules and removing the reference to EXECSYMB_KM from the link 
file.  Of course, EXECSYMB will then be unable to perform any cleanup if it is 
aborted.  To do the same under AXP VMS, you'll first have to use
MACRO/MIGRATION to compile SETUSER.MAR; I haven't tried building EXECSYMB this
way for the AXP, so I can't tell you whether it works or not.

Release notes
-------------

Changes since the previous public release (V3.5.2, 13-Jan-1994) are as follows:

    1.	Bug fix required for VAX VMS V6.x -- EXECSYMB's version detection code
	had a really stupid bug in it, which caused a bunch of messages in the
	EXECSYMB log files showing a status of 00000154 (%SYSTEM-F-IVLOGNAM),
	and prevented the symbiont from working.

    2.	Bug fix in EXECSYMB_KM; a line of code was placed in a VAX-only section
	that should have been in the architecture-independent section.  This
	would have caused problems in the AXP flavor of EXECSYMB_KM.

    3.	One new feature: a new flag "HOLD" is recognized in the queue parameter
	string (i.e. the /SEPARATE=RESET string).  Prior to V3.6, if you wanted
	jobs to be requeued for retry on a failure completion status, you had
	to specify a wait time via the "TIME=" queue parameter.  I ran into 
	many cases where I just wanted the jobs held indefinitely (e.g. if the 
	queue processor modifies and requeues the job for processing elsewhere,
	and then releases it).  HOLD enables you to do this.  If you specify 
	"HOLD", don't specify "TIME=", and a job reports an error completion 
	status, the job will be requeued and put on indefinite hold.