How well integrated they are into the system depends on the stack, your
version of VMS, and the version of your C compiler.
-The most portable solution uses the SOCKETSHR library. In combination with
-either UCX or NetLib, this supports all the major TCP stacks (Multinet,
-Pathways, TCPWare, UCX, and CMU) on all versions of VMS Perl runs on, with
-all the compilers on both VAX and Alpha. The socket interface is also
-consistent across versions of VMS and C compilers. It has a problem with
-UDP sockets when used with Multinet, though, so you should be aware of
-that.
-
-The other solution available is to use the socket routines built into DEC
+The default solution available is to use the socket routines built into DEC
C. Which routines are available depend on the version of VMS you're
running, and require proper UCX emulation by your TCP/IP vendor.
Relatively current versions of Multinet, TCPWare, Pathway, and UCX all
provide the required libraries--check your manuals or release notes to see
if your version is new enough.
+The other solution uses the SOCKETSHR library. Before VAX/VMS 5.5-2 it was
+the most portable solution. The SOCKETSHR library has not been maintained
+since VAX/VMS 5.5-2, and it is not known if will even compile with the ANSI
+C that Perl currently requires. It remains an option for historical reasons,
+just in case someone might find it useful.
+
+In combination with either UCX or NetLib, this supported all the major TCP
+stacks (Multinet, Pathways, TCPWare, UCX, and CMU) on all versions of VMS
+Perl ran on up to VAX/VMS 6.2 and Alpha VMS 1.5 with all the compilers on
+both VAX and Alpha. The portion of the socket interface was also consistent
+across versions of VMS and C compilers.
+
+It has a problem with UDP sockets when used with Multinet, though, so you
+should be aware of that.
+
+As of VAX/VMS 5.5-2 and later, CMU is the only TCP/IP program that requires
+socketshr, and the sources have been lost to the most recent CMU bug fixes,
+so CMU is limited to OpenVMS/VAX 6.2 or earlier, which is the last release
+that binaries for the last released patches are known to exist.
+
+There is currently no official web site for downloading either CMU or
+SOCKETSHR; however, copies may be found in the DECUS archives.
+
=head1 Building Perl
The configuration script will print out, at the very end, the MMS or MMK
except that the element separator is '|' instead of ':'. The
directory specifications may use either VMS or Unix syntax.
+=head1 The Perl Forked Debugger
+
+The Perl forked debugger places the debugger commands and output in a
+separate X-11 terminal window so that commands and output from multiple
+processes are not mixed together.
+
+Perl on VMS supports an emulation of the forked debugger when Perl is
+run on a VMS system that has X11 support installed.
+
+To use the forked debugger, you need to have the default display set to an
+X-11 Server and some environment variables set that Unix expects.
+
+The forked debugger requires the environment variable C<TERM> to be C<xterm>,
+and the environment variable C<DISPLAY> to exist. C<xterm> must be in
+lower case.
+
+ $define TERM "xterm"
+
+ $define DISPLAY "hostname:0.0"
+
+Currently the value of C<DISPLAY> is ignored. It is recommended that it be set
+to be the hostname of the display, the server and screen in UNIX notation. In
+the future the value of DISPLAY may be honored by Perl instead of using the
+default display.
+
+It may be helpful to always use the forked debugger so that script I/O is
+separated from debugger I/O. You can force the debugger to be forked by
+assigning a value to the logical name <PERLDB_PIDS> that is not a process
+identification number.
+
+ $define PERLDB_PIDS XXXX
+
+
=head1 PERL_VMS_EXCEPTION_DEBUG
The PERL_VMS_EXCEPTION_DEBUG being defined as "ENABLE" will cause the VMS
projects / p5sagit/p5-mst-13.2.git / commitdiff