Recently when working at a client site with a mixed OI/AREV32 environment we were asked if it was possible to call AREV32 programs within OpenInsight - a perfectly valid question when so much historical business logic already exists in that environment.

We considered that this was a perfectly reasonable request and set about establishing whether this was possible in a straightfoward manner.

Now to investigate this it is necessary to know a little about how OpenEngine loads programs to be run. This is all done via the RTP27 program loader. To simplify, RTP27 firstly looks to see if the program requested is already on the program stack and if it isn't it looks for it in SYSOBJ. Naturally it does this following the application inheritance chain. So assuming an application called SATS, which inherited from SFX, which in turn inherited from SYSPROG. If you were trying to run a program called GEN_CONV, RTP27 would first try to load $GEN_CONV*SATS then if that failed $GEN_CONV*SFX and finally if that failed $GEN_CONV.

The exception to this rule is for programs found in SYSPROCNAMES in SYSENV. If the program exists in this list then regardless of whether a program of that name exists at the application level, the system routine will be called in preference.

However with the introduction of AREV32 things got a little more complicated. AREV expected object code to be allowed to reside in tables other than SYSOBJ - so RTP27 had to be modified to deal with that. To find out how it copes we once again must turn to our LH logs and trawl through to see what happens when we try to load a non-existent program.

RD 10 GEN_CONV ERROR:100 FILE:0 GROUP:0RD 30 $GEN_CONV*SATS ERROR:100 FILE:0 GROUP:0
RD 30 $GEN_CONV*SFX ERROR:100 FILE:0 GROUP:0
RD 30 $GEN_CONV ERROR:100 FILE:0 GROUP:0


Now earlier in the log file we were able to identify the files identified by these numeric handles as  MD (10) and SYSOBJ (30).

So if we've catalogued a routine in AREV32 we should just be able to call it from OI right?

Wrong!

For ex-AREV people this log shows something anomalous. VOC and MD are actually separate files not synonyms of each other. So the logic in an out of the box OI system - whether running AREV32 or not is :- read from MD and if that fails walk the application inheritance chain.Now cataloguing routines in AREV32 updates VOC not MD, so the AREV32 routines will never be found.

So the simple answer for developers wishing to call AREV32 routines in OI is to copy the VOC rows to the MD table. This actually also has an added benefit for those who wish to override system routines without altering SYSPROCNAMES. If you catalog your routine in MD then this version will be called in preference to the system routine. Handy if you want to forensically examine system behaviour.

Note that this does mean that the order of precedence has changed from AREV's VOC->SYSOBJ to OI's SYSOBJ->VOC so developers ought to bear this in mind in case it impacts their application.

Revelation have confirmed to us that the default behaviour in the next release of OI will be to check MD then walk the inheritance chain then check VOC so the double entry of catalogued items will not be needed.

Finally as an observation, whilst it wasn't possible to reload programs onto the program stack easily in AREV, in OI you can just call RTP27 passing the program name and the object code will be reloaded onto the stack.