Re:is anybody else just fed up

[ca.portal.admin]

With the new Support Connect? Crikey!
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
WG: JDBC and IDMS - connection lost - Problem solved
"Hi David,

thanks for your fast answer.
It is the ""PARM string TASK=IDMSJSRV"" that solved the problem!
I had no PARM string at all in this pterm definition.
The IDMSJCF Applet is now running without any problems.

Yes, I am interested in the IDMS Dialect for Hibernate
and would like to test it.

Kind regards

Thomas Schmid
IDMS/MQS/SAG Services
Application Line Automotive & Manufacturing
Computing Services & Solutions (CSS)
T-Systems Enterprise Services GmbH
Emmy-Noether-Str. 17, D-76131 Karlsruhe
[phone] (Phone)
[phone] - 05 93 (Fax)
[phone] (Mobile)
E-Mail: [e-mail]
Internet: http://www.t-systems.com
Funktionsmailbox: [e-mail]


-----Ursprüngliche Nachricht-----
Von: Hearn, David E [mailTo:[e-mail]]
Gesendet: Mittwoch, 12. März 2008 16:27
An: Schmid, Thomas
Cc: Hearn, David E
Betreff: FW: JDBC and IDMS - connection lost

Hi Thomas, I just happened to see your e-mail on the IDMS-L. It sounds
like the problem is on the IDMS side of things, so I would check in the
DC Log to see if any errors are appearing. I would also check the
listener PTERM definition on your TCP/IP line. Here's an example from
one of our test systems:

D PTE TCPJSRV
Logical Term ID TCPJSRV
Physical Term ID TCPJSRV
Physical Line ID TCPIP
Physical Term Type TCP/IP List
Physical Term Model
Physical Term Status InSrv
Logical Term Status InSrv
Task code RHDCNP3J
Task mode SYSTEM
Port number 3730
Backlog 100
IP specification TCPIP31
PARM string TASK=IDMSJSRV
Number of Reads 0000000
Number of Writes 0000000
Number of Read Errors 0000000
Number of Write Errors 0000000

I recall having a similar problem to yours when we initially set this up
and didn't have the PARM string 'TASK=IDMSJSRV' specified. It also
might be that security is causing a problem. You generally want to have
RHDCNP3J set up as unsecured or PUBLIC, and the IDMSJSRV task security
set as normal. The reason for this is that the RHDCNP3J task is started
first, before the signon takes place. After this, the IDMSJSRV task
takes over.

I'm interested in your comments about Hibernate since I've recently been
working on Hibernate testing with IDMS. In fact, we have a ""development
buddy"" program for Hibernate in which we could supply you with the
initial version of the dialect as well as some documentation. Might you
be interested in this? If so, I'll send you the information.

Finally, there are some suggestions I could give you regarding setup of
C3P0 connection pools. First, however, I would concentrate on getting
things working properly with IDMSJCF.

Let me know if you have any questions. I'll be interested to hear your
response.

Dave Hearn
Software Engineer
CA
tel: [phone]
[e-mail]