ca.portal.admin

Re:Re: IDMS Data Replication Via TCP/IP

Discussion created by ca.portal.admin on Nov 9, 2008
This probably doesn't help your situation any, but I can tell you what
we did.

We are trying to get off the mainframe (and IDMS).
We have a need to keep many databases synchronized real-time throughout
the day while development continues to retire IDMS applications and
replace with brand new non-IDMS systems.

We wrote our own message exchange system.
It handles both PUBLISH and SUBSCRIBE messages.
IDMS can be updated from an update that originates on another database
and another database can be updated when an update originates in IDMS.

On the PUBLISH end:
1. An update occurs in IDMS.
2. A database procedure gets called for the record and writes a queue
record to any one of over a hundred queues.
3. A DC-COBOL program fires up as a result of queue trigger of 1.
4. DC-COBOL program re-obtains the record or (in case of an ERASE,
captures the key from the queue record) and writes appropriate fields
for the record to message exchange database on IDMS.
5. TCP/IP Socket program idles looking for PUBLISH records to send to
server.
6. Server routes message to appropriate system and processes update
database.

On the SUBSCRIBE end:
1. TCP/IP Socket program sends message to message exchange database on
IDMS from open-systems side.
2. Another non-socket idler program looks for SUBSCRIBE messages to
process.
3. Idler program reads the tag to figure out what message it is.
4. Idler attaches the appropriate task to process the message and
update IDMS.

The above is a simplification of what happens.
There are called programs for handling writing and reading messages and
a lot of tables are involved so we don't have to recompile / reassemble
every time there is a change or a new message.

It took a while to develop ( 1 year +) and it was a lot of fine-tuning
effort along the way for the first couple of years.
Also, it is possible to end up with ""Dead Messages"" for any of a number
of reasons.
We have a process in place to handle those so we don't lose updates and
get databases out-of-sync.

Thanks.
Jon Gocher

----- Original Message -----
From: ""Govan, Hal (RET-DAY)"" <Harold.Govan@REEDELSEVIER.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Thursday, November 06, 2008 11:35 AM
Subject: IDMS Data Replication Via TCP/IP


Hi Everyone:

I have a question for folks using IDMS TCP/IP under R16.0.

We are currently using IDMS TCP/IP to support web-based apps coming in
from WebSphere. We are contemplating doing selective data replication
to ORACLE and MS SQL Server databases using TCP/IP enhancements to
existing IDMS-DC applications.

Has anyone out there done this type of replication without the benefit
of a third-part product ? If so, I would appreciate any information
you could share regarding your experiences.

TIA


Hal Govan
Senior Database Administrator
Reed Elsevier - Technology Services
harold.govan@reedelsevier.com <mailTo:harold.govan@lexisnexis.com>
Phone: (937) 865-7820
"
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
"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
Re: Unload/Reload Calc change
"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 extra=
ct,
when you reload the CALC record, it will be sorted by target page but y=
ou
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 stor=
ed
next to the CALC records.

By using the new CALC definition during the unload, you will get both t=
he
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 Subj=
ect
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. (Althou=
gh I
need to check because I never got it to finish before the ops had to ca=
ncel
it in the night).

However because the calculation for the suggested dbkey position is bas=
ed
on the values in the old subschema - it is in the manual look it up - t=
hen
the suggested dbkeys for the records in the unloaded file are completel=
y
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 u=
p in
the right page.

I have a theory. I don't think that Unload will ever issue an obtain CA=
LC .
I also think that no checking goes on of whether an existing CALC recor=
d
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. Obviousl=
y 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 sl=
ot
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 recipie=
nt
only and may contain confidential or privileged information. If you hav=
e
received this e-mail by mistake, please contact us immediately and
completely delete it (and any attachments) and do not forward it or inf=
orm
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, howev=
er,
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 kno=
w.
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 th=
e
content of this message which arise as a result of its e-mail transmiss=
ion.
Please note that all e-mail communications to and from the Julius Baer
Group may be monitored. This communication is for informational purpose=
s
only. It is not intended as an offer or solicitation for the purchase o=
r
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
"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.

Regards
Martin



_____

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Tue 11/11/2008 08:22
To: IDMS-L@LISTSERV.IUASSN.COM
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

______________________________________________________________

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.








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 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
"Dear Chris
=20
Unique or not unique? - that is the question. Unload uses the calc set =
to determine duplicate sequence.....
=20
Otherwise I don't see a problem.
=20
A simple test unload (canned) with and without the subschema change and =
an unload file compare should prove it.
=20
Regards
Martin
=20
=20

_____ =20

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Tue 11/11/2008 08:22
To: IDMS-L@LISTSERV.IUASSN.COM
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=C3=BCrich, 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.




=20
=20
=20
=20
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
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
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

______________________________________________________________

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
Unload/Reload Calc change
"Dear Listers
=20
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.
=20
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).
=20
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.
=20
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...
=20
What do the listers think?
=20
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.
=20
Thanks =20
=20
______________________________________________________________
=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
www.juliusbaer.com <http://www.juliusbaer.com/>=20
=20
______________________________________________________________
*****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.=20

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 =20

Outcomes