History of changes put into version 2 and 3 of PVM

PVM 3.4.0 
Besides bug fixes to 3.3, there are many new features in Version 3.4
including a port to WIN95, NT 3.51, and NT 4.0. New feature areas include:

  -------- Message Context --------

* To allow more flexibility in organizing message tags sets, and
  to provide support for "safe" libraries that will not inadvertently
  intercept user messages, the concept of "message context" in PVM
  has been introduced.  The context is an additional system-defined
  message tag that each message carries, such that each given message
  can only be sent or received within a single unique context.  For
  example, all internal system messages in PVM now utilize a different
  context than the base user application context, so that system
  messages cannot be incorrectly received by the application.  The
  user can determine the current context, create a new context,
  set the current context and free message contexts using the new
  routines pvm_getcontext(), pvm_newcontext(), pvm_setcontext() and
  pvm_freecontext(), respectively (see man pages for details).  The
  context itself is an integer value which can be packed into messages
  and sent to cooperating tasks, or placed in a message mailbox (see
  below) for client-service lookup.  By default, all tasks are spawned
  in the same base context.

  -------- Message Handlers --------

* In the spirit of Active Messages, PVM now supports "message handlers"
  for automatic processing of incoming messages.  The user can define
  any number of message handler functions, each with a corresponding
  (source, tag, context) tuple.  Then when a message matching a
  particular tuple arrives at the local task, the user-specified
  handler routine is automatically invoked to process the message.
  Within a message handler, the message can be unpacked and a simple
  response message can be packed and sent (using pvm_send() only).
  The new PVM routines for creating and deleting message handlers are
  pvm_addmhf() and pvm_delmhf(), respectively (see man pages for
  details).  Note that message handlers are only invoked when the
  application is already executing a PVM messaging routine - handlers
  cannot interrupt normal program execution.  Typically, message
  handlers will trigger transparently during other communication,
  but the user can specifically invoke them by calling pvm_probe()
  or an equivalent function in a loop.

  -------- Message Mailboxes --------

* To provide a new means for name service that does not require the
  PVM dynamic group server ("pvmgs"), a "message mailbox" mechanism
  has been added to PVM 3.4.  Using this feature a user application
  can post a message to a public mailbox which can subsequently be
  "looked up" and retrieved by other independently spawned tasks in
  the virtual machine.  Each mailbox is created using a specific
  "class name" and can consist of either exactly one or many entries
  for that given name.  When a task "looks up" a mailbox entry, it
  receives back the message contained in it, to be unpacked and
  processed as desired.  Mailboxes can be mutually exclusive, to
  act as a locking mechanism for resources, and can be created as
  "persistent" so that they will continue to exist after the owner
  (or creator) task exits.  The new routines in PVM for creating,
  retrieving and freeing message mailboxes are pvm_putinfo(),
  pvm_recvinfo() and pvm_delinfo(), respectively, plus an additional
  routine, pvm_getmboxinfo(), for obtaining a list of the currently-
  defined class names (see man pages for details).

  -------- Spawn Siblings --------

* Often when designing SPMD programs, it is useful to know which tasks
 were spawned together as a group.  This information can be used to
  form static groups for efficient group communication, or simply for
  referencing other members of your own "spawn siblings".  The new
  PVM call pvm_siblings() (see man page for details) returns a list
  of integer task ids that corresponds to all the tasks that were
  spawned together from a single pvm_spawn() call (or from the "pvm"
  console).

  -------- Tracing --------

* Routines in libpvm and the group library have included built-in
  tracing of calling parameter/results since PVM 3.3.  In PVM 3.4,
  the tracing facility has been completely rewritten to be more
  general, flexible and maintainable.  As a result, the tracing
  capabilities of PVM 3.4 have been expanded to support trace
  buffering, several levels of tracing, and user-defined trace
  events.  The graphical PVM interface, XPVM 1.2, has been rewritten
  to use a new PVM library, libpvmtrc, and a new text-based trace
  collection tool ("tracer") has been added to the standard PVM
  distribution to allow easy trace file collection on systems where
  X11 compilation is either difficult or impossible.  In addition,
  the new tracing facility now supports "automatic" attachment to
  trace collection programs, so that when tasks are independently
  spawned, e.g. from the shell, their trace events will still
  propagate to the proper trace tool (without any manual "attachment"
  procedure).  Other various improvements have been applied to
  specific trace events, e.g. pvm_send() events now carry the message
  size information, allowing proper driving of XPVM's Message
  Queue View (you will notice the difference in the message coloring
  to indicate this added capability).  Upon re-compiling XPVM with
  the new PVM 3.4 libraries (by clearing the defines for PVMVERSION
  and PVMGLIB, and modifying TRCDIR to point to pvm3/tracer in the
  file "xpvm/src/Makefile.aimk"), you will find additional options
  on the "Tasks.../SPAWN" dialog to control the new tracing features.
  The new "pvm" console also supports new options to the "trace"
  commands (type "help trace" in the console for a description).
  For additional information regarding use of the more advanced
  tracing features, send email to "kohl@msr.epm.ornl.gov".

