As long as a catalogued program handle is cached by any program then that
program will use it - e.g.:

...
CALL MYSUB1
...
(recatalogued)
...
CALL MYSUB1
...

This will call the same subroutine every time as the first CALL resolved the
address of the subroutine and this will be reused until the (internal)
variable created by the "CALL MYSUB1" declaration is trashed by dropping to
ECL or (if this is in a subroutine itself) the subroutine exits and local
variables are trashed.

Similarly, placing a resolved subroutine address in a variable will use the
same subroutine for the life of the variable, whether LOCAL, COMMON or NAMED
COMMON (which persists for the whole session) - e.g.:

COMMON /SUBS/ MYSUB1, MYSUB2, etc
MYSUB1="ACCOUNT_LEDGER_1"
CALL @MYSUB1 <- replaces the text with the address....

And yes - there are differences depending upon how the program is catalogued
- in particular on UniVerse if you pre-load using SHM.TO.LOAD where programs
are loaded when UniVerse starts and persist as long as UniVerse is still
running.

I remember (some years ago) spending a lot of time trying to work out why
new programs were not running, and the old ones were. I had written a
virtual protocol stack and all subroutines were in named common for
efficiency due to the heavily re-entrant code and runtime dependent
subroutine names - e.g.:

VBP.SUFFIX.x where x was a number 1 -> 7 of last memory I think.

It took me a while to work out what was going on....

For those of us who got involved with VM assembly code (or C) and the system
internals, the internal data descriptor tables used different data types to
determine the content: String, FP, Address etc. When you assigned a name to
a variable it became a string - either in the descriptor itself if very
short, or in a buffer referenced by the address in the descriptor if longer.


When you assigned a variable to a string (which happens to be a subroutine
name) it is just a string - but when you CALL @variable the data type
changes to the resolved address. If you want try a CRT on the variable used
in the CALL after the CALL ...... you will see the difference.

Hope this helps

JayJay
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to