RE: [Security400] QINACTITV does not appear to be working

["Bale, Dan" <D.Bale@xxxxxxxxxxxxx>]

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
A good idea, but I was under the impression that TFRJOB was strictly a
batch function.  You even mention the QCTL jobq.  So, presuming you've
done this <g>, can you give more details on this?  Reading the help
text, it appears that the interactive job transfers into the job
queue?!?!?  Are you really running an interactive job from batch?  Wow.

Am I correct to assume that this method wouldn't help me if I'm not
already signed on when QINTER is ended?  Sounds like Evan's method would
allow me to sign on even if QINTER is ended.  Although, you bring up
another issue with "randomly assigned QPADEVxxxx names".  We use CA
(v3r1m2; cuz lowest common denominator is OS/400 v3r2).  I seem to
recall that later versions of CA allowed you to fix the session names.

<sigh> What to do? What to do?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From: Buck Calabro [SMTP:Buck.Calabro@commsoft.net]
> Sent: Thursday, August 30, 2001 2:30 PM
> To:   security400@midrange.com
> Subject:      RE: [Security400] QINACTITV does not appear to be
> working
>
> >To enable access to particular individuals during the
> >backup I starts a second subsystem that has
> >workstation entries included in it and only allow
> >people with a particular routing entry to sign on.
>
> An alternative is to secure access to jobq(qctl) and allow only
> authorised
> individuals the ability to TFRJOB QCTL.  In the era of randomly
> assigned
> QPADEVxxxx, it's easier to restrict by user ID than by device ID.  A
> second
> (private) subsystem is a very good idea.
>
> Buck