[Oorexx-devel] IKJCV441/EXECCOMM and Mainframe ooRexx

[Hobart S. <ore...@gm...>]

All;

I've started this new thread for the following reasons:

   - Trying to do this on the first build would complicate the process,
   and I don't want to  get bogged down.
   - An interface between IKJCV441/EXECCOMM and ooRexx may be
   impractical.
   - If such an interface is practical, doing so well may not subtle.
   Special code in the default string method may be needed.
   - I want to get this information down now for later use.
   - I may not be the right one to work on this interface.
   - Most of the reason for an IKJCV441/EXECCOMM interface is ISPF and
   Pipes.  The I/F may work, but ISPF's and Pipes' simulated multi-tasking may
   wreak havoc on ooRexx's own multi-threading mechanisms.
   - IKJCV441 has know performance issues for which a fix has not been
   forthcoming.  (I don't know about EXECCOMM.)

Most of the following is from memory.  So please chime in with suggestions,
corrections, updates, questions, etc.
Background:

IKJCV441 and, under CMS, EXECCOMM are interfaces that provide
for interrogation and setting of CLIST, REXX, ISPF, and
EXEC variables.  ISPF and PIPEs use these services.  (Yes, there is a Pipes
for z/OS!)

Under ISPF, programs should be invoked using the SELECT service and either
the PGM or CMD options.  The first provides a batch JCL like parameter
list.  (R1 points to a halfword length prefix which is followed by the PARM
characters.)  The CMD option provides the standard TSO parameter list.  (R1
points to a 4 word block, each of which points in turn to another TSO
control block, IIRC, ECT, UCT, etc.)  (Under CMS, things are similar, but
not identical.)  Under the covers, but perhaps more importantly, PGM vx. CMD
determines how function pool variables are managed.

Function pool variables are the variables that ISPF, REXX, EXEC, and CLISTs
use to display data on screens, update tables, and retain global variables.
ISPF limits functions pool variable names to 8 characters.  REXX variable
names 9 character and longer are hidden from ISPF and its services.

Under ISPF SELECT CMD(...), IKJCV441/EXECCOMM are used to set and query
function pool variables, which, except for the name length limitation are
REXX variables.  CMS/TSO Pipes can set and query REXX, CLIST and EXEC2(?)
using various stages.

Under ISPF SELECT PGM(...), the program manages the storage for function
pool variables.  That storage can be in the load module, or GETMAINed.  Each
variable must be VDEFINEd, VCOPY, and VREPLACEd by address, length, and data
type.  The data must not move unless you tell ISPF about it.  The REXX/370
developers ran into the distinction the hard way:  IIRC, CEXEC compiled and
ran correctly under ISPF, but TEXT/TXTLIB and LOAD/MODULE files had no
access to the variable pool.  An option had to be added to tell ISPF to use
IKJCV441 to query and set function pool variables.  With compiled REXX
object and load modules.

Approach:

Because everything in ooRexx is an object, and everything in procedural REXX
is a string, I would guess that ooRexx would lack the synergy with
IKJCV441/EXECCOMM that I exists with procedural REXX under TSO and CMS.

Possibility 1 - Every time the default string and/or string= method(s) are
used, map the call into the IKJCV441/EXECCOM equivalent.  This doesn't sound
efficient, but it might work.

Possibility 2 - Replace/hide IKJCV441/EXECCOMM, perhaps using a
TASKLIB/NUCXLOAD or similar mechanism.  This appears to be much more of a
challenge, but with some knowledgeable help, might be the superior
approach.

Those are my thoughts for now.  What does everybody else think?

- Hobart

-- 
OREXXMan