ca.portal.admin

Re: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




""Trayler,
Christopher""
<christopher.tray To
ler@JULIUSBAER.CO IDMS-L@LISTSERV.IUASSN.COM
M> cc
Sent by: IDMS
Public Discussion Subject
Forum Unload/Reload Calc change
<IDMS-L@LISTSERV.
IUASSN.COM>


11/11/2008 03:26
AM


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






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ürich, 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 Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
cics to idms lu62 connectivity failure on CICS startup
"apparently for the last hundred ? years, when CICS bounces (with IDMS up)
- the Lu6.2 connections do not automatically sync up - they cannot force
them from the CICS side, and the only way they have been able to resolve
this is to issue DCMT V LINE *** OFL / ONL
(in any event I am going to suggest connect)

but is there a IDMS or CICS parameter that should make this happen
automatically when CICS shuts down and starts while IDMS remains active??

(we are idms 15.0 SP5 and CICS TS 3.1 and 3.2)


thanks,

Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
cics to idms lu62 connectivity failure on CICS startup
"apparently for the last hundred ? years, when CICS bounces (with IDMS up)
- the Lu6.2 connections do not automatically sync up - they cannot force
them from the CICS side, and the only way they have been able to resolve
this is to issue DCMT V LINE *** OFL / ONL
(in any event I am going to suggest connect)

but is there a IDMS or CICS parameter that should make this happen
automatically when CICS shuts down and starts while IDMS remains active??

(we are idms 15.0 SP5 and CICS TS 3.1 and 3.2)


thanks,

Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-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: 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. =20

Outcomes