|
*This message was transferred with a trial version of CommuniGate(r) Pro*
Thank you for your response.
The application currently runs on distributed 170s which were rolled
out in 1999. There are about 40 users per system.
The rollout will be gradual with 2000 being the max.
All of the users are pretty much casual users. There is no heads down
data entry.
Will the data that I collect on the 170s be of any use for sizing the
new system?
Albert
On Fri, Jul 2, 2010 at 9:47 AM, John Jones<chianime@xxxxxxxxx> wrote:
Just telling us they're 5250 users doesn't say much. For instance,
traditional JDE can support hundreds of green screen users with virtually no
CPU usage whatsoever. Back when we ran a 730 I'd have 250 or so concurrent
users online& interactive CPW was around 100. Heads down data entry
generally isn't demanding. However, eventually they start running the batch
report jobs they need to actually get data back out of the system and for
that you never have enough CPU. Each app will be different so YMMV.
Other info that needs to be considered:
1. Named v. concurrent users. 2000 named users isn't so bad if only 400 are
on at any given time.
2. What constitutes an acceptable response time?
3. What percent are power users v. casual users? A power user will usually
count the same as 3-5 casual users.
4. Approx size of the database (so RAM& DASD - both capacity& arms - can
be estimated).
5. Back up window / off-hours batch needs / 24x7 availability requirement
6. What else will be running? 3rd party apps, HA, web/FTP servers, queries
run against the db from Crystal or other non-i sources, etc.
7. Phased implementation or big-bang? It matters as a phased implementation
allows you to start small and turn on capacity as needed. It also gives
wiggle room if the actual workload requirements aren't specific enough and
it allows you to see if adding users creates a linear or geometric need for
added resources. Along with that it implies there's budget for adding
capacity as needed.
8. Along those lines, is 2000 a starting? Will it be 3000 in 2 years?
As Dan said, you need to work with a BP and your vendors to get some
estimations from them. Apply that to what you know of the organization.
Don't start with a maxed out machine; always leave room for
growth/expansion.
On Fri, Jul 2, 2010 at 10:49 AM, Albert York<alfromme@xxxxxxxxx> wrote:
We were planning on putting the users on the corporate network. We
need to do this for other reasons than accessing the iseries. I just
need to know a range of configurations that will support 2000 green
screen users.
Albert
On Fri, Jul 2, 2010 at 7:29 AM, Mark Murphy/STAR BASE Consulting Inc.
<mmurphy@xxxxxxxxxxxxxxx> wrote:
I suspect this has not been answered because it is so simple. Just putthe iSeries on the corporate network. As long as your remote users have
access to the network they can get top the iSeries using iSeries Access.
This is a network issue, not an iSeries configuration issue. In the case
that the remote users are individuals with laptops, set up VPN access to
your network. I would use a hardware solution like one from Cisco, or if
the remote is a branch office, just use a couple routers to connect the
branch office to your main network.
Mark Murphylist
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange technical discussions<midrange-l@xxxxxxxxxxxx>
From: Albert York<alfromme@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 07/01/2010 02:07PM
Subject: iSeries configuration
I have a client who has requested a suggestion for an iseries
configuration that will support about 2000 remote users running a
green screen application. At this point I am just trying to get an
idea of some approximate costs to see if this will be a reasonable
solution. The users might be on one lpar or they may be split between
3 lpars, depending on the cost difference.
Does anyone have any reccomendations?
Thanks,
Albert
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxxlist
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx--
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
JJ
4 Out of 3 people have trouble with fractions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
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.
midrange.com
