We need to record TN3270 session messages (over TCP) to virtualize mainframe response: what is the best approach?
Trying various request/reply delimiters but it doesn't work, due to the protocol it doesn't translate into to correct R?R pairs in VSI.
I do not have experience with TN3270; therefore, the remainder of the post may or may not be helpful.
I suspect you will need to develop some type of custom DPH and possibly a custom delimiter to parse the request / response into a usable asset in the service.
I saw a similar type of mainframe connectivity tool called JNative client. JNative uses TCP and sends what amounts to a screen scraped command line with input to the mainframe. The requests on the wire contain a combination of EBCDIC and ASCII characters. The EBCDIC characters, which appear to be control information, wrapped the ASCII user input sent to the mainframe. I had to create custom logic to programmatically determine the request / response delimiters because JNative led the payload with several Hex record lengths, userId information in binary format, and padded a variable number of 0x00 characters to align each request and response to a full word boundary. (Probably because the mainframe was expecting data to align to a full word boundary)
During recording, I also found that the response payload generated in the VSI translated as binary due to the EBCDIC characters (0x80, 0x00, 0xFF, etc.) in the payload. I spent a considerable amount of time unpacking and repacking the requests / responses in order to make the VSI response editable. I had no documentation as to what the makeup of the request and responses looked like, so most of my parsing was done on a best guess hack basis. I was able to get a working prototype in place. Had we gone beyond a prototype we would need to re-engineer some of the work due to findings that were uncovered as we learned more.
TN3270 is a combination of Telnet (with prolog negotiation) and screen scrapping as payload with ASCII + EBCDIC characters ....
So we came up to the conclusion that developing and validating such DPH would be too expensive and therefore DevTest not adapted to virtualize such Mainframe service.
Did Joel's recommendation help you out with this issue?