Fix Network Printer Problems

When network printouts are not printing, the following steps are recommended.
cadts151
When network printouts are not printing, the following steps are recommended.
Check the Release of SC00TRAN
To check the SC00TRAN release, issue one of the following commands. If you are using
Datacom CICS Services
, you can use the following command:
DBUT M=SC00TRAN +2A
If you are using
IPC
, you can use the following command:
@I$SCF PGM=SC00TRAN OFF=2A.
The resulting display should show either NETT or your default network print transaction. If not, an old copy of SC00TRAN is being picked up. Reassemble SC00TRAN and recycle.
Verify CICS Printers
If one or more printers are not working at all, verify that CICS is able to print to a specific printer. Issue the following command in native CICS:
CMSG 'text here',R=ntid,SEND
Where
ntid
is the 4-character network printer ID. This is a transaction distributed with CICS that prints the message you specify in quotes to the printer. It does not control paging, so you want to make sure that no one is printing to the printer at the time you try this command.
Check NETT Tasks
Verify that the NETT transaction is enabled with the CEMT INQ TRAN(NETT) command. Check the MAX value for the TRANCLASS with the CEMT INQ TCL command, if a TRANCLASS was specified for NETT. Use the CEMT INQ TASK command to look for all NETT tasks. Some NETT tasks could be suspended due to TRANCLASS Max task limitation, which can be a valid limitation in the CICS environment.
Check the Network Print Table (NPT)
The network print table (NPT) may not be built.
Make sure that the program SCPSPLTI is in the PLT startup. You should see the following message during CICS startup:
ICPSPLTI01I - TASK NETT SUCCESSFULLY STARTED
If that message does not appear, issue the NETT transaction from native CICS to build the network print table. (You do not get any message back from this transaction as to what it did). If this was the problem, things should start printing. Your site will need to enter the NETT transaction from native CICS each time CICS is brought up until the SCPSPLTI program is added to the PLT.
Check Security Packages
Security packages could cause problems with network printing.
Check to see if the NETT transaction is secured by CICS or a security package, such as
Top Secret
,
ACF2
, or RACF. NETT is an asynchronous transaction so the user probably will not receive any message that is issued by the security package. A CICS auxtrace may also help in finding out if this is the problem.
Abends in NETT
Check the dump dataset for transaction abends in NETT. Because NETT is an asynchronous transaction, the user who initiated the print request does not receive the ASRA at his terminal. If any abend is found in the dump dataset, follow normal procedures for any abend found in the dump dataset, follow normal procedures for resolving abends.
Check ADROUT
ADROUT could be corrupted. If ADROUT is corrupted, it is unlikely that your only printer-related problem will be the inability to print to network printers. Verify the following:
  • Able to print to system printers
  • Whether recovery seems to be working
  • Result of issuing the commands DIS OUT STA, DIS OUT DEST, and similar commands
If ADROUT is corrupted, follow these steps:
  1. Close the file.
  2. Back it up using VLSUTIL and a straight dataset backup. (This step may be useful in determining what caused the corruption.)
    Before performing the next steps, make sure you have an
    Ideal for Datacom
    member containing a DEFINE OUTPUT DESTINATION command for each destination, because running these jobs deletes the Destination Table.
  3. Run VLSUTIL FORMAT function
  4. Run SCPSUTIL INIT function
  5. Recycle CICS.
If taking these steps resolves the problem, try to determine the cause of the problem. Look for storage violations, internal errors, and abends that may have occurred around the time the problem with printing started. Were any utilities like SCPSUTIL or VLSUTIL run that would have updated ADROUT in some fashion?