Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ZIP File Transferred 100% but Delivered Corrupted? 1

Status
Not open for further replies.

PS2GT3

Programmer
Jun 26, 2003
8
IE
I have an automated script which transferrs a ZIP file to a HOST, the file transfer seems to work 19 times out of twenty, however, in about 5% of cases the transfer dialog stalls at the 85%-100% mark on the remote for a few seconds and then indicates 100%. On the host side the ZIP has been received and from a size viewpoint is correct, however, it cannot be unzipped due to errors. It has been confirmed that the source ZIP file is in good shape and can be unzipped. Why do I get good XFERSTATUS results instead of an error indicating that the transfer actually failed?
 
Hi knob

Here is the script, customer detail left out where applicable, hope it tells you what causing the problem.
Please note we are using a slightly modified version of
the procomm supplied host.wax in the Host Site, however, the file transfer aspect remains as the original:-


#define NOTRANSFER 0
#define TRANSFERRING 1
#define TRANSFEROK 2
#define TRANSFERNOTOK 3

proc main

integer iXFer
integer nRetrys

; Dial into Host Site
WriteLog( "Beginning Price/Promotion Comms with Host Site." )
dial data "HostSite"
while $DIALING
endwhile

; Log into the System, User Id and Password must be correct
waitfor "Enter your FULL Name: "
WriteLog( "Logging In." )
transmit "FullName^M"
waitfor "Is this correct (Y/N)? "
transmit "y"
waitfor "Password: "
transmit "ThePassword^M"


; Now we switch to the price and common promos folder where we will deposit relevant data
; such that price/product changes can be maintained and also common promotions can be maintained
WriteLog( "Switching to the price/promo folder." )
transmit "s"
waitfor "Change to what directory? "
transmit "c:\procfile^M"
waitfor "Your Choice? "

nRetrys = 3
iXFer = 0
while nRetrys>0

; Get the HOST to remove the previous price/promotions data file before sending the current one
; It is possible that the file may not send correct is the same named file already exists
WriteLog( "Removing DATA.ZIP if it exists already." )
transmit "k"
waitfor "File name? "
transmit "data.zip^M"

; Now prepare to send the data to Knocknacarra
waitfor "Your Choice? "
WriteLog( "Sending price/promo data to Knocknacarra." )

transmit "u"
waitfor "Your choice? "
transmit "z"
waitfor "File name? "
transmit "data.zip^M"
; the pause is necessary for the HOST to be ready to receive the data
pause 2
sendfile ZMODEM "data.ZIP" ; Upload using ZMODEM protocol.
; we pause again to ensure that the $XFERSTATUS var
pause 2
iXFer = $XFERSTATUS
while iXFer==TRANSFERRING ; Pause script while transferring.
iXFer = $XFERSTATUS ; Reads the current status and resets $XFERSTATUS to real-time transfer position
yield ; Yield processing
endwhile
waitfor "Your Choice? "

if iXFer==TRANSFEROK
; the price/promo transfer went OK
WriteLog( "Price/Promo Transfer Completed Successfully." )
WriteLog( "Removing our own price/promo flag file due to successful comms." )
if isfile "c:\preppfile\pricfile.ok"
delfile "c:\prepfile\pricfile.ok"
endif
nRetrys = 0
else
; the price/promo transfer failed
WriteLog( "Price/Promo Transfer Failed." )
iXFer = 0
nRetrys--
endif
endwhile

WriteLog( "Logging out." )
transmit "g" ; Log out of the Host Site system, this also disables the Host Site Host Mode

pwexit
endproc

proc WriteLog

param string cLogMess

string cDTLog

strfmt cDTLog "%s %s : %s`r`n" $DATE $TIME cLogMess

fopen 0 "c:\procomm.log" APPEND
fputs 0 cDTLog
fclose 0

endproc

 
I seem to recall a problem where $XFERSTATUS does not return the correct value if, I believe, the receiving system aborts the transfer. I will see if I can test this theory tonight.


aspect@aspectscripting.com
 
OK, it looks like the scenario I am remembering is if a transfer is ongoing from one machine running Procomm, performing a file transfer to another machine also running Procomm (I doubt what is running on the second machine matters). If the transfer is cancelled on either side, $XFERSTATUS correctly reports 3. However, if the phone line is unplugged, $XFERSTATUS incorrectly reports 2. Is the connection possibly dropping in your case?

Procomm has an option to cancel the file transfer if the connection drops, but $XFERSTATUS still reports an incorrect result. It should be possible for your script to detect that carrier has been dropped by monitoring the $CARRIER system variable with a when command (I have an example or two of this on my site). When this happens, a cleanup procedure can be called to handle the situation.


aspect@aspectscripting.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top