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.

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

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.

…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

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?

Im having the same problem for more than a month now. Are there other discussions that points to the probable solution.

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

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.

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.

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.