What AS400 CL COMMAND TO USE?

370 pts.
Tags:
CL command
IBM iSeries
Network
     Seeking your opinion on this actual scenario (still unresolved as of this writing): an external branch windows server connected to an AS400(model 820) via IPVPN connection with 512 kbps bandwidth have a "CONNECTION FAILURE" message but other Windows Application used by the branch that's still connected to AS400 as backend server runs smoothly. The Windows application that is at issue here is a Report Download facility that's connected to the AS400 which previously was working but there was an incident wherein the Network connectivity of the branch was down and when it became normal, the branch could not anymore use the windows application to download reports, there's the message "CONNECT FAILED ERROR NO. 53" message. Other Windows Applications used by the branch that's connected to the AS400 as backend server are working after the "network down incident" except for this windows application to download reports. Is it possible that this connection failure message when doing report downloading is due to the sudden network problem of the branch that when the network connection returned back to normal, when the branch repeated to do the report download activity, the previous "abruptly ended" report download activity still persists and is causing the problem. The reports being downloaded by the branch from AS400 are linked to QDLS where the concerned branch has an enrolled folder in QDLS and the Windows Application used by the branch is accessing this folder to come up with the reports. Is there a command in AS400 to check on this scenario? I already check the ip address of the branch server and this is defined in the AS400. Also adviced the branch do a "PING" if the branch can detect the AS400 and the ping was successful and vice-versa, i can also ping the branch. Do you have suggestions on how to address this issue using other AS400 CL commands? Thanks.

Software/Hardware used:
i-Series model 820, OS V5R3M0

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: 2  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
    ...use the windows application to download reports, there's the message "CONNECT FAILED ERROR NO. 53" message. What does that "windows application" documentation say that "CONNECT FAILED ERROR NO. 53" means? I'm not sure we can help since we don't know what the application is nor how it works. Error 53 isn't meaningful to us. The reports being downloaded by the branch from AS400 are linked to QDLS... The /QDLS file system possibly ought to be abandoned. If this "windows application" relies on it, the application should probably be replaced. You tagged the question with V5R3, so the server is probably okay due to its age. But if you're running Windows beyond Win2K, the Windows networking may be contributing to problems. The /QDLS file system is an old DOS-style file system that Microsoft is slowly leaving behind, with good reason. IBM has been following along as the demand has faded. Is there a command in AS400 to check on this scenario? To check what scenario? To check if a Windows app is having problems? I already check the ip address of the branch server and this is defined in the AS400. That shouldn't matter at all unless your AS/400 somehow needs to connect to the branch. From your description, it sounds like the connection is initiated from the opposite direction. Also adviced the branch do a "PING"... As long as any other connection works from the branch to the AS/400, a ping is unlikely to give much useful info. If you have a network tech available, multiple pings over time can be useful for some high level indications. Do you have suggestions on how to address this issue using other AS400 CL commands? When the Windows successfully connects to your AS/400, it will be a connection to one (or maybe more) of the various servers. It might connect through the file server for example. When it does, there will be tracks you can follow. First, you should be aware of when the connection is going to happen. A few seconds before, you should be watching the system history log through the DSPLOG command. You may need to specify a starting time close to the current time on the command if your history log has many (hundreds or thousands per minute) messages to scroll through. Refresh the list and watch until you see a message like one of these:
    • *SIGNON server job 275702/QUSER/QZSOSIGN processing request for user WINAPP on 11/17/11 14:34:09 in subsystem QUSRWRK in QSYS.
    • User WINAPP from client 10.0.1.57 connected to job 275867/QUSER/QZHQSSRV in subsystem QUSRWRK in QSYS on 11/17/11 14:34:10.
    The first message would be a CPIAD0B, and the second would be CPIAD09. In those two examples, I used WINAPP as the name of the user profile that the Windows app connects as. You'll need to determine what that name is. (You might determine it simply by watching DSPLOG and keeping track.) Or you might see a message like this one instead:
    • Job 275967/QPGMR/QZLSFILE started on 11/17/11 at 18:27:43 in subsystem QSERVER in QSYS. Job entered system on 11/17/11 at 18:27:43.
    That will be a CPF1124 message and will reference a job named QZLSFILE, and it won't be as useful as if one (or both) of the others appear. It won't directly identify the Windows app user, and there might be a lot of simple 'job start' messages that will confuse things. In any case, what those messages can do is give you the name of a server job that is serving the request. You then have an opportunity to use DSPJOB against the server job to watch its joblog. The server joblog may contain helpful info about any disconnections that happen. Another possibility is to use the WRKOBJLCK command against the WINAPP user profile object (the *USRPRF object) while the Windows app is connected. There is a basic lock applied over the user profile by the system while any job is running under that profile. That includes server job instances. By listing locks for the profile, you can get a list of current jobs that are associated with the profile. And again, that lets you have some visibility into joblogs. A third possibility is the NETSTAT *CNN command to bring up a list of connections. After the full list displays, you can press F15=Subset to subset the list down to only connections from the remote IP address, as long as you know the address. There might be one or many connections. You might need to drill into multiple connection jobs to track down ones associated with WINAPP (whatever the profile actually is). No matter what, until you start to track what types of connections are being made and by what profile, there is little that can be said about where to look and for what. (Worse, if this is running completely under old networking technology, it might be difficult obtaining fixes -- if any exist.) Post back if new info is available. Tom
    125,585 pointsBadges:
    report
  • danmd5systemad
    Sir Tom, the culprit on this problem is already identified.... it's the telco company that installed the network infrustructure in our branch. When our network guys swiched to DIAL UP setup for the branch network connectivity, the branch was able to use the windows application to download reports, although it was a slow process, so this problem has been elevated now to our telco provider to sort and fix this problem. Thanks for your assistance.
    370 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