If you can not see the user profile active with the command WRKACTJOB, check to see if the users is signed on to the system. You should be able to see the user if active with the WRKUSRJOB USER(user profile). If not check the user profile for invalid JOBD, INLPGM ,
and INLMNU. You can also check the user joblog to see if the user profile had a login error message.
============================================================
The most common reason that a job is not shown is that it's in some type of secondary status such as SRQ (SystemRequest) or GRP (GroupJob) and is suspended.
To view all jobs, press <F14=Include> to include all jobs. Press <F14=Exclude> to remove suspended jobs from the WRKACTJOB list. ("Exclude" is the default.)
Tom
Last Wiki Answer Submitted: September 23, 2010 11:36 pm by Security1770 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
There shouldn’t be anything about QDFTJOBD that would keep an active job from being visible in WRKACTJOB — unless the QDFTJOBD is badly misconfigured (or the job simply routed to a subsystem that was in an unexpected segment of the WRKACTJOB display and scrolling would show where it was).
The QDFTJOBD might have the USER() parameter configured with a name instead of USER(*RQD) for example. If the problem user then also had *USE authority to the profile on QDFTJOBD, then jobs could be submitted to run under the other user’s authority. That is an extremely risky item that should be changed ASAP.
But an incorrect *JOBD could easily cause a job to end abnormally for many reasons.
So, perhaps the “most common” reason that a job doesn’t show up in WRKACTJOB is simply that the job isn’t active.
If there was some other reason, could you let us know what it was?
No, just discovered another wrinkle. These are thin client sessions that have gone into a disconnected mode. I will have to see how my client is handling the signoff.
If these are “disconnected jobs”, they should have status DSC. They should show up in WRKACTJOB with <F14=Include> just like SRQ and GRP jobs.
If they’re disconnected, users can enter their profile and password, and they should be able to jump back into whatever they were doing — if things are configured appropriately.
Is the user truly SIGNED ON thru a 5250 session (ex: Client Access) or is the connection thru ODBC or some other method>
It truly was the Job description on the user’s profile. It was set to QDFTJOBD. Thanks all for your input.
QDFTJOBD
There shouldn’t be anything about QDFTJOBD that would keep an active job from being visible in WRKACTJOB — unless the QDFTJOBD is badly misconfigured (or the job simply routed to a subsystem that was in an unexpected segment of the WRKACTJOB display and scrolling would show where it was).
The QDFTJOBD might have the USER() parameter configured with a name instead of USER(*RQD) for example. If the problem user then also had *USE authority to the profile on QDFTJOBD, then jobs could be submitted to run under the other user’s authority. That is an extremely risky item that should be changed ASAP.
But an incorrect *JOBD could easily cause a job to end abnormally for many reasons.
So, perhaps the “most common” reason that a job doesn’t show up in WRKACTJOB is simply that the job isn’t active.
If there was some other reason, could you let us know what it was?
Tom
No, just discovered another wrinkle. These are thin client sessions that have gone into a disconnected mode. I will have to see how my client is handling the signoff.
…a disconnected mode.
If these are “disconnected jobs”, they should have status DSC. They should show up in WRKACTJOB with <F14=Include> just like SRQ and GRP jobs.
If they’re disconnected, users can enter their profile and password, and they should be able to jump back into whatever they were doing — if things are configured appropriately.
Tom