V6.2-000 is a major release that introduces auto-relink, a
publish+subscribe model that enables GT.M processes to
automatically and safely execute the latest published versions of
routines; adds support to read and write encrypted sequential disk
files, pipes, and FIFOs; adds the ability to pass SOCKET devices
from one process to another; and includes many other enhancements
and fixes.

+ Released as field test grade functionality in a production
release, auto-relink provides a way to allow long-running
processes to automatically and safely execute the latest
versions of routines. It also has uses in development and
testing. Each process that wishes to subscribe to updates of
object files in a directory appends an asterisk ("*") suffix to
that directory name in $ZROUTINES before linking from it. When
a process publishes updates to routines (including the presence
of new routines, and the removal of existing routines) with the
ZRUPDATE command, processes that have subscribed to those
updates automatically perform a ZLINK on the next execution of
a command or function call that explicitly invokes a routine
with a published update. Safe execution means that auto-relink
of new versions of routines ensures that prior versions of
those routines on the M call stack continue executing correctly
through their QUIT commands and are not "clobbered" when
control returns to them. Field-test grade functionality in a
production release means that FIS considers auto-relink
functionality sufficiently robust for use in development and
testing, but not robust enough for use in production
environments. Except for auto-relink, all other functionality
in V6.2-000 is robust enough for use in production.

+ To protect non-database data at rest, and more securely
exchange data with other systems and applications, both GT.M as
well as non-GT.M processes, GT.M encryption functionality
extends to file, pipe, and FIFO IO. As with all GT.M encryption
features, GT.M itself includes no cryptographic software;
instead it accesses external cryptographic libraries using a
plugin architecture. The GT.M distribution includes a reference
implementation of the plugin, which FIS tests during GT.M
development against a couple of widely available cryptographic
packages. FIS neither supports cryptographic libraries with
GT.M nor recommends the use of any specific library - refer to
the GT.M Administration and Operations Guide UNIX Edition for
more details.

+ Functionality to transfer DETACHed TCP or LOCAL sockets between
GT.M processes using a LOCAL SOCKET device as the rendezvous is
a fundamental enabling technology. Rich user interfaces can be
built with multiple bi-directional TCP connections between
clients such as browsers and server processes, using a layered
protocol such as WebSockets. When a client and server wish to
add a TCP connection between them, the client can initiate a
new connection to a known port on server. An Internet
superserver, such as xinetd, can screen the request and start a
GT.M process, which can use an application-defined protocol to
obtain the process id of the client's existing server process
to whom it transfers the connection. The technique can also be
used by a server to pass an existing client socket to a
different process, for example, one that publishes information,
such as a news feed or weather report.


V6.2-000 also has numerous smaller enhancements, including:

+ $ZSOCKET() provides information about a SOCKET device and its attached sockets.
+ $ZSYSLOG() allows a process to send a message to the syslog
without requiring the POSIX plugin.
+ GT.M for 32-bit Linux is compiled using the i586 ("Pentium
compatible") instruction set, allowing it to run on recent
System on Chip (SoC) based computers.
+ MUPIP SIZE includes an estimate of adjacency.
+ $PRINCIPAL can be a LOCAL socket.


The online help facilities provided through the ZHELP command in
GT.M, and the HELP commands in the utilities, provide
hierarchically organized information current with V6.2-000. These,
as well as robustness improvements, fixes to issues, and
performance enhancements, are described in the Release Notes.

Please do include an upgrade to V6.2-000 in your plans. As always,
please do send any feedback our way. Thank you for using GT.M.

Regards
-- Bhaskar

--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

V6.1-000 brings a number of other new features, as well. For example:

- SOCKET device support for local sockets (also known as UNIX domain
sockets).
- The ability for a parent process to pass a SOCKET device to a child
process in a JOB command.
- A $ZCLOSE intrinsic special variable that provides the status of a
CLOSE of a PIPE device.
- Faster database reads, especially when large numbers of processes
(thousands) concurrently access a database file.
- Nanosecond timestamps to determine whether a source file is newer
than an object file.
- Performance enhancements to databases on AIX that use the MM access
method.

We'll try to add examples to the documentation. But let me ask you a question - if xinetd does the job for you, why not continue to use it? We made the change to GT.M because there was a specific application situation, not a general requirement, that made xinetd slightly more awkward to use than GT.M socket passing. I would expect xinetd to be a more general solution because it is better integrated with the OS, e.g., for protection, that you would otherwise have to code with GT.M socket passing.

If you have a use case that is not easily addressed with xinetd, please describe it.

Thank you very much.

Regards
-- Bhaskar