Informing the IBM Community

Last signon date – set it yourself

0
(0)

Something that came up recently and jogged my memory for a tweak I made a few years ago.

I was asked to confirm if a user had logged into a profile, now on the face of it a nice simple question and answer. WRKUSRPRF <username> and return the date I get on the screen.

The problem is that this profile is only being used with a third-party application, and so while it hasn’t signed into a 5250 session it is being used in jobs. The third-party app isn’t updating last sign-on date so at first glance the user appears unused, in my case since December 2019 whereas I can see jobs being run this month.

This also feeds back into an article I did early 2019 about using the last used date to determine whether a user/device is inactive. I could use the user profiles last used date from a WRKOBJ to determine this, but why not actually make this app update the sign-on date?

Enter QSYCHGPR a handy IBM API for changing the previous sign-on date. Running this updates the date/time for the current user, you can try it at home if you like from a command line:

CALL       PGM(QSYCHGPR) PARM(‘ ‘)

The parameter is for any error code being returned by the API call. If I do a before & after on my WRKUSRPRF, I’ll immediately see the difference:

This is also quite simple to code into the application I was looking at, it already uses another API QSYGETPH to validate that the username/password provided are valid followed by swapping the job from a generic user to the one provided (QWTSETP). So once it’s completed those checks it’s another couple of lines of code to call the API and handle if there’s an error.

The middle step, of swapping the job to the appropriate user, is an important one to remember. Although QSYGETPH will tell you whether it’s a valid user that doesn’t automatically let you update the sign-on date/time as QSYCHGPR only works for the user you’re logged on as.

The Change Previous Sign-On Date (QSYCHGPR) API changes the previous sign-on date and time to the current date and time for the user profile that is currently running. If a user has been swapped in using the Set Profile (QWTSETP) API, that user’s previous sign-on date and time is the one that gets changed.

Which, as a side note, would explain why the user I was using to ‘log into’ my node project wasn’t getting updated, but the profile running the project was!

For those interested, the rough structure of a CL to do all of this:

PGM (&USERPROF &PASSWORD &RETURN &ERROR)

DCL        VAR(&USERPROF) TYPE(*CHAR) LEN(10)
DCL        VAR(&PASSWORD) TYPE(*CHAR) LEN(128)
DCL        VAR(&RETURN) TYPE(*CHAR) LEN(10)
DCL        VAR(&ERROR) TYPE(*CHAR) LEN(132)
DCL        VAR(&PROFHAND) TYPE(*CHAR) LEN(12)
DCL        VAR(&RTNVAR) TYPE(*CHAR) LEN(8) VALUE(X’0000000000000000′)

CALL       PGM(QSYGETPH) PARM(&USERPROF &PASSWORD &PROFHAND &RTNVAR X’00000080′ + X’00000000′)
<series of MONMSGs to interpret the various codes that could come back saying the user doesn’t exist, is disabled, password is rubbish, etc, etc. Pass back in Return/Error parms>

CALL       PGM(QWTSETP) PARM(&PROFHAND &RTNVAR)
<more MONMSG>

CALL       PGM(QSYCHGPR) PARM(&RTNVAR)
<more MONMSG>

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.


Comments

One response to “Last signon date – set it yourself”

  1. Kevin Bridge avatar
    Kevin Bridge

    Hi David,

    Interested in your article ‘Last signon date – set it yourself’.

    However, we have a similar issue when users map to the IFS, but very rarely log in using ‘Green’ screen.

    Is there a way to update the ‘Last signon date’ when using the IFS?

    Kind regards

    Kevin

Leave a Reply

Your email address will not be published. Required fields are marked *