>Actually, there is a command called EXITONERROR.

That is the problem.  Exitonerror is not working on our new Nclass.

Also, FTPLASTERROR is not reliable.  When exitonerror was working (on our
old 987) and we had time-outs, transfer errors etc. FTPLASTERROR would
sometimes show 0 (no error).  That is why we came up with the technique
below.

Here is my original post:

Because FTP never sets the JCW to FATAL we came up with a workaround to trap
failed FTP's transfers.
The following code used to work on our 987.  Now on our new Nclass it seems
to be ignoring the exitonerror.  Anyone had similar problems?

     90   ftp> open DOLLY
     91   220 Serv-U FTP-Server v2.5i for WinSock ready...
     92   Connected to DOLLY (10.206.50.152).  (FTPINFO 40)
     93   ftp> user xxxx
     94   331 User name okay, need password.
     95   Password:
     96   230 User logged in, proceed.
     97   Remote system type is UNIX
     98   ftp> :SETVAR FTP_OK FALSE
     99   ftp> exitonerror
    100   ExitOnError mode on.  (FTPINFO 33)
    101   ftp> bin
    102   200 Type set to I.
    103   ftp> put ../TRANSFER/t_tran2.dat t_tran2.dat
    104   200 PORT Command successful.
    105   150 Opening BINARY mode data connection for t_tran2.dat.
    106   FTP/XL Unknown Error Detected.  Error = 232
    107   426 Data connection closed, receive file t_tran2.dat aborted.
    108   ftp> :SETVAR FTP_OK TRUE
    109   ftp> quit
110 110            221 Goodbye!
111 111            NE %IF FTP_OK
112 112            PURGE /NE/TRANSFER/t_tran2.dat
    112   -----Purging /NE/TRANSFER/t_tran2.dat (7000000 sectors)
113 113            7000000 sectors (1709 megabytes) saved
114 114              NE %ENDIF

Thanks,
Tim Cummings

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *