ca.portal.admin

Re: CASERVER and ODBC

Discussion created by ca.portal.admin on Feb 5, 2010
Chris
=20
I assume educating the users has failed as it so often does:)
=20
Could you use the limits exit to take a look around to see if this user =
has another CCI task running and if he has kill this one (as this =
probably started first) if not up the limit and let it carry on.
=20
Cheers
Martin

_____ =20

From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Fri 05/02/2010 09:26
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: CASERVER and ODBC



We allow unlimited SQL select access to our IDMS network database on the =
Test system. Developers love it because they can use Excel and Access =
etc to verify their test results without having to write Culprits or =
special Cobol programs.

Unfortunately it is really easy with a point and click system like =
Windows to get it wrong pretty much instantly by doing a cartesian join =
for example without any where criteria and various other combinations =
which - from the PC user's point of view - is a locked up system. In =
reality the run unit on the mainframe is beavering away trying to build =
a huge result table.

PC users are used to just clicking the cross at the top right hand =
corner and then starting again. The result is multiple CCI sessions for =
a user and an enormous useless overhead on the mainframe.

I can kick them off by using Limits on the CASERVER task but some =
queries are expensive but valid. Finding the right limit for on DB Calls =
to avoid cancelling a valid task is very difficult. So I have to put the =
limits unrealistically high which means that the problem is not really =
solved.

IDMS has the CHKUSER tasks to solve this kind of problem with batch =
jobs. But with an ODBC query it is trickier. IDMS only realises via CCI =
that the physical terminal is no longer there when the query is ready to =
return rows to the user.

Does anybody have a clever trick to make IDMS realise that a Windows =
application on the other end of a CCILINE has disappeared before the =
query has finished?

Here is the kind of thing I get.=20

PM-R17.0 TIDMS11E CA, Inc. =
V126 10.036 10:18:24.68
CMD--> =
=20
CMD--> Window : 02
=
Refresh: 10
02 Transaction Detail =
i>
=
=20
Task Tskcd/ Bound Task Subschma Transaction DBMS Pages =
Pages Pages Rcrds Rcrds Frags Updat Selct Locks Bfore After=20
Number LTE Program Status Acc_Mod Status Calls Writn =
Read Reqst Reqst Curnt Stord Locks Locks Reqst Image Image=20
2 RHDCRUAL WAIT IDMSNWK7 H 25 0 =
4 5 5 0 0 1 0 6 0 0=20
3 RHDCRUAL WAIT IDMSNWKL H 2154 0 =
101 1668 1675 1591 0 1 0 1657 0 0=20
4 RHDCRUAL WAIT IDMSNWK6 A 795 0 =
95 397 717 396 0 0 1 1 0 0=20
5 RHDCRUAL WAIT IDMSSECU H 743 0 =
25 289 459 63 0 1 0 417 0 0=20
6 RHDCRUAL WAIT IDMSSECS A 1011 0 =
210 1366 3004 314 0 0 1 1 0 0=20
7 RHDCRUAL WAIT IDMSSECQ A 512K 0 =
1797 442K 564K 37210 0 0 2 2 0 0=20
8 RHDCLGSD WAIT IDMSNWK9 A 3 0 =
0 0 0 0 0 0 1 1 0 0=20
9 RHDCLGSD WAIT IDMSNWK9 A 3 0 =
0 0 0 0 0 0 1 1 0 0=20
10 RHDCLGSD WAIT IDMSNWK9 A 3 0 =
0 0 0 0 0 0 1 1 0 0=20
160643 CASERVER CAIDOD32 WAIT IDMSCATY I H 20M 0 =
726K 53M 65M 9932K 0 0 18 71M 0 0=20
164874 CASERVER CAIDOD32 WAIT IDMSCATY IBH 16M 0 =
468K 42M 51M 7829K 0 0 23 56M 0 0=20
LTECCI03 CAIDOD32 IBH 0 0 =
0 0 0 0 0 0 0 0 0 0=20
181955 CASERVER CAIDOD32 HICCUP IDMSCATY I H 11121 0 =
44686 24M 25M 9334 0 0 10 48M 0 0=20
184558 CASERVER CAIDOD32 WAIT IDMSCATY I H 74641 0 =
27803 111K 122K 44114 0 0 14 145K 0 0=20
185921 CASERVER CAIDOD32 WAIT IDMSCATY I H 196K 0 =
33074 655K 769K 203K 0 0 12 757K 0 0=20
186808 11EBBULK TKP00 WAIT PPROD H 191 6 =
28 230 239 138 0 59 30 234 10 10 =20


All those CASERVER tasks belong to the same user. He has killed 4 of =
them at the PC end and has no idea that they are still running in IDMS. =
I have to monitor manually and then call him to find out which windows =
he still has open. Almost certainly the 36 Million calls made by the =
first two tasks are a complete waste of effort for IDMS.

Any ideas would be great. On the Windows side we currently are quite =
backward. CA SERVER 5.0 is actually being used. I have CA SERVER 16.1 in =
test but I am waiting for the guys from the Windows world to roll it out =
for me - and have been for some time. Even then I will still have the =
problem. I think.
______________________________________________________________

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 =
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
Reuters Limited, a Thomson Reuters company, is a company incorporated =
under the laws of England and Wales (registered number 145516) having =
its registered office and address for service at the Thomson Reuters =
Building, 30 South Colonnade, Canary Wharf, London, E145EP, United =
Kingdom.
=20
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.
=20
??????
???
"
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: CASERVER and ODBC
"Yes. I could do that. But sometimes they have two sessions intentionally. I really need to be able to find out from within the UX20 code if the application on the end of the CCILINE is still there or not. IDMS finds out when it gets to the end and tries to return the result table:

14.27.04 JOB03278 +IDMS DC001003 V126 T593859 TASK:CASERVER PROG:CASERVER STALLED WAITING FOR PTERM PTECCI04
14.27.04 JOB03278 +IDMS DC027007 V126 T593859 TASK:CASERVER PROG:CASERVER ABENDED WITH CODE D002

I need to be able to find that out before I get to the end of the expensive useless query.

I don't think there is a flag set in the PTEDS at the time they X or Ctrl/Alt/Del out. If it was then I would expect a different Abend. Not a Stall time abend.

Chris

Outcomes