|
Anything with SSL (especially on V7R1) I would call IBM support. ;)
Anyhow do you have a full job log and possibly the FTP log? That may help.
Brad
www.bvstools.com
On Wed, Jan 4, 2017 at 12:02 PM, Rob Berendt <rob@xxxxxxxxx> wrote:
Good try on logging off and back on again.
Are you a single lpar / system environment? So it's not like one of your
sessions came from a different system?
Ooo, I just thought of something! NETSTAT *IFC. Do you only have one? If
not, then perhaps the target will only accept ftp connections from one
particular interface. Nothing comes to mind as to how to "bind specific"
the ftp client. And if you start hopping around interfaces at random this
can be an issue.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Mike Cunningham <mike.cunningham@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 01/04/2017 12:41 PM
Subject: IBM FTP Command using *SSL
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
We use the IBM supplied FTP command to do a lot of file transfers to
windows servers. Many of these file transfers run automated late night or
early morning when we are not open. Recently we started seeing dumps from
these jobs. A QPDSPJOB and a QPSRVDMP spool file. Error issued is C2M1601
Signal SIGABRT raised (abnormal termination). We would run these same jobs
when we start in the morning if we see them fail overnight and they will
run perfectly fine in the morning. We have been trying many different
things to try and isolate this issue and thought for sure it had something
to do with the windows server being the FTP Server in these cases. At
times an FTP download would fail and an FTP upload from the same location
on the windows server would work. We would even try watching the jobs
from home at night and when one failed we would manually run the FTP
command from a command line and it would fail with the same error and 10
minutes late it would work without any changes made anywhere on either
side of the process. When we could see the failure if we changed to a
non-SSL connection it would work every time. (FTP RMTSYS() SECCNN(*SSL) vs
FTP RMTSYS())
Just today for the first time it failed on an FTP I was doing from an
interactive 5250 session. Tired it three times from one session and it
failed three times with the error we see in the automated jobs. I used a
second session I happen to have started and it work correctly immediately.
Used the IBM FTP command from the session where it worked and that worked
too both SSL and nonSSL. Went back to the other session where it didn’t
work and IBM FTP command failed also on SSL bot not on nonSSL. Signed off
the failing session and back on and tried FTP again and both failed while
the other session worked fine in all instances. Ten minutes later (the
time I was writing this email) the session that was failing is not
working and I did nothing.
This almost seems like something with an SSL connection is being cached
outside the interactive session that eventually gets cleaned up and then
it works again. If there were an incoming HTTP request I would suspect
one of the service jobs in the HTTP subsystem was getting confused. Is
there some autostart or prestart service job that all FTP traffic might
use/reuse in QSYSWRK that might be where our issue exists?
This one really has us stumped.
Mike Cunningham
p.s. search for the C2M1601 error didn’t find anything related to FTP on a
V7.1
________________________________
This email may contain confidential information about a Pennsylvania
College of Technology student. It is intended solely for the use of the
recipient. This email may contain information that is considered an
“educational record” subject to the protections of the Family Educational
Rights and Privacy Act Regulations. The regulations may be found at 34
C.F.R. Part 99 for your reference. The recipient may only use or disclose
the information in accordance with the requirements of the Federal
Educational Rights and Privacy Act Regulations. If you have received this
transmission in error, please notify the sender immediately and
permanently delete the email.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
