Google turned up: --<snip>--- TRANS13 Error Writing File to Host: File Transfer Canceled Explanation: Host program has detected an error in the data file during the Send operation. User Action: Retry. If problem persists, call your host personnel. ---<snip>-- Some listed the same Explanation for a "Receive" operation.
Editing the IND$FILE MODULE and searching for '13' also turned up: 13 Error writing file to host: file transfer canceled $ Google also showed a number of different terminal emulators displaying TRANS13. One of them referred to the difference between CUT (Control Unit Terminals) and DFT (Distributed Function Terminals) terminals (if I remember those acronyms correctly). Which are you using? Often, the descriptions were for PC to MVS/TSO. Most referred to the DCB being wrong (LRECL, RECFM, and for MVS, BLKSIZE). What are the DCB specs for the file being transferred? Can you provide the exact command you are using? If it's from a GUI, then check the CMS command buffer for the previous command immediately after the failure. You can do that by issuing: SET PF07 RETRIEVE BACKWARD and the pressing PF7 twice. The first press will display the SET command. The second should show the IND$FILE command with all its arguments. That may provide a little bit more useful information. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Horlick, Michael" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 12/04/2008 01:40 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject TRANS13 , IND$FILE and CA-TPX Greetings, My client is still having problems with using IND$FILE over TCP/IP for VM and CA-TPX. This does not occur with SNA. I have opened an issue with CA and they can?t see the problem and the client is supposed to be dealing with MicroFocus regarding the PC component of this puzzle (ProClient). The client has asked me about TN3270E and claims that the Cisco Router 7505 that he uses for SNA connectivity to the mainframe has TN3270E installed. I explained that I don?t think that is an issue (he pointed to me to an IBM web-site stating that TN3270E is not available in TCP/IP for VM for terminals, just printers). He think maybe it is an issue. Also, the file transfer works when he deselects extended attributes. Any clue on how to get to the bottom of this? What exactly does a TRANS13 error mean and how does IND$FILE communicate that info to the emulator so that a pop up window would appear with that error? Is it a return code from the IND$FILE module? Maybe I need to open an issue with IBM to help me understand IND$FILE and when this error message occurs? Of course, to complicate the issue, sometimes a file transfer works, sometimes it says it works but doesn?t actually create the file on the mainframe and sometimes he get the TRANS13 (but only moving a file from the PC to the mainframe and not the reverse). Why would something work in SNA and not TCP/IP when the same 3270 datastream is sent to it? Any nuggets of wisdom/advice would be appreciated. Mike Horlick CGI Montreal The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
