Discussion created by ca.portal.admin on Feb 5, 2010

I assume educating the users has failed as it so often does:)

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.



From: IDMS Public Discussion Forum on behalf of Trayler, Christopher
Sent: Fri 05/02/2010 09:26
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.

PM-R17.0 TIDMS11E CA, Inc. V126 10.036 10:18:24.68
CMD--> Window : 02
Refresh: 10
02 Transaction Detail i>

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

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ürich, Switzerland
Telephone +41 (0)58 887 4332, Fax +41 (0)58 887 4969 <>


*****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.

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.

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


"No. Single user ids is a security requirement. This is a Swiss Bank for =
heaven's sake. They like to have people pinned down pretty secure.=20

What I need is to be able to query the Physical Terminal from the exit =
20 code. But without disturbing anything if the PTE is actually valid. I =
could try blasting it with a #SENDMSG but I don't know how well that =
would be received by a Physical Terminal which is actually an ODBC =
client. I shall certainly try it though and see what happens.

I was hoping someone else had solved the problem. I have already =
enhanced my Exit 20 so that it sends an abusive E-Mail to the user =
asking if he has cancelled a session but that rather depends on him =
looking in his Mail. Half the time the guys have just gone home and =
turned their PC off.

Anyway. I am about to leave for a 2 week break. If anybody has an idea I =
would like to hear it on my return.

Chris =20