Client Access Disconnect

135 pts.
Tags:
AS400 V7.1
iSeries Access
Windows 7 Professional
I have the latest version of iSeries Access running on a Windows 7 Prof PC and connection to a AS400 running V7.1 through a VPN connection. After establishing a 5250 session I can run any file inquiry RPG program, WRKACTJOB, WRKSPLF etc without a problem. If I run a query400 query, the session disconnects before all of the records are even selected. If I run a CL program containing a SNDUSRMSG, the session disconnects before the message is displayed. The job log on the 400 indicates that the PC initiated to disconnect. I have a laptop with the same Client Access and it does not have this problem. It appears that there is a setting in the PC that is causing the problem. Does anyone have a solution to this problem? Google search does not provide any help.

Software/Hardware used:
iSeries access for windows V7R1M0 on Windows 7

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: 12  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
  • CarterC19
    First question - Did you configure your 5250 session to be 132 column? I suspect most modern-day output query screens will want to go to a 132 col session and I can see odd sorts of comm problems happening when a screen gets something it's not ... expecting.
    220 pointsBadges:
    report
  • TomLiotta
    What service level is installed on the PC for System i Access? Anything before SI42424 has known display problems; and SI42424 apparently introduced "random" display problems for Windows 7. (Having the session configured for 80 columns shouldn't make any difference for query or SNDUSRMSG displays. It should only matter for custom programming that doesn't account for 80-column displays.) Tom
    125,585 pointsBadges:
    report
  • Oldtonew
    Tom I'm sorry, I should have had the service level in the original question. It is SI44594. I have deleted all of the .WS files, uninstalled and reinstalled the iSeries Access software which made no difference. There was an article by Cozzi that gave instructions for adding the Keep Alive settings to the registry and the .WS files. I added those but that didn't help either. I also discovered that, using RSE, I can make changes to RPG source but I can't save the changes back to the AS400. The error here indicates a TCP/IP timeout. Here again, the laptop does not have this problem.
    135 pointsBadges:
    report
  • TomLiotta
    ...using RSE, I can make changes to RPG source but I can’t save the changes back to the AS400. The error here indicates a TCP/IP timeout. That would indicate to me that something (e.g., firewall ports) is misconfigured. If it shows as a timeout, then it might be that inbound and outbound traffic isn't quite in sync in a firewall for example. Requests can flow inbound okay, but responses might not be returning properly. I would look closely at all DDM (over TCP/IP) settings on the AS/400 and also ensure that DDM ports are appropriately open. But that doesn't quite fit with the original issue. The oddly selective nature of the disconnects doesn't seem to make sense yet. To get some specific info, try this small DSPPGMMSGQ command. The CL source is:
    pgm
    
    
    /* sndpgmmsg   '===> External program message queue +
                    display was requested...'  +
                     topgmq( *EXT ) +
                     msgtype( *INFO )   */
    
       sndusrmsg   '===> External program message queue +
                    display was requested...'  +
                     msgtype( *INFO )
    
    
       rcvmsg     pgmq( *EXT ) msgtype( *LAST ) +
                    rmv( *YES )
       monmsg   ( CPF0000 )
    
       return
    
    
    endpgm
    And the *CMD source is simply this:
     DSPPGMMSGQ: CMD        PROMPT('Display the *ext program *msgq')
    Over the years, I often wanted to go back and look at what some function had sent from a RPG DSPLY op-code or other means. Getting the original display back was always tricky, so I put that trivial code together. With that, I just run DSPPGMMSGQ and the external message display shows up. I made a minor change for your case by commenting out the original SNDPGMMSG and using SNDUSRMSG instead. The program sends a message for the external display. After you look the display over and press <Enter>, the program removes the temporary marker message to clean up after itself. It might be useful to see how your session reacts with that simple SNDUSRMSG. It might also be useful to see how it reacts if the SNDUSRMSG is commented out in favor of the original SNDPGMMSG. Tom
    125,585 pointsBadges:
    report
  • Oldtonew
    Tom, Thank you for the CL. I ran the program with the sndusrmsg and sndpgmmsg and the results were the same. The session disconnected both times. The appropriate portion of the job log on the AS400 is below. Statement . . . . . . . . . : 1501 Message . . . . : 1501 - SNDUSRMSG MSG('===> External program message queue display was requested... ') MSGTYPE(*INFO) CPI2401 Information 70 01/28/12 06:59:09.698591 QMHSNUSR QSYS 003A *EXT *N Message . . . . : ===> External program message queue display was requested... Cause . . . . . : The message was sent by the SNDUSRMSG command. CPF5140 Diagnostic 70 01/28/12 07:00:02.012550 QWSERROR QSYS 0630 QWSMEEH QSYS 0073 Message . . . . : Session stopped by a request from device ISDGHOMEA. Cause . . . . . : The request shutdown was caused by either the user turning the power off, by a device error, or the ASCII controller inactivity timer expired. Recovery . . . : Close the files and vary the device off (VRYCFG command). If the problem occurs again, enter the ANZPRB command to run problem analysis. CPF5503 Diagnostic 30 01/28/12 07:00:02.012663 QWSERROR QSYS 0652 QWSMEEH QSYS 0073 Message . . . . : Input or Output request failed. See message CPF5140. Recovery . . . : See the message CPF5140. Correct the errors and then try the request again. As I mentioned earlier, the laptop I have does not have this problem. Is there something in Windows 7 where some setting could have been set and never was cleared?
    135 pointsBadges:
    report
  • OldSchoolGuy
    Im having the same problem for more than a month now. Are there other discussions that points to the probable solution.
    10 pointsBadges:
    report
  • TomLiotta
    Im having the same problem...
    .
    What problem? A couple different problems are mentioned in this thread. That is, please describe your symptoms and tell us your Windows OS and service packs, your server OS version, your iSeries Access version and its service level. Does your problem also happen only for SNDUSRMSG or Query/400?
    .
    I missed the earlier reply to this thread, so I didn't get a chance to follow up. The IBM tech note Telnet Session Drop Checklist should be followed first to be sure those elements are covered.
    .
    Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Also, please describe how the problem PC is connected to the server? Is it a local LAN connection? Or is it remote? If it's remote, what routers or firewalls are used? Is it a VPN connection? -- Tom
    125,585 pointsBadges:
    report
  • Programmer02
    We have an iSeries that runs on V5R1 and are using the Client Access V5R1 for our 5250 connectivity. For so many years we never had this problem of intermittent user disconnection. What we noticed is that when a session will be disconnected, a log with Message ID CPF590A with severity 40 will be recorded for a particular session (QPADEV02R8). Then right after that, a message "Session stopped by a request from device QPADEV02R8" with a Message ID CPF5140 appears.with severity 70. Cause . . . . . : The request shutdown was caused by either the user turning the power off, by a device error, or the ASCII controller inactivity timer expired. Then it will be followed (in the DSPLOG) by a message ID CPF1164, indicating that the associated job was abnormally terminated. Problems like this happens to workstations connected to the iSeries. PCs are connected to the iSeries via LAN. PC's accessing Linux Servers does not experience disconnetion problem of any sort. Please help.
    10 pointsBadges:
    report
  • Splat
    Programmer02, what you're seeing in your job logs is the result of users exiting the iSeries Access session without signing off. If the users were to sign off first, then exit the session you wouldn't be seeing that in the job logs.
    6,995 pointsBadges:
    report
  • TomLiotta
    The joblog messages are the general result of any service disconnection, whether initiated by users or not. Anything that causes RST to come on can be an example cause. They're often misleading in that they allow the assumption of user action. The "device error" can be in any component from the remote keyboard through to the adapter in the server, including software components.
    .
    When a disconnection happens, there's no way for an end-point of the connection to know where along the route the problem arose. It just knows that there is no longer any signal coming through that was part of the conversation.
    .
    For V5R1, there is the complication of age. It has to run on an older Windows OS as well as being older itself. Any newer replacement hardware, e.g., a more 'modern' switch, might complicate the networking. If cabling has been in place for a long time, it might simply have worn shielding and pick up stray signals.
    .
    Before doing that kind of checking in depth, make sure items in the IBM Telnet Session Drop Checklist are verified. Whether anything can be done for V5R1 is unknown.
    .
    Tom
    125,585 pointsBadges:
    report
  • ToddN2000
    We see a lot of that as well. Some users accidently close the CA window instead on minimizing it when trying to open a second session on go to the web.
    9,655 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