This is a reply to Eric Schubert, who replied to Ken Sletten's stepchildren
memo.
 
[from Eric's reply]
> Don't be fooled about Transact's "XL" library routines.  If you want to call
> a transact "subprogram" from Pascal, C, COBOL, etc. you must pass through a
> kludge transact processor interface, executed as a separate process, with
> parameters passed through global extra data segments.  What a treat!
 
I believe you're getting Transact/V confused with Transact/iX.  Transact/V
does create a separate process.  However, Transact/iX is like other
languages.  You can call a Transact subprogram from COBOL, etc. by
issuing tl_call_transact routine.  This routine does initializations for
error messages and some other tasks.  Then it dynamically loads and invokes
the Transact subprogram.  It is not a different process.  When the
subprogram is complete, tl_call_transact does cleanup before returning
to the main program.  (You can see that it is the same process via Glance.)
 
A Transact/iX subprogram does not have local data space.  The main
program sets up the buffer and passes it to the subprogram.
(No extra data segments - an MPE/V concept, not MPE/iX.)
 
[from Eric's reply]
>In short, make Transact follow universal code conventions and be linkable
>into other standard language object code.
 
Transact/iX does follow other standard language object code.  You can
link it with other language's object code.  (It just doesn't have its
own local data space.)
 
Be aware that Transact is not a 3GL, it is more.  It does more tasks
in fewer statements and therefore, is not totally comparable to a 3GL.
But if you look at multiple 3GLs, they are not totally comparable
either.  Data types are not transferrable.  Some 3GLs do not allow
calling subprograms, etc.
 
For more information, see the Transact Reference Manual Appendix D about
the Architected Call Interface or call the HP Response Center.
 
Regards,
Kelly Sznaider
Hewlett-Packard