← All Articles

Slave Printer Session: Transparent Host Print Passthrough

A slave printer session is a dedicated TN5250E connection that presents itself to the AS/400 (IBM i) as a network printer device. The host routes SCS print jobs directly to this connection, and IMTerm converts them to PDF and dispatches them to the configured local printer - without any user interaction. The user's terminal session and the print session are separate connections to the same host.


What Is a Slave Printer Session

When a user runs a report or a batch process produces printed output on the AS/400, the output lands in a spool queue. A printer device on the system picks up the job from the queue and sends the SCS data stream over a TN5250E connection to a network printer endpoint.

IMTerm's slave printer session acts as that network printer endpoint. It opens a TN5250E connection with device type *PRT (or IBM-3812-1), negotiates as a printer session, and then waits for the AS/400 to send spool jobs. When a job arrives, IMTerm:

  1. Receives the raw SCS (SNA Character Stream) data from the host
  2. Decodes EBCDIC characters using the configured CCSID
  3. Runs the SCS through the built-in parser to produce a PDF
  4. Dispatches the PDF to the configured print queue (CUPS, LPR, or saved as PDF)

This happens in the background. Users do not need to do anything - they print from their AS/400 applications exactly as they always have, and the output appears on the physical printer.


When You Need It

Use a slave printer session when:

  • The AS/400 routes print jobs to a specific device name (not a shared output queue that users browse manually)
  • Print jobs must reach a physical printer without user intervention - batch reports, payroll runs, invoice printing
  • You are replacing a dedicated hardware printer or a legacy print server that presented a TN5250E printer session to the AS/400
  • You need to archive all print output centrally (combine with Print Archive Pro)

If your users prefer to browse their own spool files and download PDFs on demand, use the Spool File Viewer instead. The two approaches can run simultaneously.


Device Types: IBM-3812-1 vs *PRT

Device type When to use Notes
IBM-3812-1 Named device - jobs go to a specific device description on the AS/400 The device description (DEVD) must exist or be auto-created. Recommended for production use.
*PRT Pool printer - the AS/400 assigns a device from a pool The AS/400 selects any available printer device from a defined pool. Easier setup but less control over routing.

For most deployments, use IBM-3812-1 with a fixed device name. The device name appears in AS/400 output queues, reports, and audit trails, making it easy to track where jobs are being sent.


How SCS Data Flows

The data flow is entirely server-side - the user's browser is not involved:

AS/400 spool queue
       |
  TN5250E printer session (port 449 or 992 for TLS)
       |
  IMTerm slave printer connection (persistent, auto-reconnects)
       |
  SCS parser (pure Go, built-in)
       |
  EBCDIC decode (using configured CCSID)
       |
  PDF generator
       |
  Print dispatcher: CUPS queue / LPR / PDF file / Print Archive

The connection is persistent - IMTerm opens it at startup and reconnects automatically if the AS/400 or network is interrupted. The auto_reconnect setting controls the reconnect behavior (see config below).


Connection Profile

Configure slave printer sessions in config.yaml under printer_sessions. Each entry defines one printer session (one device on the AS/400):

printer_sessions:
  - name: IMTRMPRN1             # display name in admin console
    host: as400.corp.com
    port: 449                   # TN5250E printer port; use 992 for TLS
    device_type: printer        # tells IMTerm this is a slave printer session
    term_type: IBM-3812-1       # what to present to the AS/400
    device_name: IMTRMPRN1      # AS/400 device description name
    ccsid: 424                  # 424 = Hebrew New; 37 = US English; 500 = International
    output: cups                # where to send completed jobs
    cups_queue: lp0
    auto_reconnect: true
    reconnect_delay_sec: 30

  - name: IMTRMPRN2
    host: as400.corp.com
    port: 449
    device_type: printer
    term_type: IBM-3812-1
    device_name: IMTRMPRN2
    ccsid: 37
    output: pdf
    pdf_dir: /var/lib/imterm/printjobs

