I posted a discussion in the general side about a bizarre I/O error which would corrupt global @Vars (@ID, @RECORD, etc.). Yet if the I/O used local variables and then assigned them to the same global variables, everything is hunky dory.

Our good friends at SPREZZ posted the following:

* In coding S/List we found this WAS a problem with calling Yield() so we always saved off the @Vars before a Yield OR a program is likely to call Yield. *

Sure enough, I was using the MSG call with the GY option (Gasbar with yield) during the processing. Called first to initialize the image and the counter, subsequently to update the gasbar during processing. This is the culprit. If I save the global vars before the MSG calls no corruption. This may also cause problems in any piece of code that calls Yield() or calls something that might call this function.

At least RTI can fix the MSG bit to do its part.

Don Miller

C3 Inc.

Don-

The culprit is actually RUN_EVENT, Not MSG.

I'll take a look at this and see:

1- If we can fix it

2- We can get it rolled out into 3.7.5

Thanks for the heads up- I didn't know about this.

Mike Ruane

Mike ..

TIA. Thank Sprezz because they found it when they were doing S/LIST. They attributed it to the Yield() subroutine. Here's a way to fix it in application code:

Subroutine ShieldYield(Cursor)

* routine to save the contents of an active select when the YIELD function

* is called. YIELD() can fire up an event handler which diddles the global

* variables or cursors.

Declare subroutine Push.Select, Yield, Pop.Select

transfer @id to HoldId

transfer @record to HoldRecord

transfer @dict to HoldDict

Push.Select(Cursor,c1,c2,c3)

Yield()

Pop.Select(Cursor,c1,c2,c3)

transfer HoldId to @id

transfer HoldRecord to @record

transfer HoldDict to @dict

return

Instead of calling Yield() call ShieldYield()

I think this came from Sprezz at some point and we modified it a little to use transfer rather than using the=operator.

Don M.

View this thread on the Works forum...