1X3270-SCRIPT(1) General Commands Manual X3270-SCRIPT(1)
2
6 Scripting Facilities for x3270, c3270 and s3270
7
9 x3270 -script [ x3270-options ]
10 x3270 -socket [ x3270-options ]
11 x3270 -scriptport port [ x3270-options ]
12 c3270 -socket [ c3270-options ]
13 c3270 -scriptport port [ s3270-options ]
14 s3270 [ s3270-options ]
15 Script ( command [ ,arg... ] )
16
18 The x3270 scripting facilities allow the interactive 3270 emulators
19 x3270 and c3270 to be operated under the control of another program,
20 and forms the basis for the script-only emulator s3270.
21 There are four basic scripting methods. The first is the peer script
23 facility, invoked by the x3270 -script switch, and the default mode for
24 s3270. This runs the emulator as a child of another process. Typi‐
25 cally this would be a script using expect(1), perl(1), or the co-
26 process facility of the Korn Shell ksh(1). In this mode, the emulator
27 process looks for commands on its standard input, and places the
28 responses on standard output.
29 The second method is the child script facility, invoked by the emula‐
31 tor's Script() action. This runs a script as a child process of the
32 emulator. The child has access to pipes connected to the emulator; the
33 emulator looks for commands on one pipe, and places the responses on
34 the other. The file descriptor of the pipe for commands to the emula‐
35 tor is passed in the environment variable X3270INPUT (e.g., the text
36 string "7" if the file descriptor is 7); the file descriptor of the
37 pipe for responses from the emulator is passed in the environment vari‐
38 able X3270OUTPUT.
39 The third method uses a TCP socket. The -scrpiptport command-line
41 option causes the emulator to bind a socket to the specified port (on
42 the IPv4 loopback address, 127.0.0.1). The emulator accepts TCP con‐
43 nections on that port. Multiple commands and responses can be sent
44 over each connection.
45 The fourth method uses a Unix-domain socket. The -socket command-line
47 option causes the emulator to create a Unix-domain stream socket named
48 /tmp/x3sck.pid. The emulator accepts connections to that socket. Mul‐
49 tiple commands and responses can be sent over each connection.
50 It is possible to nest the methods. For example, a peer or TCP socket
52 script can invoke the Script() action. The calling script will be
53 resumed when the nested script completes.
54 Commands are emulator actions; the syntax is the same as for the right-
56 hand side of an x3270 or c3270 keymap. Unlike translation tables,
57 action names are case-insensitive, can be uniquely abbreviated, and the
58 parentheses may be omitted if there are no parameters. Any input line
59 that begins with # or ! is treaded as a comment and will be ignored.
60 Any emulator action may be specified. Several specific actions have
62 been defined for use by scripts, and the behavior of certain other
63 actions (and of the emulators in general) is different when an action
64 is initiated by a script.
65 Some actions generate output; some may delay completion until the cer‐
67 tain external events occur, such as the host unlocking the keyboard.
68 The completion of every command is marked by a two-line message. The
69 first line is the current status of the emulator, documented below. If
70 the command is successful, the second line is the string "ok"; other‐
71 wise it is the string "error".
72
74 The status message consists of 12 blank-separated fields:
75 1 Keyboard State
77 If the keyboard is unlocked, the letter U. If the keyboard is
78 locked waiting for a response from the host, or if not connected
79 to a host, the letter L. If the keyboard is locked because of
80 an operator error (field overflow, protected field, etc.), the
81 letter E.
82 2 Screen Formatting
84 If the screen is formatted, the letter F. If unformatted or in
85 NVT mode, the letter U.
86 3 Field Protection
88 If the field containing the cursor is protected, the letter P.
89 If unprotected or unformatted, the letter U.
90 4 Connection State
92 If connected to a host, the string C(hostname). Otherwise, the
93 letter N.
94 5 Emulator Mode
96 If connected in 3270 mode, the letter I. If connected in NVT
97 line mode, the letter L. If connected in NVT character mode,
98 the letter C. If connected in unnegotiated mode (no BIND active
99 from the host), the letter P. If not connected, the letter N.
100 6 Model Number (2-5)
102 7 Number of Rows
104 The current number of rows defined on the screen. The host can
105 request that the emulator use a 24x80 screen, so this number may
106 be smaller than the maximum number of rows possible with the
107 current model.
108 8 Number of Columns
110 The current number of columns defined on the screen, subject to
111 the same difference for rows, above.
112 9 Cursor Row
114 The current cursor row (zero-origin).
115 10 Cursor Column
117 The current cursor column (zero-origin).
118 11 Window ID
120 The X window identifier for the main x3270 window, in hexadeci‐
121 mal preceded by 0x. For s3270 and c3270, this is zero.
122 12 Command Execution Time
124 The time that it took for the host to respond to the previous
125 commnd, in seconds with milliseconds after the decimal. If the
126 previous command did not require a host response, this is a
127 dash.
128
130 When an action is initiated by a script, the emulators behave in sev‐
131 eral different ways:
132 If an error occurs in processing an action, the usual pop-up window
134 does not appear. Instead, the text is written to standard output.
135 If end-of-file is detected on standard input, the emulator exits. (A
137 script can exit without killing the emulator by using the CloseScript()
138 action, below.) Note that this applies to peer scripts only; end-of-
139 file on the pipe connected to a child script simply causes the pipes to
140 be closed and the Script() action to complete.
141 The Quit() action always causes the emulator to exit. (When called
143 from the keyboard, it will exit only if not connected to a host.)
144 Normally, the AID actions (Clear(), Enter(), PF(), and PA()) will not
146 complete until the host unlocks the keyboard. If the parameter to a
147 String() action includes a code for one these actions, it will also
148 wait for the keyboard to unlock before proceeding.
149 The AidWait toggle controls with behavior. When this toggle is set
151 (the default), actions block as described above. When the toggle is
152 clear, AID actions complete immediately. The Wait(output) action can
153 then be used to delay a script until the host changes something on the
154 screen, and the Wait(unlock) action can be used to delay a script until
155 the host unlocks the keyboard, regardless of the state of the AidWait
156 toggle.
157 Note that the Script() action does not complete until end-of-file is
159 detected on the pipe or the CloseScript() action is called by the child
160 process. This behavior is not affected by the state of the AidWait
161 toggle.
162
164 3270 session scripting can be more difficult than other kinds of
165 scripting, because it can be hard to tell when the host is finished
166 processing a command. There is a well-defined 3270 Data Stream facil‐
167 ity for doing this: The emulator locks the keyboard when it sends the
168 host an AID, and the later host unlocks the keyboard. The emulator
169 supports this facility directly by not allowing an AID action to com‐
170 plete until the keyboard is unlocked. Unfortunately, some hosts and
171 some host applications unlock the keyboard as soon as they begin pro‐
172 cessing the command, instead of after it is finished. A human operator
173 can see on the screen when the command is finished (e.g., when a READY
174 prompt is displayed), but it can be difficult for a script to do this.
175 For such early-unlock hosts, the only option in a script is to poll the
176 screen until it can determine that the command is complete.
177 Another complication is that host I/O and script operation are asyn‐
179 chronous. That is, the host can update the screen at any time, even
180 between actions that are reading the screen contents, so a script can
181 get inconsistent results. Assistance for this problem is provided by
182 the Snap() action. The Snap(save) action saves a snapshot of the
183 screen in a special buffer. Then the script can use Snap() variants of
184 the Ascii1() and Ebcdic1() actions (Snap(Ascii1) and Snap(Ebcdic1)) to
185 query the saved buffer -- which the host cannot modify -- to get the
186 data it wants. Finally, Snap(wait,output) blocks the script until the
187 host modifies the screen, specifically since the last call to
188 Snap(save). Thus a script can poll the screen efficiently by writing a
189 loop that begins with Snap(save) and ends with Snap(wait,output).
190
192 The following actions have been defined or modified for use with
193 scripts. Note that actions that use row and column coordinates gener‐
194 ally use an origin of 1, with row 1 at the top and column 1 at the
195 left. This is consistent with the on-screen cursor position and data
196 stream trace messages.
197 AnsiText()
199 Outputs whatever data that has been output by the host in NVT
200 mode since the last time that AnsiText() was called. The data
201 is preceded by the string "data: ", and has had all control
202 characters expanded into C backslash sequences.
203 This is a convenient way to capture NVT mode output in a syn‐
205 chronous manner without trying to decode the screen contents.
206 Ascii1(row,col,rows,cols)
208 Ascii1(row,col,length)
210 Ascii1(length)
212 Ascii1()
214 Outputs an ASCII text representation of the screen contents.
215 Each line is preceded by the string "data: ", and there are no
216 control characters.
217 If four parameters are given, a rectangular region of the screen
219 is output. (Note that the row and column are 1-origin.)
220 If three parameters are given, length characters are output,
222 starting at the specified 1-origin row and column.
223 If only the length parameter is given, that many characters are
225 output, starting at the cursor position.
226 If no parameters are given, the entire screen is output.
228 The EBCDIC-to-ASCII translation and output character set depend
230 on the both the emulator host code page (the -codepage option)
231 and the locale. UTF-8 and certain DBCS locales may result in
232 multi-byte expansions of EBCDIC characters that translate to
233 ASCII codes greater than 0x7f.
234 AsciiField()
236 Outputs an ASCII text representation of the field containing the
237 cursor. The text is preceded by the string "data: ".
238 Connect(hostname)
240 Connects to a host. The command does not return until the emu‐
241 lator is successfully connected in the proper mode, or the con‐
242 nection fails.
243 CloseScript(status)
245 Causes the emulator to stop reading commands from the script.
246 This is useful to allow a peer script to exit, with the emulator
247 proceeding interactively. (Without this command, the emulator
248 would exit when it detected end-of-file on standard input.) If
249 the script was invoked by the Script() action, the optional sta‐
250 tus is used as the return status of Script(); if nonzero,
251 Script() will complete with an error, and if this script was
252 invoked as part of login through the ibm_hosts file, the connec‐
253 tion will be broken.
254 Disconnect()
256 Disconnects from the host.
257 Ebcdic1(row,col,rows,cols)
259 Ebcdic1(row,col,length)
261 Ebcdic1(length)
263 Ebcdic1()
265 The same function as Ascii1() above, except that rather than
266 generating ASCII text, each character is output as a 2-digit or
267 4-digit hexadecimal EBCDIC code.
268 EbcdicField()
270 The same function as AsciiField() above, except that it gener‐
271 ates hexadecimal EBCDIC codes.
272 Info(message)
274 In x3270, pops up an informational message. In c3270 and
275 wc3270, writes an informational message to the OIA (the line
276 below the display). Not defined for s3270 or tcl3270.
277 Expect(text[,timeout])
279 Pauses the script until the specified text appears in the data
280 stream from the host, or the specified timeout (in seconds)
281 expires. If no timeout is specified, the default is 30 seconds.
282 Text can contain standard C-language escape (backslash)
283 sequences. No wild-card characters or pattern anchor characters
284 are understood. Expect() is valid only in NVT mode.
285 MoveCursor1(row,col)
287 Moves the cursor to the specified 1-origin coordinates.
288 MoveCursor1(offset)
290 Moves the cursor to the specified offset. Offset 0 is the upper
291 left-hand corner of the screen.
292 PrintText([command,]filter)
294 Pipes an ASCII representation of the current screen image
295 through the named filter, e.g., lpr.
296 PrintText([html,][append,][replace,]file,filename)
298 Saves the current screen contents in a file. With the html
299 option, saves it as HTML, otherwise saves it as plain ASCII.
300 The append option (the default) causes the data to be appended
301 to the file if it already exists. The replace option causes the
302 file to be overwritten instead.
303 PrintText(html,string)
305 Returns the current screen contents as HTML.
306 Query(keyword)
308 Returns state information. Keywords are:
309 Keyword output
311 ─────────────────────────────────────────────
312 BindPluName BIND PLU returned by the
313 host
314 ConnectionState TN3270/TN3270E mode and
315 submode
316 CodePage Host code page
317 Cursor Cursor position (row col)
318 zero-origin
319 Cursor1 Cursor position (row col)
320 1-origin
321 Formatted 3270 format state
322 (formatted or unformatted)
323 Host Host name and port
324 LocalEncoding Local character encoding
325 LuName Host name LU name
326 Model 3270 model name (IBM-327x-
327 n)
328 ScreenCurSize Current screen size (rows
329 cols)
330 ScreenMaxSize Maximum screen size (rows
331 cols)
332 Tls TLS state (secure or not-
338 secure) and host
339 validation state (host-
340 verified or host-
341 unverified)
342 Without a keyword, Query() returns each of the defined
344 attributes, one per line, labeled by its name.
345 ReadBuffer(ascii)
347 Dumps the contents of the screen buffer, one line per row. Each
348 buffer position inside a data field is generally output as a
349 2-digit hexadecimal code, translated from the host EBCDIC code
350 page to the current locale. (E.g., the EBCDIC value for the
351 letter A in host code page 037 is X'C1'. In ASCII, this is 0x41,
352 so it is output as 41.) If the current locale specifies a
353 multi-byte character set such as UTF-8, some positions may be
354 output as 4-, 6- or 8-digit codes. (E.g., in host code page
355 037, the EBCDIC value for a U+00ac NOT symbol is X'5F'. In
356 UTF-8, this is 0xc2, 0xac, so it is output as c2ac.) DBCS
357 characters take two positions in the screen buffer; the first
358 location is output as a multi-byte code, and the second location
359 is output as a dash. Start-of-field characters (each of which
360 takes up a display position) are output as SF(aa=nn[,...]),
361 where aa is a field attribute type and nn is its value.
362 Attribute Values
364 ─────────────────────────────────────
365 c0 basic 3270 20 protected
366 10 numeric
367 04 detectable
368 08 intensified
369 0c non-display
370 01 modified
371 41 highlighting f1 blink
372 f2 reverse
373 f4 underscore
374 f8 intensify
375 42 foreground f0 neutral black
376 f1 blue
377 f2 red
378 f3 pink
379 f4 green
380 f5 turquoise
381 f6 yellow
382 f7 neutral white
383 f8 black
384 f9 deep blue
385 fa orange
386 fb purple
387 fc pale green
388 fd pale turquoise
389 fe grey
390 ff white
391 43 character set f0 default
392 f1 APL
393 f8 DBCS
394 Extended attributes (which do not take up display positions) are
396 output as SA(aa=nn), with aa and nn having the same definitions
397 as above (though the basic 3270 attribute will never appear as
398 an extended attribute).
399 NULL characters in the screen buffer are reported as ASCII
401 character 00 instead of 20, even though they are displayed as
402 blanks.
403 ReadBuffer(ebcdic)
405 Equivalent to ReadBuffer(ascii), but with the data fields output
406 as hexadecimal EBCDIC codes. If a buffer position has the
407 Graphic Escape attribute, it is displayed as GE(xx). If a
408 buffer position was written in NVT mode, it does not have an
409 EBCDIC value, and will be displayed as 00.
410 ReadBuffer(unicode)
412 Equivalent to ReadBuffer(ascii), but with the data fields output
413 as 4-digit hexadecimal Unicode values.
414 ReadBuffer(field)
416 Dumps information about the current field. ascii, ebcdic and
417 unicode keywords are also accepted. The output consists of
418 keywords and parameters. Note that `field start' is the
419 location of the start-of-field character, which is displayed on
420 the screen as a blank to the left of the field, and is dumped as
421 SF. The Contents line is always last.
422 Keyword Parameters Meaning
424 ────────────────────────────────────────────────
425 Start1 row col Field start
426 coordinates
427 (1-origin)
428 StartOffset offset Field start
429 location as offset
430 Cursor1 row col Cursor coordinates
431 (1-origin)
432 CursorOffset offset Cursor location as
433 offset
434 Contents contents Field contents on
435 one line in
436 ReadBuffer() format
437 Script(path[,arg...])
439 Runs a child script, passing it optional command-line arguments.
440 path must specify an executable (binary) program: the emulator
441 will create a new process and execute it. If you simply want the
442 emulator to read commands from a file, use the Source() action.
443 Snap() Equivalent to Snap(save) (see below).
445 Snap(Ascii1,...)
447 Performs the Ascii1 action on the saved screen image.
448 Snap(Cols)
450 Returns the number of columns in the saved screen image.
451 Snap(Ebcdic1,...)
453 Performs the Ebcdic1() action on the saved screen image.
454 Snap(ReadBuffer)
456 Performs the ReadBuffer() action on the saved screen image.
457 Snap(Rows)
459 Returns the number of rows in the saved screen image.
460 Snap(save)
462 Saves a copy of the screen image and status in a temporary
463 buffer. This copy can be queried with other Snap() actions to
464 allow a script to examine a consistent screen image, even when
465 the host may be changing the image (or even the screen
466 dimensions) dynamically.
467 Snap(status)
469 Returns the status line from when the screen was last saved.
470 Snap(wait[,timeout],output)
472 Pauses the script until the host sends further output, then
473 updates the snap buffer with the new screen contents. Used when
474 the host unlocks the keyboard (allowing the script to proceed
475 after an Enter(), PF() or PA() action), but has not finished
476 updating the screen. This action is usually invoked in a loop
477 that uses the Snap(Ascii1) or Snap(Ebcdic1) action to scan the
478 screen for some pattern that indicates that the host has fully
479 processed the last command.
480 The optional timeout parameter specifies a number of seconds to
482 wait before failing the Snap() action. The default is to wait
483 indefinitely.
484 Source(file)
486 Read and execute commands from file. Any output from those
487 commands will become the output from Source(). If any of the
488 commands fails, the Source() command will not abort; it will
489 continue reading commands until EOF.
490 Title(text)
492 Changes the x3270 window title to text.
493 Transfer(keyword=value,...)
495 Invokes IND$FILE file transfer. See FILE TRANSFER below.
496 Wait([timeout,] 3270mode)
498 Used when communicating with a host that switches between NVT
499 mode and 3270 mode. Pauses the script or macro until the host
500 negotiates 3270 mode, then waits for a formatted screen as
501 above.
502 The optional timeout parameter specifies a number of seconds to
504 wait before failing the Wait() action. The default is to wait
505 indefinitely.
506 For backwards compatibility, Wait(3270) is equivalent to
508 Wait(3270mode)
509 Wait([timeout,] disconnect)
511 Pauses the script until the host disconnects. Often used to
512 after sending a logoff command to a VM/CMS host, to ensure that
513 the session is not unintentionally set to disconnected state.
514 The optional timeout parameter specifies a number of seconds to
516 wait before failing the Wait() action. The default is to wait
517 indefinitely.
518 Wait([timeout,] inputfield)
520 A useful utility for use at the beginning of scripts and after
521 the Connect() action. In 3270 mode, waits until the screen is
522 formatted, and the host has positioned the cursor on a
523 modifiable field. In NVT mode, waits until the host sends at
524 least one byte of data.
525 The optional timeout parameter specifies a number of seconds to
527 wait before failing the Wait() action. The default is to wait
528 indefinitely.
529 For backwards compatibility, Wait is equivalent to
531 Wait(inputfield).
532 Wait([timeout,] nvtmode)
534 Used when communicating with a host that switches between 3270
535 mode and NVT mode. Pauses the script or macro until the host
536 negotiates NVT mode, then waits for a byte from the host as
537 above.
538 The optional timeout parameter specifies a number of seconds to
540 wait before failing the Wait() action. The default is to wait
541 indefinitely.
542 For backwards compatibility, Wait(ansi) is equivalent to
544 Wait(nvtmode).
545 Wait([timeout,] output)
547 Pauses the script until the host sends further output. Often
548 needed when the host unlocks the keyboard (allowing the script
549 to proceed after a Clear(), Enter(), PF() or PA() action), but
550 has not finished updating the screen. Also used in non-blocking
551 AID mode (see DIFFERENCES for details). This action is usually
552 invoked in a loop that uses the Ascii1() or Ebcdic1() action to
553 scan the screen for some pattern that indicates that the host
554 has fully processed the last command.
555 The optional timeout parameter specifies a number of seconds to
557 wait before failing the Wait() action. The default is to wait
558 indefinitely.
559 Wait([timeout,] unlock)
561 Pauses the script until the host unlocks the keyboard. This is
562 useful when operating in non-blocking AID mode (toggle AidWait
563 clear), to wait for a host command to complete. See DIFFERENCES
564 for details).
565 The optional timeout parameter specifies a number of seconds to
567 wait before failing the Wait() action. The default is to wait
568 indefinitely.
569 Wait(timeout, seconds)
571 Delays the script timeout seconds. Unlike the other forms of
572 Wait(), the timeout is not optional.
573 WindowState(mode)
575 If mode is iconic, changes the x3270 window into an icon. If
576 mode is normal, changes the x3270 window from an icon to a
577 normal window.
578
580 The Transfer() action implements IND$FILE file transfer. This action
581 requires that the IND$FILE program be installed on the IBM host, and
582 that the 3270 cursor be located in a field that will accept a TSO or
583 VM/CMS command.
584 Because of the complexity and number of options for file transfer, the
586 parameters to the Transfer() action can take the unique form of
587 option=value. They can also be given with their parameters separately.
588 Options can appear in any order. Note that if the value contains
589 spaces (such as a VM/CMS file name), then the entire parameter must be
590 quoted, e.g., "hostfile=xxx foo a". With sequential options, this
591 would be hostfile,"xxx foo a". The options are:
592 Option Required? Default Other Values
594 ────────────────────────────────────────────────────────
595 direction No receive send
596 hostfile Yes
597 localfile Yes
598 host No tso vm, cics
599 mode No ascii binary
600 cr No remove add, keep
601 remap No yes no
602 exist No keep replace, append
603 recfm No fixed, variable,
604 undefined
605 lrecl No
606 blksize No
607 allocation No tracks,
608 cylinders,
609 avblock
610 primaryspace Sometimes
611 secondaryspace No
612 avblock Sometimes
613 buffersize No 4096
614 The option details are as follows.
616 direction
618 send to send a file to the host, receive to receive a file from
619 the host.
620 hostfile
622 The name of the file on the host.
623 localfile
625 The name of the file on the local workstation.
626 host The type of host (which dictates the form of the IND$FILE
628 command): tso (the default), vm or cics.
629 mode Use ascii (the default) for a text file, which will be
631 translated between EBCDIC and ASCII as necessary. Use binary
632 for non-text files.
633 cr Controls how newline characters are handled when transferring
635 mode=ascii files. remove (the default) strips newline
636 characters in local files before transferring them to the host.
637 add adds newline characters to each host file record before
638 transferring it to the local workstation. keep preserves
639 newline characters when transferring a local file to the host.
640 remap Controls text translation for mode=ascii files. The value yes
642 (the default) causes s3270 to remap the text to ensure maximum
643 compatibility between the workstation's character set and
644 encoding and the host's EBCDIC code page. The value no causes
645 s3270 to pass the text to or from the host as-is, leaving all
646 translation to the IND$FILE program on the host.
647 exist Controls what happens when the destination file already exists.
649 keep (the default) preserves the file, causing the Transfer()
650 action to fail. replace overwrites the destination file with
651 the source file. append appends the source file to the
652 destination file.
653 recfm Controls the record format of files created on the host. (TSO
655 and VM hosts only.) fixed creates a file with fixed-length
656 records. variable creates a file with variable-length records.
657 undefined creates a file with undefined-length records (TSO
658 hosts only). The lrecl option controls the record length or
659 maximum record length for recfm=fixed and recfm=variable files,
660 respectively.
661 lrecl Specifies the record length (or maximum record length) for files
663 created on the host. (TSO and VM hosts only.)
664 blksize
666 Specifies the block size for files created on the host. (TSO
667 and VM hosts only.)
668 allocation
670 Specifies the units for the primaryspace and secondaryspace
671 options: tracks, cylinders or avblock. (TSO hosts only.)
672 primaryspace
674 Primary allocation for a file. The units are given by the
675 allocation option. Required when the allocation is specified as
676 something other than default. (TSO hosts only.)
677 secondaryspace
679 Secondary allocation for a file. The units are given by the
680 allocation option. (TSO hosts only.)
681 avblock
683 Average block size, required when allocation specifies avblock.
684 (TSO hosts only.)
685 buffersize
687 Buffer size for DFT-mode transfers. Can range from 256 to
688 32768. Larger values give better performance, but some hosts
689 may not be able to support them.
690 There are also resources that control the default values for each of
692 the file transfer parameters. These resources have the same names as
693 the Transfer() keywords, but with ft prepended and the option name
694 capitalized. E.g., the default for the mode keyword is the s3270.ftMode
695 resource.
696
698 For comptibility with earlier versions, there are alternate versions of
699 several of these actions. These versions use zero-origin coordinates,
700 with row 0 at the top and column 0 on the left.
701 Ascii(...)
704 Ebcdic(...)
706 MoveCursor(...)
708 Identical to Ascii1(), Ebcdic1() and MoveCursor1(), but using
709 zero-origin coordinates.
710 The Snap() action also accepts Ascii and Ebcdic keywords, allowing
712 zero-origin coordinates.
713
716 expect(1)
717 perl(1)
718 ksh(1)
719 x3270(1)
720 x3270if(1)
721 c3270(1)
722 s3270(1)
723
725 Version 4.0ga12
726 26 September 2020 X3270-SCRIPT(1)