ca.portal.admin

Re: Unload/Reload Calc change

Discussion created by ca.portal.admin on Nov 11, 2008
Chris,

Your theory is correct. I have used that method in the past to =
unload/reload with a CALC change.

What happens is that the target page is calculated at the time of =
extract, when you reload the CALC record, it will be sorted by target =
page but you will end up storing it ion the correct page.
The ""good"" news is the VIA records are stored direct and then connected =
afterwards, so that will be fast, the bad news is they will not be =
stored next to the CALC records.

By using the new CALC definition during the unload, you will get both =
the CALC and VIA record target pages calculated correctly.

Tommy Petersen



=20
""Trayler, =20
Christopher"" =20
<christopher.tray =
To
ler@JULIUSBAER.CO IDMS-L@LISTSERV.IUASSN.COM =20
M> =
cc
Sent by: IDMS =20
Public Discussion =
Subject
Forum Unload/Reload Calc change =20
<IDMS-L@LISTSERV. =20
IUASSN.COM> =20
=20
=20
11/11/2008 03:26 =20
AM =20
=20
=20
Please respond to =20
IDMS Public =20
Discussion Forum =20
<IDMS-L@LISTSERV. =20
IUASSN.COM> =20
=20
=20




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

______________________________________________________________

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 www.juliusbaer.com =
<http://www.juliusbaer.com/>

______________________________________________________________
*****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 =
transaction.
"
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: Unload/Reload Calc change
"Good Morning America

I have successfully run and checked with DBAN and indeed this slightly ""illegal"" use of Unload does work.Even the VIA records appear to be on the correct pages.

My run time of 5 hours on a busy machine compares very favourably with the previous run time of - cancelled after 18 hours only 5% of the way through IDMSDBL2 on an empty machine.

Well done Tommy for thinking of it first. I think it should be put in the manual.

Or perhaps everybody else had already thought of it except me? Better late than never. I like it!

Swiss Chris

Outcomes