X3270-SCRIPT(1)

📦 version 4.0ga14, in centos-stream 9

💖 X3270-SCRIPT(1) 💖

From General Commands Manual, bestie — this is the scripting-facilities page for x3270, c3270, and s3270. Buckle up, because it’s giving “your terminal has main character energy” ✨

🌸 NAME 🌸

Scripting Facilities for x3270, c3270 and s3270

✨ SYNOPSIS ✨

x3270 -script [ x3270-options ]
x3270 -socket [ x3270-options ]
x3270 -scriptport port [ x3270-options ]
c3270 -socket [ c3270-options ]
c3270 -scriptport port [ s3270-options ]
s3270 [ s3270-options ]
Script ( command [ ,arg... ] )

🦋 DESCRIPTION 🦋

Okay so the x3270 scripting facilities are how you let another program drive the interactive 3270 emulators x3270 and c3270. They’re also literally the whole foundation of s3270, the script-only emulator. 💅

There are four basic scripting methods, bestie:

  1. The first is the peer script facility, invoked by the x3270 -script switch, and it’s the default mode for s3270. This runs the emulator as a child of another process. Typically that other process is a script using expect(1), perl(1), or the co-process facility of the Korn Shell ksh(1). In this mode, the emulator process looks for commands on its standard input and puts the responses on standard output. 🫶
  2. The second method is the child script facility, invoked by the emulator’s Script() action. This runs a script as a child process of the emulator. The child gets pipes connected to the emulator: the emulator looks for commands on one pipe and puts responses on the other. The file descriptor of the pipe for commands to the emulator is passed in the environment variable X3270INPUT — for example, the text string "7" if the file descriptor is 7. The file descriptor of the pipe for responses from the emulator is passed in the environment variable X3270OUTPUT. 🎀
  3. The third method uses a TCP socket. The -scriptport option from the synopsis (the DESCRIPTION text in this page spells it -scrpiptport once, so 💀 spelling-check energy) causes the emulator to bind a socket to the specified port on the IPv4 loopback address, 127.0.0.1. The emulator accepts TCP connections on that port, and multiple commands and responses can be sent over each connection. 🌈
  4. The fourth method uses a Unix-domain socket. The -socket command-line option causes the emulator to create a Unix-domain stream socket named /tmp/x3sck.pid. The emulator accepts connections to that socket, and multiple commands and responses can be sent over each connection. 🦋

You can nest these methods, no cap. For example, a peer or TCP socket script can invoke the Script() action. The calling script will be resumed when the nested script completes. 🔥

Commands are emulator actions. The syntax is the same as for the right-hand side of an x3270 or c3270 keymap. Unlike translation tables, action names are case-insensitive, can be uniquely abbreviated, and the parentheses may be omitted if there are no parameters. Any input line that begins with # or ! is treated as a comment and will be ignored. 🙈

Any emulator action may be specified. Several specific actions have been defined for use by scripts, and the behavior of certain other actions — and of the emulators in general — is different when an action is initiated by a script. 👑

Some actions generate output; some may delay completion until certain external events occur, such as the host unlocking the keyboard. The completion of every command is marked by a two-line message. The first line is the current status of the emulator, documented below. If the command is successful, the second line is the string "ok"; otherwise it is the string "error". 😭

🎀 STATUS FORMAT 🎀

