ca.portal.admin

Re:Re: [IDMSVENDOR-L] cics to idms lu62 connectivity failure on

Discussion created by ca.portal.admin on Nov 12, 2008
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: APAR question
"In IDMS 16.0 - Service pack SP00, gen level 0401
we apply apar Ro01018 for already 4 weeks in customer test environment.
Until now there are no problems seen.


M.v.g.
Cher Adamczyk
System Programmer DB, ISM-P Mainframe Platform
T-Systems Nederland b.v.
Address: Spoorsingel 61, NL-6412 AA Heerlen (L)
P.O.Box Postbus 2814, NL-6401 DH Heerlen (L)
Phone: (+31-) 045-5769.472
Fax: (+31-) 045-5740.121
E-Mail: Cher.Adamczyk@t-systems.nl
Internet: http://www.t-systems.nl




""Hall, Dan (GE
Comm Fin)""
<Dan.Hall@GE.COM> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> APAR question


13-11-2008 20:56


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






Hello fellow IDMS'ers,
We had a problem with a user index and CA has recommended apar RO01019.
This was published back in late July. Has anyone else put this on their
systems? Any issues?

Thanks for any info you can pass on.

Dan Hall
GE Capital Solutions
Database Administrator

T 513.217.5060
E dan.hall@ge.com
www.ge.com/capitalsolutions/

Middletown, OH 45042
General Electric Capital Corporation




----------------------------------------------------------

Confidentiality statemSent: this email message may contain confidential and privileged information and is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the content of this message is prohibited. If you have received this message in error, please notify the sender by reply email and delete the material from your computer.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: APAR question
"In IDMS 16.0 - Service pack SP00, gen level 0401
we apply apar Ro01018 for already 4 weeks in customer test environment.
Until now there are no problems seen.


M.v.g.
Cher Adamczyk
System Programmer DB, ISM-P Mainframe Platform
T-Systems Nederland b.v.
Address: Spoorsingel 61, NL-6412 AA Heerlen (L)
P.O.Box Postbus 2814, NL-6401 DH Heerlen (L)
Phone: (+31-) 045-5769.472
Fax: (+31-) 045-5740.121
E-Mail: Cher.Adamczyk@t-systems.nl
Internet: http://www.t-systems.nl



=

""Hall, Dan (GE =

Comm Fin)"" =

<Dan.Hall@GE.COM> To =

Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM =

Public Discussion cc =

Forum =

<IDMS-L@LISTSERV. Subject =

IUASSN.COM> APAR question =

=

=

13-11-2008 20:56 =

=

=

Please respond to =

IDMS Public =

Discussion Forum =

<IDMS-L@LISTSERV. =

IUASSN.COM> =

=

=





Hello fellow IDMS'ers,
We had a problem with a user index and CA has recommended apar RO01019.
This was published back in late July. Has anyone else put this on their
systems? Any issues?

Thanks for any info you can pass on.

Dan Hall
GE Capital Solutions
Database Administrator

T 513.217.5060
E dan.hall@ge.com
www.ge.com/capitalsolutions/

Middletown, OH 45042
General Electric Capital Corporation




----------------------------------------------------------

Confidentiality statemSent: this email message may contain confidential and =
privileged information and is intended to be for the use of the individual =
or entity named above. If you are not the intended recipient, be aware that=
any disclosure, copying, distribution, or use of the content of this messa=
ge is prohibited. If you have received this message in error, please notify=
the sender by reply email and delete the material from your computer.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
umod for WTOEXIT only (not embedded in a startup module)
"wow - this release 16 thingy might really catch on

I am very interested in specifying all (former RHDCPARM) attributes on the
EXEC care, executing IDMSDC
one question - if I specify WTO=, it is expecting a assembled/linked
WTOEXIT load module. The onle UMOD sample I could find (UMODWTO) is one to
build a startup module with an embedded WTOEXIT)

(and you know how I am about trying to get EVERYTHING under SMP/E control

has anyone build a USERMOD to control the assemble and linkedit of the
WTOEXIT only? - if so - can you share

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
umod for WTOEXIT only (not embedded in a startup module)
"wow - this release 16 thingy might really catch on

I am very interested in specifying all (former RHDCPARM) attributes on the
EXEC care, executing IDMSDC
one question - if I specify WTO=, it is expecting a assembled/linked
WTOEXIT load module. The onle UMOD sample I could find (UMODWTO) is one to
build a startup module with an embedded WTOEXIT)

