An old client recently got in contact about the system we had written for them in AREV in the early 90s and subsequently ported to AREV32. Over the years, we had added some bells and whistles including an incredibly specifically tailored OI export utility which we installed about 10 years ago.

Just recently, we added another OI export utility, and it was working as expected. But now, the client has reported that when including a specific set of columns, the report just hung - no messages, nothing. Eventually they just had to kill it in the task manager. They wondered if this was in any way connected to the recent upgrade?

Now here's where it gets interesting. The columns in question are used frequently throughout the system, displayed on entry screens, reports and the like with no issues, so we thought the client's concern might be justified.

We spun up our test system and attempted to produce the report the client was trying to create. Immediately upon selecting the columns in question, the system broke into the debugger with 'Unable to load program XXX'.

At least this explained why the report was failing (the live system runs with the debugger disabled so they wouldn't see the error message). But it didn't explain how anything we might had done in the latest upgrade could have caused this.

So down to TCL and EDIT BP XXX.

The program is there. Perhaps it hadn't been compiled? Recompile. The issue was not resolved. 

Maybe, just maybe it hadn't been cataloged? EDIT VOC XXX. The catalog pointer is there and pointing to the correct program. But still the system crashes with being unable to load XXX.

Then a vestigial memory oozed from the nether regions of our consciousness. In AREV, VOC and MD are synonyms. In AREV, CATALOG writes to the VOC file. In OI VOC and MD are two separate files. One used for AREV32 and one used for CTO/OI. 

So EDIT MD XXX

New Record.

COPY VOC XXX TO:(MD

and all was fixed,  nothing, fortunately, to do with the upgrade.

Having been bitten by one missing VOC record we thought discretion was the better part of valour, and copied over all missing MD entries from VOC. All should be good yes? So we logged out of the system.

Next time we logged in, disaster struck. ENG0711 RLIST. Cannot start engine... 

Once again it's LH logs to the rescue. We tried to start OI, and again it failed. But from the log we could see that the system wanted to load RLIST. So it went to the Global MD file and looked for an RLIST entry. Regretfully it found one pointing to the AREV RLIST which doesn't take parameters - it parses @SENTENCE - and called it instead of OI RLIST.

Armed with this knowledge we could restore the Global MD files and sanity was restored.

Almost happy with the solution we hit a realisation. ALL of the catalog pointers in the client's app are in VOC - not MD. So why isn't the system falling over left right and centre? 

The answer lies in OI's RTP27 program loader optimisations. 

When OI knows that it's running as a native windows app, RTP27 first looks in the Global MD for a pointer to the program in question, and if finding a pointer, executes that program, and if failing follows the inheritance chain looking for the program in SYSOBJ. In theory RTP27 then checks your VOC file, but this currently (10.2.3) tends not to work.

When OI knows that it's running as AREVNN, it first checks VOC, then MD, then looks for the program. 

The issue here was that despite the fact we were running AREV32, the Export Window was running as a native window and so skipped the VOC step. If only we'd taken our own advice from over a decade ago...

In summation, RTP27 loads programs in the following order