5250 connections to partitions keeps disconnecting

[JustPassing]

Hello,

I'd like to specify that I'm not an administrator, so my knowledge is limited. We've created partitions on our Power 9 server. When we connect to our main partition, we never have any issues. However, when connecting to one of the new partitions, many of us have disconnects. It feels like it's related to inactivity. If we don't do anything for a while, we get disconnected.

After a few disconnects, the connection somehow is able to remain connected. However, it is extremely exhausting to have to reconnect so many times before it is able to do so. Some users suffer no disconnects at all, others suffer disconnects all the time. Once we are disconnected, no joblog or spool is conserved, meaning the job is no longer in the system and we can't see the joblog for clues.

We are all connected to the same network by ethernet cable.

Is there any way to see why our 5250 sessions are being disconnected? Is there any way to force the joblog to be created as a spool so the job remains in the system and so we can look at the joblog once the job disconnects for clues?

Thanks.

[Scott Klement]

I'd like to specify that I'm not an administrator, so my knowledge is limited. We've created partitions on our Power 9 server. When we connect to our main partition, we never have any issues. However, when connecting to one of the new partitions, many of us have disconnects. It feels like it's related to inactivity. If we don't do anything for a while, we get disconnected.

What happens when you get disconnected? Does the network connection actually terminate, if so, how do you know that it's terminating? Is there a message at all explaining that you had a network error or that something was disconnected? What does that message say?

Or is there simply an inactivity timeout set on the system? Run this command and see what those settings are:

WRKSYSVAL QINACT*

After a few disconnects, the connection somehow is able to remain connected. However, it is extremely exhausting to have to reconnect so many times before it is able to do so. Some users suffer no disconnects at all, others suffer disconnects all the time. Once we are disconnected, no joblog or spool is conserved, meaning the job is no longer in the system and we can't see the joblog for clues.

Job logs are typically configured via the job description. You can look at the user profile to see which "Job Description" a user is set to use. The default is QGPL/QDFTJOBD.

Once you know the name of the job description, change it like this:

CHGJOBD JOBD(the-job-description-object) LOG(4 00 *SECLVL) LOGOUTPUT(*JOBEND)

This says that all messages should always be printed from the job log, including second-level text -- LOG(4 00 *SECLVL) -- and that the job log should be printed by the job itself -- LOGOUTPUT(*JOBEND). Look at the help for the CHGJOBD command for more details on these parameters and what other options you have.

Once you've made that change, you'll need to restart the job for the changes to take affect.

[JustPassing]

What happens when you get disconnected? Does the network connection actually terminate, if so, how do you know that it's terminating? Is there a message at all explaining that you had a network error or that something was disconnected? What does that message say?

Or is there simply an inactivity timeout set on the system? Run this command and see what those settings are:

WRKSYSVAL QINACT*

When our sessions have been open and we try to do something, for example type something on the command line, we see a X SYSTEM in the bottom left and the screen hangs for around 5 seconds before returning us to the login screen. There is no message.



Here are our values :
QINACTITV : *NONE
QINACTMSGQ : *ENDJOB

Job logs are typically configured via the job description. You can look at the user profile to see which "Job Description" a user is set to use. The default is QGPL/QDFTJOBD.

Once you know the name of the job description, change it like this:

CHGJOBD JOBD(the-job-description-object) LOG(4 00 *SECLVL) LOGOUTPUT(*JOBEND)

This says that all messages should always be printed from the job log, including second-level text -- LOG(4 00 *SECLVL) -- and that the job log should be printed by the job itself -- LOGOUTPUT(*JOBEND). Look at the help for the CHGJOBD command for more details on these parameters and what other options you have.

Once you've made that change, you'll need to restart the job for the changes to take affect.

We do use QGPL/QDFTJOBD. Our values for the JOBD are those you've specified, except for the third parameter of LOG. We have LOG(4 00 *NOLIST). We will try changing to *SECLVL and see if that gives us clues.

Thanks.

[Scott Klement]

We do use QGPL/QDFTJOBD. Our values for the JOBD are those you've specified, except for the third parameter of LOG. We have LOG(4 00 *NOLIST). We will try changing to *SECLVL and see if that gives us clues.

*NOLIST means that it will not print (or "list") the job log unless the job ends due to error. You can read the help for the CHGJOBD (or CHGJOB) command to learn what these values mean.

I doubt the job log will help, though... it sounds to me like the network connection is failing intermittently.