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