The device_type: printer field in the connection profile is what switches IMTerm into slave printer mode for that session. Without it, the session would be treated as an interactive terminal session.


CCSID Configuration

The CCSID (Coded Character Set Identifier) tells IMTerm how to decode the EBCDIC bytes in the SCS stream. Common values:

CCSID Encoding Use when
424 EBCDIC Hebrew (New) Israeli AS/400 systems with Hebrew applications
803 EBCDIC Hebrew (Old) Older Israeli systems using the old Hebrew encoding
37 EBCDIC US English US/international AS/400 systems
500 EBCDIC International Multi-language environments
0 Auto-detect IMTerm reads the CCSID from the TN5250E NEW-ENVIRON negotiation

Set ccsid: 0 to let IMTerm detect the CCSID automatically from the TN5250E negotiation. This works reliably when the AS/400 advertises the CCSID in the NEW-ENVIRON exchange. For Hebrew systems, set it explicitly to 424 to avoid any ambiguity.


REST API

Printer sessions can also be managed via the REST API. This is useful for provisioning sessions programmatically or integrating with configuration management systems.

Create a new printer session:

curl -X POST https://imterm.corp.com/api/print/sessions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "IMTRMPRN3",
    "host": "as400.corp.com",
    "port": 449,
    "termType": "IBM-3812-1",
    "deviceName": "IMTRMPRN3",
    "ccsid": 424,
    "output": "cups",
    "cupsQueue": "lp1"
  }'

List all printer sessions:

curl https://imterm.corp.com/api/print/sessions \
  -H "Authorization: Bearer $TOKEN"

The response includes the current connection state (connected, disconnected, reconnecting) and the count of jobs processed since startup.


Supported Printers

IMTerm dispatches completed print jobs as PDFs. Any printer that can accept PDF via CUPS or LPR is supported. This includes:

  • CUPS printers - any printer registered in CUPS on the IMTerm server. Use output: cups and set cups_queue to the CUPS queue name (lpstat -p lists available queues).
  • LPR/LPD network printers - any printer or print server that accepts LPR (RFC 1179). Use output: lpr with lpr_host and lpr_port.
  • PDF file output - save each job as a PDF in a directory. Use output: pdf with pdf_dir. Useful for archiving or integration with document management systems.
  • Print Archive Pro - with archive.enabled: true, every job is also indexed in the searchable compliance archive, regardless of the primary output destination.

For Windows printing from a Linux IMTerm server, the easiest approach is to add the Windows shared printer to CUPS using the SMB backend, then point the slave printer session at that CUPS queue.


Troubleshooting

Session stays in "Connecting" state

Check that port 449 (or 992 for TLS) is open from the IMTerm server to the AS/400. Run WRKCFGSTS CFGTYPE(*DEV) CFGD(IMTRMPRN1) on the AS/400 to check the device status. If the device is already held by another session, vary it off first: VRYCFG CFGOBJ(IMTRMPRN1) CFGTYPE(*DEV) STATUS(*OFF).

Jobs arrive but PDF is blank

The AS/400 may have Host Print Transform (HPT) enabled, which converts the SCS stream to PCL before sending it. IMTerm expects raw SCS. Disable HPT on the device description: CHGDEVPRT DEVD(IMTRMPRN1) TRANSFORM(*NO).

Hebrew characters print as question marks

The CCSID in the printer session configuration does not match the AS/400 output queue's CCSID. Check the output queue's CCSID with WRKOUTQ OUTQ(queuename) and update the printer session's ccsid to match.

Session auto-reconnects but jobs are lost during reconnect

Jobs sent while the printer session is reconnecting are held in the AS/400 output queue and will be sent after the session reconnects. The AS/400 retries job delivery automatically. No jobs are permanently lost unless the session remains disconnected longer than the AS/400's retry timeout (default: no timeout, jobs wait indefinitely).