ca.portal.admin

Re: [IDMSVENDOR-L] System Owned Indexes

Discussion created by ca.portal.admin on Feb 7, 2005
if they are ""linked"" indexes - you will have to hit the member area anyhow
in order to modify the member record index pointers
only if they are ""unlinked"" (which implies MA) might you gain significant
time and i/o by rebuilding from index

but i could be mistaken



Chris Hoelscher
IDMS & DB2 Database Administrator
Humana Inc
502-580-2538
choelscher@humana.com





The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Resizing Load Area at 12.01 - Follow up
"Many thanks to all of you who responded to this thread with helpful,
informative advice. Just to let you know, the temporary patch to allow
unload to work with subschemas containing duplicate record ID's isn't
available for 12.01. The latest patch level was, if I remember right,
9811. I was able to accomplish the job by punching all load modules,
changing the area, and adding all load modules. One dragon down, who
knows how many to go.

Much thanks!

Roger C. Lawrence
Database Administrator
Seminole Electric Cooperative, Inc.
Tampa, Fl.
813.739.1518
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] System Owned Indexes
"if they are ""linked"" indexes - you will have to hit the member area anyhow
in order to modify the member record index pointers
only if they are ""unlinked"" (which implies MA) might you gain significant
time and i/o by rebuilding from index

but i could be mistaken



Chris Hoelscher
IDMS & DB2 Database Administrator
Humana Inc
502-580-2538
choelscher@humana.com





The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
System Owned Indexes
"I am putting together a project to rebuild all 100 of the CAS system-owned
indexes and was wondering if anyone knows the answer to this question: is
there any downside to doing the rebuild 'from index' for sets that are
defined as <?xml:namespace prefix = st1 ns =
""urn:schemas-microsoft-com:office:smarttags"" />OM, OA, or MM. There are no
changes being made - just a rebuild to clean things up. Normally I would do
'from members' for any set that is not MA but that always takes more time.
<?xml:namespace prefix = o ns = ""urn:schemas-microsoft-com:office:office"" />


Thanks,

Craig Mc Gregor
Acxiom Corp.
Online Database Administration
630-944-4899
Craig.McGregor@acxiom.com





**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
R16 question - about printer form feeds
"We are upgrading from R14.1 to R16. For R14.1, we had applied optional
APAR LS56777, with an override of 'CF'. This has been replace by the
new SYSGEN 'printer control' parameters. Can anyone tell me how we
should code these to achieve the same result we had before?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Recovery at a DR Site
"Hi All,
Sorry for the long post, but I need to explain the situation before asking
the question.
We are now doing data replication for disaster recovery, so I no longer
need to rely on journals to foll forward at a DR site. For those who are
not familiar with this facility, it simply means there is a remote site with
duplicate DASD which is constantly kept in sync with the main data center.
During the current DR test, I noticed that once the IDMS regions
WARMSTARTed, one region had a full journal. This could only mean that a
journal offload was running at the main site when the decision was made to
""snapshot"" the data (all IDMS regions are active at the time). I simply ran
an offload at the DR site and all was fine.
However, this got me to thinking. What if the journal offload was
performing the condense of the journal file when the ""disaster"" occurred?
This would mean that the journal file at the DR site was in an unknown state
- having been constantly copied while the condense was occuring. If the
region (at DR) needed data within that journal file in order to restart (a
very real possibility), the restart could very well fail.
So, I'm thinking a simple solution to this problem would be to modify the
journal offload job. It would copy the journals before the offload step,
and then delete the copy once the offload was successful. In this way, if a
disaster occurred, I could check for the presence of a backup journal at the
DR site before bringing up IDMS. If it is there, that would indicate that
an offload was occuring at the time of the disaster and I would copy the
backup journal file (only the FULL one) over the top of the real journal
file, then start the regions.
One question which comes to mind is whether I back up all the journals
before the offload or just the one which is full. If I only wanted to back
up the journal which would get offloaded, I'm guessing I would need to write
a program to determine the full journal (with the lowest sequence number)
and somehow generate the correct control cards for the backup.
If I decide to back up all the journal files before the offload, I would
then need to determine which journal should get overlayed at the DR site
(ie. which journal was being offloaded at the main site). This could be
done by running a simulated offload against the backup journals at the DR
site and see which one would get chosen.
I think backing up all the journals is the easiest method. Does anyone
see anything wrong in this approach?
Thanks.


Joe Lupico
IDMS System Support
""Our World is a Happy World""

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Recovery at a DR Site
"Joe, are you truly doing data replication (real-time data mirroring), or a
""snap copy"" at intervals ?

Outcomes