Patch-ID# 101404-13 Keywords: SunLink 8.0 SNA RJE Client mandatory binaries Solaris 2.x fails Synopsis: SunLink 8.0: SNA RJE Client bug fixes Date: Aug/21/96 Solaris Release: 2.1, 2.2, 2.3, 2.4 SunOS Release: 5.1, 5.2, 5.3, 5.4 Unbundled Product: SunLink SNA RJE Client Unbundled Release: 8.0 Relevant Architectures: sparc BugId's fixed with this patch: 1144030 1145608 1146584 1147246 1147247 1147249 1147250 1147398 1147424 1147981 1147987 1147992 1147993 1159365 1161134 1162509 1169365 1169546 1169810 1120964 1159303 1176739 1181013 1182013 1183197 1194030 1194428 1203706 1204531 1205235 1210405 1211363 1212970 1213329 1218785 1224054 1233814 1242673 1246123 Changes incorporated in this version: 1246123 1242673 Patches accumulated and obsoleted by this patch: Patches which conflict with this patch: Patches required with this patch: 101280-12 or higher revision Obsoleted by: Files included with this patch: /opt/SUNWconn/snarjec/rje_call /opt/SUNWconn/snarjec/rje_gateway /opt/SUNWconn/snarjec/rje_link /opt/SUNWconn/snarjec/rjeadmin /opt/SUNWconn/snarjec/rjecmd /opt/SUNWconn/snarjec/rjecopy /opt/SUNWconn/snarjec/rjedispatch /opt/SUNWconn/snarjec/rjeretry /opt/SUNWconn/snarjec/rjerm /opt/SUNWconn/snarjec/rjesend /opt/SUNWconn/snarjec/rjeshow /opt/SUNWconn/snarjec/rjestatus /opt/SUNWconn/snarjec/debug/rje_call /opt/SUNWconn/snarjec/debug/rje_gateway /opt/SUNWconn/snarjec/debug/rje_link /opt/SUNWconn/snarjec/debug/rjeadmin /opt/SUNWconn/snarjec/debug/rjecmd /opt/SUNWconn/snarjec/debug/rjecopy /opt/SUNWconn/snarjec/debug/rjedispatch /opt/SUNWconn/snarjec/debug/rjeretry /opt/SUNWconn/snarjec/debug/rjerm /opt/SUNWconn/snarjec/debug/rjesend /opt/SUNWconn/snarjec/debug/rjeshow /opt/SUNWconn/snarjec/debug/rjestatus Problem Description: (Rev 13) -------- 1246123 ------- Random trunction of receive files due to bug in handling a TRN byte when that byte is part of a repeat-next-character SCB. For example, 0xC2 0x35 CNT should be interpreted as a TRN TRN CNT where the first TRN is taken as data and the second TRN is part of the transparent-count combo. 1242673 ------- Random trunction of receive files due to bug in setting controlling SCB byte when handling spanned records with a repeat-next-character SCB byte. (Rev 12) -------- 1210405: rje ignores UNBIND and continues to send data Previously, rje was not checking the ownership state after it sent data to the host. As a result, it was not always detecting the fact that the host had sent an UNBIND. rje was modified to check the ownership status after it sends data to the host. rje was also modified to indicate that it is sending job data on a LU-LU session. Also, the new utility rjeretry was created. With this utility, a user can resubmit a job that failed earlier. See Documentation Changes in the Special Install Instructions below for details about rjeretry. 1224054: rjesend sets invalid scb rjesend was sometimes sending a incorrect scb to the host. This incorrect scb was the last scb of the frame and should have been a "1", followed by an IRS. rjesend was modified to send the correct scb in these situations. 1233814: rje translates FFs and CRs to NLs Previously, when rje would translate FFs and CRs that it received from the host, it would translate them to NLs. Now, if the environment variable SNARJE_XLATE_TO_NL is not defined, rje will translate FFs to FFs and CRs to CRs. If this environment variable is defined, rje will translate FFs and CRs to NLs. See Documentation Changes in the Special Install Instructions below for details. (Rev 11) -------- 1189893: SNA RJE Server process passes incorrect job id to dispatch script SNA RJE Server was passing an incorrect job id as a parameter to the dispatch script for the _orphans directory. As a result, such a dispatch script would not be able to process the new NJHxxxx and NJDxxxx files. 1194030: rjeshow and rjestatus display incorrect data class rje_link and rjesend were writing incorrect data to the NJHxxxx files. As a result, rjeshow and rjestatus would display the incorrect class information. rje_link and rjesend were modified to write the correct class data to the NJHxxxx files. 1194428: rjesend fails to send multiple files rjesend allows a user to specify more than one data file on the command line. In these cases, rjesend is supposed to send each file to the host. However, when a user specified more than one data file, rjesend only sent out the first. rjesend was updating the NJDxxxx files with incorrect data from the other data files. As a result, rje_link would only send the data for the first file. rjesend was modified to update the NJDxxxx files correctly with data for the other data files. 1203706: rjesend gets error when user data contains 61 non repeating characters When a data file contained 61 non repeating characters, rjesend returned this error message: "rjesend: process_file: nje_convert_toibm: compression failed". rjesend was modified to handle this situation. 1204531: SNARJE receiving garbage file from a valid HOST job rje was misinterpreting an SCB of 0x35 as a TRN control code. Because of this error, rje did not process the data from the host properly. rje was modified to look for a TRN only after the current SCB has been retrieved. 1205235: RJE processes "TRN CNT" incorrectly when they span RUs The datastream which is sent by the host to rje can contain the Transparent control code (TRN), which indicates that data is transmitted in transparent mode. TRN is followed by a one byte count (CNT), which specifies the number of bytes of transparent data. Previously, rje was not able to process the sequence "TRN CNT" correctly when it spanned RUs. In these cases, rje ignored the TRN and treated CNT (and the next CNT bytes) as regular data. rje was modified to check for the case in which TRN is the last byte of an RU. In this situation, rje will retrieve the CNT from the next frame. 1211363: rje cannot retrieve TRN-CNT from SCB of 0x81 Previously, rje only attempted to retrieve the TRN-CNT within the scope of a 00xx xxxx type of SCB. rje failed to realize that the TRN-CNT could have been compressed into an SCB of 0x81. rje was modified to handle this situation. 1212970: rje sending uncompressed binary data to the host When a user used the "-b" option of rjesend, rjesend assumes that the data was in binary format. However, when rjesend formatted this data, it failed to compress it. rje was modified to compress binary data. If a user wants to send binary data in the old, uncompressed format, he can use the new "-bu" (binary uncompressed) option for rjesend. Please refer to the "Documentation Changes" section below for more details. 1213329: rje does not support record lengths > 255 Previously, rje could not handle a 256 byte record sent by the host. rje was modified so that it would support a record of this length. 1218785: rjesend formats binary data with incorrect SCB Sometimes, rje would format binary data (in uncompressed format) incorrectly. rje was modified to fix this problem. (Rev 10) -------- 1183197: ======== While output jobs are received by the SUN RJE node on dispatching program, rjesend program got an error as "rjesend: SNA RJE Link: on machine: is not active" (Rev 9) ------- 1182013 & 1181013: ================= When rjesend command sends JCL job, if the line is started a DCB and which is a continuation of the previous line, the "DCB" is changed to "iDDCC.B". (Rev 8) ------- 1176739: ======== When using the "-l" option with the 'rjesend' command, the record size specified is not inserted into the FMH-1 BDS header. 1120964 and 1159303: ==================== When sending an empty file to the IBM host, the SNA RJE link is restarted because the IBM "chokes" when receiving no data. Sending the Unix file: "/etc/termcap" ascii file causes the IBM host to send an UNBIND. When this happens the offending job/file being sent is not removed from the SNA RJE queue. So, the very next and additional executions of SNA RJE will cause this same occurance. Receiving large files from the host did not work. Under Solaris 2.3 from a 'rlogin session, starting the SNA RJE application results in an "accept()" socket connection failure from the SNA RJE client to the 'sna3770' gateway. However, when on a local console window and executing the SNA RJE application, everything works fine. When starting the SNA RJE package and the LU sessions bringup sequences are still being exchanged, jobs in the queue to be sent to the IBM host were not sent. The SNA RJE package would just stop doing work after being up for about a half hour and sending and receiving files. When receiving and multiple SDS FMH headers are sent from host, SNA RJE loses track of the 'scb' byte when uncompressing receive data. (Rev 7) ------- 1159365: ======= On expansion of received compressed data and "end-of-record" also equals "end-of-block", the expansion fails. 1161134: ======= The sna3770 gateway receives 262495 bytes and passes them through to snarje client which show up in the rjetrace. None gets written into /var/spool/rje/node/user, although an empty data file gets created. The rjetrace says it received 0 bytes. (Rev 6) ------- 1169810: ======= This bug refers to the incorrectly built SNA v8.0 patches, which cause the entire package to be removed if a customer backs out the patch. 1169365: ======= The SNA RJE expansion of compressed records is "broken". (Rev 5) ------- 1162509: ======= The SNA RJE gateway is started and the SNA RJE client is brought up. It binds all the lu's and signs on to JES. The 6 reader jobs are started and 4 of them complete. The remaining two jobs just stay in the input queue. (Rev 4) ------- 1159365: **NOTE** This fix has been removed in version 101404-06 of the patch. ======= On expansion of received compressed data and "end-of-record" also equals "end-of-block", the expansion fails. 1156925: ======= Compression of one character records does not work. (Revs 1, 2, & 3) ---------------- 1144030: ======= SNARJE Invalid data on send/No data in rec'd files. 1145608: ======= SNARJE gateway getting sequence and chaining errors. 1146584: ======= Intermittent data loss when using PDIR SNA FMH-2 headers. 1147246: ======= Output from multiple jobs to the SAME emulated printer device from the mainframe causes SNA RJE client to hang. 1147247: ======= Two or more SNA RJE links will not work simultaneously. 1147249: ======= Logon fails if jobs are queued for the gateway. 1147250: ======= If the mainframe is taken down and then it is brought back up again, then SNA RJE locks up. 1147398: ======= Compression fails on boundary of end of block/end of record. 1147424: ======= RPC failures and SNA chaining and unbind problems. 1147981: ======= Send from sun rje hangs. 1147987: ======= If 2 links are active, jobs get queued to the wrong link. 1147992: ======= Supertracs (a JES2 replacement) compressed console data not being sent even though PU is configured for compression. 1147993: ======= If there are jobs to be sent when SNA/RJE is brought up, the send fails. Patch Installation Instructions: -------------------------------- Special Install Instructions: ----------------------------- 1) Documentation Changes: SunLink SNA RJE Client 8.0 User's Guide (801-3810-10) Chapter 2, Configuring the SNA RJE Server Section 2.8.3, Environment Variables If you want the SNA RJE Server to translate FFs and CRs received from the host to NLs, you must define the environment variable SNARJE_XLATE_TO_NL. Chapter 5, Using the Command Line Interface to the SNA RJE Server Section 5.1, SNA RJE Server Commands Section 5.1.5, rjesend Command -b Treat subsequent data sources as fixed length card images. The current -l parameter specifies the length of each image. No ASCII to EBCDIC translation is done. The data is sent in compressed format. -bu Treat subsequent data sources as fixed length card images. The current -l parameter specifies the length of each image. No ASCII to EBCDIC translation is done. The data is not sent in compressed format. Section 5.1.8, rjeretry Command This command allows you to resend to the IBM SNA host a job that had failed earlier. This failed job should be located in the _failures subdirectory. The rjeretry command is invoked as follows: hostname% rjeretry -g [-n ] \ [-sp ] where: This is a required parameter. It is the sequence number of the job in the _failures directory to be processed. It is a number in the range 1-9999. -g This is a required parameter. It specifies the machine where the SunLink SNA RJE gateway and SNA RJE Server processes are running. -n Specifies the Sun user's machine name. It is converted to upper case and pertains to the /var/spool/rje/ spooling directory. -sp Is the location of the spooling directory. The default is /var/spool/rje. This parameter is only required for configurations where the spool directory has been mounted in a nonstandard location. Instructions to install patch using "installpatch" -------------------------------------------------- 1. Become super-user. 2. Apply the patch by typing: //installpatch / where is the directory containing the patch and is the patch number. must be a full path name. Example: # /tmp/123456-01/installpatch /tmp/123456-01 3. If any errors are reported, see "Patch Installation Errors" in the Command Descriptions section below. Rebooting the system or restarting the application after a successful patch installation is usually necessary to utilize patch. NOTE: On client server machines the patch package is NOT applied to existing clients or to the client root template space. Therefore, when appropriate, ALL CLIENT MACHINES WILL NEED THE PATCH APPLIED DIRECTLY USING THIS SAME INSTALLPATCH METHOD ON THE CLIENT. See the next section for instructions for installing a patch on a client. Instructions for installing a patch on a diskless or dataless client -------------------------------------------------------------------- 1. Before applying the patch, the following command must be executed on the server to give the client read-only, root access to the exported /usr file system so that the client can execute the pkgadd command: share -F nfs -o ro,anon=0 /export/exec/Solaris_2.1_sparc.all/usr The command: share -F nfs -o ro,root= \ /export/exec/Solaris_2.1_sparc.all/usr accomplishes the same goal, but only gives root access to the client specified in the command. 2. Login to the client system and become super-user. 3. Continue with step 2 in the "Instructions to install patch using installpatch" section above. Instructions for backing out patch using "backoutpatch" ------------------------------------------------------- 1. Become super-user. 2. Change directory to /var/sadm/patch: cd /var/sadm/patch 3. Backout patch by typing: /backoutpatch where is the patch number. Example: # 123456-01/backoutpatch 123456-01 4. If any errors are reported, see "Patch Backout Errors" in the Command Descriptions section below. Instructions for identifying patches installed on system: ---------------------------------------------------------- Type: installpatch -p This command produces a list of the patch IDs of the patches that are currently applied to the system. When executed with the -p option, the installpatch command does not modify the system in any way. Command Descriptions -------------------- NAME installpatch - apply patch package to Solaris 2.x system backoutpatch - remove patch package from Solaris 2.x system SYNOPSIS installpatch [-u] [-d] backoutpatch DESCRIPTION These installation and backout utilities apply only to Solaris 2.x associated patches. They do not apply to Solaris 1.x associated patches. These utilities are currently only provided with each patch package and are not included with the standard Solaris 2.x release software. OPTIONS installpatch -u unconditional install, do not verify file attributes -d do not save original files being replaced -p print a list of the patches currently applied on the system DIAGNOSTICS Patch Installation Errors: -------------------------- Error message: Patch has already been applied. Explanation and recommended action: This patch has already been applied to the system. If the patch has to be reapplied for some reason, backout the patch and then reapply it. Error message: This patch is obsoleted by a patch which has already been applied to this system. Application of this patch would leave the system in an inconsistent state. Patch installation is aborted. Explanation and recommended action: Occasionally, a patch is replaced by a new patch which incorporates the bug fixes in the old patch and supplies additional fixes also. At this time, the earlier patch is no longer made available to users. The second patch is said to "obsolete" the first patch. However, it is possible that some users may still have the earlier patch and try to apply it to a system on which the later patch is already applied. If the obsoleted patch were allowed to be applied, the additional fixes supplied by the later patch would no longer be available, and the system would be left in an inconsistent state. This error message indicates that the user attempted to install an obsoleted patch. There is no need to apply this patch because the later patch has already supplied the fix. Error message: The packages to be patched are not installed on this system. Explanation and recommended action: None of the packages to be updated by this patch are installed on the system. Therefore, this patch cannot be applied to the system. Error message: This patch is not applicable to client systems. Explanation and recommended action: The patch is only applicable to servers and standalone machines. Attempting to apply this patch to a client system will have no effect on the system. Error message: The /usr/sbin/pkgadd command is not executable. Explanation and recommended action: The /usr/sbin/pkgadd command cannot be executed. The most likely cause of this is that installpatch is being run on a diskless or dataless client and the /usr file system was not exported with root access to the client. See the section above on "Instructions for installing a patch on a diskless or dataless client". Error message: Patch directory is not of expected format. Explanation and recommended action: The patch directory supplied as an argument to installpatch did not contain any patch packages. Verify that the argument supplied to installpatch is correct. Error message: The following validation errors were found: Explanation and recommended action: Before applying the patch, the patch application script verifies that the current versions of the files to be patched have the expected fcs checksums and attributes. If a file to be patched has been modified by the user, the user is notified of this fact. The user then has the opportunity to save the file and make a similar change to the patched version. For example, if the user has modified /etc/inet/inetd.conf and /etc/inet/inetd.conf is to be replaced by the patch, the user can save the locally modified /etc/inet/inetd.conf file and make the same modification to the new file after the patch is applied. After the user has noted all validation errors and taken the appropriate action for each one, the user should re-run installpatch using the "-u" (for "unconditional") option. This time, the patch installation will ignore validation errors and install the patch anyway. Error message: Insufficient space in /var/sadm to save old files. Explanation and recommended action: There is insufficient space in the /var/sadm directory to save old files. The user has two options for handling this problem: (1) generate additional disk space by deleting unneeded files, or (2) override the saving of the old files by using the "-d" (do not save) option when running installpatch. However if the user elects not to save the old versions of the files to be patched, backoutpatch CANNOT be used. One way to regain space on a system is to remove the save area for previously applied patches. Once the user has decided that it is unlikely that a patch will be backed out, the user can remove the files that were saved by installpatch. The following commands should be executed to remove the saved files for patch xxxxxx-yy: cd /var/sadm/patch/xxxxxx-yy rm -r save/* rm .oldfilessaved After these commands have been executed, patch xxxxxx-yy can no longer be backed out. Error message: Save of old files failed. Explanation and recommended action: Before applying the patch, the patch installation script uses cpio to save the old versions of the files to be patched. This error message means that the cpio failed. The output of the cpio would have been preceded this message. The user should take the appropriate action to correct the cpio failure. A common reason for failure will be insufficient disk space to save the old versions of the files. The user has two options for handling insufficient disk space: (1) generate additional disk space by deleting unneeded files, or (2) override the saving of the old files by using the "-d" option when running installpatch. However if the user elects not to save the old versions of the files to be patched, the patch CANNOT be backed out. Error message: Pkgadd of package failed. See /tmp/log. for reason for failure. Explanation and recommended action: The installation of one of patch packages failed. Any previously installed packages in the patch should have been removed. See the log file for the reason for failure. Correct the problem and re-apply the patch. Error message: error while adding patch to root template Explanation and recommended action: The install script determined this system to be a client server. The attempt to apply the patch package to the appropriate root template space located under /export/root/templates failed unexpectedly. Check the log file for any failure messages. Correct the problem and re-apply the patch. Patch Backout Errors: --------------------- Error message: Patch has not been applied to this system. Explanation and recommended action: The user has attempted to back out a patch that was never applied to this system. It is possible that the patch was applied, but that the patch directory /var/sadm/patch/ was deleted somehow. If this is the case, the patch cannot be backed out. The user may have to restore the original files from the initial installation CD. Error message: Patch was installed without backing up the original files. It cannot be backed out. Explanation and recommended action: Either the -d option of installpatch was set when the patch was applied, or the save area of the patch was deleted to regain space. As a result, the original files are not saved and backoutpatch cannot be used. The original files can only be recovered from the original installation CD. Error message: Pkgrm of package failed. See /var/sadm/patch//log for reason for failure. Explanation and recommended action: The removal of one of patch packages failed. See the log file for the reason for failure. Correct the problem and run the backout script again. Error message: Restore of old files failed. Explanation and recommended action: The backout script uses the cpio command to restore the previous versions of the files that were patched. The output of the cpio command should have preceded this message. The user should take the appropriate action to correct the cpio failure. KNOWN PROBLEMS: On client server machines the patch package is NOT applied to existing clients or to the client root template space. Therefore, when appropriate, ALL CLIENT MACHINES WILL NEED THE PATCH APPLIED DIRECTLY USING THIS SAME INSTALLPATCH METHOD ON THE CLIENT. See instructions above for applying patches to a client. After a patch package has been installed pkginfo(1) will not recognize the SUNW_PATCHID macro in the patch package pkginfo file. Instead, to identify patches installed on the system use the grep command method described in the patch README. The pkgadd command shipped with Solaris 2.1 fails (drops core without any error message) when there are more than 100 entries in the /etc/mnttab file. This means that installpatch can fail, because it uses pkgadd. Since this is very likely on any big system with lots of automounts, ANY patch could fail. Applying patch 100901-01 fixes this problem (the README for patch 100901 mentions shutting down the automounter while applying it). SEE ALSO pkgadd(1), pkgchk(1), pkgrm(1), pkginfo(1)