interactive sessions limit - IBM AS400

This is a discussion on interactive sessions limit - IBM AS400 ; Hi. I would like to limit users interactive sessions to 1 only. But not all users, some group must be able to have more sessions at one time. I thougt that I'll create new interactive subsystem with work station name ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: interactive sessions limit

  1. interactive sessions limit

    Hi.

    I would like to limit users interactive sessions to 1 only.
    But not all users, some group must be able to have more sessions at one
    time.
    I thougt that I'll create new interactive subsystem with work station
    name entries looks like KOL*. Each user will run mocha 5250 client with
    device name looks like KOLP0001, 0002 etc. When user connects to i5 its
    interactive session will be in new interactive subsystem. Because
    terminal will have unique name only one session will be available for user.

    Other users will use standards QPADEV.... device names and will be able
    to run nolimit interactive sessions.

    Does anybody know any other - maybe better way to solve handle such a
    situation?

    Regards,
    Tomasz

  2. Re: interactive sessions limit

    On Apr 2, 9:46 am, tomasz wrote:
    > Hi.
    >
    > I would like to limit users interactive sessions to 1 only.
    > But not all users, some group must be able to have more sessions at one
    > time.
    > I thougt that I'll create new interactive subsystem with work station
    > name entries looks like KOL*. Each user will run mocha 5250 client with
    > device name looks like KOLP0001, 0002 etc. When user connects to i5 its
    > interactive session will be in new interactive subsystem. Because
    > terminal will have unique name only one session will be available for user.
    >
    > Other users will use standards QPADEV.... device names and will be able
    > to run nolimit interactive sessions.
    >
    > Does anybody know any other - maybe better way to solve handle such a
    > situation?
    >
    > Regards,
    > Tomasz


    You might want to change system value QLMTDEVSSN to '1' (limit
    sessions) and change the user profiles of those who should have
    multiple sessions set LMTDEVSSN = *NO.



  3. Re: interactive sessions limit

    Hi.

    How did it happen that I omited it.

    Thanks a lot, that's what I needed to have.

    Regards,
    Tomasz



    Graybeard napisał(a):
    > On Apr 2, 9:46 am, tomasz wrote:
    >> Hi.
    >>
    >> I would like to limit users interactive sessions to 1 only.
    >> But not all users, some group must be able to have more sessions at one
    >> time.
    >> I thougt that I'll create new interactive subsystem with work station
    >> name entries looks like KOL*. Each user will run mocha 5250 client with
    >> device name looks like KOLP0001, 0002 etc. When user connects to i5 its
    >> interactive session will be in new interactive subsystem. Because
    >> terminal will have unique name only one session will be available for user.
    >>
    >> Other users will use standards QPADEV.... device names and will be able
    >> to run nolimit interactive sessions.
    >>
    >> Does anybody know any other - maybe better way to solve handle such a
    >> situation?
    >>
    >> Regards,
    >> Tomasz

    >
    > You might want to change system value QLMTDEVSSN to '1' (limit
    > sessions) and change the user profiles of those who should have
    > multiple sessions set LMTDEVSSN = *NO.
    >
    >


  4. Re: interactive sessions limit

    Graybeard wrote:
    > On Apr 2, 9:46 am, tomasz wrote:
    >>
    >> I would like to limit users interactive sessions to 1 only.
    >> But not all users, some group must be able to have more sessions at one
    >> time.


    > You might want to change system value QLMTDEVSSN to '1' (limit
    > sessions) and change the user profiles of those who should have
    > multiple sessions set LMTDEVSSN = *NO.


    Note that if single sessions is the objective, QLMTDEVSSN will not be
    sufficient. QLMTDEVSSN can limit a user's sessions to single devices at
    any one time, but multiple sessions can be started from a device.

    To enforce "single session", best choice might be a fairly simple
    routing program.

    The program would take the job user and list all current interactive
    jobs for the user. If there are active jobs other than the current job,
    the routing program would display whatever screen or message was
    appropriate and the end.

    If no other active jobs are found, then the routing program simply does
    TFRCTL QSYS/QCMD. (If QCMD is not the desired program, then TFRCTL to
    the appropriate one.)

    The routing program can be as simple or complex as needed. E.g., you
    might have a user index that lists users who can have multiple sessions
    -- if the job user is in that index, then don't bother to check for
    other jobs, simply TFRCTL.

    --
    Tom Liotta
    http://zap.to/tl400

  5. Re: interactive sessions limit

    Hi.

    Thank you for explenation but I don't think I understand everything.
    ---
    LMTDEVSSN can limit a user's sessions to single devices at
    > any one time, but multiple sessions can be started from a device.

    ---
    When I change QLMTDEVSSN to 1 I can only log on just one the time - no
    matter if I log from mocha with named terminal or not.
    I get message:
    CPF1220 User MYUSER cannot sign on to more than one device.

    So I get all I need - don't I?

    So, how can I start more session from one device ?

    Regards,
    Tomasz



    Tom Liotta napisał(a):
    > Graybeard wrote:
    >> On Apr 2, 9:46 am, tomasz wrote:
    >>>
    >>> I would like to limit users interactive sessions to 1 only.
    >>> But not all users, some group must be able to have more sessions at one
    >>> time.

    >
    >> You might want to change system value QLMTDEVSSN to '1' (limit
    >> sessions) and change the user profiles of those who should have
    >> multiple sessions set LMTDEVSSN = *NO.

    >
    > Note that if single sessions is the objective, QLMTDEVSSN will not be
    > sufficient. QLMTDEVSSN can limit a user's sessions to single devices at
    > any one time, but multiple sessions can be started from a device.
    >
    > To enforce "single session", best choice might be a fairly simple
    > routing program.
    >
    > The program would take the job user and list all current interactive
    > jobs for the user. If there are active jobs other than the current job,
    > the routing program would display whatever screen or message was
    > appropriate and the end.
    >
    > If no other active jobs are found, then the routing program simply does
    > TFRCTL QSYS/QCMD. (If QCMD is not the desired program, then TFRCTL to
    > the appropriate one.)
    >
    > The routing program can be as simple or complex as needed. E.g., you
    > might have a user index that lists users who can have multiple sessions
    > -- if the job user is in that index, then don't bother to check for
    > other jobs, simply TFRCTL.
    >


  6. Re: interactive sessions limit

    il 03/04/2007 13.31, Scrive tomasz 40748016:
    > So, how can I start more session from one device ?

    You cannot. When you start a job from a device, the device is locked by
    the job itself.


    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherA˝e joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vŃo Ó merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  7. Re: interactive sessions limit

    On Apr 3, 12:31 pm, tomasz wrote:
    > Hi.
    >
    > Thank you for explenation but I don't think I understand everything.
    > ---
    > LMTDEVSSN can limit a user's sessions to single devices at
    > > any one time, but multiple sessions can be started from a device.

    > ---
    > When I change QLMTDEVSSN to 1 I can only log on just one the time - no
    > matter if I log from mocha with named terminal or not.
    > I get message:
    > CPF1220 User MYUSER cannot sign on to more than one device.
    >
    > So I get all I need - don't I?
    >
    > So, how can I start more session from one device ?
    >
    > Regards,
    > Tomasz
    >


    Do sysrequest 1 - then you get a second signon from the same
    workstation.

    Jonathan.


  8. Re: interactive sessions limit

    On Apr 3, 2:30 am, Tom Liotta wrote:

    [limit interactive sessions]

    >
    > Note that if single sessions is the objective, QLMTDEVSSN will not be
    > sufficient. QLMTDEVSSN can limit a user's sessions to single devices at
    > any one time, but multiple sessions can be started from a device.
    >
    > To enforce "single session", best choice might be a fairly simple
    > routing program.
    >
    > The program would take the job user and list all current interactive
    > jobs for the user. If there are active jobs other than the current job,
    > the routing program would display whatever screen or message was
    > appropriate and the end.
    >
    > If no other active jobs are found, then the routing program simply does
    > TFRCTL QSYS/QCMD. (If QCMD is not the desired program, then TFRCTL to
    > the appropriate one.)
    >
    > The routing program can be as simple or complex as needed. E.g., you
    > might have a user index that lists users who can have multiple sessions
    > -- if the job user is in that index, then don't bother to check for
    > other jobs, simply TFRCTL.



    I had one client for which the following solution was acceptable:

    Only one session allowed. If a user signing on had existing
    interactive jobs, they were cancelled (i.e. all interactive
    jobs other than the current one).

    In this particular case, the vast majority of people attempting a
    second session were doing so because the first session had 'hung'.
    You would think it would have been easier to resolve why sessions
    were hanging, but it wasn't.

    www.brilligware.com/cp0300r.html

    A call to the program cp0300r would be inserted in the intial
    program.

    Chris
    --
    Books to the ceiling, Books to the sky,
    My pile of books is a mile high.
    How I love them! How I need them!
    I'll have a long beard by the time I read them.
    Arnold Lobel



  9. Re: interactive sessions limit

    Jonathan Bailey wrote:
    > On Apr 3, 12:31 pm, tomasz wrote:
    >>
    >> Thank you for explenation but I don't think I understand everything.
    >> ---
    >> LMTDEVSSN can limit a user's sessions to single devices at
    >> > any one time, but multiple sessions can be started from a device.

    >> ---
    >> When I change QLMTDEVSSN to 1 I can only log on just one the time - no
    >> matter if I log from mocha with named terminal or not.
    >> I get message:
    >> CPF1220 User MYUSER cannot sign on to more than one device.
    >>
    >> So, how can I start more session from one device ?
    >>

    >
    > Do sysrequest 1 - then you get a second signon from the same
    > workstation.


    Jonathan has given the simplest method. But if SysReq isn't available as
    a function from a particular emulator, the TFRSECJOB command can perform
    the same function.

    --
    Tom Liotta
    http://zap.to/tl400

  10. Re: interactive sessions limit

    Chris Pando wrote:
    > On Apr 3, 2:30 am, Tom Liotta wrote:
    >
    > [limit interactive sessions]
    >
    >> Note that if single sessions is the objective, QLMTDEVSSN will not be
    >> sufficient. QLMTDEVSSN can limit a user's sessions to single devices at
    >> any one time, but multiple sessions can be started from a device.
    >>
    >> To enforce "single session", best choice might be a fairly simple
    >> routing program.
    >>
    >> The program would take the job user and list all current interactive
    >> jobs for the user. If there are active jobs other than the current job,
    >> the routing program would display whatever screen or message was
    >> appropriate and the end.
    >>
    >> If no other active jobs are found, then the routing program simply does
    >> TFRCTL QSYS/QCMD. (If QCMD is not the desired program, then TFRCTL to
    >> the appropriate one.)
    >>
    >> The routing program can be as simple or complex as needed. E.g., you
    >> might have a user index that lists users who can have multiple sessions
    >> -- if the job user is in that index, then don't bother to check for
    >> other jobs, simply TFRCTL.

    >
    >
    > I had one client for which the following solution was acceptable:
    >
    > Only one session allowed. If a user signing on had existing
    > interactive jobs, they were cancelled (i.e. all interactive
    > jobs other than the current one).


    Chris:

    Heh, that's a solution that certainly could discourage the practice.

    > In this particular case, the vast majority of people attempting a
    > second session were doing so because the first session had 'hung'.
    > You would think it would have been easier to resolve why sessions
    > were hanging, but it wasn't.


    In such an environment, one enhancement might be a simple prompt asking
    if the previous session should be killed. If "yes", then kill it and
    continue this job. If "no", then simply end this job.

    > www.brilligware.com/cp0300r.html
    >
    > A call to the program cp0300r would be inserted in the intial
    > program.


    I like routing programs because they apply to a component of work
    management -- the subsystem -- rather than an individual. The TFRCTL
    QCMD removes the initial routing program from the call stack, so it
    isn't evident after control is passed.

    As a routing program, it automatically applies to every job entering
    that subsystem without any change to new or old user profiles. Making it
    active for individuals or device classes or group profiles or accounting
    codes or whatever you choose to program is completely flexible. A single
    user index can hold exception entries for any type of check you want to
    use to run or skip any procedure in the program.

    One of my favorite uses is as a simple "bulletin board" that pops up
    notices for the day.

    --
    Tom Liotta
    http://zap.to/tl400

  11. Re: interactive sessions limit

    On Apr 5, 2:14 am, Tom Liotta wrote:
    > Chris Pando wrote:


    > > [limit interactive sessions]


    [kill the jobs]

    >
    > Heh, that's a solution that certainly could discourage the practice.
    >


    .... snip ...

    >
    > > A call to the program cp0300r would be inserted in the intial
    > > program.

    >
    > I like routing programs because they apply to a component of work
    > management -- the subsystem -- rather than an individual. The TFRCTL
    > QCMD removes the initial routing program from the call stack, so it
    > isn't evident after control is passed.



    Believe it or not, shop standards prohibited creation of new
    subsystem descriptions or modification of shipped subsystems.
    This ultimately resulted in my departure, to, I suspect, everyone's
    relief.


    >
    > As a routing program, it automatically applies to every job entering
    > that subsystem without any change to new or old user profiles. Making it
    > active for individuals or device classes or group profiles or accounting
    > codes or whatever you choose to program is completely flexible. A single
    > user index can hold exception entries for any type of check you want to
    > use to run or skip any procedure in the program.


    I'm fond of using routing data/entries to control adoption of
    owner authorities. Also the place for any dynamic memory
    management.

    Chris
    --
    Show me your flowcharts and conceal your tables, and I
    shall continue to be mystified. Show me your tables, and
    I won't usually need your flowcharts; they'll be
    obvious. Frederick Brooks


  12. Re: interactive sessions limit

    Chris Pando wrote:

    [routing comments]

    > Believe it or not, shop standards prohibited creation of new
    > subsystem descriptions or modification of shipped subsystems.
    > This ultimately resulted in my departure, to, I suspect, everyone's
    > relief.


    Gotta agree with leaving. To ignore one of the strongest advantages of a
    platform's architecture is nuts. If I couldn't get that policy changed,
    I couldn't feel that I was being allowed to do my job.

    [more routing comments]

    > I'm fond of using routing data/entries to control adoption of
    > owner authorities. Also the place for any dynamic memory
    > management.


    Owner adoption... I'll need to think about that in a routing function.
    Interesting. Might be particularly useful when entry to different
    application areas can be controlled by routing or even separate
    subsystems entirely. Owner adoption should be controlled at application
    entry points; a routing program doesn't _have_ to be dedicated to
    system-level actions, so there's a potential for thinking of one as an
    app entry.

    Dynamic memory management... At the memory pool level, certainly. In
    terms of performance adjustments, that's another fundamental part of
    what work management attributes expose; and another reason it's nuts to
    restrict changes.

    But were you meaning more granular? That'd seem to take application
    design in an unusual direction. If so, I'd be interested in an example
    usage (at the routing level).

    --
    Tom Liotta
    http://zap.to/tl400

+ Reply to Thread