Determining Whether a User Is Already Signed On, Take Three
June 28, 2002 Timothy Prickett Morgan
Hey, Ted:
I’d try to allocate the user’s message queue.
That would eliminate a data area in the mix.
— Tim
Several people wrote in with the same suggestion, Tim.
Most objected to creating the data area, saying it was unnecessary.
Here is the code to do it your way:
DCL VAR(&FIRSTSESSN) TYPE(*LGL) VALUE('1') DCL VAR(&MSGQ) TYPE(*CHAR) LEN(10) DCL VAR(&MSGQLIB) TYPE(*CHAR) LEN(10) RTVUSRPRF USRPRF(*CURRENT) MSGQ(&MSGQ) MSGQLIB(&MSGQLIB) ALCOBJ OBJ((&MSGQLIB/&MSGQ *MSGQ *EXCL)) WAIT(0) MONMSG MSGID(CPF1002 CPF1085) EXEC(DO) CHGVAR VAR(&FIRSTSESSN) VALUE('0') ENDDO IF COND(&FIRSTSESSN) THEN(DO) DLCOBJ OBJ((&MSGQLIB/&MSGQ *MSGQ *EXCL)) ENDDO
The program attempts to allocate the message queue with an exclusive lock. This only succeeds if the user is signing on to the first session. When the user signs on to a second or subsequent session, the allocation fails, setting variable &FIRSTSESSN to false.
A reader named Mark pointed out that you should de-allocate the message queue in case other jobs need access to those messages. The de-allocation was not necessary with the original version that I presented.
— Ted
Sponsored By ADVANCED SYSTEMS CONCEPTS |
SEQUEL meets all your iSeries and AS/400 data access needs in a single, integrated solution:
Take 6 minutes to For more information or a FREE trial of SEQUEL, |