Hi All,
As part of our ongoing upgrade, we are transitioning the Uniface environment from Uniface 7 (on OpenVMS) to Uniface 10 (on Linux).
During this migration, we encountered an issue with a 3GL function that was previously working as expected in the OpenVMS environment. The function is invoked using the following Uniface command:
perform "3glfunction"
edit/nowander
This 3GL function is implemented in a .c file located in a Linux directory. Its purpose is to pause the Uniface application until a specified time has elapsed. Once the timer completes, the function uses UPUTAMES to send a response back to Uniface.
While this setup worked seamlessly on OpenVMS, it does not function correctly on Linux. The Linux version of the 3GL function uses a timer thread, which is detached after the timer ends. Although UPUTAMES works independently and is capable of sending responses back to the application, it fails to trigger the expected behavior in Uniface-specifically, the form does not display as intended when using edit/nowander.
Additionally, UPUTAMES either returns no value or returns -1 when called from within the 3GL function.
We are currently investigating this behavior and would appreciate any insights or suggestions regarding compatibility or alternative approaches on Linux.
------------------------------
Rahul Kini
Mr
Rocket Software Forum Member
------------------------------
This sounds like the function UTIMER which is a built in function to wait a length of time and then send a message back to a recipient instance.
Sample code from one of our components.
Starting the timer.
newinstance "UTIMER","%%$instancename%%%_UT"
if($status = -154)
activate "%%$instancename%%%_UT".STOP()
endif
activate "%%$instancename%%%_UT".SETREPEAT(1)
activate "%%$instancename%%%_UT".SETMESSAGE($instancename,"REFRESH","%%$datim%%%")
activate "%%$instancename%%%_UT".START(d_refresh)
Where d_refresh is a time field, to allow variable input.
This sends a message, caught by the recievemessage trigger of the target instance (same instance in this case, and I suspect your example.)
trigger receiveMessage
if($result="message")
selectcase $msgid
case "REFRESH"
......
Regards,
Iain
------------------------------
Iain Sharp
Head of Technical Services
Jonas Metals Software Limited
Sheffield GB
------------------------------
This sounds like the function UTIMER which is a built in function to wait a length of time and then send a message back to a recipient instance.
Sample code from one of our components.
Starting the timer.
newinstance "UTIMER","%%$instancename%%%_UT"
if($status = -154)
activate "%%$instancename%%%_UT".STOP()
endif
activate "%%$instancename%%%_UT".SETREPEAT(1)
activate "%%$instancename%%%_UT".SETMESSAGE($instancename,"REFRESH","%%$datim%%%")
activate "%%$instancename%%%_UT".START(d_refresh)
Where d_refresh is a time field, to allow variable input.
This sends a message, caught by the recievemessage trigger of the target instance (same instance in this case, and I suspect your example.)
trigger receiveMessage
if($result="message")
selectcase $msgid
case "REFRESH"
......
Regards,
Iain
------------------------------
Iain Sharp
Head of Technical Services
Jonas Metals Software Limited
Sheffield GB
------------------------------
Hi,
Thank you for your suggestion. We had already considered this approach; however, the challenge lies in the fact that the 3GL call is implemented in over a hundred places throughout the codebase. To avoid a large-scale change and extensive retesting, we are currently exploring ways to make the .c file work as intended without modifying all those instances.
------------------------------
Rahul Kini
Mr
Rocket Software Forum Member
------------------------------
Hi,
Thank you for your suggestion. We had already considered this approach; however, the challenge lies in the fact that the 3GL call is implemented in over a hundred places throughout the codebase. To avoid a large-scale change and extensive retesting, we are currently exploring ways to make the .c file work as intended without modifying all those instances.
------------------------------
Rahul Kini
Mr
Rocket Software Forum Member
------------------------------
Ah, I had presumed that since perform is deprecated and dropped from the documentation, that it no longer worked anyway and you'd be re-doing all the calls.
------------------------------
Iain Sharp
Head of Technical Services
Jonas Metals Software Limited
Sheffield GB
------------------------------
Ah, I had presumed that since perform is deprecated and dropped from the documentation, that it no longer worked anyway and you'd be re-doing all the calls.
------------------------------
Iain Sharp
Head of Technical Services
Jonas Metals Software Limited
Sheffield GB
------------------------------
Hi,
Yes, the function is deprecated. However, given that there are over a hundred calls across the codebase for various 3GL operations, it's still being reused. For this reason, we're currently focused on finding a way to make the .c file work rather than refactoring all those instances.
------------------------------
Rahul Kini
Mr
Rocket Software Forum Member
------------------------------
Hi,
Yes, the function is deprecated. However, given that there are over a hundred calls across the codebase for various 3GL operations, it's still being reused. For this reason, we're currently focused on finding a way to make the .c file work rather than refactoring all those instances.
------------------------------
Rahul Kini
Mr
Rocket Software Forum Member
------------------------------
Hi,
to which Version of Uniface 10 are you migrating?
Release: 10.4.03
Update: 10.4.03.024 (024 0904_1)
Phase 7: Procs compilation
(EXEC) 6 perform uocxmethod
(EXEC) warning: 1000 - Statement 'perform' is no longer supported
Do you get such a warning?
This means it is not just deprecated.
It is no longer supported.
Regards
Norbert
------------------------------
Norbert Lauterbach
Infraserv Gmbh & Co. Höchst Kg
Frankfurt DE
------------------------------