Does the AS/400 keep a log of when users sign on and sign off?

Hi, Phil
1) By default, you can use to the system history log to get a listing like this:

Job 080894/BARRY/QPADEV000B started on 03/28/06 at 18:08:41 in subsystem QINTER
Job 080894/BHARPER/QPADEV000B ended on 03/28/06 at 19:08:57; 17 seconds used;

Use the display log (DSPLOG) command like this:
DSPLOG LOG(QHST) OUTPUT(*PRINT) MSGID(CPF1124 CPF1164)

The problem is that you will get batch jobs and interactive jobs. You could dump the report to a spooled file, copy it to a physical file of length 132, and try to query it.

2) Job accounting can be turned on by:
-create a journal receiver
-create the job accounting journal QACGJRN and attach the receiver
-change the QACGLVL system value to *JOB
You can then display the entries by:
-create a duplicate of file QJBACG from QSYS to yourlib
-use display journal command to dump entries:
DSPJRN JRN(QACGJRN) FROMTIME(031406 080000) TOTIME(032106 170000) ENTTYP(JB) OUTPUT(*OUTFILE) OUTFILE(yourlib/QAJBACG)
You can then query the file to get a report in the format required.

Please post back if more details are needed.
Barry

Phil:

It's easy enough to track job start and end times as Barry shows. This could be your best choice. Basic QHST is the simplest; the accounting journal is more difficult.

One difficulty is determining whether or not a job start is due to a "sign on" or it's simply a batch job that happens to be named the same as a workstation device. This is harder to do if the job has ended and hasn't created any spooled file that would cause the the job information to stay in the system. Also, accounting journal management _might_ be an issue.

Also, secondary and group jobs can really mess up the logic for determining "sign on and off" times.

One possibility is the QIBM_QWT_JOBNOTIFY (Job Notification) exit point. This can do the job of tracking by placing entries in a data queue. The entries include most useful info about the jobs that start and end in the subsystems you want to track, e.g., QINTER.

Data queue entries could be retrieved live by a never-ending program or retrieved in a batch every night. The entries could be then written into a database however you wish.

A live NEP gives the chance to access job info almost as soon as the sign on occurs.

Tom

Tom,
 I like your idea about the data queues. I'm not really familiar with exit points. Could you cite an example of how
the program would look, and how the data would be written to the data queue.

Thanks,

Phil

Phil:

Not sure how much time I have. Barry or Dave might have samples handy. Anybody else is perfectly welcome to take this if I can't get to it soon.

Data queues are really simple once you see them working a time or two. They can be thought of as files where the record is automatically deleted as soon as you read it. You call an API telling it what data queue to read and the API returns the next record in its return buffer. There is no record format, so you take substrings of that buffer or you declare an overlay that defines a data structure.

One API reads entries from the queue; another API sends entries to the queue. You can send and receive entries all on your own, or you can interact with system functions that might send or receive entries. The job notification exit point is an example of a system function that sends entries to a queue. Your program would receive those entries.

That's the really really short version of the concept. More if I get to it.

Tom

I think I understand how to do the data queues. I found an old program I'd done a while back
so I've got that covered.

I just don't have any experience on exit points.

Anyone who could help would be appreciated.

Thanks,

Phil

I've also increased the point value from 250 to 500.

Thanks,

Phil

Check out the infocenter at:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp
and search for the exit point name:
QIBM_QWT_JOBNOTIFY
This will show you the format of the data queue entries, how entries are added to the data queue, how to add the data queue to the exit point (instead of an exit program), etc.

Barry

I'm using V4R3M0 if you can believe it. Will this still work?

Thanks,

Phil

I just checked my V4R3 system using Work with Registration Info (WRKREGINF) and the exit point QIBM_QWT_JOBNOTIFY is there.
Barry

If you go to the V4R3 library:
http://publib.boulder.ibm.com/pubs/html/as400/online/v4r3eng.htm
and look for the Work Management APIs V4R3 book which contains info on the exit point.
Barry

One more thing....
You add the data queue using the Add Exit Program command:
ADDEXITPGM EXITPNT(QIBM_QWT_JOBNOTIFY) FORMAT(NTFY0100) PGMNBR(1) PGM(yourlib/data-queue)

Yeah, it looks a little odd to put the data queue name into the PGM() parm, but the parm is really nothing more than a qualified object name. The system can use the name as a data queue name if it wants to.

If I were IBM, I might have extended the ADDEXITPGM command rather than reuse a misleading parm name. But I suppose that's why they make the big bucks.

Tom

Barry,

In the Work Management API for QIBM_QWT_JOBNOTIFY
I found this:

2.4.3 Program Data


When you register the data queue, the following is required for the program data.

   Offset                        Type                            Field                                        
 
   Dec        Hex
 
   0           0                CHAR(4)                         Notification type
   4           4                CHAR(10)                       Subsystem description                        
  14          E                CHAR(10)                       Subsystem description library                
 
What is 'registering' the data que?

Thanks,

Phil

To register the data queue, use the ADDEXITPGM command above:
ADDEXITPGM EXITPNT(QIBM_QWT_JOBNOTIFY) FORMAT(NTFY0100) PGMNBR(1) PGM(yourlib/data-queue)

Barry

ok, thanks

Phil

How do I tell the exit point which sub-system I want to monitor?

Phil