Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

vms pascal problem

 
ye kuang
Occasional Contributor

vms pascal problem

Hi,

My customer enviroment is OpenVMS I64 V8.2-1,HP Pascal I64 V5.9-103,after they run a program that write by themselves, the program show this message: returned by Add_Atomic: xxxx. their program see the attached file.we can't fix this error, can anyone help to fix this?


thanks

ye kuang
3 REPLIES 3
Brian Reiter
Valued Contributor

Re: vms pascal problem

Hmmm,

Seems to work as expected on my test systems (HP Pascal Alpha V6.0-107 on OpenVMS Alpha V7.3-2 and HP Pascal I64 V6.0-112 on OpenVMS I64 V8.3-1H1) . It may be worth while trying a newer version of Pascal. John Reagan or John Gillings may be able to shed more light on what the problem really is.


cheers

Brian
Jur van der Burg
Respected Contributor

Re: vms pascal problem

Looks like a bug in the old version, it returns a status instead of the old value:

$ write sys$output f$mess(2424833)
%MAT-S-NORMAL, normal successful completion

Upgrade to the new version.

Jur.
John Gillings
Honored Contributor

Re: vms pascal problem

ye,

Sorry, I can't test your program at the moment, but I'm fairly sure Jur has the right answer.

In general, whenever you have a compiler related problem, you should test against the latest release. The Pascal installation has a mechanism to retain all previous versions of the compiler, and to select which one to use. Best practice is to keep current.

That said, even with the correct behaviour, for add_atomic, I find this construct rather curious:

nmronq := add_atomic( +1, opq_l_nmronq ) + 1;

The add atomic will add 1 to the variable buffer.opq_l_nmronq, returning the previous value. You then add 1 to the previous value and store the result in nmronq.

Please realise that a comparison between nmronq and buffer.opq_l_nmronq immediately afterwards will not necessarily be equal!

Presumably the reason you're using add_atomic is because the variable "buffer" is written from multiple processes or threads, it can therefore change at any time (it should probably be declared VOLATILE). Similarly, the value printed by your first writeln could have been updated elsewhere before the add_atomic executes. In a "live" environment, your code could conceivably return (say)

run TEST_ADDATOMIC
opq_l_nmronq before Add_Atomic: 1
opq_l_nmronq after Add_Atomic: 4
nmronq returned by Add_Atomic: 3

and still be correct, because other processes have updated the field between your calls to writeln.

(though in your test program the buffer record is private and non-shared, so is not subject to asynchronous updates).

Please think very carefully about what you intend to do with the return value of add_atomic, and what assumptions you make about it.
A crucible of informative mistakes