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: cics to idms lu62 connectivity failure on CICS startup
"well, since i am not familiar with what you are talking about, I will gess
the asnwer is ... NO
can you point me (in doc) to what you are referencing?
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
Re: [IDMSVENDOR-L] cics to idms lu62 connectivity failure on CICS startup
"well, since i am not familiar with what you are talking about, I will gess
the asnwer is ... NO
can you point me (in doc) to what you are referencing?
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: IDMS Data Replication Via TCP/IP
"Now that the traffic on this topic has died down, and many folk are packing
for Vegas...
A few unsolicited thoughts on the matter of home-baked vs. store-bought
replication mechanisms.
First the disclaimer: Run Right, LLC is a consulting firm, and while we
don't sell software, we (from time to time) DO provide services to firms
that do. Be aware that we are not unbiased, and take what follows for what
it's worth. Also note that we highly value the technical qualities of the
IDMS product line, and believe that businesses have a huge investment of
great value in the business logic embedded in their legacy IDMS
applications.
That said, there are situations why replication (and even migration) makes
sense. What follows is a generic discussion, applicable to many products
available commercially. This is not a commercial for a specific product or
products (not going to discuss any), more of a Public Service Announcement,
intended to point out things you should consider in approaching any
replication project.
Jon and his team are to be congratulated for crafting a solution that works
for his shop. Another shop where I have toiled for many years (henceforth
referred to as ""Company 'A'"") did something similar, but used embedded logic
in applications and storing information in a databases rather than using DB
Procedures and Queues. At Company A there are hundreds of thousands of IDMS
record images sent down the pipe to Oracle-land daily (maybe millions).
This solution has been in place for at least 10 years; the plumbing has
changed slightly over time, but the basic architecture remains. Key to all
this discussion is ""works for his (or your) shop"". What are you trying to
do? I want to focus this discussion on: ""Offloading Reporting"".
There are many objectives a company may have in seeking a replication
strategy; offloading reporting to a cheaper platform than the mainframe
being a common one. I personally think you're going to have problems
arguing AGAINST the economics of offloading reporting cycles from the
mainframe, but that's not where THIS PARTICULAR discussion is going.
Once management has made this decision, the question becomes what is the
most effective means of replicating to a distributed platform; and aside
from functionality, performance and supportability, the issues of
time-to-implement and net CPU savings need to be part of the evaluation.
There are two major advantages commercial replication mechanisms will tend
to have over home-grown: you can put it in quicker (thus starting to save
cycles earlier), and you can save MORE cycles.
Why is this?
Most commercial solutions tend to be driven by JRNL data; home grown tend to
be constructed using triggers and re-extracting from the original database
(as in Jon's and Company A's solutions).
So what?
Well, using Jon's solution as an example (and Company A is the same), each
time an update happens that needs to be replicated, TWO MORE IDMS UPDATES
must happen to effect this change... a trigger (QUEUE record or other) is
STORED, then eventually must be OBTAINED and ERASED. This is additional
locking, updating, journaling... something that a solution based on JRNL
extracts (either thru realtime exits or JRNL post-process) doesn't have to
incur. You also won't have to concern yourself with lock contention if
you're in a high volume situation. My guess is the locking issue posed Jon
and team some serious implementation/design issues; I know it did at Company
A.
On top of the tripling of the update overhead (the original update plus two
for the triggering), you have to OBTAIN the trigger/QUEUE record and
re-OBTAINING the record(s) in question. That's two updates and two
retrievals added for every change you're trying to replicate. This added
overhead is a cost that a JRNL-based approach avoids.
The downside of trying to construct a JRNL-based homegrown solution is that
decoding JRNL data is hideously messy, and you have some real challenges
pasting things together in a meaningful manner. It will require an advanced
skill set to construct and maintain, and while you may have such expertise
available, is this how you want them spending their time?
So... the message here is IF your objective is workload offloading, esp in a
high-volume environment, there are definite advantages to commercial
solutions. You want to make sure you understand your shop's specific
objectives, so you can map them in a prioritized fashion against the various
commercial offerings vs. a DIY approach. And don't forget to factor in the
time-to-implement dimension (rolling your own, as Jon notes below, can take
some time).
End of PSA.
Don Casey
Run Right, LLC
P.S. Hi Jon! Linda says ""Hi"" too.