The status message consists of 12 blank-separated fields:

  1. Keyboard State — If the keyboard is unlocked, the letter U. If the keyboard is locked waiting for a response from the host, or if not connected to a host, the letter L. If the keyboard is locked because of an operator error (field overflow, protected field, etc.), the letter E.
  2. Screen Formatting — If the screen is formatted, the letter F. If unformatted or in NVT mode, the letter U.
  3. Field Protection — If the field containing the cursor is protected, the letter P. If unprotected or unformatted, the letter U.
  4. Connection State — If connected to a host, the string C(hostname). Otherwise, the letter N.
  5. Emulator Mode — If connected in 3270 mode, the letter I. If connected in NVT line mode, the letter L. If connected in NVT character mode, the letter C. If connected in unnegotiated mode (no BIND active from the host), the letter P. If not connected, the letter N.
  6. Model Number (2-5)
  7. Number of Rows — The current number of rows defined on the screen. The host can request that the emulator use a 24x80 screen, so this number may be smaller than the maximum number of rows possible with the current model.
  8. Number of Columns — The current number of columns defined on the screen, subject to the same difference for rows, above.
  9. Cursor Row — The current cursor row (zero-origin).
  10. Cursor Column — The current cursor column (zero-origin).
  11. Window ID — The X window identifier for the main x3270 window, in hexadecimal preceded by 0x. For s3270 and c3270, this is zero.
  12. Command Execution Time — The time that it took for the host to respond to the previous command, in seconds with milliseconds after the decimal. If the previous command did not require a host response, this is a dash. ⭐

💜 DIFFERENCES 💜

When an action is initiated by a script, the emulators behave in several different ways:

  • If an error occurs in processing an action, the usual pop-up window does not appear. Instead, the text is written to standard output. 🫶
  • If end-of-file is detected on standard input, the emulator exits. A script can exit without killing the emulator by using the CloseScript() action, below. Note that this applies to peer scripts only; end-of-file on the pipe connected to a child script simply causes the pipes to be closed and the Script() action to complete. 😭
  • The Quit() action always causes the emulator to exit. When called from the keyboard, it will exit only if not connected to a host. 💀
  • Normally, the AID actions (Clear(), Enter(), PF(), and PA()) will not complete until the host unlocks the keyboard. If the parameter to a String() action includes a code for one of these actions, it will also wait for the keyboard to unlock before proceeding. ⌨️
  • The AidWait toggle controls this behavior. When this toggle is set (the default), actions block as described above. When the toggle is clear, AID actions complete immediately. The Wait(output) action can then be used to delay a script until the host changes something on the screen, and the Wait(unlock) action can be used to delay a script until the host unlocks the keyboard, regardless of the state of the AidWait toggle. 🌀
  • Note that the Script() action does not complete until end-of-file is detected on the pipe or the CloseScript() action is called by the child process. This behavior is not affected by the state of the AidWait toggle. ✨

🌟 BASIC PROGRAMMING STRATEGIES 🌟

3270 session scripting can be more difficult than other kinds of scripting, because it can be hard to tell when the host is finished processing a command. There is a well-defined 3270 Data Stream facility for doing this: the emulator locks the keyboard when it sends the host an AID, and the later host unlocks the keyboard. The emulator supports this facility directly by not allowing an AID action to complete until the keyboard is unlocked. 😌

Unfortunately, some hosts and some host applications unlock the keyboard as soon as they begin processing the command, instead of after it is finished. A human operator can see on the screen when the command is finished (e.g., when a READY prompt is displayed), but it can be difficult for a script to do this. For such early-unlock hosts, the only option in a script is to poll the screen until it can determine that the command is complete. 👀

Another complication is that host I/O and script operation are asynchronous. That is, the host can update the screen at any time, even between actions that are reading the screen contents, so a script can get inconsistent results. Assistance for this problem is provided by the Snap() action. The Snap(save) action saves a snapshot of the screen in a special buffer. Then the script can use Snap() variants of the Ascii1() and Ebcdic1() actions (Snap(Ascii1) and Snap(Ebcdic1)) to query the saved buffer — which the host cannot modify — to get the data it wants. Finally, Snap(wait,output) blocks the script until the host modifies the screen, specifically since the last call to Snap(save). Thus a script can poll the screen efficiently by writing a loop that begins with Snap(save) and ends with Snap(wait,output). 🔁

💅 SCRIPT-SPECIFIC ACTIONS 💅

The following actions have been defined or modified for use with scripts. Note that actions that use row and column coordinates generally use an origin of 1, with row 1 at the top and column 1 at the left. This is consistent with the on-screen cursor position and data stream trace messages. 🎯

AnsiText()

