Your terminal emulator is the I/O between your PC and the mainframe or some other system.
The process on the mainframe is asynchronous to your VB code process. Text you Put on the screen is there when you put it there. There is no delay, so any Wait that you have in your code is utterly unnecessary if you're simply placing text on your screen
However, once you issue a Command via SendKeys(), it's like arriving at a STOP sign at an intersection in the road. The only way that you know that it's TIME to enter the intersection, is when you observe that no other vehicles will coincide with your vehicle's space as you proceed through the intersection. That is observational feedback. A rational person would never pre-determine that they would simply WAIT 10 seconds at every stop sign and then blindly charge through the intersection.
In a similar way, when you send a command to the mainframe from your emulator, the mainframe asynchronously processes the command and then returns the result to the emulator. That might take 1 ms, 1 min, never or anything between. Your code must WAIT and monitor the feedback before executing the next statement.
There are several techniques for waiting for just the right moment. WaitForCursor: You can wait until the cursor appears at the screen rest coordinates...
Do Until oScreen.WaitForCursor(row, col)
WaitForString: You can wait until a particular string appears on the screen at a specified coordinate in a similar way.
This quote from the Reflection site is applicable for Extra!
Use the appropriate "WaitFor..." method
After sending each AID key (Enter, PF3, etc.) to an IBM 3270 or 5250 session, it is necessary to use some technique to wait adequately until the host system sends the next screen of data. Reflection provides several convenient methods for this in the IbmScreen interface: WaitForCursor, WaitForText, WaitForHostSettle, WaitForKeyboardEnabled, and others. If you know what screen should appear after sending the AID key, use WaitForText or WaitForCursor rather than other methods that work by monitoring the state of the keyboard being unlocked for a particular duration. WaitForText or WaitForCursor will always be faster than using a method that works by waiting for an arbitrary duration to elapse.