1. Action blocks and dead text

A RXS program consists of one or more 'action blocks' containing coding in REXX syntax.

The action blocks are connected with each other and with the surrounding world through queues and files, thus implementing a 'pipes-and-nodes' pattern, the nodes being the action blocks containing the coding. Between the action block may reside 'dead' text: lines of text that are copied to final output file without any interpretation or altering. Using such 'dead' text is often essential in code generation: the job is to generate a complete program, but often parts of the program is not suited for code generation, but better written as is.

'The surrounding world' for RXS is all the common file formats and data store used on the mainframe: DB2, MQSeries, XML, COBOL-source, sequential and partitioned files, files on the mainframe UNIX-file system, and files on PC and LAN. Even the person sitting in front of the screen is - as seen from RXS - a source of data which could be tapped using a pipeline (section 21).

An action block is a part of the RXS program delimited by the two lines

)action

and

)endaction

In the wrapper for the coding, following the word )action, may be some assignments ('general orders'), also in REXX syntax, describing the connection between the surrounding world and the coding: Which pipes leads to and from the coding, and how are these pipes consumed by the action block. Action block may be without general orders, in which case they are executed just once, consuming no external input. Otherwise an action block is triggered once per element (record or row or...) input to the action block.

 

Here is a trivial example: a RXS program consisting of 'dead' text only - no action blocks:

 

Example 1.1:

1.

What shall we do with the drunken sailor

What shall we do with the drunken sailor

What shall we do with the drunken sailor

Early in the morning

 

2.

Put him in the longboat till he's sober

Put him in the longboat till he's sober

Put him in the longboat till he's sober

Early in the morning

Notice that RXS coding (that is: what is to by consumed by the RXS interpeter) throughout this paper is in a coloured courier font. Dead text is coloured olive.

 

Writing the text in a dataset or member using ISPF edit, then writing RXS in the command field on the screen, and pressing enter will start the RXS interpreter, trying to see the text as a program. Because no part of the text is contained in an )action )endaction block, all lines will be copied unaltered to output.

Now, adding a couple of action blocks:

 

Example 1.2:

1.

)action

do 3

"What shall we do with the drunken sailor"

end

)endaction

Early in the morning

 

2.

)action

do 3

"Put him in the longboat till he's sober"

end

)endaction

Early in the morning

 

Output from example 1.2 is identical to output from example 1.1 The program is now a mixture of lines not contained in action blocks (dead text) (lines 1, 7, 8, 9 and 15), programmed logic (lines 3, 5, 11 and 13), and lines inside action blocks to be written to output (lines 4 and 12). Notice that no general orders are given in the )action lines: The above program is not to work on anything. Accordingly the action blocks are triggered only once.

How does the RXS interpreter see that a line inside an action block is to be written to output? RXS inherits and expands a core principle from the REXX language: Any line in the coding which is not executable is considered aimed at 'the addressed environment' and is sent to that environment. For RXS the 'adressed environment' is output (normally). A line in the coding contained inside quotes is not executable, and therefore is sent to output.

Accordingly, RXS is probably the only programming language not using som kind of 'write' command: Creating output is default.

Notice that execution of a RXS program is always top-down: Imagine some 'execution counter' sweeping down the program, line after line. When this execution counter hits a line of 'dead' text, the line is written to output. When the execution counter hits an action block, the whole block is read and then interpreted.

Besides the )action )endaction constructs, the following meta-structures exists in RXS:

)text )endtext (See section 17) - kind of action blocks containing only strings

)imbed (section 31) - indicating externally defined RXS coding

)trigger )notrigger (section 12) - sub structure inside action blocks: specifying reaction on empty input

)interface (section 39) - opening an interface into an internal queue in rxs

)nop (section 03) - doing nothing