ca.portal.admin

Factors to take into account when deciding whether to create a

Discussion created by ca.portal.admin on Mar 5, 2009
Latest reply on Mar 6, 2009 by ca.portal.admin
new production Retrieval CV

There are plans to significantly increase the number of users, possibly
thousands, defined to our IDMS application. Many of the existing users
and a high proportion of the new users will be retrieval only. Currently
we have approximately 3500 users, where the most we see signed on
concurrently is 580 or so. We kick them off after 20 minutes inactivity.

The users we currently have defined are the ""core"" stakeholders, and I
expect the new users will not be signed on as long or do as much
activity with the application.

I am aware of some of the issues when having a retrieval CV. What may
appear to be broken chains to the retrieval CV unless the buffers are
shared with the update system, the application would have to be adjusted
slightly to eliminate any updates during signon etc.

From the performance point of view, we don't have max tasks exceeded, no
SOS type issues and excellent response time overall. My expectation is
that we could add these new users into the existing update CV, scale the
maximum number of concurrent users appropriately, and there would be no
negative impact, except possibly for an increase in the size of pool 128
which contains SH,SK,US,UK types. However I would like to know what the
major benefits are in having a retrieval CV and what I should monitoring
in the update CV that will indicate a retrieval CV would be worth
considering.

Thank you all for the information.=20

Tim Williams
Alberta Department of Justice
JOIN Technical support
(780) 415 6160
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Factors to take into account when deciding whether to create a new production Retrieval CV
"Tim, have you considered data sharing ? This could avoid the false
broken chain errors. From your comments, I am assuming you have a
large environment with multiple LPARs so this could be a possibility if
there is sufficient storage available in your CF.

If your retrieval users don't need up-to-the-minute currency of data,
you could use a relatively static copy of your databases for retrieval.
This can be updated from backups or, at intervals, by applying journal
extract data via rollforward to your retrieval DB. We have done this
for some time now with good results.


Hal Govan
Senior Database Administrator
Reed Elsevier - Technology Services
harold.govan@reedelsevier.com
Phone: (937) 865-7820

Outcomes