Re: iseries pgm call support

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

Bob Donovan said:

>o How do the caller's obtain the address of the external module?   What if
>I need to change the external module ... will all of the caller's be
>updated with the new address (even if they are currently running)?
>


You would set a system pointer to the module and than an instruction
pointer. Same as a dynamic pgm call. If the module is subsequently
recreated, invalidating the instruction pointer, an exception would occur.

A solution: exception handling in the caller would reresolve the ptr and
retry the call.  This requires an enhancement to the machine to enable the
dynamic setting of an instruction pointer within a pgm so that the exception
handler could branch back to the code to be retried.

A 2nd solution: Another machine enhancement. Provide a bit in the 16 byte
pointer itself. If set and a destroyed object exception occurs, the machine
would auto resolve to the new version of the named object.  ( this is a
little tough to do because the original resolve template has to be retained.
( in case *libl was spcfd )  But hey, space is cheap.  The machine should
provide a "ptr plus" data object.  Large enough to contain the 16 byte ptr
plus the resolve template contents.


>o Can external modules define data?  If so, explain how you might support
>static or automatic variables.


Statics and globals. Arguably can be implemented as data in a usrspc in
qtemp of the job. Otherwise, the machine could provide some kind of run time
name resolution to the actual location of the variable in the global space
of the job/pgm. Very interesting topic of discussion though, the role of
globals in a structured modular pgm.


>
>As you address these details, I think you might come up with something that
>is pretty similar to the existing mechanisms for transferring control
>between code e.g., dynamic program calls and static binding).  If not, then
>I would agree that Roch needs to take a closer look.


If comparing against the dynamic pgm call than the comparison is based on
speed of the call,  the size of the pgm/module object and most important,
the default behavior of the system when entering and exiting the pgm/module
( close files, delete overrides: pgm yes. module no. )

If comparing against the static ile module I have to defer to those who know
more than I do.    If the static binding contributes to pgm structure and
design, that is something in its favor.  But if static binding is justified
because of run time efficiency and aux storage space constraints, well I
judge that reason as retired. Computers are 1000x faster now than when
static binding was first introduced.


enjoy your weekend,

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
+---