|
|||||||
I've just spent one of the most frustrating weeks of my life working on an AREV 2.12 to AREV 3.12 conversion prior to an OI Upgrade. The upgrade itself was relatively painless but the application itself then began to fail in mysterious ways - the worst of which was in a custom program designed to display grids of information. This program - checking in at nearly three thousand lines of code - just wouldn't display the current line in the grid correctly - everything was off by 4 bytes.
Well as the object code hadn't changed it had to be something that had changed between AREV 2.12 and 3.12 right? So I started comparing @Variables between the two systems and found a few likely contenders - @CRTHIGH for example. But try as I might nothing worked. Finally as Friday evening approached a small light went off in my head. The program referenced @ATRBT and this doesn't actually compile in AREV 3.12... So all we had to do was load a non-existent variable with its old value and then everything would work... suffice to say this proved challenging to say the least but eventually I had a routine that loaded what @ATRBT used to be and lo and behold the recalcitrant program now worked. It's not very often that you have to know about the absolutely obscure aspects of system internals but when you do you're grateful for the knowledge. Labels: Atrbt 3.12 2.12 |
|||||||
| |||||||
2 Comments:
Hi, may i know how do you solve the @ATRBT issue ?
By Lim, At 5 January 2013 at 14:05
Thanks for the interest! The simple fix is, of course, not to use @ATRBT. If this doesn't work for you - well as the title says "A week in the life of a Revelation Consultant" - so if you'd like to contact our office (http://www.sprezzatura.com/contact.php) we'd be happy to discuss consultancy with you. The fix wasn't simple and doesn't lend itself to explanation easily online.
By Sprezz, At 6 January 2013 at 18:48
Post a Comment
Subscribe to Post Comments [Atom]
<< Home