Hi All,
We tried to login to VLF one URL and once we try to signout then we get message "Your session has ended". when we check WRKACT job in Iseries for the respective environment, LWEB_JOB are not getting ended it stays idle and when anyone tries to login later point of time, same LWEB_JOB is used.
In cases when it crashes due to some server error or navigation error in those cases as well, these LWEB_JOB are not getting ended.
Is there any way were we can control the duration how long can these jobs be idle. As we observed approx after 3hrs if jobs stays idle it was vanishing from WRKACTJOb. Not very sure If we are on the right track.
Can you please share your thoughts regarding the same.
Thanks for your help in advance.
Thanks & Regards,
Priya
Signoff from VLF one doesn't clear job in ISeries
Re: Signoff from VLF one doesn't clear job in ISeries
What does your system value QDEVRCYACN (Device I/O error action) say happens when jobs get disconnected
Use DSPSYSVAL QDEVRCYACN to see it.
Use DSPSYSVAL QDEVRCYACN to see it.
Re: Signoff from VLF one doesn't clear job in ISeries
Hi Mark,
It has below value
Action . . . . . . . . : *DSCMSG
It has below value
Action . . . . . . . . : *DSCMSG
Re: Signoff from VLF one doesn't clear job in ISeries
You need *ENDJOB to get the 5250 jobs to end rather than disconnect.
You can do this in a few ways:
• Change the QDEVRCYACN system variable.
• Change the DEVRCYACN parameter of job description(s) used to start the RAMP 5250 sessions.
• Use a CHGJOB command at logon time to change the job’s DEVRCYACN value.
I think that doing this will solve most of the issues you are having.
You can do this in a few ways:
• Change the QDEVRCYACN system variable.
• Change the DEVRCYACN parameter of job description(s) used to start the RAMP 5250 sessions.
• Use a CHGJOB command at logon time to change the job’s DEVRCYACN value.
I think that doing this will solve most of the issues you are having.
Re: Signoff from VLF one doesn't clear job in ISeries
Hi Mark,
When we login to URL and while we try to access any BO's from application, new session gets opened while we check (WRKUSRjOB) for that particular user. when we try to log off/signoff new job gets vanished from screen (WRKUSRJOB).
Whereas in WRKACTJOB those LWEB_JOB are not getting ended. As you had suggested I tried CHGJOB for LWEB_JOB, and later tried to signout still these LWEB_JOB are active.
Kindly let us know is there any other possibility.
When we login to URL and while we try to access any BO's from application, new session gets opened while we check (WRKUSRjOB) for that particular user. when we try to log off/signoff new job gets vanished from screen (WRKUSRJOB).
Whereas in WRKACTJOB those LWEB_JOB are not getting ended. As you had suggested I tried CHGJOB for LWEB_JOB, and later tried to signout still these LWEB_JOB are active.
Kindly let us know is there any other possibility.
Re: Signoff from VLF one doesn't clear job in ISeries
There are two jobs type involved:
Type 1- 5250 interactive sessions that supports an aXes/RAMP session.
Type 2- L4Web job that support your VL-Web applications - be they VLF-ONE, VL-Web, WAMs or WEBEVENT.
My understanding was that your question was about type 1 jobs only?
The *ENDJOB option is controlling how the type 1 jobs end.
i.e. So that when you close a business object the associated 5250 session job ends.
Type 2 jobs are how all VL-Web applications works - your older VLF-WEB application would use these in exactly the same way.
Its normal too have multiple L4Web jobs running in a shared pool.
There are various L4Web configuration options to control how many get pre-started, how many can run at once, etc.
They service incoming requests and are not assigned to you - they get shared by all active users.
A L4web job should not end if you end a VLF-ONE session.
Instead it goes back into a pool of available jobs ready to be assigned to someone else.
(In fact it goes back into the shared pool at the end of every single interaction).
The fact that they are shared is important because you might have one request go into job L4Web A and the next click go into L4Web Job B.
So server modules need to be completely stateless, so things like using the job number as a session key will not work.
It should not matter that a L4Web job vanishes, even if you used it a moment ago.
Your next click will get routed into another L4Web job.
Type 1- 5250 interactive sessions that supports an aXes/RAMP session.
Type 2- L4Web job that support your VL-Web applications - be they VLF-ONE, VL-Web, WAMs or WEBEVENT.
My understanding was that your question was about type 1 jobs only?
The *ENDJOB option is controlling how the type 1 jobs end.
i.e. So that when you close a business object the associated 5250 session job ends.
Type 2 jobs are how all VL-Web applications works - your older VLF-WEB application would use these in exactly the same way.
Its normal too have multiple L4Web jobs running in a shared pool.
There are various L4Web configuration options to control how many get pre-started, how many can run at once, etc.
They service incoming requests and are not assigned to you - they get shared by all active users.
A L4web job should not end if you end a VLF-ONE session.
Instead it goes back into a pool of available jobs ready to be assigned to someone else.
(In fact it goes back into the shared pool at the end of every single interaction).
The fact that they are shared is important because you might have one request go into job L4Web A and the next click go into L4Web Job B.
So server modules need to be completely stateless, so things like using the job number as a session key will not work.
It should not matter that a L4Web job vanishes, even if you used it a moment ago.
Your next click will get routed into another L4Web job.
Re: Signoff from VLF one doesn't clear job in ISeries
I guess I had confused you in my first post.. I was aware about 5250 sessions, wanted to know about LWEB_JOBS.
Thanks Mark for your elaborate explanation.
Thanks Mark for your elaborate explanation.
Re: Signoff from VLF one doesn't clear job in ISeries
Mark,
Based upon your explanation, we tried couple of scenarios to monitor LWEB_JOB performance in terms of CPU%.
1) We URL crashes due to server error, then LWEB_JOB vanishes or otherwise CPU becomes 0%
2) When user does normal sign off, here as well CPU becomes 0%
3) In case user doesn't do sign-off instead just closes, then CPU% doesn't become 0 and next time when it uses same LWEB_JOB percentage increases from were it was earlier.
Due to Point 3 scenario, we face CPU raises and reaches 90% plus. Hence can you suggest us how to handle such case.
Based upon your explanation, we tried couple of scenarios to monitor LWEB_JOB performance in terms of CPU%.
1) We URL crashes due to server error, then LWEB_JOB vanishes or otherwise CPU becomes 0%
2) When user does normal sign off, here as well CPU becomes 0%
3) In case user doesn't do sign-off instead just closes, then CPU% doesn't become 0 and next time when it uses same LWEB_JOB percentage increases from were it was earlier.
Due to Point 3 scenario, we face CPU raises and reaches 90% plus. Hence can you suggest us how to handle such case.
Re: Signoff from VLF one doesn't clear job in ISeries
If a L4Web job is using up CPU time when it is not being used by anyone then I think you should report this to support.
Include some steps on how to reproduce the situation.
The more that you can discover about what the L4Web job is doing when no one is supposed to using it the better.
For example, if you display the job and use "11. Display call stack, if active" several times over a few minutes with F5=Refresh you can possibly identify the programs or commands that are being executed and that are causing it to use up CPU cycles. Even if you don't know what the programs are this information could possibly be quite useful to the LANSA support people.
Include some steps on how to reproduce the situation.
The more that you can discover about what the L4Web job is doing when no one is supposed to using it the better.
For example, if you display the job and use "11. Display call stack, if active" several times over a few minutes with F5=Refresh you can possibly identify the programs or commands that are being executed and that are causing it to use up CPU cycles. Even if you don't know what the programs are this information could possibly be quite useful to the LANSA support people.
Re: Signoff from VLF one doesn't clear job in ISeries
yes you should look at what the Lweb job is doing. Post the call stack.
Art Tostaine