Print Out of Last Log in Time and Date in AS400
Hello,
Is it possible to print out a last log in time and date for all user's on the AS400?
Is it possible to print out a last log in time and date for all user's on the AS400?
ASKER
It would be for ISeries Access.
riuser:
iSeries Access... okay -- iSeries Navigator? Terminal emulation? Remote command/distributed program call? Database server? File server? Other?
My guess would be terminal emulation, which for many purposes can be considered "telnet".
In that case, see how this might approach what you're looking for:
==> dspusrprf *all output( *outfile ) outfile( qtemp/users )
==> runqry *n qtemp/users
The simple RUNQRY over the USERS file will have a column out to the right with a column heading "Previous Sign-on Date". The name of the column is UPPSOD.
You could query the outfile in SQL if you preferred that over the simple RUNQRY. Refresh the file by re-runing the DSPUSRPRF command. Name the file whatever you choose; I chose USERS for example. Place the file in the library of your choosing; I chose QTEMP for example, mostly just so it would go away by itself when I logged off.
Tom
iSeries Access... okay -- iSeries Navigator? Terminal emulation? Remote command/distributed program call? Database server? File server? Other?
My guess would be terminal emulation, which for many purposes can be considered "telnet".
In that case, see how this might approach what you're looking for:
==> dspusrprf *all output( *outfile ) outfile( qtemp/users )
==> runqry *n qtemp/users
The simple RUNQRY over the USERS file will have a column out to the right with a column heading "Previous Sign-on Date". The name of the column is UPPSOD.
You could query the outfile in SQL if you preferred that over the simple RUNQRY. Refresh the file by re-runing the DSPUSRPRF command. Name the file whatever you choose; I chose USERS for example. Place the file in the library of your choosing; I chose QTEMP for example, mostly just so it would go away by itself when I logged off.
Tom
Tom, do you know if the last login date & time on the profile record is updated if the login was not interactive? ie. via ODBC or web site?
rward:
> ie. via ODBC...
It _can_ be updated during ODBC logins. For example, the IBM iSeries Access file transfer capability will cause the last-login date to be updated when the Excel add-on is first used in a session and a logon is requested through the Signon Server. There are potential complications that will make a difference and many that I haven't tested.
For example, the "Signon Server" is a 'host' server that was apparently intended by IBM to be generally used by 3rd-party connectivity vendors. It accepts profile/password info and returns a 'token' when the logon is accepted. The token can then be presented to other host servers (Database, Data Queue, File, etc.) for additional connections. Each of the host servers can also accept profile/password explicitly, performing a kind of mini-logon for each transaction. I haven't tested the results of individual transaction connections.
Also, the host servers have been "kerberized" over recent releases to accommodate kerberos tickets. The "logon" is actually to a kerberos server in the network, for example Windows Active Directory, and a ticket is obtained by the PC. The ticket can be presented to any server application in the network that honors it. I haven't tested how that is reflected in last-logon-date for a user profile.
And, the TCP/IP servers -- telnet, ftp, rexec, etc. -- are non-native application protocols that were ported back when TCP/IP started being used widely in business intranets. Those are primarily architected around RFCs that describe standard behaviors that must be followed. FTP doesn't update last-logon-date at least up to V6R1 (I just tested it there.) Telnet updates it because it uses the terminal logon facility.
IOW, it depends.
> ...or web site?
Well, that depends on what the web site enforces for logons, if it even does any kind of logon at all. A web site can present whatever is programmed to be presented.
One facility that may used is authentication through a "validation list". Usually, that has nothing to do with 'logons' as most people think of them. It has more to do with what directories may be accessed and what pages or files might be served. In that sense, it isn't as much about 'authentication (who are you)' as it is about 'authorization (what can you do)'.
I can imagine that I'm adding more confusion rather than giving a hoped-for straight answer. But it is indeed complicated. There are all kinds of platforms and operating systems and server applications, and they all want to talk behind the scenes to each other in some kind of organized sense.
Unfortunately, different vendors have their own ideas about how interaction should work. Microsoft wants nothing but Microsoft products talking to Microsoft servers. The various Unix/Linux vendors want developers to build their own stuff in wherever they want. IBM wants... well, like others, they want what they want and they want to do it their way; they do try to support 'standards' when they exist, but they also want to sell "services" to whoever is willing to buy them.
Some connections are 'connection-oriented' -- these are commonly related to logons, but not always. Other connections are 'connectionless' -- these are commonly irrelevant for logons, but not always.
A potential resolution on AS/400s and on their successor systems, iSeries and System i, can be found in programming for the "exit points". OS/400 and i5/OS present exit points for most server functions. These allow you to supply programs that extend services as you choose.
For example, there is an exit point for "FTP Server Logon". The program that you name at that exit point will be called whenever an FTP logon occurs. You can write logon log records, reject the logon attempt or do whatever action you choose.
Many similar exit points exist. There are two _basic_ forms for these exit programs, so that a couple programs might be used for many exit points. Generally, if a server application doesn't update last-logon in the user profile, it's not too hard to create the capability yourself -- as long as logging is about as far as you want to go.
When the programming becomes much more complicated, there can be plenty of elements to watch. But that's about as far as I can discuss that because <Disclaimer> my employer is a vendor of products that perform many exit program functions </Disclaimer>.
I can generally answer specific questions and offer suggestions and/or corrections. Others here might provide a lot more than I can.
I hope this isn't too discouraging. Ask for specific clarifications if necessary.
Tom
> ie. via ODBC...
It _can_ be updated during ODBC logins. For example, the IBM iSeries Access file transfer capability will cause the last-login date to be updated when the Excel add-on is first used in a session and a logon is requested through the Signon Server. There are potential complications that will make a difference and many that I haven't tested.
For example, the "Signon Server" is a 'host' server that was apparently intended by IBM to be generally used by 3rd-party connectivity vendors. It accepts profile/password info and returns a 'token' when the logon is accepted. The token can then be presented to other host servers (Database, Data Queue, File, etc.) for additional connections. Each of the host servers can also accept profile/password explicitly, performing a kind of mini-logon for each transaction. I haven't tested the results of individual transaction connections.
Also, the host servers have been "kerberized" over recent releases to accommodate kerberos tickets. The "logon" is actually to a kerberos server in the network, for example Windows Active Directory, and a ticket is obtained by the PC. The ticket can be presented to any server application in the network that honors it. I haven't tested how that is reflected in last-logon-date for a user profile.
And, the TCP/IP servers -- telnet, ftp, rexec, etc. -- are non-native application protocols that were ported back when TCP/IP started being used widely in business intranets. Those are primarily architected around RFCs that describe standard behaviors that must be followed. FTP doesn't update last-logon-date at least up to V6R1 (I just tested it there.) Telnet updates it because it uses the terminal logon facility.
IOW, it depends.
> ...or web site?
Well, that depends on what the web site enforces for logons, if it even does any kind of logon at all. A web site can present whatever is programmed to be presented.
One facility that may used is authentication through a "validation list". Usually, that has nothing to do with 'logons' as most people think of them. It has more to do with what directories may be accessed and what pages or files might be served. In that sense, it isn't as much about 'authentication (who are you)' as it is about 'authorization (what can you do)'.
I can imagine that I'm adding more confusion rather than giving a hoped-for straight answer. But it is indeed complicated. There are all kinds of platforms and operating systems and server applications, and they all want to talk behind the scenes to each other in some kind of organized sense.
Unfortunately, different vendors have their own ideas about how interaction should work. Microsoft wants nothing but Microsoft products talking to Microsoft servers. The various Unix/Linux vendors want developers to build their own stuff in wherever they want. IBM wants... well, like others, they want what they want and they want to do it their way; they do try to support 'standards' when they exist, but they also want to sell "services" to whoever is willing to buy them.
Some connections are 'connection-oriented' -- these are commonly related to logons, but not always. Other connections are 'connectionless' -- these are commonly irrelevant for logons, but not always.
A potential resolution on AS/400s and on their successor systems, iSeries and System i, can be found in programming for the "exit points". OS/400 and i5/OS present exit points for most server functions. These allow you to supply programs that extend services as you choose.
For example, there is an exit point for "FTP Server Logon". The program that you name at that exit point will be called whenever an FTP logon occurs. You can write logon log records, reject the logon attempt or do whatever action you choose.
Many similar exit points exist. There are two _basic_ forms for these exit programs, so that a couple programs might be used for many exit points. Generally, if a server application doesn't update last-logon in the user profile, it's not too hard to create the capability yourself -- as long as logging is about as far as you want to go.
When the programming becomes much more complicated, there can be plenty of elements to watch. But that's about as far as I can discuss that because <Disclaimer> my employer is a vendor of products that perform many exit program functions </Disclaimer>.
I can generally answer specific questions and offer suggestions and/or corrections. Others here might provide a lot more than I can.
I hope this isn't too discouraging. Ask for specific clarifications if necessary.
Tom
ASKER
Thanks that's exactly what I needed. If I can ask you one more question; Now that I have my list of last known log-ins created I'd like to print it, is there a command to do this?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Very informative, thank you.
"Login" for what? DB2? Telnet? FTP? iSeries Access? A web service? Other?
With all the possible services nowadays, it's not always as easy as it used to be.
It used to be that you could display the user profiles to an output file and query the 'Previous Sign-on Date' column UPPSOD. It's can be complicated now, depending on what you need to find out.
Tom