RE: sFTP expect odditity

Dennis, first off, I apologize for the woefully incomplete information. No real excuse, other than I was working through a slow connection on a netbook that liked to not move nicely.

This is probably the only time a laptop with a full screen would have been a big help. Got to work this morning and learned that all worked as expected. Error processing was correct. My only guess is I was having enough frustrtation trying to scroll through joblogs that I missed it. I apologize for wasting anybody's time.

My supervisor has always been against making changes, unless an emergency, on a Friday. This mess was out of my hands, as the tail was wagging the dog. But, it does point to the potential issue of making changes on a Friday night.

Again, I apologize for the post. As Emiliy Litilla would have said "Oh, never mind".

John McKee
-----Original message-----
From: "Dennis Lovelady" iseries@xxxxxxxxxxxx
Date: Mon, 13 Sep 2010 03:57:07 -0500
To: "'Midrange Systems Technical Discussion'" midrange-l@xxxxxxxxxxxx
Subject: RE: sFTP expect odditity

Any attempt to answer your question about cause of unexpected behavior would
be pure conjecture without the source code.

Put yourself in our shoes. You've said, "My script doesn't work; what's
wrong with it," and you haven't provided anything that would help us arrive
at a conclusion.

Maybe I should take that back. Maybe the correct answer is, "your script is
probably wrong."

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Let us endeavor so to live that when we come to die even the undertaker
will be sorry."
-- Mark Twain

The switchover to a different server was made Friday night. The
manager did maintain sftp access. I ran sftp and ssh interactively to
get the known_hosts entry updated. But, Saturday morning, the job did
not work. I was able to (again) sign on interactively and do the file
transfer. That was when I noticed the difference. The site now does
not request a password. My unmodified expect script is coded to return
a 2 if no password prompt is received. And that is to be returned to
the CL so that error processing can be done. This has worked before.
Any idea why the return code did not get set to an error value since
the password prompt was never sent?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.