|
SENDEPSV 0SENDEPSV is off.
CD medicat250 Command CWD succeed
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
