|
midrange.com
Alan,
I) We've had audits before which 'recommend' the one signon - one session.
Failure of one incident on the audit does not necessarily mean failure of
the audit entirely. How do they define the session? For example...
a) If I have Client Access (pre Express) and I have a directory mapped
(I: drive), a virtual printer, a file transfer set up, an ftp window open,
some odbc connections and a 5250 display on the same PC does that count as
1 session?
1) If I didn't have the 5250 open would that not even count as a
session?
b) Is there anything on your 400 from preventing the same user id from
being used from multiple PC's to connect, if they stay out of 5250? For
example, three PC's signed on by SAM all doing some ODBC, and whatnot, but
no 5250?
** This is one more reason to drop 5250 and go web or C/S - to pass audits
designed in the 1970's.
II) The performance of having multiple sessions varies. If they are not
doing anything then their performance impact is next to nothing. There
used to be a problem on very ancient machines, like the old letter models
B, C, D; that genre. If they are doing something then, yes there may be a
performance impact. But, then otherwise to get the same amount of work
done, you could hire 3 more people to keep 4 sessions input inhibited and
enforce your single signon rule. Or give the person multiple signon id's.
(Even though all the ODBC, FTP, File transfers, etc will all use the same
signon.)
Now we may be overlooking maximum jobs in a subsystem or some such thing.
Also, the likelihood of increased record locks goes up with some software
packages. They pull an account up for maintenance in a poorly written
application which leave the record locked. Open up another session to view
something else. Some other user elsewhere stays locked out of that first
account.
But given all this, we will give up our multiple sessions when you peel our
cold dead fingers away from the keyboard.
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
"alan shore"
<SHOREA@dime.com> To:
<MIDRANGE-L@midrange.com>
Sent by: cc:
owner-midrange-l@mi Subject: Re: Counting users
drange.com
07/31/2001 02:32 PM
Please respond to
MIDRANGE-L
Yes, I am a programmer/analyst (or whatever the buzz word is today).
Working for a savings and loan, we are ruled by an outside governing body,
who declares, for any and every type of platform....
One signon, one session.
No arguments, no discussion, and as we rely on passing their audit, guess
which track we follow.
My next question follows on from there,
Surely with a user signed on more than once (and that user can only work on
one session at a time (please read this last statement carefully--- no
matter how good you are, nobody [to my knowledge] can type into 2 separate
windows coherently at once) the system is somewhat degraded with multiple
interactive sessions.
>>> <MWalter@hanoverwire.com> 07/31/01 03:00PM >>>
Alan,
Are you a programmer? Before PCs and CODE/400, I would have a session for
CL,RPG,DDS source and still another session with a command entry. Just one
example.
Mark
Mark Walter
Sr. Programmer/Analyst
Hanover Wire Cloth a div of CCX, Inc.
mwalter@hanoverwire.com
http://www.hanoverwire.com
717.637.3795 Ext.3040
"alan shore"
<SHOREA@dime.com> To:
<MIDRANGE-L@midrange.com>
Sent by: cc:
owner-midrange-l@mi Subject: Re: Counting
users
drange.com
07/31/01 02:17 PM
Please respond to
MIDRANGE-L
I'm sorry, but I have to start asking questions. I was hoping that it would
become much clearer once the answers started to appear, but that has'nt
happened.
Why has a User Profile the ability to sign onto the system more than once?
Surely, the user can only work on one session at a time. If so, why not
limit the number of sessions to 1 per User. What advantage would there be
to having more than 1 session per user?
>>> <rob@dekko.com> 07/31/01 01:02PM >>>
Have you thought about polling your customer base and see how many are
actually using dumb 5250 terminals? You may retrieve many answers:
1) Yes, but only 1 or two at our site, they are expendable
2) No
3) Yes, but please stop supporting them. Therefore we can finally
convince management to dump them for PC's.
4) Yes, and so many it would be a serious financial burden on us to
change.
5) I am using one here, (amidst dozens of PC's) and I'll whine and stomp
my feet if you stop supporting it.
I have heard of option 3. One vendor was talking about doing a minimum
supported version of OS, and that is what they got.
Anything other than 4 I wouldn't use as a reason to keep supporting them.
Heck your licensing issue may be a financial incentive for them to upgrade
the dumb terminal to a PC.
Please, let's not start the argument for dumb:
training
concentration of work effort vs games
reliability
dirty environments
I am trying to help him help his customers
Ron,
Perhaps you should also check out the 'key' api's and see if you can use
that technique. ADDLICKEY and how to check. This might be a good start:
http://publib.boulder.ibm.com/html/as400/v5r1/ic2924/info/apis/sw1.htm
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
Ron@cpumms.com
Sent by: To:
MIDRANGE-L@midrange.com
owner-midrange-l@mi cc:
drange.com Subject: Re: Counting
users
07/31/2001 10:29 AM
Please respond to
MIDRANGE-L
Leif,
<<Did you ever tell us the REASON for wanting this?
I don't think I ever stated it directly, but a couple of people on the list
(Al Mac? and Rob) did state it.
We have license agreements to use our software and as part of that we count
the number of users using the software. This works fine, but our customers
want to be able to sign onto multiple sessions on the same terminal and not
be counted more than once. If they're using "dumb" terminals to accomplish
this, I don't know how to tell the difference between a user signing onto a
single terminal 5 times and a user signing onto 5 terminals.
Ron Hawkins
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
