ca.portal.admin

Extraction of CAS data from IDMS into SQL

Discussion created by ca.portal.admin on Aug 3, 2007
Good morning fellow listees -

As a CAS shop, the proverbial handwriting is on the wall for us that -
sooner or later - we're going to have to move to some other ERP system.

Furthermore, it's practically a foregone conclusion that, whatever
system this ends up being, it will likely be built on top of some form
of SQL or, at the very least, will be ""loadable"" from an SQL
environment, and any data-warehousing solution that we may wish to
implement would likely be SQL-able as well.

Given the above, we need to begin looking at methods of migrating our
data out of IDMS into SQL as a ""neutral format"" for lack of a better
term, from which we will eventually load our ""new"" ERP database,
whatever it ends up being, and likely leave the remainder as a ""data
warehouse"" or at least the beginnings of one.

To this end, has anyone on this list had any experience with vendors
and/or their products that would be useful to us towards this end?
While experience with IDMS data in general is not unimportant, I'm
especially curious if anyone has any experience in doing this with a CAS
database as well.

I'm looking for basic information as well as recommendations, however if
you have any damning testimony it's probably better to send that to me
off-list. :)

TIA for all responses,

Mike

PELLERIN MILNOR CORPORATION
Michel J Champagne
Systems Analyst / DBA
<<Picture (Metafile)>>
Voice: 504-712-7589
FAX: 504-712-3589

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Avoiding long outages with large databases
"I have a question regarding large databases. In the last few years for various business reasons, we have drastically increased the number of occurrences of 3 specific record types (two are via the third) that reside in the same area. The numbers will continue to increase. Our DBA has increased the size of the area several times to accommodate this. However, she has advised us that the area cannot be made much larger, as it will mean long outages when database maintenance/changes need to be done involving that area (restructures, etc.). Our business runs 24/7, and so long outages are a major issue for our users. One of the records in question is 464 characters, and we have almost 2 million occurrences of it. It is used frequently by our applications. The second is 168 characters, and we have 1.5 million occurrences, and the third is 52 characters, and we have 1.5 million occurrences. The area currently has over 1 million pages. We do archive/delete old data, but not enough is considered 'old' by our users' requirements to alleviate enough of the problem. No doubt there are larger databases out there than ours with more data...what strategies/products/etc. do you use to avoid long outages when you must make changes to the records/indexes in an area? Any feedback would be most appreciated.

We are a VM/VSE shop with IDMS Release 15.0.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Avoiding long outages with large databases
"Do you use DB-EZREORG to handle reorgs, unloads etc on this database? It
is the one way to handle situations such as yours.

Dick

Richard C Borman/GIS/CSC
CSC/GIS Idms System Support
9305 Lightwave Ave
San Diego, Ca 92193-9011
home 760-787-1075
cell 858-245-4761
rborman@csc.com



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------





Joan Hutchinson
<JHUTCHIN@IPSCO.C
OM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> Avoiding long outages with large
databases

08/08/2007 10:15
AM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>






I have a question regarding large databases. In the last few years for
various business reasons, we have drastically increased the number of
occurrences of 3 specific record types (two are via the third) that reside
in the same area. The numbers will continue to increase. Our DBA has
increased the size of the area several times to accommodate this. However,
she has advised us that the area cannot be made much larger, as it will
mean long outages when database maintenance/changes need to be done
involving that area (restructures, etc.). Our business runs 24/7, and so
long outages are a major issue for our users. One of the records in
question is 464 characters, and we have almost 2 million occurrences of it.
It is used frequently by our applications. The second is 168 characters,
and we have 1.5 million occurrences, and the third is 52 characters, and we
have 1.5 million occurrences. The area currently has over 1 million pages.
We do archive/delete old data, but not enough is considered 'old' by our
users' requirements to alleviate enough of the problem. No doubt there are
larger databases out there than ours with more data...what
strategies/products/etc. do you use to avoid long outages when you must
make changes to the records/indexes in an area? Any feedback would be most
appreciated.

We are a VM/VSE shop with IDMS Release 15.0.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Avoiding long outages with large databases
"Been a while since I worked on VM, but when I did there was 4K page size
limit and that unfortunately increases the number of pages and can
impede effective clustering. If that is still true (or even if it's
not), one possible solution is splitting the single area into 3 separate
areas, each containing one of the record types mentioned. By doing
this, you could improve throughput by spreading out I/O access and
reduce the number of pages assigned to each of the individual areas.
You might also get away with doing maintenance on only one of these
areas at a time depending on the growth patterns of the records. This
can cause some significant application changes because you would need to
add the extra areas to any programs that use these records, but it might
be worth it if this area will continue to grow at a rapid pace.

Linda Campbell
Informatix Inc

Outcomes