Hi all,

I have come across a change in error reporting in OI 9.0/9.1

Basically we have an MFS that maintains pointers in records in historical tables within the records immediately either side of the record in question. If writing a new record then obviously the lock on one or both of these has to be clear. Within the MFS we check the locks and return with a False status for the write event. We also return a File_Error with only Pos populated with our error message and and other required information.

This is then handled by the promoted event logic for the SysMsg event on the window.

This works fine up to version 8, but now we have installed version 9.0 & 9.1, the @File_Error variable has been cleared.

Is this intended behaviour, as I can imagine that a number of other users will have used similar methodology. If so, is there a fix readily available as we are supplying our client with a product upgrade within a week !! If not, is there an easily coded work around that doesn't involve re-coding all our MFSes with setting user global or common variables.

Note that the MFSes are coded within the application and then copied to Sysprog. This is a legacy from when it was the best way of doing things - obviously we dont want to have to remove and re-apply all the MFSes in the system to use the application version either !!

TIA,

Simon

Simon,

I'm assuming that your MFS chain is something simple like:

 SIMONAPP.MFS-]RTP57

and there's no system indexing in the way?

I'm not aware of any changes in the MFS chain as such that would arbitrarily clear @file.error. However I can see why the problem might occur:

Basically, you can't rely on the contents of @file.error remaining constant when it has moved outside of the scope of the program you are using it with. @file.error should be handled within the context of the IO call (open/read/write/delete/lock etc etc) that generated the original MFS/BFS request. Once outside of this context all bets are off as there may be plenty of other things that come into play before you can access it again.

Consider the chain of programs you need to go through to get to your promoted event handler, which looks something like this:

RUN_EVENT (start of the WRITE event)
SYSPROG*WRITE.WINDOW.OIWIN* (SYSTEM WRITE handler)
SEMANTICLOGICLAYER
FORMUPDATE (this is where your MFS will get called)
  ]]] assume the write fails
  SEND_EVENT( SYSMSG )
  RUN_EVENT ( start of the SYSMSG call )
  SIMONAPP*SYSMSG.WINDOW.OIWIN* (your promoted event handler)

By the time your promoted event gets to @file.error at least 2 other programs have been executed, each of them with their own agenda to follow which may or may not involve @file.error, and this is without assuming anything makes a yield call which could allow other processes to run first.

This is a very similar problem to the early days of OI where we found that run_Event overwrote @id under certain circumstances during a yield() call, so we had to rewrite some programs to use our own ID variable. Since then I'm VERY careful where I rely on the contents of a commonly used "@" variable…

However, as a possible workaround for you be aware that the system WRITE event copies the contents of @file.error into the SP status code via set_FSerror() so you might be able to use get_Status() in your SYSMSG handler to see if there's anything in there that you can find to help… You could also try looking at get_EventStatus() to see if there's anything there as well.

ALos, just FYI :) … the FS error code 499 (FS499:Extended error: %1%) is normally used to report "custom" errors from an MFS, with the first argument containing details of the error condition you wish to report. You may wish to use this in future instead of a "blank" error code with just field 3 populated - I don't think the behaviour of the system with a blank FS error code is defined?

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Hi Carl,

Thanks for that - the last bit is certainly useful info. Meanwhile I have checked all our MFSes and there is only one that uses this, and we already had a wokround using a common variable for another situation, so I have used that for the time being.

Given the above, it is amazing that this has managed to work through all the updates in the last n years !!

Cheers,

Simon

View this thread on the Works forum...