Outputs whatever data has been output by the host in NVT mode since the last time that AnsiText() was called. The data is preceded by the string "data: ", and has had all control characters expanded into C backslash sequences. 🍓

This is a convenient way to capture NVT mode output in a synchronous manner without trying to decode the screen contents. 😌

Ascii1(row,col,rows,cols)

Ascii1(row,col,length)

Ascii1(length)

Ascii1()

Outputs an ASCII text representation of the screen contents. Each line is preceded by the string "data: ", and there are no control characters. ✨

If four parameters are given, a rectangular region of the screen is output. Note that the row and column are 1-origin. 📐

If three parameters are given, length characters are output, starting at the specified 1-origin row and column. 🔢

If only the length parameter is given, that many characters are output, starting at the cursor position. 📍

If no parameters are given, the entire screen is output. 🖥️

The EBCDIC-to-ASCII translation and output character set depend on both the emulator host code page (the -codepage option) and the locale. UTF-8 and certain DBCS locales may result in multi-byte expansions of EBCDIC characters that translate to ASCII codes greater than 0x7f. 🌍

AsciiField()

Outputs an ASCII text representation of the field containing the cursor. The text is preceded by the string "data: ". 🎀

Connect(hostname)

Connects to a host. The command does not return until the emulator is successfully connected in the proper mode, or the connection fails. 🔌

  • CloseScript(status) — tells the emulator to stop reading commands from the script, bestie 💅. This is lowkey iconic for letting a peer script exit while the emulator keeps going interactively. (Without this, the emulator would just exit the moment it detected end-of-file on standard input. Rude.) If the script was invoked by the Script() action, the optional status becomes the return status of Script() — and if it's nonzero, Script() completes with an error, and if this script was invoked as part of login through the ibm_hosts file, the connection gets broken. So like… use with intention ✨
  • Disconnect() — disconnects from the host. That's it, that's the whole vibe 🦋
  • Ebcdic1(row,col,rows,cols)
  • Ebcdic1(row,col,length)
  • Ebcdic1(length)
  • Ebcdic1() — same function as Ascii1() above, except instead of generating ASCII text, each character is output as a 2-digit or 4-digit hexadecimal EBCDIC code 🔥
  • EbcdicField() — same function as AsciiField() above, except it generates hexadecimal EBCDIC codes 🎀
  • Info(message) — in x3270, pops up an informational message. In c3270 and wc3270, writes an informational message to the OIA (that's the line below the display, iykyk). Not defined for s3270 or tcl3270 🙈
  • Expect(text[,timeout]) — pauses the script until the specified text shows up in the data stream from the host, or until the specified timeout (in seconds) expires ⏳. If you don't give a timeout, the default is 30 seconds. Text can contain standard C-language escape (backslash) sequences. No wild-card characters or pattern anchor characters are understood — like, none, don't try it. And heads up: Expect() is valid only in NVT mode 🫶
  • MoveCursor1(row,col) — moves the cursor to the specified 1-origin coordinates ✨
  • MoveCursor1(offset) — moves the cursor to the specified offset. Offset 0 is the upper left-hand corner of the screen 🎯
  • PrintText([command,]filter) — pipes an ASCII representation of the current screen image through the named filter, e.g., lpr 🖨️
  • PrintText([html,][append,][replace,]file,filename) — saves the current screen contents in a file. With the html option it saves it as HTML, otherwise as plain ASCII. The append option (which is the default, fyi) causes the data to be appended to the file if it already exists. The replace option causes the file to be overwritten instead 💾
  • PrintText(html,string) — returns the current screen contents as HTML 🌈
  • Query(keyword) — returns state information. The keywords are:
    • BindPluName — BIND PLU returned by the host
    • ConnectionState — TN3270/TN3270E mode and submode
    • CodePage — Host code page
    • Cursor — Cursor position (row col) zero-origin
    • Cursor1 — Cursor position (row col) 1-origin
    • Formatted — 3270 format state (formatted or unformatted)
    • Host — Host name and port
    • LocalEncoding — Local character encoding
    • LuName — Host name LU name
    • Model — 3270 model name (IBM-327x-n)
    • ScreenCurSize — Current screen size (rows cols)
    • ScreenMaxSize — Maximum screen size (rows cols)
    • Tls — TLS state (secure or not-secure) and host validation state (host-verified or host-unverified)

Without a keyword, Query() returns each of the defined attributes, one per line, labeled by its name 🏷️

  • ReadBuffer(ascii) — dumps the contents of the screen buffer, one line per row 📋. Each buffer position inside a data field is generally output as a 2-digit hexadecimal code, translated from the host EBCDIC code page to the current locale. (E.g., the EBCDIC value for the letter A in host code page 037 is X'C1'. In ASCII, this is 0x41, so it is output as 41.) If the current locale specifies a multi-byte character set such as UTF-8, some positions may be output as 4-, 6- or 8-digit codes. (E.g., in host code page 037, the EBCDIC value for a U+00ac NOT symbol is X'5F'. In UTF-8, this is 0xc2, 0xac, so it is output as c2ac.) DBCS characters take two positions in the screen buffer; the first location is output as a multi-byte code, and the second location is output as a dash. Start-of-field characters (each of which takes up a display position) are output as SF(aa=nn[,...]), where aa is a field attribute type and nn is its value:
    • c0 basic 3270 — 20 protected, 10 numeric, 04 detectable, 08 intensified, 0c non-display, 01 modified
    • 41 highlighting — f1 blink, f2 reverse, f4 underscore, f8 intensify
    • 42 foreground — f0 neutral black, f1 blue, f2 red, f3 pink, f4 green, f5 turquoise, f6 yellow, f7 neutral white, f8 black, f9 deep blue, fa orange, fb purple, fc pale green, fd pale turquoise, fe grey, ff white
    • 43 character set — f0 default, f1 APL, f8 DBCS

Extended attributes (which do not take up display positions) are output as SA(aa=nn), with aa and nn having the same definitions as above (though the basic 3270 attribute will never appear as an extended attribute).

NULL characters in the screen buffer are reported as ASCII character 00 instead of 20, even though they are displayed as blanks 👀

  • ReadBuffer(ebcdic) — equivalent to ReadBuffer(ascii), but with the data fields output as hexadecimal EBCDIC codes. If a buffer position has the Graphic Escape attribute, it is displayed as GE(xx). If a buffer position was written in NVT mode, it does not have an EBCDIC value, and will be displayed as 00 💜
  • ReadBuffer(unicode) — equivalent to ReadBuffer(ascii), but with the data fields output as 4-digit hexadecimal Unicode values ⭐
  • ReadBuffer(field) — dumps information about the current field. The ascii, ebcdic and unicode keywords are also accepted. The output consists of keywords and parameters. Note that field start is the location of the start-of-field character, which is displayed on the screen as a blank to the left of the field, and is dumped as SF. The Contents line is always last 🧚
    • Start1 — row col — Field start coordinates (1-origin)
    • StartOffset — offset — Field start location as offset
    • Cursor1 — row col — Cursor coordinates (1-origin)
    • CursorOffset — offset — Cursor location as offset
    • Contents — contents — Field contents on one line in ReadBuffer() format
  • Script(path[,arg...]) — runs a child script, passing it optional command-line arguments. path must specify an executable (binary) program: the emulator will create a new process and execute it. If you simply want the emulator to read commands from a file, use the Source() action instead 🫡
  • Snap() — equivalent to Snap(save) (see below) 📸
  • Snap(Ascii1,...) — performs the Ascii1 action on the saved screen image ✨
  • Snap(Cols) — returns the number of columns in the saved screen image 📐
  • Snap(Ebcdic1,...) — performs the Ebcdic1() action on the saved screen image 🎀
  • Snap(ReadBuffer) — performs the ReadBuffer() action on the saved screen image 📋
  • Snap(Rows) — returns the number of rows in the saved screen image 📏
  • Snap(save) — saves a copy of the screen image and status in a temporary buffer. This copy can be queried with other Snap() actions so a script can examine a consistent screen image, even when the host may be changing the image (or even the screen dimensions) dynamically. Honestly? Chef's kiss consistency 💅
  • Snap(status) — returns the status line from when the screen was last saved 🏷️
  • Snap(wait[,timeout],output) — pauses the script until the host sends further output, then updates the snap buffer with the new screen contents. Used when the host unlocks the keyboard (allowing the script to proceed after an Enter(), PF() or PA() action), but has not finished updating the screen. This action is usually invoked in a loop that uses the Snap(Ascii1) or Snap(Ebcdic1) action to scan the screen for some pattern that indicates that the host has fully processed the last command 🔁

Quick Snap() timeout tea: the optional timeout parameter is a number of seconds to wait before failing the Snap() action. Default? Wait indefinitely, bestie. ⏳💅

  • Source(file) — Reads and executes commands from file. Any output from those commands becomes the output from Source(). If any of the commands fails, Source() will not abort — it keeps reading commands until EOF. 🫶
  • Title(text) — Changes the x3270 window title to text. Main character energy for your window bar. ✨
  • Transfer(keyword=value,...) — Invokes IND$FILE file transfer. See FILE TRANSFER below. 📦
  • Wait([timeout,] 3270mode) — For hosts that switch between NVT mode and 3270 mode. Pauses the script or macro until the host negotiates 3270 mode, then waits for a formatted screen as above. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. For backwards compatibility, Wait(3270) is equivalent to Wait(3270mode). 🦋
  • Wait([timeout,] disconnect) — Pauses the script until the host disconnects. Often used after sending a logoff command to a VM/CMS host, to ensure that the session is not unintentionally set to disconnected state. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. 👋
  • Wait([timeout,] inputfield) — A useful utility for use at the beginning of scripts and after the Connect() action. In 3270 mode, waits until the screen is formatted and the host has positioned the cursor on a modifiable field. In NVT mode, waits until the host sends at least one byte of data. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. For backwards compatibility, Wait is equivalent to Wait(inputfield). 🎀
  • Wait([timeout,] nvtmode) — For hosts that switch between 3270 mode and NVT mode. Pauses the script or macro until the host negotiates NVT mode, then waits for a byte from the host as above. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. For backwards compatibility, Wait(ansi) is equivalent to Wait(nvtmode). 🌈
  • Wait([timeout,] output) — Pauses the script until the host sends further output. Often needed when the host unlocks the keyboard (allowing the script to proceed after a Clear(), Enter(), PF() or PA() action), but has not finished updating the screen. Also used in non-blocking AID mode (see DIFFERENCES for details). This action is usually invoked in a loop that uses the Ascii1() or Ebcdic1() action to scan the screen for some pattern that indicates that the host has fully processed the last command. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. 🔍
  • Wait([timeout,] unlock) — Pauses the script until the host unlocks the keyboard. This is useful when operating in non-blocking AID mode (toggle AidWait clear), to wait for a host command to complete. See DIFFERENCES for details. The optional timeout parameter is a number of seconds to wait before failing the Wait() action. Default: wait indefinitely. 🔓
  • Wait(timeout, seconds) — Delays the script timeout seconds. Unlike the other forms of Wait(), the timeout is not optional. ⏰
  • WindowState(mode) — If mode is iconic, changes the x3270 window into an icon. If mode is normal, changes the x3270 window from an icon to a normal window. 🪟

🔥 FILE TRANSFER 🔥

The Transfer() action implements IND$FILE file transfer. This action requires that the IND$FILE program be installed on the IBM host, and that the 3270 cursor be located in a field that will accept a TSO or VM/CMS command. 😤

Because of the complexity and number of options for file transfer, the parameters to the Transfer() action can take the unique form of option=value. They can also be given with their parameters separately. Options can appear in any order. Note that if the value contains spaces (such as a VM/CMS file name), then the entire parameter must be quoted, e.g., "hostfile=xxx foo a". With sequential options, this would be hostfile,"xxx foo a". The options are: 💅

  • direction — Required? No. Default: receive. Other values: send.
  • hostfile — Required? Yes.
  • localfile — Required? Yes.
  • host — Required? No. Default: tso. Other values: vm, cics.
  • mode — Required? No. Default: ascii. Other values: binary.
  • cr — Required? No. Default: remove. Other values: add, keep.
  • remap — Required? No. Default: yes. Other values: no.
  • exist — Required? No. Default: keep. Other values: replace, append.
  • recfm — Required? No. Other values: fixed, variable, undefined.
  • lrecl — Required? No.
  • blksize — Required? No.
  • allocation — Required? No. Other values: tracks, cylinders, avblock.
  • primaryspace — Required? Sometimes.
  • secondaryspace — Required? No.
  • avblock — Required? Sometimes.
  • buffersize — Required? No. Default: 4096.

The option details are as follows. 🧚

  • direction — send to send a file to the host, receive to receive a file from the host.
  • hostfile — The name of the file on the host.
  • localfile — The name of the file on the local workstation.
  • host — The type of host (which dictates the form of the IND$FILE command): tso (the default), vm or cics.
  • mode — Use ascii (the default) for a text file, which will be translated between EBCDIC and ASCII as necessary. Use binary for non-text files.
  • cr — Controls how newline characters are handled when transferring mode=ascii files. remove (the default) strips newline characters in local files before transferring them to the host. add adds newline characters to each host file record before transferring it to the local workstation. keep preserves newline characters when transferring a local file to the host.
  • remap — Controls text translation for mode=ascii files. The value yes (the default) causes s3270 to remap the text to ensure maximum compatibility between the workstation’s character set and encoding and the host’s EBCDIC code page. The value no causes s3270 to pass the text to or from the host as-is, leaving all translation to the IND$FILE program on the host.
  • exist — Controls what happens when the destination file already exists. keep (the default) preserves the file, causing the Transfer() action to fail. replace overwrites the destination file with the source file. append appends the source file to the destination file.
  • recfm — Controls the record format of files created on the host. (TSO and VM hosts only.) fixed creates a file with fixed-length records. variable creates a file with variable-length records. undefined creates a file with undefined-length records (TSO hosts only). The lrecl option controls the record length or maximum record length for recfm=fixed and recfm=variable files, respectively.
  • lrecl — Specifies the record length (or maximum record length) for files created on the host. (TSO and VM hosts only.)
  • blksize — Specifies the block size for files created on the host. (TSO and VM hosts only.)
  • allocation — Specifies the units for the primaryspace and secondaryspace options: tracks, cylinders or avblock. (TSO hosts only.)
  • primaryspace — Primary allocation for a file. The units are given by the allocation option. Required when the allocation is specified as something other than default. (TSO hosts only.)
  • secondaryspace — Secondary allocation for a file. The units are given by the allocation option. (TSO hosts only.)
  • avblock — Average block size, required when allocation specifies avblock. (TSO hosts only.)
  • buffersize — Buffer size for DFT-mode transfers. Can range from 256 to 32768. Larger values give better performance, but some hosts may not be able to support them. 🚀

There are also resources that control the default values for each of the file transfer parameters. These resources have the same names as the Transfer() keywords, but with ft prepended and the option name capitalized. E.g., the default for the mode keyword is the s3270.ftMode resource. 👑

💀 DEPRECATED/COMPATIBILITY ACTIONS 💀

For compatibility with earlier versions, there are alternate versions of several of these actions. These versions use zero-origin coordinates, with row 0 at the top and column 0 on the left. 🙈

  • Ascii(...)
  • Ebcdic(...)
  • MoveCursor(...) — Identical to Ascii1(), Ebcdic1() and MoveCursor1(), but using zero-origin coordinates.

The Snap() action also accepts Ascii and Ebcdic keywords, allowing zero-origin coordinates. 🫶

🌸 SEE ALSO 🌸

⭐ VERSION ⭐

Version 4.0ga14

That’s the whole X3270-SCRIPT(1) vibe — source/version Version 4.0ga14, dated 31 January 2021. Byeeee, bestie 💖🦋

📦 where this page comes from