RSCS 3.2.0 Common Problems and Solutions
Product Number: 5684-096 Release 3.2.0
To receive a notice whenever this web page changes, click here.
What are the recommendation's when defining a TN3270E-type link?
- Use the auto-start parameter when defining the link to RSCS.
- Make use of the initial timeout (ITO) parameter. The default ITO setting is 0 which will cause the link to automatically drain when there are no files to be processed. This will preserve the auto-start parameter.
- it is not recommended to have a TCP/IP exit issue commands to RSCS (such as START, DRAIN, or STOP) that will cause auto-start to be disabled.
How can I avoid having files and messages queued to an LPD- or UFTD-type link?
You can route all traffic destined for an LPD- and UFTD-type link to another link, such as a notify link. A sample route configuration statement would look like:
ROUTE LPD TO *UNKNOWN ROUTE UFTD TO *UNKNOWNThe notify link could be defined to specifically handle traffic destined for an LPD- or UFTD-type link only.
I have defined an RSCS LPR-type link for handling a printer attached directly to a LAN. Occasionally, RSCS issues message DMT184E (Link linkid received NAK from host; file held NAK message=.). Most, but not all, of the file is printer. Other files will print but never this one.
We have seen this problem based on a specific byte count. Add or remove a byte and the problem doesn't occur. In the instances we have investigated, the problem only occurs on printers that are at an old microcode level. Check with your printer manufacture to see if the printer microcode level requires updating.
I installed RSCS RSU 9801 or 9802, now I am having NJE link problems
CP APARS VM61399 and VM61468 as well as RSCS APAR VM61888 must be applied when installing the RSCS RSU to correct CP performance problems, FRF002 or UDR001 abends and RSCS NJE link hangs (caused when receiving files containing no records), which are all due to RSCS's use of ASYNCHRONOUS CLOSE.
I installed RSU 9801, now some of my LPR-type links are not printing correctly.
RSCS APAR VM61312 (included on RSU 9801) changed how the LPR-type links handle original record length. Before this APAR, DMTLPR was not restoring the original blanks. LPRXPSE was attempting to, and in some instances, restored ASCII blanks instead of EBCDIC blanks. With this APAR, DMTLPR will now restore original blanks to the end of records for fixed length files. If you are having strange print problems, it could be because blanks are being restored after each record. Try printing the file as a variable record length file instead of fixed.
How should I order RSCS 3.2 when ordering VM/ESA 2.3.0?
RSCS 3.2 is pre-installed on the DDR tapes for VM/ESA 2.3.0. If you are already licensed for RSCS 3.2, then there is nothing further you need to order for RSCS. If you are not currently licensed for RSCS 3.2 and desire to, then order RSCS 3.2 indicating you wish to suppress media shipment. This will license you for RSCS 3.2 and only the manuals will be shipped.
An RSCS TCP/IP link connect attempt to the remote host is failing with socket error error number 49, EADDRNOTAVAIL (Cannot assign requested address). But doing a PING or using the VM/TCPIP LPR command works.
VM/TCPIP APAR PQ19377 may correct this failure.
Message DMTLPR195E is received when RSCS attempts to send a print job to a remote LPR daemon. This usually is due to an incorrect printer queue name. What are some common (and unique) printer queue names?
raw (HP), text (HP), lp (Xerox, Lexmark, sometimes defined as LP), print_cr, PASS (IBM Network Printer and INFOPRINT), LPT1_PASSTHRU, d1prn (for the IBM 6400 which can also be d2prn, d3prn, and d4prn).
When starting an LPR link, a bind socket error, PERMISSION DENIED, occurs.
This can occur when the ASSORTEDPARMS statement in the TCP/IP configuration has the RESTRICTLOWPORTS option specified. To solve this problem:
- Specify PORT statements for ports 721-731 authorizing the RSCS
- Specify the SECure=No LPR link parameter to cause RSCS to use ports 1024-2048 instead of 721-731.
Timeouts occasionally occur on LPR links.
There are several reasons this problem can occur. Some potential solutions to try include:
- Make sure the printer (or LAN card if directly connected to a LAN) has latest microcode installed.
- Increase the timeout value LPR link parameter.
- Increase the TCP/IP packet size