Somewhere between 9.4.1 and 9.4.6 a change was made to OI so that if an unassigned variable is passed into Xlate, it no longer creates a VNAV error in RTP16. Rather it initializes the unassigned variable and returns it back as empty. This has the negative effect of bad code not being caught but bad data might get processed. Can someone confirm that this was an intentional change? Is there a way to restore the VNAV functionality?

Don Bakke

SRP Computer Solutions, Inc.

Hi Don,

It looks like I made that change in 2014.

* rjc 9-24-14

If Assigned(keys) Else keys = ''

If Assigned(field.no) else field.no = ''

I should have coded it so it does not change the incoming parameters

* rjc 9-24-14

inkeys = If Assigned(keys) then keys Else  ''

inField.No = If Assigned(field.no) then field.no else ''

I cannot undo it at this point, and IIRC rtp16 is part of revboot, so, you cannot simply copy in $RTP16 from an older OI.

Is the issue that it changes the incoming parameters, or that it is desirable for OI to crash with a vnav on null input?

I can make the latter a config setting in OI10.

Bob

It looks like I made that change in 2014.

I appreciate the review and response. This helps with our sanity if nothing else.

I cannot undo it at this point, and IIRC rtp16 is part of revboot, so, you cannot simply copy in $RTP16 from an older OI.

Are you unable to undo it because this would break other things? IIRC, there is a fix to $RELATOR that is still pending to be released for OI 9.4.x. Could you not include both in a patch? It could be an optional patch for those who prefer the old behavior.

Is the issue that it changes the incoming parameters, or that it is desirable for OI to crash with a vnav on null input?

I can make the latter a config setting in OI10.

In our client's case, it would be more desirable for OI to crash with a VNAV. That would ensure quicker identification of problematic code.

Don Bakke

SRP Computer Solutions, Inc.

View this thread on the Works forum...