Noctam/DWP/ACS Test Harness/Existing System/CISSIM/Command Line Tools

There are many command line tools to do various things within the CISSIM / proxy / data management / testing stub / kitchen sink application.

This page tries to exhaustively go through all of them. It fails. But it continues to try.

pdutils

Primarily a library file, used throughout various calls from the daemon programs as well as other utilities. It can, however, also be called directly from the command line.

Usage: pdutils <DUMP/OUT/SAVE/CONVERT2E/CONVERT2A> <dialog> <RQST/RPLY> <requestfile/replyfile>

  Note that SAVE requires redirected input from an ASCII text string, such as '< <datafile>'
       and that CONVERT requires redirected input from B64 encoded ASCII data '< <datafile>'

DUMP

Dumps the structure of a request found in a base64-encoded EBCDIC file out to the console.

This puts everything out - ie. all the fields, the fillers and the groups. The values are wrapped into square brackets the appropriate size for capturing the data for the field. Binary values have leading zeroes trimmed; all char values are displayed as found.

It prefixes the field with the data structure (eg B4 for binary 4 bytes; X16 for char 16 bytes; N2 for numeric char 2 bytes).

It suffixes the value with the hex value found for the field, separated into space-separated octets, wrapped in parantheses.

OUT

Dumps the structure of a request found in a base64-encoded EBCDIC file out to the console.

This only puts out the fields and fillers. The values are wrapped into square brackets the appropriate size for capturing the data for the field. Binary values have leading zeroes trimmed; all char values are displayed as found.

SAVE

Note: this doesn't work on Windows, because it uses select.select() to ensure that stdin is available, and that function only works on file descriptors on POSIX systems.

Uses a 'hidden' fifth argument, i.e. it expects the input file to be provided on stdin. The <requestfile/replyfile> argument is, in this case, an output file.

I have tweaked the code to work in Windows and... I don't really know what this does, i.e. I don't know what format the input file is expected to be in. It's not the same as the 'requestfile/replyfile' used for DUMP and OUT, because that fails with the exception message: invalid literal for int() with base 10: 'AAAAMMPJ4'

CONVERT2E

Note: this doesn't work on Windows, because it uses select.select() to ensure that stdin is available, and that function only works on file descriptors on POSIX systems.

Uses a 'hidden' fifth argument, i.e. it expects the input file to be provided on stdin. The <requestfile/replyfile> argument is, in this case, an output file.

This converts input from stdin, in base64-encoded ASCII record format to the output file, in base64-encoded EBCDIC record format. This is the exact mirror of CONVERT2A.

Note: This only works for PD data, not DCI or NPS (which are only ever required in ASCII-based encodings).

CONVERT2A

Note: this doesn't work on Windows, because it uses select.select() to ensure that stdin is available, and that function only works on file descriptors on POSIX systems.

Uses a 'hidden' fifth argument, i.e. it expects the input file to be provided on stdin. The <requestfile/replyfile> argument is, in this case, an output file.

This converts input from stdin, in base64-encoded EBCDIC record format to the output file, in base64-encoded ASCII record format. This is the exact mirror of CONVERT2A.

Note: This only works for PD data, not DCI or NPS (which are only ever required in ASCII-based encodings).

pdedit

Edits the PD and DCI call data via a curses interface, using the COBOL data layouts for the calls.

Usage: pdedit <dialog> <RQST/RPLY> <sourcefile> <destfile>

The 'sourcefile' in this case is the same as the 'requestfile/replyfile' provided in pdutils, that is, a file containing base64-encoded EBCDIC data. The 'destfile' is in the same format with the changes applied (assuming that you save inside pdedit).

Intriguingly, it appears to ignore the 'RQST/RPLY' in the dialog and effectively overwrites it with the RQST/RPLY argument given to the program. Not really sure why... that dialog is a bit of a hack, really, I suspect just to avoid multiple keys or too much structure in the config.

PD350/1151/RQST/R

might have worked better, with a structured system, be it XML or JSON or YAML or whatever. Since I don't really understand which things would be better grouped together, I'll leave this as an idle thought for now.