* Added new "trcsort" program (in pvm3/tracer subdirectory) for
  sorting trace files by timestamp.  Takes into account approximate
  clock skew among hosts (still no guarantees about "tachyons" though).

  -------- Misc --------
* Most of the MIMD and SHMEM code has been completely rewritten
  (as of this beta release, the SHMEM ports are still work in progress)
  to eliminate many bugs and improve maintainability and robustness.
  On architectures that support shared memory operations, the
  default PVM architecture selection is now non-shmem, and to turn
  on selection of the appropriate *MP architecture the user must
  set the environment variable "PVM_SHMEM" to "ON", as in
  "setenv PVM_SHMEM ON" (see "Potential Incompatibilities" below).
  The style of compiling PVM applications for MPP systems has
  also changed slightly - please refer to the pvm3/examples directory
  for the proper Makefile.aimk targets.

* The Makefiles for PVM 3.4 have been completely overhauled to
  (theoretically) allow easier setting of desired compile options
  from the new top level Makefile.aimk.  The new defines "CFLOPTS" and
  "FFLOPTS" are passed down into the various subdirectories and then
  prepended to the definitions for CFLAGS and FFLAGS, respectively.
  Likewise, setting CC or F77 at the top level will force that setting
  throughout the source tree when making at the top level.

* Extensive work has been done on the PVM port to Windows systems,
  the "WIN32" architecture.  The stuff really works!  :-)

* Added new "srm" simple resource manager example, in pvm3/rm.

* Added new pvm_setopt() option "PvmNoReset" for system tasks, to
  prevent tasks from being killed during a system reset.

* Added new pvm_setopt() option "PvmNoSpawnParent" so that tasks can
  now use pvm_parent() to determine if they are the "master" in
  master-slave applications, even if tasks are spawned from the
  "pvm" console or XPVM.

------------------------------------------------------------------------

Bug Fixes:

* Remote task output collection and tracing is now correctly working
  on MPP systems such as PGON and SHMEM architectures.

* It is now possible to fully interoperate pvm_send(), pvm_recv(),
  pvm_nrecv() and pvm_trecv() with pvm_psend() and pvm_precv()
  (assuming that the appropriate PvmDataRaw data encoding is used!).
  MPPs can use pvm_psend() and pvm_precv() off-machine with tasks
  that are using the traditional send and receive routines.

* Modified pvm_freebuf() so that freeing a NULL buffer no longer
  generates an error.  Many 3.3 codes exhibited this error through
  the use of pvm_freebuf( pvm_setsbuf(x) ) where there was no old
  send buffer.

* A static character variable has been utilized inside pvm_version()
  to prevent stack problems on certain architectures.

* Removed ancient "-lmutex" from SGI architectures ARCHDLIB defines!

* Lots of random manual pages (more to come...).

------------------------------------------------------------------------

Changes - Potential Incompatibilities:

* The old "$SGIMP" environment variable has been subsumed with the
  new "$PVM_SHMEM" environment variable.

* Due to incompatibilities between AIX 4.1 and 4.2, the previous RS6K
  architecture has been split to add several new architectures for
  different OS / SHMEM combinations:  AIX46K, AIX4MP, AIX4SP2.

* All of the various daemon-to-task and task-to-task protocols have
  been moved to a new public header file, "pvm3/include/pvmproto.h".
  The constants for utilizing the protocols for task control messages
  and other system support programs are all included in this new header
  file.

* Tracing facility has been completely rewritten, new trace messages
  are incompatible with PVM 3.3 tracing tools (except XPVM 1.2, see
  above).

* Defunct functs - the following functions are no longer supported
  in PVM 3.4:  pvm_insert(), pvm_delete(), pvm_lookup().  The name
  service features that these routines provided are now handled
  using the message mailbox system.

* Obsolete functions - the following functions will be eliminated
  in a future release:  pvm_getmwid(), pvm_setmwid().  Users should
  switch to pvm_getminfo() and pvm_setminfo().