HP3000-L Archives

October 2003, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tim Cummings <[log in to unmask]>
Reply To:
Tim Cummings <[log in to unmask]>
Date:
Tue, 7 Oct 2003 15:43:27 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
James,

I misunderstood the use of quit in your earlier post.  I agree that
internally calling "quit" is what is needed when an error occurs.  However
in the example shows an error and does not quit (abort).  It seems like if
you don't want to quit on error then don't use "exitonerror".

Tim

-----Original Message-----
From: James Hofmeister [mailto:[log in to unmask]]
Sent: Tuesday, October 07, 2003 11:56 AM
To: [log in to unmask]
Subject: [HP3000-L] FTP 7.0 EXITONERROR not setting variables

Hello Tim, all @ 3000-l,

------------------------------------------------------------
>> James, I think your example says it all.  You missed the
>> point of this thread. Exitonerror means it should not
>> process any more ftp commands after an error occurs, it
>> should just set the VARs accordingly and abort.  The QUIT
>> command (nor any other command) should never have been
>> processed.
------------------------------------------------------------

Sorry, I disagree and the GET example provided is an excellent sample of
why.

First to avoid any confusion... the "exitonerror" is internally calling
"quit" which is not related to a "QUIT" command which may or may not be in
the FTP job or stdin script.

The importance of internally calling "quit" on an "exitonerror" condition is
it drives an orderly shutdown of the FTP Client/Server connection.  The
reason to do this is if we do not perform an orderly shutdown of the FTP
Client/Server connection, then in some cases the remote FTP Server will get
stuck (hung waiting for a command), or will bark an error message due to an
error termination.  As you may guess, this is not an appropriate response in
our example where the "exitonerror" condition is triggered due to a missing
file on the remote host which may be a possible "expected" condition or
outcome.

The solution to our problem here is to make sure that we preserve the
correct variable settings when we call quit from "exitonerror".

I hope this helps.




Regards,

James Hofmeister
Email: <first>.<last>@hp.com
Hewlett Packard - Global Solutions Engineering (WTEC)
P.S. My Ideals are my own, not necessarily my employers.

---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

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

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

ATOM RSS1 RSS2