[fa.info-vax] Running jnet

ARNOLD%WISCPSLB.BITNET@WISCVM.ARPA (Stephen L. Arnold) (09/16/85)

Recently, Marty Sasaki wrote:
        When we updated our systems to 4.2, JNET stopped working.
        Has anyone else experienced this problem?
This hardly seems like the forum to go into VMS V4.2 jnet upgrade problems in
detail, but since we have had so many questions from INFO-VAX readers, I will
try to explain the situation in a way that's interesting to other INFO-VAX
readers.

jnet was affected by two changes in VMS V4.2.  The first affected sites running
jnet V1.2.  The second affected sites running V2.0X2 (external field test 2).

jnet components that are installed with privileges are carefully coded to keep
all image privileges turned off except at the instant that they are needed.  At
V4.2, Digital tightened security in the Files-11 Extended QIO Processor (XQP):
a file opened with image privileges (to which the process would not normally
have access) cannot be closed without those privileges if the FAB has a
protection XAB (XABPRO) attached to it.   If this requirement is not met, the
XQP reports a  privilege/protection violation back to the image.

jnet's JMAIL.EXE and SENDFILE.EXE, used to send RSCS mail and files,
respectively, had to be modified to turn SYSPRV on when closing the EBCDIC
versions of the file just sent:  JAN_SYS:linkname.RSC.  The unmodified versions
correctly created the files but did not increment the queue count for the link
and did not wake the link daemon to send the file because the image exited
early on the file close error.

A temporary workaround is to stop and restart the link.  On startup, the daemon
counts and sends the files. Unfortunately, it appears to users as if the files
are not sent, so users may send additional copies.  A permanent fix was
developed on June 16 and has been sent to all sites reporting the symptoms I
described. Each of these sites had received an early release of the V4.2 XQP
from Digital to fix one problem or another.  jnet kits manufactured after June
16 include the modified files; if your SENDFILE and JMAIL images were linked on
June 16 you can upgrade to VMS V4.2 with confidence that jnet will run
correctly.

If you do not have the June 16 versions of SENDFILE and JMAIL you have three
options.  (1) You can delay your upgrade to VMS V4.2 until the middle of
October, when you should have jnet V2.0, which is unaffected by this problem.
(2) You can use the workaround mentioned above.  (3) You can request the new
versions of SENDFILE and JMAIL from us.  Send your requests to any of the
electronic addresses below, telephone, or send (yuch!) paper mail.

The second problem prevented approximately 40 machines running jnet V2.0X2 from
immediately upgrading to VMS V4.2.  At V4.2, Digital restricted the behavior
of the run-time library routine LIB$FIND_IMAGE_SYMBOL to conform to the
documentation.  This routine dynamically merges a sharable image into another
running image.  VMSmail uses it to merge "alternate mail protocols" (including
JNET%) into itself when mail is addressed in the form protocolname%otherstuff.
jnet also uses it internally. The change in VMS V4.2 was to accept only a file
name (as documented), not a complete filespec as was done in jnet V2.0X2.  This
change in the RTL prevented jnet from sending mail and from receiving any
files.

jnet V2.0 (the version to be released) avoids this problem by giving a filename
to LIB$FINE_IMAGE_SYMBOL and setting up a logical for the filename to point to
the complete filespec.  jnet V2.0 was sent to all test sites yesterday (Sept.
13) and is now in manufacturing.  We expect to ship V2.0 to to customers on
service of around the middle of October.

While these problems are illuminating, and may help INFO-VAX readers avoid
similar difficulties with other software during the upgrade to V4.2, requests
for jnet service should be sent to one of the addresses below, not to
INFO-VAX.  Thank you!

Regards,
Stephen L. Arnold, jnet Product Manager, Joiner Associates Inc.
Mail    P.O. Box 5445, Madison WI  53705-0445  U.S.A.
Phone   (608) 238-8134
Telex   650 110-6813
BITNET  arnold@wiscpsl
ARPA    arnold%wiscpsl.BITNET@wiscvm.ARPA
Easynet RHEA::DECWRL::"arnold@wiscpsl.BITNET"
UUCP    arnold%wiscpsl.BITNET@psuvax1.UUCP

(R)jnet is a registered trademark of Joiner Associates Inc.  jnet was developed
by Craig R. Watkins.