RE: Limit CA/400 Sessions

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