ca.portal.admin

Re:Re: [IDMSVENDOR-L] Database Compare Utilities - Help

Discussion created by ca.portal.admin on Feb 11, 2005
Since this is the VENDOR list, I think I can say that we, ISP, have a
superfast utility for dumping IDMS records to flat files. The real purpose
of this tool is to extract IDMS data for loading to relational tables but it
could be used to create before and after flat files for comparison. So long
as there aren't more than tens of millions of records I'd think this
feasible.

We also have some low cost journal reporting software that might be used but
I suspect building a system to compare the content of the journals would be
more trouble than it's worth.

If you'd like to try the superfast extract, I'm at (800) 295-7608 x23.

Cheers,

Jim.


From: Chris Hoelscher <choelscher@HUMANA.COM>
Reply-To: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Database Compare Utilities - Help
Date: Thu, 10 Feb 2005 15:53:57 -0500

then how about looking at the journal files?


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
Re: [IDMSVENDOR-L] Database Compare Utilities - Help
"Since this is the VENDOR list, I think I can say that we, ISP, have a
superfast utility for dumping IDMS records to flat files. The real purpose
of this tool is to extract IDMS data for loading to relational tables but it
could be used to create before and after flat files for comparison. So long
as there aren't more than tens of millions of records I'd think this
feasible.

We also have some low cost journal reporting software that might be used but
I suspect building a system to compare the content of the journals would be
more trouble than it's worth.

If you'd like to try the superfast extract, I'm at (800) 295-7608 x23.

Cheers,

Jim.


From: Chris Hoelscher <choelscher@HUMANA.COM>
Reply-To: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Database Compare Utilities - Help
Date: Thu, 10 Feb 2005 15:53:57 -0500

then how about looking at the journal files?


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
Database Compare Utilities - Help
"Linda

Since you seem to be working with databases that are too large to be
exported into flat files and then compared, I think Chris's solution of
comparing journal images is the only feasible way. There are, however, a
number of potential pitfalls:
You have to assemble BFOR/AFTR images of database records when they span
two journal records. This is possible - CA used to have an Assembler
routine to do so, but you can write your own in CULPRIT (use the Input
Module CULLJRNL as a starting point).
If the database records are compressed, then you have to decompress their
images to make them comprehensible. See Appendix A of the Presspack User
Guide.
If you need to identify which database record occurrences have variations,
either the record's data portion must contain a means of identification
(CALC or index key), or you need, from its prefix portion, the dbkey of
another record that does, and which you can look up on the database.
If you cannot guarantee updates on your databases are performed in an
identical sequence, you need a key, compound or otherwise, to which the
images, or your extracts therefrom, can be sorted before performing the
comparison.
I do not wish to depress you, but you need to know what you may be letting
yourself in for.


Disclosure of Material Facts
Every Proposer or Insured / Reinsured when seeking new insurance / reinsurance or renewing an existing Policy must disclose any information which might influence the Insurer / Reinsurer in deciding whether or not to accept the risk, what the terms should be, or what premiums to charge. Failure to do so may render the insurance / reinsurance voidable from inception and enable the Insurer / Reinsurer to repudiate liability.

This email, together with any attachments, is for the exclusive and confidential use of the addressee(s) and may contain legally privileged information. Any other distribution, use or reproduction without the sender's prior consent is unauthorised and strictly prohibited. If you have received this message in error, please notify the sender by email immediately and delete the message from your computer without making any copies. While attachments are virus checked, Aon Limited does not accept any liability in respect of any virus which is not detected.

Aon Limited
Company Number: 210725
Registered Address: 8 Devonshire Square, London, EC2M 4PL

Aon Limited is authorised and regulated by the Financial Services Authority in respect of insurance mediation activities only
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Changing binary zeroes to comp-3 on database record
">
Date: Wed, 9 Feb 2005 18:12:49 -0500
From: Roger Lawrence <RLawrence@SEMINOLE-ELECTRIC.COM>
Subject: Changing binary zeroes to comp-3 on database record

For reasons I have not yet been able to ascertain, we have database
records with binary zeroes in an element defined as s9(11) comp-3. The
element was added several months ago using restructure and was
initialized correctly at that time. Records stored since then have
binary zero while older records have packed zeroes. I suspect the
records were added using a batch program and an old subschema (without
this element in the record) so the element wasn't initialized correctly
before the store. I will be quizzing the developer for more details
tomorrow. Meanwhile, I am hopeful that this esteemed body can offer
suggestions for changing the value from binary to packed.

Any ideas?

Thanks,

Roger C. Lawrence
Database Administrator
Seminole Electric Cooperative, Inc.
Tampa, Fl.
813.739.1518
If it's acceptable to zero the packed field in question in all records in
the area, then a restructure using this restructure table should work:

IDMSRSTT BUFSIZE=(4200,4200)
*
IDMSRSTT RECNAME=recname
IDMSRSTT SETPTR=ALL
IDMSRSTT FIELD=(1,1,length_before) copy elements before
IDMSRSTT FIELD=(PL6'0',pos,6,NEW) init packed element
IDMSRSTT FIELD=(pos+6,pos+6,length_after) copy elements after
IDMSRSTT END
END

where 'recname' should be replaced with the record name, 'length_before'
with the length of all elements before the packed element, 'pos' with the
current displacement in the record of the packed element, and
'length_after' with the length of all remaining elements.

Just a suggestion -- I haven't tested this.

Peter Hannigan,
IBM GS.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Simple Question
"Hi Mary,

0308 Service Pack 7 - it needs a lot of patching to bring it up to date.

Sam

Outcomes