Service Virtualization

 View Only
  • 1.  Suggestion on TN3270 recording

    Posted May 10, 2017 08:01 AM

    Hi Team,

     

    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.

    Any clue?

     

    Thanks  



  • 2.  Re: Suggestion on TN3270 recording

    Posted May 24, 2017 12:45 PM

    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.



  • 3.  Re: Suggestion on TN3270 recording

    Posted Jun 08, 2017 12:39 PM

    Hi Joel,

     

    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.



  • 4.  Re: Suggestion on TN3270 recording

    Posted Jun 08, 2017 10:11 AM

    Philippe,

    Did Joel's recommendation help you out with this issue?