|
> >Steve, can you explain to me how "external module functionality" differs >from late-bound program calls? > >- Bob Donovan > Bob, My module call would be the calli equivalent of spcptr access to a usrspc. Once the InsPtr has been resolved to the module entry point, execution speed would be the same as CALLI to an internal entry point. System integrity would not be compomised because an InsPtr could only be set to the entry point of the module. Modules could only be called from pgms, so all the usrprf security of the job and pgm would apply to the module. How is this diff from CALLB. I dont know how ile modules are implemented and branched to so I cant say. But the ile callb does update the call stack, does have built in scoping and has multiple entry points into the external module, so there is probably more overhead involved in calling an ile module than my proposed mi module. My modules would be one function, one module. An optional associated space would provide room for the function desc and debug info like the function source code. Argument passing, call stack updating, would be the responsibilty of the caller. I think the machine should be non partisan, or at least have a non partisan mode, when it comes to how a function call stack should be structured. The module/function name should be as long as possible. Use the 30 char max min object name? Best would be the support of an AKA name on the RSLVSP cmd. An unlimited lgth name that corresponds to the short system name would be stored by the machine and could be spcfd when RSLVSP to the machine object. etc, etc. Steve Richter > >+--- >| This is the MI Programmers Mailing List! >| To submit a new message, send your mail to MI400@midrange.com. >| To subscribe to this list send email to MI400-SUB@midrange.com. >| To unsubscribe from this list send email to MI400-UNSUB@midrange.com. >| Questions should be directed to the list owner/operator: dr2@cssas400.com >+--- > +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.