Re: Unload/Reload Calc change

Discussion created by ca.portal.admin on Nov 11, 2008
Dear Chris
Unique or not unique? - that is the question. Unload uses the calc set =
to determine duplicate sequence.....
Otherwise I don't see a problem.
A simple test unload (canned) with and without the subschema change and =
an unload file compare should prove it.

_____ =20

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Tue 11/11/2008 08:22
Subject: Unload/Reload Calc change

Dear Listers

I have a large DB with a mixture of CALC and VIA records and loads of =
indexes. I wish to change the key of the CALC records.

If I unload/reload it with an old subschema and a new subschema then =
unload/reload is perfectly capable of getting the answer right. =
(Although I need to check because I never got it to finish before the =
ops had to cancel it in the night).

However because the calculation for the suggested dbkey position is =
based on the values in the old subschema - it is in the manual look it =
up - then the suggested dbkeys for the records in the unloaded file are =
completely wrong for the new calc keys and by association the VIA =
records as well. After the sort IDMSDBL2 valiantly stores all the =
records in the new DB but of course it takes for ever because the sort =
order is wrong and you end up with a random storing pattern instead of =
the usual sequential albeit backwards storing of the records in the new =
DB. But the CALC records do end up on the right page. I have yet to =
check whether the vIA records end up in the right page.

I have a theory. I don't think that Unload will ever issue an obtain =
CALC . I also think that no checking goes on of whether an existing CALC =
record actually has the right key. If that is true, then I should be =
able to change the old subschema to the new CALC values and use it for =
both the Unload and the Reload and the answer will be correct and fast. =
Obviously as soon as I change the old subschema then I would not be able =
to legally find any CALC records but if I just Unload it...

What do the listers think?

This DB is relatively large at around 12 Million records spread over 8 =
record types - 3 CALC and 5 VIA - plus a ridiculous 25 indexes and I am =
limited with testing time. I am going to test my theory when I get a =
slot unless someone can tell me that I am already wrong. That would save =
me a lot of effort.

Thanks =20


Chris Trayler, IXD
Bank Julius Baer & Co. Ltd.
P. O. Box, CH-8010 Z=FCrich, Switzerland
Telephone +41 (0)58 887 4332, Fax +41 (0)58 887 4969 =

*****JuliusBaer Disclaimer***** This e-mail is for the intended =
recipient only and may contain confidential or privileged information. =
If you have received this e-mail by mistake, please contact us =
immediately and completely delete it (and any attachments) and do not =
forward it or inform any other person of its contents. If you send us =
messages by e-mail, we take this as your authorization to correspond =
with you by e-mail, however, we will not accept the electronic =
transmission of orders/instructions without a specific agreement being =
in place to govern the same. If you do not wish to receive any further =
e-mail correspondence please let us know. E-mail transmission cannot be =
guaranteed to be secure or error-free as information could be =
intercepted, amended, corrupted, lost, destroyed, arrive late or =
incomplete, or contain viruses. Neither the Julius Baer Group nor the =
sender accept liability for any errors or omissions in the content of =
this message which arise as a result of its e-mail transmission. Please =
note that all e-mail communications to and from the Julius Baer Group =
may be monitored. This communication is for informational purposes only. =
It is not intended as an offer or solicitation for the purchase or sale =
of any financial instrument or as an official confirmation of any =

Thomson Financial Limited, a Thomson Reuters company, is a company =
incorporated under the laws of England and Wales (registered number =
2012235) having its registered office and address for service at Aldgate =
House, 33 Aldgate High Street, London, EC3N 1DL, UK.
This e-mail is for the sole use of the intended recipient and contains =
information that may be privileged and/or confidential. If you are not =
an intended recipient, please notify the sender by return e-mail and =
delete this e-mail and any attachments.
IDMS 3rd-party providers forum


Re: Unload/Reload Calc change
"The original CALC Keys are unique. The new ones are a subset of the original and are duplicates last. It is trying to get rid of a CALC to CALC set which gives a performance problem. The new definition uses the common part of the original Calc Key to end up with identical Calc keys for the owner and the members. The ""Loads of indexes"" that I mentioned are sufficiently redundant to ensure the uniqueness of the original key. They will just get a 1205 with the index instead of a 1205 with the Calc set if they try and storea duplicate.

I have set up the test and it is running now. It is certainly quicker than before - in fact I never got the original to finish - I shall run a DBAN at the end and see what I get. I'm worried that the VIA records may target to the wrong page.

We shall see.