FTP and response issues in AS400

125 pts.
Tags:
AS/400 FTP
AS/400 V7R1
Hi Experts, We have just finished relocating our AS400 from one site to another. Hence change of IP was done but setup remains the same machine wise. After which, some FTP and response issues started to arise. My AS400 is a two partition machine running on the same segment as my users and other interfaces. Issue 1 - Cannot FTP from AS400 (UAT) to Windows server (remote). - This was working fine prior to relocation. Now, we cannot perform GET for files exceeding 1kb (both secured and Non secured). But PUT is working fine. We have opened up all ports in firewall to eliminate any restriction issues. We have already checked the Maximum Transmission Unit (MTU) of AS400 and the switches and are both set to 1500. This only happens in only one of the partition (UAT), the other one is working perfectly fine (DEV). We have done a series of communication trace, it appears that the DEV is by default using a framesize of 590 during transfer. And the remote server is issuing a RESET during transmission from UAT. We have added an additional routing in UAT going to the windows server with MTU of 576 and it works fine. This seems to be a workaround though. Any advice on how we can resolve the RESET thing, and what causes it? Issue 2 - Slow response from AS400 - We have a windows server pulling data from AS400 (UAT again). And based from previous data, current response time is 20 secs delayed. Admittedly, Im not entertaining the Performance issue thing because of some network issues arising (Issue 1) and my Performance tuning skills are not that strong :-(. Nevertheless, anything from the AS400 and Network end that may contribute in improving this response time. Thanks in advance. Jerico

Software/Hardware used:
V7R1

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    ...running on the same segment as my users and other interfaces. However: We have opened up all ports in firewall to eliminate any restriction issues. Can you clarify your network a little? If they're on the same segment, where does a firewall get involved? Or are you saying that the (remote) Windows server is on the outside of the firewall? ...relocating our AS400 from one site to another. So, it is physically the same system? Do you know of any configuration changes that were involved in the relocation? The first area I would check is the match between the TCP/IP interface on the AS/400 and the switch it connects to. First thing to check is the half-/full-duplex setting. If it's set to *AUTO, test setting it manually to the appropriate value in case the auto-negotiation is contributing to any problem. Also, are there other devices that were connected to the same switch during the relocation? Any one of those could be causing trouble, especially during any negotiation. How did you determine that the RESET was actually coming from the remote server? The RST bit could be set by almost any device along the route. It's possible that an auto-negotiate results in a reset. And you might simply replace the cable to your AS/400. It's too easy and inexpensive to skip a simple replacement check. Tom
    125,585 pointsBadges:
    report
  • Jerico
    Hi Tom, Can you clarify your network a little? . . . . Sorry to confuse everyone. Only my AS400 environments are in the same segment. Users and the remote server are on a different segment. From AS400 to the remote server, all rules are allowed. -Yes it is physically the same system. There are no other configuration changes other than the changes in IP. Initially, during relocation I tried to implement a virtual IP setup. But when these issues came up, I switched back to single IP setup. -The TCP/IP interface on both AS400 and switch are set 1Gb line and *AUTO. -The other devices connected to the switch now, are the as400 tape drive and HMC console. Just to highlight, before relocating the switch ports are already configured. When we plugged in, the ports are not working though. Our network guy did a so-called reset on the ports and it worked. I dont know if this could be a factor as well. -The RESET was shown in both communication trace in AS400 and from our network trace. -Yes we have tried to replace the cables. We have even tried to use the actual cable from our DEV server (the one with working FTP) but issue still persists. Thanks
    125 pointsBadges:
    report
  • TomLiotta
    The RESET was shown in both communication trace in AS400 and from our network trace. If the RST bit shows on the segment that the (remote) server is on, then that server is where any specific reason will be found. There's no way to determine a cause of RST from anywhere else. Technically, the RST bit is expected to be handled by the receiving end of the socket by the receiving application closing the socket and attempting to reopen the connection. It's a messy item for something like FTP because you have no control over the programming. No reason is sent across to say why it was done. The only way to determine any reason is to go the sending device and look for the reason. ...before relocating the switch ports are already configured. That sounds like it's a 'managed switch'. Do you know if it is? It probably should be. ...both AS400 and switch are set 1Gb line and *AUTO. *AUTO for the switch implies it handles full duplex. Set the AS/400 line to full and skip negotiation. Get it out of the equation if possible. So far, there's nothing obvious. The only real clue would be in verifying the physical source of any reset. That won't necessarily be where any fix is done, but it's the only device that knows the reason it set RST in the first place. Tom
    125,585 pointsBadges:
    report
  • Jerico
    Hi Tom, Have set the Ethernet line to *FULL Ethernet standard . . . . . . . . : ETHSTD *ETHV2 Line speed . . . . . . . . . . . . : LINESPEED *AUTO Current line speed . . . . . . . . : 1G Duplex . . . . . . . . . . . . . . : DUPLEX *AUTO Current duplex . . . . . . . . . . : *FULL Serviceability options . . . . . . : SRVOPT *NONE Maximum frame size . . . . . . . . : MAXFRAME 1496 What do you mean by "skip negotiations" Thanks
    125 pointsBadges:
    report
  • TomLiotta
    What do you mean by “skip negotiations” When you use something like DUPLEX(*AUTO), there is extra communication between your adapter and whatever it is connected to (your switch). The two send info back and forth to tell the other what they support. At some point, your switch says "Okay, I'll reset for the best setting that you said was good for you." Your adapter may do something similar. That really should only happen when the two first start talking, so it's not a big deal... most of the time. The same kind of thing happens with some other operational parameters, e.g., LINESPEED(*AUTO). Generally, when a high value is negotiated, transient errors may cause a throttling back later. Regardless, if you believe that a value is supported, and you are trying to track down problems, it can be very useful to eliminate elements that (1) aren't needed and (2) affect the area you're investigating. If DUPLEX(*FULL) is supposed to work, then set it that way. You could perform some network analysis to see if DUPLEX(*AUTO) actually results in DUPLEX(*FULL), but it's a lot easier just to set it and see if it is used. Eliminate any *AUTO negotiation. Until you prove it, you don't really know if the two devices are choosing a useful setting. BTW, you should be sure that you have a way to undo anything you set. If the adapter is your only communication path into the system, then some alternative needs to be established in case the setting really turns out to be unsupported on either end. In such cases, I'll often set up a small CL program in the job scheduler to run maybe 10 minutes in the future to undo changes. If things work, I can always stop it from running in a couple minutes. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following