|
I'd have an initial program that checks a user space (named the same as the user profile) that contains the user's job name(s). 1. Check to see if the job name stored in the user space is same as the current job (you have to figure out what to do with System Request 2nd sessions: user and device will be the same; the job numbers won't). 2. If it's not the same, check to see if the previously-stored job name(s) is(are) still active. a. If it is, sign the user off. b. If it's not, write the current job name in the user space and allow the sign-on process to continue. 3. Or...if you have a standard signoff program (or if you add an exit program), you can go into the user space and clear the specific job name. When all sessions are signed off, the user space is empty. You can take this logic and allow > 1 session; you just have to store multiple job names in the user space and check each one. Yes, you'll have to use API's but there are hundreds of API examples floating around the Internet. This approach avoids files and locked records. -----Original Message----- From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On Behalf Of Bernard Burchell Sent: Thursday, August 30, 2001 9:09 PM To: midrange-l@midrange.com Subject: Re: Limit CA/400 Sessions Dan, The problem with QLMTDEVSSN is that it's only 1 session. You can't enter an actual number-of-sessions in there, the value is a Yes/No type question. A better method would be to have an initial program which checked for object locks. E.g. suppose you wanted to limit the number of sessions to 2. You could create 2 data areas for each user like DAN1 and DAN2. Then apply object locks first against DAN1, and if that failed, try locking DAN2, and if that failed, sign them off. But I would avoid using data areas because you would have hundreds of them and the user name could not be more than 9 characters. A far better way is to use member locks. Again suppose you wanted to limit the sign-on to two sessions. First create 2 physical files (I am using source files here, but any physical file type would work): CRTSRCPF QGPL/SESSION1 CRTSRCPF QGPL/SESSION2 Your user's initial program could look something like this (Note: I haven't tested the below code so it may need a few changes): PGM DCL &USER *CHAR 10 RTVJOBA USER(&USER) /* Add member to Session1 if not there */ CHKOBJ OBJ(SESSION1) OBJTYPE(*FILE) MBR(&USER) AUT(*OBJEXIST) MONMSG CPF9815 EXEC(ADDPFM SESSION1 &USER) /* Try to lock member in Session1 */ ALCOBJ OBJ((SESSION1 *FILE *EXCLRD &USER)) WAIT(0) MONMSG CPF1002 EXEC(DO) /* If lock failed, first session already in use, so try session 2 */ /* Add member to Session2 if not there */ CHKOBJ OBJ(SESSION2) OBJTYPE(*FILE) MBR(&USER) AUT(*OBJEXIST) MONMSG CPF9815 EXEC(ADDPFM SESSION2 &USER) /* Try to lock member in Session2 */ ALCOBJ OBJ((SESSION2 *FILE *EXCLRD &USER)) WAIT(0) MONMSG CPF1002 EXEC(DO) /* Both sessions are in use, so sign off */ /* First send a status message */ SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) + MSGDTA('Limit of two sessions exceeded.') MSGTYPE(*STATUS) DLYJOB 5 SIGNOFF ENDDO ENDDO /* Now call the main menu */ TFRCTL USERMENU ENDPGM A problem with the above program is that if a user does a Sys-Req-1 it will try and re-lock the members. So it will be rejected or prevent a second session from being used. This can be avoided by placing some text on the member which is the device name, then checking that the text is different before rejecting a session. You can use commands CHGPFM to put text on a member, and RTVMBRD to retrieve the current text. -------------- Another approach is to use exit programs. There are two registry entries to consider QIBM_QTG_DEVINIT and QIBM_QTG_DEVTERM. These entries are used when a telnet session is started and ended. Without going into specifics here, you can write a program that checks whether an IP address has been used and keep track of how many times a session has been opened against an IP address. There was a time when I would have considered that the exit point program was the correct approach, especially as it allows you to also specify a device name for the session. However discussions on this list of late indicate that it is possible for many machines to share the same IP address, so this may not always be a suitable method. Bernard Burchell Precosis Pty Ltd bburchell@precosis.com.au http://www.precosis.com.au
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.