We are currently using UiPath Studio 2023.10 with Terminal Activities 2.8.2 (tested up to 2.9.0; issue persists).
Issue:
Our company is upgrading Rocket Terminal Emulator from version 7.1.8 (32-bit) to 10.3.1 (64-bit).
The terminal itself remains 3270-3 (32x80), which was correctly passed from RTE to UiPath before the upgrade.
After the update, only 24 lines are sent to UiPath.
We have already reviewed the issue with Rocket support using various log files. It appears that UiPath does not correctly handle the thread support of the 64-bit HLLAPI and calls HLLAPI function 22 (Query Session Status) with an incorrect thread ID.
As a result, the buffers are reset to 24 lines (from the API perspective).
Has anyone encountered this issue and found a solution?
Unfortunately, we cannot easily replace RTE due to technical dependencies.
I suggest trying the 2.9.1 version. The release notes mention a similar issue regarding the Rocket Bluzone emulator.
If that still fails, You have the option to override the screen resolution in your code. You can do that by:
Saving the Terminal Session connection in the Output Connection property as a variable of type TerminalConnection
Whenever the screen changes resolution, add an Invoke Code activity, with Target Object = <the_connection_var>, Method Name = OverrideScreenResolution. Set parameters collection as:
a. Direction=In, Type=UiPath.Terminal.Data.ScreenSize, Value=New ScreenSize(32, 80)
b. Direction=In, Type=UiPath.Terminal.Data.CommandOptions, Value=New CommandOptions(100)
As for the response from Rocket support, I’d be very interested in any technical details they provided. If you can share such details, please DM me.
I’m not aware of any thread thread support in the specification of the Query Session Status function. The same function works fine in our implementation with other terminal emulators that implement the HLLAPI specification.
Downgrading RTE 10 is not an option (company decision)
Switching providers/DLLs (ehlapi64.dll, whlapi64.dll, pcshll64.dll) did not help
Upgrading Terminal.Activities from 2.9.0 to 2.9.1 had no effect
Using a direct connection is currently not feasible due to technical dependencies between RTE and another tool
The working solution for us was overriding the screen resolution as described by @bogdan.gaspar
It works across workflows, libraries (our HOST implementations are in a separate library), and processes.
Therefore, I’m marking @bogdan.gaspar´s answer as the solution for this specific issue.
For completeness, here’s an excerpt from the relevant BlueZone/RTE logs showing the issue:
In the attached image, the left side shows logs from BlueZone 32-bit (v7.1.8) and Rocket Terminal Emulator 64-bit (v10.3.1), with versions listed in line 1.
Note: In the 64-bit logs, thread IDs are shown in brackets.
Lines 16 and 22 show the first call to function 22 (thread ID 48300:53964), correctly reporting 32 rows (highlighted in green).
The logs then behave identically until lines 78 and 83, where function 22 is called again—this time with a different thread ID (48300:42268).
However, function 1 (Connect Presentation Space) was never called for this thread ID (48300:42268).
As a result, only the default buffer size of 24 rows is returned.
This incorrect value is ultimately used in communication, causing the issue described.
Notes:
There are no other log entries for the faulty thread ID (48300:42268).
When applying the workaround (overriding screen resolution), the faulty function 22 calls (lines 78+83) no longer appear in the logs.
