Browse Prior Art Database

5250 Twinax File Transfer Scheme

IP.com Disclosure Number: IPCOM000116614D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-31

Publishing Venue

IBM

Related People

Leith, VS: AUTHOR [+2]

Abstract

Methods for transferring a text or binary file between a PC emulating a 5250 display and an AS/400* via twinax protocol are disclosed. Both text and binary file transfer algorithms are presented.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 15% of the total text.

5250 Twinax File Transfer Scheme

      Methods for transferring a text or binary file between a PC
emulating a 5250 display and an AS/400* via twinax protocol are
disclosed.  Both text and binary file transfer algorithms are
presented.

      The 5250 file transfer implies that both ends of a link
understand the transfer scheme and implement that scheme.
Limitations of the 5250 link and host high level programming
languages force the handling of text files to be different than the
handling of data files.  For the purposes of this document, a text
file is one that contains only code points that the host link and
host application can operate on without modification.  Binary files
are any files that are not text files.

      The host file transfer program is XFRCP5250.  Once started,
XFRCP5250 will monitor the 5250 link traffic for further messages.
Once the transfer is complete, XFRCP5250 will return the user to the
command display from which XFRCP5250 was started.

      Messages are exchanged via the emulation session display
buffer.  The starting location of each message is byte is row 1,
column 1.

      Each PC to Host message must be followed by the Enter (Hex 68)
scan code.  The first six bytes of each message are defined as
follows:
    Byte 1   - Always 20
    Byte 2   - F6 when sent from host to PC, D7 when sent
                from PC to host
    Byte 3   - Always FB
    Byte 4   - message sequence number.  The sequence number starts
                with hex 80.  Each message increments by one.  When
                message Hex FF is reached, the message count
                wraps around to hex 80.
    Byte 5   - Byte encoded as follows
                   80 - Initialization message
                   F1 - Download text file
                   F2 - Record template
                   F3 - Upload text file
                   F4 - Upload Complete (from Host)
                   F5 - Reserved
                   F6 - Data block
                   F7 - Error message
                   F8 - Download binary file
                   F9 - Upload binary file
    Byte 6   - Message block indicator
                   F0 - Only block in message
                   F1 - First block in multiple message sequence
                   F2 - Middle block in multiple message sequence
                   F3 - Last block in multiple message sequence
  This byte is meaningful to message types 2 and 6.  It is
   ignored in all other message types.

Error information is byte-encoded as follows:
     F0 - Acknowledge indicator, no error
     F1 - File not found
     F2 - File in use
 ...