Topic
  • 18 replies
  • Latest Post - ‏2013-03-22T08:27:31Z by SystemAdmin
SystemAdmin
SystemAdmin
6195 Posts

Pinned topic iSeries job lost after 1 hour of inactivity on RUI-client

‏2013-01-24T08:49:05Z |
Hey Forum,

We have got some connection-problems with our application.
When a user logs-in, a job on iSeries (Power 7) is created by syslib.setRemoteUser(username,password).
When this user in inactive for 1 hour, this job disappears from the iSeries.

Our specifications:
  • Application developed and deployed with RBD 8.0.1.3
  • Service layer in EGL, generated to java
  • data access on iSeries, written in EGL and generated to COBOL
Updated on 2013-03-22T08:27:31Z at 2013-03-22T08:27:31Z by SystemAdmin
  • dan_darnell
    dan_darnell
    973 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-24T16:52:41Z  
    Is the IBM i job related to making program calls from the service tier or what does the job do? I understand that the job ends but what is the problem, exactly? How is this negatively impacting your application?

    --Dan
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-25T09:02:36Z  
    Is the IBM i job related to making program calls from the service tier or what does the job do? I understand that the job ends but what is the problem, exactly? How is this negatively impacting your application?

    --Dan
    Hey Dan,

    The iSeries job is used by the services to call programs.
    This job is reused when a user makes a call within the hour.
    When a user is inactive for 1 hour, the job is ended on the iSeries.

    We want to increase this timeout, but we don't find the correct spot.
    We have already looked into tomcat, the web.xml of the application and on the iSeries, but no success.
  • M Groeneweg
    M Groeneweg
    80 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-25T12:55:41Z  
    Hi Niek,

    Does the iSeries have system value QINACTITV to anything else than *NONE? Or more specifically, 60?
    I'm not sure whether this system value affects the job type used in your configuration, but just to make sure.

    Marcel
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-25T14:05:03Z  
    Hi Niek,

    Does the iSeries have system value QINACTITV to anything else than *NONE? Or more specifically, 60?
    I'm not sure whether this system value affects the job type used in your configuration, but just to make sure.

    Marcel
    Hey Marcel,

    QINACTITV is set to 300, so this does not cause the problem...
    Thanks for you reply.

    Niek
  • markevans
    markevans
    2844 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-25T14:14:57Z  
    Hey Marcel,

    QINACTITV is set to 300, so this does not cause the problem...
    Thanks for you reply.

    Niek
    Niek,

    As Dan asked..what is the problem with the job ending? Performance, the call fails, or something else?

    Are you using a JCA connection (connection pool) vs a straight connection (Java400J2C vs Java400 as the remoteComType)?

    Is the Session for the JAva/RUI still active? In other words, did the session timeout and as a result the job was ended because the client ended?

    Is this using the UI Gateway (Converse of UI Record) or straight RUI support?

    Have you run the EGL Java Runtime trace (vgj.trace.type=-1, vgj.trace.device.option=0) and see if any additional messages are sent out at the time the job is ended?
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-29T08:54:35Z  
    • markevans
    • ‏2013-01-25T14:14:57Z
    Niek,

    As Dan asked..what is the problem with the job ending? Performance, the call fails, or something else?

    Are you using a JCA connection (connection pool) vs a straight connection (Java400J2C vs Java400 as the remoteComType)?

    Is the Session for the JAva/RUI still active? In other words, did the session timeout and as a result the job was ended because the client ended?

    Is this using the UI Gateway (Converse of UI Record) or straight RUI support?

    Have you run the EGL Java Runtime trace (vgj.trace.type=-1, vgj.trace.device.option=0) and see if any additional messages are sent out at the time the job is ended?
    Hey Mark,

    The libraries are set and an authentication program is called when a user logs-in.
    We should reuse this job for all services that are run during the session.

    • JAVA400 is the remoteComType as straight connection.

    • We cannot see any timeouts on the RUI page, all services can be called and all session variables are still in place.

    • We are using straight RUI support (didn't modify anything here...)

    • I will let you know what the outcome of the EGL Java Runtime trace will be as soon as i create another deployment.
  • dan_darnell
    dan_darnell
    973 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-29T17:58:06Z  
    Hey Mark,

    The libraries are set and an authentication program is called when a user logs-in.
    We should reuse this job for all services that are run during the session.

    • JAVA400 is the remoteComType as straight connection.

    • We cannot see any timeouts on the RUI page, all services can be called and all session variables are still in place.

    • We are using straight RUI support (didn't modify anything here...)

    • I will let you know what the outcome of the EGL Java Runtime trace will be as soon as i create another deployment.
    "The libraries are set and an authentication program is called when a user logs-in.
    We should reuse this job for all services that are run during the session."

    First:
    Are you indicating "STATELESS" or "STATEFUL" in your build descriptor for these program calls? They need to be stateful if you expect them to stick around.

    Second:
    That said, we have generally found it best not to design web applications such that they require stateful connections. Rich Internet Applications are stateless by their nature (from the perspective of the application server tier) and while you can shoehorn in sessions to gain statefullness (new word) it is better (IMHO) to design such that you don't need to maintain state in the application server tier. If you need to establish a library environment when you make a program call then you can do that with a job description.

    Is 100% of your server access via program call or are you doing any database access out of EGL via SQL? I ask because another issue with trying to be stateful is that database connections are usually pooled (and therefore stateless). If you ever plan to do any SQL-based access out of EGL you need to rethink now the whole stateful/stateless proposition.

    --Dan
  • Jeroen.ASIST
    Jeroen.ASIST
    11 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-01-31T09:58:49Z  
    "The libraries are set and an authentication program is called when a user logs-in.
    We should reuse this job for all services that are run during the session."

    First:
    Are you indicating "STATELESS" or "STATEFUL" in your build descriptor for these program calls? They need to be stateful if you expect them to stick around.

    Second:
    That said, we have generally found it best not to design web applications such that they require stateful connections. Rich Internet Applications are stateless by their nature (from the perspective of the application server tier) and while you can shoehorn in sessions to gain statefullness (new word) it is better (IMHO) to design such that you don't need to maintain state in the application server tier. If you need to establish a library environment when you make a program call then you can do that with a job description.

    Is 100% of your server access via program call or are you doing any database access out of EGL via SQL? I ask because another issue with trying to be stateful is that database connections are usually pooled (and therefore stateless). If you ever plan to do any SQL-based access out of EGL you need to rethink now the whole stateful/stateless proposition.

    --Dan
    I'm a colleague of Niek, also trying to solve this issue.

    These program calls are not stateful or stateless. RemotePgmType is not defined, so it is the default value: EGL. I tried stateful, but then those programs don't work.

    We cannot set the library list fix in the job description, the library list can change depending on the application and the user, so we use the first called program to set it. So we need the library list of the job for the rest of the programs.
    Jeroen
  • dan_darnell
    dan_darnell
    973 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-02-01T00:03:50Z  
    I'm a colleague of Niek, also trying to solve this issue.

    These program calls are not stateful or stateless. RemotePgmType is not defined, so it is the default value: EGL. I tried stateful, but then those programs don't work.

    We cannot set the library list fix in the job description, the library list can change depending on the application and the user, so we use the first called program to set it. So we need the library list of the job for the rest of the programs.
    Jeroen
    I see now that you are invoking programs written in EGL and generated to COBOL...hence the remotePgmType of "EGL".

    This one is outside of my range of experience. I don't know how the "EGL" type works when it comes to the jobs that get started on the IBM i.

    Sorry.

    --Dan
  • markevans
    markevans
    2844 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-02-01T13:24:52Z  
    I see now that you are invoking programs written in EGL and generated to COBOL...hence the remotePgmType of "EGL".

    This one is outside of my range of experience. I don't know how the "EGL" type works when it comes to the jobs that get started on the IBM i.

    Sorry.

    --Dan
    Hey,

    A couple of more questions:

    a.) What is the linkage table entry you are using? specifically what is the LUWCONTROL set to?

    b.) When you say the job is ending, I assume you mean the QZRCSRVS job associated with a particular connection? Is this correct?

    c.) Have you run an EGL Java Runtime trace to see if any messages are issued on the client side (if so, can you attach)? The properties to set are: vgj.trace.type=-1 and vgj.trace.device.option=0 (to trace to stdout/console).

    d.) I am not sure how to invoke it, but can you run a JT400 trace for remote program calls.

    Dan,

    I know EGL COBOL nor the EGL runtime are your expertise, but a question. Attached is a slide I had done a long time ago on how the Calls flow through the system. You will see that a call to the I5 server uses the normal QZRCSRVS pre-started jobs.

    My question...is there any setting in the Daemon or the prestarted jobs (or system level) that you are aware of that will kill a job after 60 minutes of inactivity? I looked around last night and could not find one.
  • dan_darnell
    dan_darnell
    973 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-02-02T07:05:17Z  
    • markevans
    • ‏2013-02-01T13:24:52Z
    Hey,

    A couple of more questions:

    a.) What is the linkage table entry you are using? specifically what is the LUWCONTROL set to?

    b.) When you say the job is ending, I assume you mean the QZRCSRVS job associated with a particular connection? Is this correct?

    c.) Have you run an EGL Java Runtime trace to see if any messages are issued on the client side (if so, can you attach)? The properties to set are: vgj.trace.type=-1 and vgj.trace.device.option=0 (to trace to stdout/console).

    d.) I am not sure how to invoke it, but can you run a JT400 trace for remote program calls.

    Dan,

    I know EGL COBOL nor the EGL runtime are your expertise, but a question. Attached is a slide I had done a long time ago on how the Calls flow through the system. You will see that a call to the I5 server uses the normal QZRCSRVS pre-started jobs.

    My question...is there any setting in the Daemon or the prestarted jobs (or system level) that you are aware of that will kill a job after 60 minutes of inactivity? I looked around last night and could not find one.
    "My question...is there any setting in the Daemon or the prestarted jobs (or system level) that you are aware of that will kill a job after 60 minutes of inactivity? I looked around last night and could not find one."

    I'm not aware of anything on the host side that would kill a QZ... job after 60 minutes of inactivity. This sounds to me like a session timeout (app server) but, as you note, I don't know the inner workings on this particular type of call.

    --Dan
  • Jeroen.ASIST
    Jeroen.ASIST
    11 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-02-04T11:18:46Z  
    • markevans
    • ‏2013-02-01T13:24:52Z
    Hey,

    A couple of more questions:

    a.) What is the linkage table entry you are using? specifically what is the LUWCONTROL set to?

    b.) When you say the job is ending, I assume you mean the QZRCSRVS job associated with a particular connection? Is this correct?

    c.) Have you run an EGL Java Runtime trace to see if any messages are issued on the client side (if so, can you attach)? The properties to set are: vgj.trace.type=-1 and vgj.trace.device.option=0 (to trace to stdout/console).

    d.) I am not sure how to invoke it, but can you run a JT400 trace for remote program calls.

    Dan,

    I know EGL COBOL nor the EGL runtime are your expertise, but a question. Attached is a slide I had done a long time ago on how the Calls flow through the system. You will see that a call to the I5 server uses the normal QZRCSRVS pre-started jobs.

    My question...is there any setting in the Daemon or the prestarted jobs (or system level) that you are aware of that will kill a job after 60 minutes of inactivity? I looked around last night and could not find one.
    Hi Mark,

    Answers to your questions:

    a.) LUWCONTROL is set to SERVER in our linkage.
    b.) QZRCSRVS is indeed the job which is ending.
    c.) I indeed run an EGL Java Runtime trace, but nothing appeared in the tomcat log the moment the job ended.
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-21T14:19:31Z  
    Hi Mark,

    Answers to your questions:

    a.) LUWCONTROL is set to SERVER in our linkage.
    b.) QZRCSRVS is indeed the job which is ending.
    c.) I indeed run an EGL Java Runtime trace, but nothing appeared in the tomcat log the moment the job ended.
    Guys,
    We have the same problem with a web service which offers a batch of 2000 records in a straight call to an RPG program. Uptil now JAVA400 was used resulting in straight connections and 2000 QZRCSRVS jobs for every batch of records. This resulted yesterday after 4 batches in 8000 jobs sitting at the iseries server.

    Now I am experimenting with the other remotecomtype setting, but without luck. We need to go live and need direct help. Can we please have a one on one TODAY!! to solve this?
    Rgrds
    William Vossen
  • dan_darnell
    dan_darnell
    973 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-21T16:16:08Z  
    Guys,
    We have the same problem with a web service which offers a batch of 2000 records in a straight call to an RPG program. Uptil now JAVA400 was used resulting in straight connections and 2000 QZRCSRVS jobs for every batch of records. This resulted yesterday after 4 batches in 8000 jobs sitting at the iseries server.

    Now I am experimenting with the other remotecomtype setting, but without luck. We need to go live and need direct help. Can we please have a one on one TODAY!! to solve this?
    Rgrds
    William Vossen
    The results you are describing from your application do not sound like anything I have seen before. I don't think that using the JAVA400 connection type is the problem. But to really be able to tell you anything (as I know you know) someone is going to have to get into the guts of your implementation.

    For immediate assistance, if you think this is a product issue, my advice is to contact IBM/Rational support.

    For "one on one" consulting services my advice is to engage one of the business partners on this page:

    https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en_US#/wiki/W75c8733d99bb_4d55_9ee8_4dbc8c56ebee/page/Partners

    Your other option is to post your project on this forum so that people can put their eyes on it -- but since this is just a community of like-minded developers supporting each other there is no guarantee that you'll get immediate assistance.

    --Dan
  • markevans
    markevans
    2844 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-21T16:48:33Z  
    The results you are describing from your application do not sound like anything I have seen before. I don't think that using the JAVA400 connection type is the problem. But to really be able to tell you anything (as I know you know) someone is going to have to get into the guts of your implementation.

    For immediate assistance, if you think this is a product issue, my advice is to contact IBM/Rational support.

    For "one on one" consulting services my advice is to engage one of the business partners on this page:

    https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en_US#/wiki/W75c8733d99bb_4d55_9ee8_4dbc8c56ebee/page/Partners

    Your other option is to post your project on this forum so that people can put their eyes on it -- but since this is just a community of like-minded developers supporting each other there is no guarantee that you'll get immediate assistance.

    --Dan
    Hi,

    I also have not seen your issue either. But I also am not sure if you are getting a timeout issue or something else (the timeout or job terminating being the original issue in the thread.

    From your description, it sounds like you are making one call per record? Is that true?

    Is it one invocation of the web service? or one invocation of the web service per record? or per batch?

    Are you doing a "call rpgpgm" from the web service? Or using the external type of Host Program

    ExternalType GETREC type HostProgram {platformData=[@i5OSProgram{ programName="GETREC", 
                             programType=NATIVE, isServiceProgram=false, libraryName="*LIBL"}]}
       function GETREC(CUST CUSTa10, EOF char(1), COUNT decimal(2,0)){ hostName="GETREC"};
    end
    


    If this is a normal remote call, what are you using for the linkage table? Have you looked at using a stateful call (which reuses the same job as I understand it).

    I am happy to discuss with you..but not sure we will have an immediate solution either and agree with Dan's suggestions.

    If you want to discuss it, please contact me at my work email with a phone number and I will call you back. My email is evansm@us.ibm.com
    Updated on 2014-03-25T04:35:38Z at 2014-03-25T04:35:38Z by iron-man
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-21T18:14:07Z  
    • markevans
    • ‏2013-03-21T16:48:33Z
    Hi,

    I also have not seen your issue either. But I also am not sure if you are getting a timeout issue or something else (the timeout or job terminating being the original issue in the thread.

    From your description, it sounds like you are making one call per record? Is that true?

    Is it one invocation of the web service? or one invocation of the web service per record? or per batch?

    Are you doing a "call rpgpgm" from the web service? Or using the external type of Host Program

    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">ExternalType GETREC type HostProgram {platformData=[@i5OSProgram{ programName="GETREC", programType=NATIVE, isServiceProgram=false, libraryName="*LIBL"}]} function GETREC(CUST CUSTa10, EOF char(1), COUNT decimal(2,0)){ hostName="GETREC"}; end </pre>

    If this is a normal remote call, what are you using for the linkage table? Have you looked at using a stateful call (which reuses the same job as I understand it).

    I am happy to discuss with you..but not sure we will have an immediate solution either and agree with Dan's suggestions.

    If you want to discuss it, please contact me at my work email with a phone number and I will call you back. My email is evansm@us.ibm.com
    Thanks Dan and Mark for your fast replies.
    To answer the remarks from Mark; I use the linkage part in the build descriptor to define the connections to the original programs. I started having the web service running with JAVA400 and stateless. Example enclosed as part of the Word document. The jobs run with login using a specific user setup with a fixed *LIBL at the user definitions of the iseries. Also the remotesystemid is set which controls the location and which is therefore Programcontrolled.

    So every qzrcsrvs job did only one call. The webservice is triggered every time for only one record at a time as this concerns communication about specific events.

    Now I am puzzled. Because of additional tests to be done, I restored the original situation after playing with statefull, JAVA400J2C and local NDI naming on the location (based on help texts on the remotecomType). I had no luck with playing, and every time again deploying this ear file using the was console which is slow.

    Now after discussing with colleges, it looks like the WAS server would have had problems. The machine hasn't been IPL-ed for a longer time. Also the WAS was not switched off for a longer time. So it seems like that could have caused this kind of strange things happening. It took me more than an hour to close down the WAS server and getting rid of those 8000 jobs. Anyway I was ashtonished that suddenly the stateless concept seemed to be working again as I only had 5 qzrcsrvs jobs left with numerous calls happening within those jobs. By the way: I tried for help at Imtech and Asist today. I will still have a call with an Imtech consultant tomorrow just to help me understand as he was not available today. I also called Asist - really bad practice for a new customer. I was put in hold for 10 minutes, after that the person answering my call for help told me she was calling me back which she did NOT. Will not call them again. Mark I will send you a mail with my phone number. Possibly you have some kind of explanation why this could happen. Many thanks for your fast replies and help...
  • paulPilotto
    paulPilotto
    28 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-21T23:04:26Z  
    Thanks Dan and Mark for your fast replies.
    To answer the remarks from Mark; I use the linkage part in the build descriptor to define the connections to the original programs. I started having the web service running with JAVA400 and stateless. Example enclosed as part of the Word document. The jobs run with login using a specific user setup with a fixed *LIBL at the user definitions of the iseries. Also the remotesystemid is set which controls the location and which is therefore Programcontrolled.

    So every qzrcsrvs job did only one call. The webservice is triggered every time for only one record at a time as this concerns communication about specific events.

    Now I am puzzled. Because of additional tests to be done, I restored the original situation after playing with statefull, JAVA400J2C and local NDI naming on the location (based on help texts on the remotecomType). I had no luck with playing, and every time again deploying this ear file using the was console which is slow.

    Now after discussing with colleges, it looks like the WAS server would have had problems. The machine hasn't been IPL-ed for a longer time. Also the WAS was not switched off for a longer time. So it seems like that could have caused this kind of strange things happening. It took me more than an hour to close down the WAS server and getting rid of those 8000 jobs. Anyway I was ashtonished that suddenly the stateless concept seemed to be working again as I only had 5 qzrcsrvs jobs left with numerous calls happening within those jobs. By the way: I tried for help at Imtech and Asist today. I will still have a call with an Imtech consultant tomorrow just to help me understand as he was not available today. I also called Asist - really bad practice for a new customer. I was put in hold for 10 minutes, after that the person answering my call for help told me she was calling me back which she did NOT. Will not call them again. Mark I will send you a mail with my phone number. Possibly you have some kind of explanation why this could happen. Many thanks for your fast replies and help...
    Please permit me to comment on "I also called Asist - really bad practice for a new customer. I was put in hold for 10 minutes, after that the person answering my call for help told me she was calling me back which she did NOT."
    In the first place, I want to excuse for this telephone incident. We work with a call center and I was not aware that callers are put on hold for 10 minutes. We will investigate this incident with the call center.
    Please accept our deepest apologies and please, if you want to give us a second chance, drop me an e-mail so I can return with my direct cellphone number or with the direct cellphone number of one of our WAS and/or iSeries specialists.

    Paul Pilotto
    Technical Director
    ASIST
    Leading Application Development & Integration
    www.asist.be
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: iSeries job lost after 1 hour of inactivity on RUI-client

    ‏2013-03-22T08:27:31Z  
    Please permit me to comment on "I also called Asist - really bad practice for a new customer. I was put in hold for 10 minutes, after that the person answering my call for help told me she was calling me back which she did NOT."
    In the first place, I want to excuse for this telephone incident. We work with a call center and I was not aware that callers are put on hold for 10 minutes. We will investigate this incident with the call center.
    Please accept our deepest apologies and please, if you want to give us a second chance, drop me an e-mail so I can return with my direct cellphone number or with the direct cellphone number of one of our WAS and/or iSeries specialists.

    Paul Pilotto
    Technical Director
    ASIST
    Leading Application Development & Integration
    www.asist.be
    Dear Paul

    I am really glad that you replied and I accept your apologies. I also apologize of putting these harsh words on this forum not realizing enough that all of the EGL community was reading this too. I was angry and desperately seeking for help yesterday especially as now we need to fly in next week to Hungary again with 3 consultants to continue with our go live process. I have seen multiple appearances of Asist at the Common events in the Netherlands and people have spoken highly about your company.

    Regards.William