I’m wondering if any issues have been reported with the behavior of trace (GCT) files.
We made a set of recordings while visiting the client, but when we replay them remotely (and run path procedures and flow procedures against them) in NON-debug mode, we notice some path errors. While running in debug mode (stepping through), we do not notice any problems.
The particular scenario that seems to keep popping (when we run against a trace file) is in the “Step” node, where source screen is A, we send a host key (e.g., [enter]), and target screen is B. We’ve seen (when running path procedures against some trace files) that ApplinX detects screen C between A and B. We don’t recall this happening (or receiving path errors) when running against the mainframe.
When executing a Path Procedure in debug mode, ApplinX does not see this screen, but when running non-debug, we get a path error.
Screen C happens to be something we call “EmptyForCommand” which is basically a blank screen. In our logic, we occasionally [clear] the screen and issue commands at this “EmptyForCommand” screen. This is the reason it has been identified as a screen.
I’ve tried adding/adjusting wait conditions, adding multiple screens to the “target” side of things, even using the “while screen id” wait type to tell ApplinX to wait until the screen goes away. Still end up with the path error. We won’t have connectivity to the mainframe for a few days, so I’m tabling this behavior assuming it’s related to some oddity in the trace file (vs. some real behavior of the mainframe). Also, I’ve tried adjusting the “Simulate host” vs. “No delays” setting when playing the trace file, but this has had no effect either.
If anyone has any insight/recommendations to add, I would appreciate any suggestions/ideas.