Our company uses Rumba Main Frame Emulator for Users to access our Terminal Sessions and implement automation. Historically, users have created macros to complete long running tasks for them within the terminal program. Our COE has been contacted and asked to move maintenance of the macros to within our team. Since the project has begun, end-users are noting the previous macro based automations are faster than our current automations.
Note
I don’t have statistics for the speed difference between the automation platform and the macro based automation. Our automation has more features like reporting and error handling. Our automations also run unattended. However, we are facing file loads that would require us to implement concurrency to be able to complete within our SLA.
Theory
The ongoing theory is that since UiPath is running both the emulation software and the automation software, it runs slower than Rumba. If we had UiPath monitoring the Macros for errors and resolves the commonly occuring errors, then the automation would be fast enough to not require concurrency while maintaining the additional features like error handling and reporting. I’m not particularly convinced.
Question
Has anyone done a similar experiment within their companies? What is your teams best practices for mainframe emulation?
No, I did not had the experience of using macros within mainframe terminal, however in my previous company, we initially used direct RUMBA sessions within UiPath which gives timeout errors a lot of times then I have suggested to use the UiPath emulators/connectors to connect mainframe directly in backend (We don’t even see a screen of emulator) without using RUMBA and it has help us solve the timeout issues and increases performance as well
I always recommend to use UiPath inbuilt emulators
This was what our team ended up doing. Mainframe applications often have an EHLLAPI.dll file within their installation. By setting up a pre-defined instance, you can have whatever Emulator you want communicate through the file. This enables the runtime and calculation to occur on a different process.
Our team treats workflow files like individual functions. It’s easier for us to maintain them over time. Repeated activities, like logging in, are grouped into a library activity. When using Terminal activities, the default delay for any “Attach Terminal Connection” activity is set to 1000 ms. We changed it to 25 ms and set the value as an asset so it’s easy to change in the future. We also combined workflows into larger files to limit connecting and reconnecting. We also reduced delays from each individual workflow activity. We found with the API, we needed 0 delays.
Note 3 - Oddities in Production
In our production environment, we found Rumba was growing in runtime per transaction by 1s every 8 transactions. There didn’t seem to be an upward limit. The longest transaction rose to 45s each. We were able to resolve this by upgrading Rumba. We don’t have a net cause, but we are expecting it’s related to logging or Rumba’s history settings. We investigated CPU usage and memory usage.
sharazkm32
donfeng91
SorenB