(and you know how I am about trying to get EVERYTHING under SMP/E control

has anyone build a USERMOD to control the assemble and linkedit of the
WTOEXIT only? - if so - can you share

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: umod for WTOEXIT only (not embedded in a startup module)
"I dont think you need to bring the WTO under SMPE control because CA is=0D=
=0Anot going to write maintenance for it=2E =0D=0A=0D=0A=0D=0ALutz Petzold=
=0D=0ATDM UDB/IDMS Support=0D=0A401-782-2265=0D=0APage 860 366 0865 or Tela=
lert=0D=0A =0D=0A =0D=0A=0D=0AThis e-mail may contain confidential or privi=
leged information=2E If=0Ayou think you have received this e-mail in error,=
please advise the=0Asender by reply e-mail and then delete this e-mail imm=
ediately=2E=0AThank you=2E Aetna
"
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: umod for WTOEXIT only (not embedded in a startup module)
"I dont think you need to bring the WTO under SMPE control because CA is
not going to write maintenance for it.


Lutz Petzold
TDM UDB/IDMS Support
401-782-2265
Page 860 366 0865 or Telalert



This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
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
"I wish to remark on Don's comments:

1. It is a true statement about the amount of updates to IDMS. Our IDMS
journaling almost doubled because of the additional update activity with our
solution.
2. It is a true statement that we had significant locking issues when we
stress-tested prior to going to production. We artificially created
ridiculous volumes to give it the worst-case shakedown. The initial
results were very discouraging and it took a month or two to re-design
around the major problems. We now purposefully single-thread many aspects
of this just to avoid such problems. It took
another couple years to fine-tune the process.
3. Fortunately, we can be regarded as a small-volume online shop. We have
under 200,000 online transactions per day. However, about 20% of these are
queue-initiated tasks. Some process
thousands of queue records in one clip. A high-volume shop could face
potential failure using our approach.
4. Our homegrown pre-design was not without some heated arguments both pro
and con. One of our technical managers, who pushed for a homegrown
solution, had a gift for articulation. He could sell
refrigerators to Eskimos and was able to convince all the right people
to move forward.
5. Whether right or wrong or smart or dumb, we made a decision to move
forward with a homegrown solution and we didn't look back or have any
regrets.
6. Today, the use of this system has gone beyond our original projections,
but still seems to be running steady and true. Everybody said: ""Hey look at
this.... let's make use of this for our new system"".
7. Besides the homegrown message-exchange, we have a number of CICS socket
programs that talk realtime to IDMS from .NET client programs. They are
CICS because IDMS didn't have a sockets
API and we wrote most of this stuff before it finally became available
in Rel. 16. There is a campaign for 2009 to convert all of these programs
to the IDMS sockets API and, convert to IDMS-DC
(which we have already) instead of UCFCICS, and get rid of CICS. Our
last commercial CICS application was retired last year.
8. All of this came about because we are moving off the mainframe (like
everybody else). This has helped us tremendously during the transition from
old to new applications. Mostly because our systems
are not neatly segregated. There is quite a bit of overlap with pieces
we can't convert right away. So, as we convert, we are actually running a
mix of old and new.

Thanks.
Jon Gocher



----- Original Message -----
From: ""Don Casey"" <donjcasey@COMCAST.NET>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Wednesday, November 12, 2008 11:26 PM
Subject: 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.

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
Behalf Of Jon Gocher
Sent: Monday, November 10, 2008 5:14 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: IDMS Data Replication Via TCP/IP

Steve -

It's our own software, ....no purchased products.
It's customized for our internal use.

The SUBSCRIBE side works using WAIT / POST.
We don't read the next message off the queue until the task that is
attached
to process the message completes.
We single-thread message processing so we don't flood the system and have
massive deadlocking problems.
On simple messages, we may process several dozen per second.
On more complex messages, we may process 1 message every couple of
seconds.
All-in-all, databases are synchronized within about 1 to 10 seconds of one
another.
This is just fine for our purposes.

Jon Gocher


----- Original Message -----
From: ""Harmeson, Steve (Newport News)"" <Steve.Harmeson@NGC.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, November 10, 2008 10:02 AM
Subject: Re: IDMS Data Replication Via TCP/IP


Are you using WebSphere MQSeries software to do this?

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Jon Gocher
Sent: Sunday, November 09, 2008 2:06 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: IDMS Data Replication Via TCP/IP

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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: IDMS Data Replication Via TCP/IP
"I wish to remark on Don's comments:

1. It is a true statement about the amount of updates to IDMS. Our IDMS
journaling almost doubled because of the additional update activity with our
solution.
2. It is a true statement that we had significant locking issues when we
stress-tested prior to going to production. We artificially created
ridiculous volumes to give it the worst-case shakedown. The initial
results were very discouraging and it took a month or two to re-design
around the major problems. We now purposefully single-thread many aspects
of this just to avoid such problems. It took
another couple years to fine-tune the process.
3. Fortunately, we can be regarded as a small-volume online shop. We have
under 200,000 online transactions per day. However, about 20% of these are
queue-initiated tasks. Some process
thousands of queue records in one clip. A high-volume shop could face
potential failure using our approach.
4. Our homegrown pre-design was not without some heated arguments both pro
and con. One of our technical managers, who pushed for a homegrown
solution, had a gift for articulation. He could sell
refrigerators to Eskimos and was able to convince all the right people
to move forward.
5. Whether right or wrong or smart or dumb, we made a decision to move
forward with a homegrown solution and we didn't look back or have any
regrets.
6. Today, the use of this system has gone beyond our original projections,
but still seems to be running steady and true. Everybody said: ""Hey look at
this.... let's make use of this for our new system"".
7. Besides the homegrown message-exchange, we have a number of CICS socket
programs that talk realtime to IDMS from .NET client programs. They are
CICS because IDMS didn't have a sockets
API and we wrote most of this stuff before it finally became available
in Rel. 16. There is a campaign for 2009 to convert all of these programs
to the IDMS sockets API and, convert to IDMS-DC
(which we have already) instead of UCFCICS, and get rid of CICS. Our
last commercial CICS application was retired last year.
8. All of this came about because we are moving off the mainframe (like
everybody else). This has helped us tremendously during the transition from
old to new applications. Mostly because our systems
are not neatly segregated. There is quite a bit of overlap with pieces
we can't convert right away. So, as we convert, we are actually running a
mix of old and new.

Thanks.
Jon Gocher



----- Original Message -----
From: ""Don Casey"" <donjcasey@COMCAST.NET>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Wednesday, November 12, 2008 11:26 PM
Subject: 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.

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
Behalf Of Jon Gocher
Sent: Monday, November 10, 2008 5:14 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: IDMS Data Replication Via TCP/IP

Steve -

It's our own software, ....no purchased products.
It's customized for our internal use.

The SUBSCRIBE side works using WAIT / POST.
We don't read the next message off the queue until the task that is
attached
to process the message completes.
We single-thread message processing so we don't flood the system and have
massive deadlocking problems.
On simple messages, we may process several dozen per second.
On more complex messages, we may process 1 message every couple of
seconds.
All-in-all, databases are synchronized within about 1 to 10 seconds of one
another.
This is just fine for our purposes.

Jon Gocher


----- Original Message -----
From: ""Harmeson, Steve (Newport News)"" <Steve.Harmeson@NGC.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, November 10, 2008 10:02 AM
Subject: Re: IDMS Data Replication Via TCP/IP


Are you using WebSphere MQSeries software to do this?

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Jon Gocher
Sent: Sunday, November 09, 2008 2:06 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: IDMS Data Replication Via TCP/IP

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
Processing IDMS User-Defined Setname in SQL Server Linked Server
"The following SQL statement works in OCF where ""CSC-CMCSEV"" is a
user-defined setname. The owner of the set is a Calc record with Calckey
""CSC_CASE_ID"".

SELECT *
FROM NSQLCOURT.""CASE-C"" C, NSQLCOURT.""CRIM-CASE-EVENT"" B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID =3D 16

OCF 16.0 IDMS PAGE 1 LINE 1 DICT=3DQALDICT 1/86
SYST0005
SELECT *
FROM NSQLCOURT.""CASE-C"" C, NSQLCOURT.""CRIM-CASE-EVENT"" B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID =3D 16
*+
*+  CSC_CASE_ID  CMCSEV_CASE_EVENT_SEQ_NO  CMCSEV_CASE_EVENT_VERSION_NO
*+  -----------  ------------------------  ----------------------------
*+           16                         1                             1
*+
*+ CMCSEV_OCOME_SORT_SEQ_ID  CMCSEV_SCHED_HEARING_DTE
*+ ------------------------  ------------------------
*+                        1                  20080618


I have defined an SQL Server Linked Server using the ODBC provider:
Microsoft OLE DB Provider For ODBC Drivers and
accessing a Data Source created by the CA-IDMS ODBC Administration tool
as a ""System""-type ODBC Data Source using CA-IDMS ODBC driver. =20


The following SQL statement works in SQL Server Linked Server but
returns too many record:

SELECT *
FROM [IDMS_DEV]..[NSQLCOURT].[CASE-C] C,
[IDMS_DEV]..[NSQLCOURT].[CRIM-CASE-EVENT] B
WHERE C.CSC_CASE_ID =3D 16;

The following SQL statement gives me an error as expected since the
setname ""CSC-CMCSEV"" is not recognized by SQL Server Linked Server.

SELECT *
FROM [IDMS_DEV]..[NSQLCOURT].[CASE-C] C,
[IDMS_DEV]..[NSQLCOURT].[CRIM-CASE-EVENT] B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID =3D 16;

Msg 4145, Level 15, State 1, Line 4
An expression of non-boolean type specified in a context where a
condition is expected, near 'AND'.

I am trying to investigate if SQL Server support SQL PASSTHRU option
that does not edit the SQL Syntax and hence allow the setname to
passthru.
I can't find any SQL Server Linked Server option that touches on SQL
PASSTHRU

Does anyone know how to process setname in SQL Server Linked Serve?=20

Regards,
Paul Mak=20
Database Administrator - IDMS

EDS, an HP company

Applications Services, Data Engineering Capability - Sydney
Level 3, 36-46 George Street,=20
Burwood, NSW 2134, AUSTRALIA

Tel: +61 2 90125434
Fax: +61 2 90126612
Mobile: +61 419 398 116
E-mail: paul.mak@eds.com <mailTo:alex.leeflang@eds.com>=20

We deliver on our commitments so you can deliver on yours.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Processing IDMS User-Defined Setname in SQL Server Linked Server
"The following SQL statement works in OCF where ""CSC-CMCSEV"" is a
user-defined setname. The owner of the set is a Calc record with Calckey
""CSC_CASE_ID"".

SELECT *
FROM NSQLCOURT.""CASE-C"" C, NSQLCOURT.""CRIM-CASE-EVENT"" B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID = 16

OCF 16.0 IDMS PAGE 1 LINE 1 DICT=QALDICT 1/86
SYST0005
SELECT *
FROM NSQLCOURT.""CASE-C"" C, NSQLCOURT.""CRIM-CASE-EVENT"" B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID = 16
*+
*+  CSC_CASE_ID  CMCSEV_CASE_EVENT_SEQ_NO  CMCSEV_CASE_EVENT_VERSION_NO
*+  -----------  ------------------------  ----------------------------
*+           16                         1                             1
*+
*+ CMCSEV_OCOME_SORT_SEQ_ID  CMCSEV_SCHED_HEARING_DTE
*+ ------------------------  ------------------------
*+                        1                  20080618


I have defined an SQL Server Linked Server using the ODBC provider:
Microsoft OLE DB Provider For ODBC Drivers and
accessing a Data Source created by the CA-IDMS ODBC Administration tool
as a ""System""-type ODBC Data Source using CA-IDMS ODBC driver.


The following SQL statement works in SQL Server Linked Server but
returns too many record:

SELECT *
FROM [IDMS_DEV]..[NSQLCOURT].[CASE-C] C,
[IDMS_DEV]..[NSQLCOURT].[CRIM-CASE-EVENT] B
WHERE C.CSC_CASE_ID = 16;

The following SQL statement gives me an error as expected since the
setname ""CSC-CMCSEV"" is not recognized by SQL Server Linked Server.

SELECT *
FROM [IDMS_DEV]..[NSQLCOURT].[CASE-C] C,
[IDMS_DEV]..[NSQLCOURT].[CRIM-CASE-EVENT] B
WHERE ""CSC-CMCSEV""
AND C.CSC_CASE_ID = 16;

Msg 4145, Level 15, State 1, Line 4
An expression of non-boolean type specified in a context where a
condition is expected, near 'AND'.

I am trying to investigate if SQL Server support SQL PASSTHRU option
that does not edit the SQL Syntax and hence allow the setname to
passthru.
I can't find any SQL Server Linked Server option that touches on SQL
PASSTHRU

Does anyone know how to process setname in SQL Server Linked Serve?

Regards,
Paul Mak
Database Administrator - IDMS

EDS, an HP company

Applications Services, Data Engineering Capability - Sydney
Level 3, 36-46 George Street,
Burwood, NSW 2134, AUSTRALIA

Tel: +61 2 90125434
Fax: +61 2 90126612
Mobile: +61 419 398 116
E-mail: paul.mak@eds.com <mailTo:alex.leeflang@eds.com>

We deliver on our commitments so you can deliver on yours.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Processing IDMS User-Defined Setname in SQL Server Linked Server
"Paul,
You can create a view in IDMS SQL catalog that encapsulates the set name. =
Then the SQL Server Linked Server won't even need to know about it. Exampl=
e:

CREATE VIEW VIEWSCHM.CSC_CMCSEV_VIEW =20
AS=20
SELECT *
FROM NSQLCOURT.""CASE-C"" C, NSQLCOURT.""CRIM-CASE-EVENT"" B
WHERE ""CSC-CMCSEV""=20
WITH CHECK OPTION
;=20

Then you would code your select as follows:=20

SELECT *=20
FROM VIEWSCHM.CSC_CMCSEV_VIEW
WHERE CSC_CASE_ID =3D 16
=20

Outcomes