ca.portal.admin

A Couple of Coupling Questions

Discussion created by ca.portal.admin on Oct 12, 2005
Okay all of you, git yer minds outa the gutter.....

I'm working on something new to me. SYSPLEX wasn't around when I was a
Sysprog (creak), and therefore I have never had the priviledge of
playing with it. We want to test SHARED CACHE to clean up our dirty
reads in our inquiry only CV's. So I thought I would come to the ""list""
for advice and assistance.

From what I gather from the IBM manuals, I need to define a CFRM policy
dataset, create a policy within this dataset (the shared cache), then
define the CFRM to the SYSPLEX. Am I missing anything? CA has
graciously forwarded a copy of their ""policy"" definition (1 line) to use
as an example. But I think there is ALOT more to it than this (grin).

We are running ZOS 1.4 and have the SYSPLEX Coupling Facility policy
dataset defined, since it is required to use WLM. But WLM doesn't
require a CFRM policy or dataset, and therefore, we have NO CFRM dataset
defined. This will have to be built from scratch, and I need to take
care that the CFRM policy dataset definition in the SYSPLEX doesn't
interfere with the WLM (I think).

Does anyone have any samples of their CFRM definition they could share?
How do I go about defining the CFRM to the SYSPLEX?

Hints, suggestions, samples, warnings and ""Hi, How are ya?""s are always
welcome.

BTW: Since our implementation of 16.2 and HPSP (and the application of
the ADSOSTAE Hyper APAR), we have not had a single (no, not ONE) problem
with the CVs (over a month now). THAT'S why I have time to play with
SHARED CACHE! (more grins) I truly believe this is the best release of
IDMS that has ever been distributed (and I've been around since 5.5).

And oh yes (for inquiring minds with need to know), married life is
GREAT! I don't know why I didn't do this sooner.......(more smiles).

The Luckiest Guy In The World,
Rikki Kirschner
(517) 347-5772



--------------------------------------
Dexia Bank disclaimer :
http://www.dexia.be/maildisclaimer.htm
--------------------------------------



"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Problem with reflection
"Hi All,

One of our IDMS-customers is facing the following problem (since a couple of
years, but now being able to reproduce with simplified application).
They are using IDMS 16.0 running on z/OS, mainly ADS-COBOL II programs.
Their PCs are using an emulator called Reflection.
What happens sometimes is the following :
An application consisting of several dialogs/programs with a number of
successive maps. Terminal operators who know the map flow very well, are
doing data entry. Because they know the application very well, data entry is
done very quickly, i.e. if they need to enter data on the 5th screen of the
application, they hit ENTER very quickly and start typing the data even before
the involved map display is finished. They have noticed that in some
cases, related with this 'high speed' data entry, the entered data are placed
into the wrong map field, causing incorrect data being transmitted.
The fields in which the data are set are even protected. Not sure dough if that
mapfield in which the data are placed is the map on which they need
to enter the data or a previous one (f.e. the fourth out of five maps to
display), but anyway, the data are dropped in the wrong mapfield.

They have modified their application to avoid that these wrong data are
forwarded to the database, but since they are not sure what causes the
problem, they don't feel very comfortable with it.

They are struggling with this problem for a long time, but now they were able to
reproduce this using a simplified application.
From the datastreams they've captured, they could see that this wrong data entry
happened before the datastream entered the mainframe, so IDMS is not
in stake here, but we opened the issue to ask you if we have heard similar
stories from other customers.


TIA

Jean Hauben
Sr. System Programmer
T-Systems
Phone: +31-45-5769462
E-Mail: jean.hauben@T-Systems.nl

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Verifying an IDMS Install
"I do like most of the other resonders do. With 1 DBA system comming up
with the new release first, then move to test, qa, mirror, training, and
then production. 3.5 million transactions/first shift (8:30-5)/day is a
bit much to rush into things.

One additional step that is always part of my/our migration is testing
the recovery process. Both the automatic rollback from an aborted
program, automatic rollback from an aborted cv, and manual rollback of a
completed task.

After earlier problems with journaling (changes in structure years ago)
this is a step I never bypass.

By the way, we went to 16.2 in July with minor problems mostly induced
by multitasking (and solved by CA.)

Dick

Richard Pierce
DBA - State of Massachusets Registry of Motor Vehicles
richard.pierce@state.ma.us

>
Date: Tue, 11 Oct 2005 22:18:57 -0400
From: ""Jon R. Gocher"" <jgocher@FRONTIERNET.NET>
Subject: Re: Verifying an IDMS Install

Ed's list is a good start, and give or take a few items, that's what I do.
I also exercise whatever online applications I know how to work myself,
which admittedly, is very limited.
I also run one or two batch jobs to make sure the SVC is working.
I signon through UCFCICS and UCFTSO to make sure that is working.
I exercise one or two CICS transactions that access IDMS through IDMSINTL to
make sure that is working.
I also compile some batch and IDMS-DC programs and dialogs on 16.0 and
migrate and run on the back-level release to make sure that works.
We have Intertest, so I make sure that works, too.

We have several test systems, so we start with the least-used,
least-impactive system first, with the expectation to developers that you
can expect to encounter problems. From there, we don't move to the next
test system until the issues we find are resolved.
When we finally move to the last test system.... the highest-use system,
that's when we do our detailed certification shakedown testing.

If you do what Ed suggests and take a few of my thoughts, I think you, as a
DBA, have acted responsibly and thoroughly enough.
Other than this, you have to rely on others who really know the applications
inside and out.

Thanks.
Jon Gocher


----- Original Message -----
From: ""EDWARD TIMM"" <ETIMM@SALLIEMAE.COM>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Monday, October 10, 2005 4:01 PM
Subject: Re: Verifying an IDMS Install



Here are STEP(s) I use to verify a 1) Everything from SMP is copied to
my RUN-TIME LOADLIB(s) and 2) Verify the CV is working, So far it has
meant approval with my management and the auditors.

See attachment in TXT.

Edward A. Timm
Sallie Mae, Senior Database Analyst
ETIMM@salliemae.com
(317) 596-1182
Fax (317) 595-1494


Joe.Lupico@AIG.COM 10/10/2005 02:22:27 PM >>>

Jon,
Thanks for the reply. However, this assumes that you have the
help/aid of
others in testing the software, and can do that testing in a test
environment. What would you do if you had to verify the software was
good
BEFORE putting it in test and allowing access to the development
community?
That's the question I will be asked - How do I (as the installer,
absent
of any other help) verify an install?

Joe Lupico
IDMS System Support
""Our World is a Happy World""


-----Original Message-----
From: IDMS Public Discussion Forum
[mailTo:IDMS-L@LISTSERV.IUASSN.COM]On
Behalf Of Jon R. Gocher
Sent: Monday, October 10, 2005 2:21 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: Verifying an IDMS Install


Joe -

I used to think that casual testing in a test or sandbox environment
for a
period of 3 to 6 months was all that was needed.
I no longer believe that.

If your IDMS regions are large in terms of transaction volumes and in
the
number of applications they run, then
the best plans I have seen are those that exercise every online and
batch
component in your test environments prior to moving to production.
The testing is done using scripts prepared by each functional
applications
development department.

This level of testing is especially necessary if you're running a lot
of
assembler custom-code or have applications using SNA.

You don't necessarily have to get end-users get involved as long as
your
development staff knows the applications inside and out.

Whatever test plan you used for Y2K is the level of effort you should
go
through with a new release of IDMS software.

We found a handful of issues this way with 16.0 - SP2 and were glad we
went
through this kind of effort.
Also, you have the comfort level and confidence that all bases were
covered
when it comes time to switch on production.

A backout plan is always a requirement, but we had a lot riding on
getting
the release in on our scheduled date.
A backout was only going to be a desparate last resort.

Thanks.
Jon Gocher

This E-Mail has been scanned for viruses.



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

End of IDMS-L Digest - 11 Oct 2005 to 12 Oct 2005 (#2005-192)
*************************************************************



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 10/7/2005

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Release 16.0 SP2 &Screen Scrappers
"Hello All:

Anybody have any issues with screen scrappers in IDMS Release 16.0 SP2?

I already know that the ENTER NEXT TASK CODE message has changed.

Bill Allen

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"Hello Margaret:

My client is running everything, ADSO, DC-COBOL Online programs and CICS
Programs that issue data base requests.

Bill Allen

In a message dated 10/16/2005 9:46:32 P.M. Eastern Daylight Time,
marg@DIVAPROGRAMMER.COM writes:

Bill,
Are you running ADSO?
Margaret
-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Friday, October 14, 2005 10:32 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Dead locking Information

Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers or CA
World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the CA
World 2004 Presentations.

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"Bill,
Are you running ADSO?
Margaret


-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Friday, October 14, 2005 10:32 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Dead locking Information

Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers or CA
World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the CA
World 2004 Presentations.

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Dead locking Information
"Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers or CA
World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the CA
World 2004 Presentations.

Bill Allen

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"Bill:

I have a hard copy of ""UNDERSTANDING DBKEY DEADLOCKS"" presented at User
Week '86, presented and written by Don Casey - Cullinet Software.
You're welcome to it, if you copy and return.

Tim Gortner


----- Original message -----
From: ""Bill Allen"" <ARCHCONB@AOL.COM>
To: IDMS-L@LISTSERV.IUASSN.COM
Date: Sat, 15 Oct 2005 01:32:22 EDT
Subject: Dead locking Information

Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers or
CA
World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the
CA
World 2004 Presentations.

Bill Allen

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"Hello Everyone:

It turns out that this is more a perception and transaction scheduling issue
than a real dead locking problem. My client processed 3.6 Millions tasks and
out of that had a total of 260 dead locks, that is approximately one tenth
of one percent.

That is a very low number, I would like to hear what others are
experiencing.

Now to the cause, some PC jockey wrote a macro and pumped the same
transactions into the CV for over two hours straight, the dead locks were the same
task code, different run units, all dead locking on each other.

I still would like to receive as much information as I can to send to the
application development staff.

Bill Allen

In a message dated 10/17/2005 2:29:46 P.M. Eastern Daylight Time,
dan.l.miley@LMCO.COM writes:

I am not sure that I would agree that most deadlocks occur
because of ADS/O retrieval locking. I would suggest that Bill analyze
the CV logs to find determine which programs are deadlocking the most
and on what records. A point to remember about the dbkey in the log, is
that the dbkey reported in the log is in horizontal hex format
(ppppppll, page and line, assuming a radix of 8).

Then after proper analysis, attention can be paid to the
programs involved. One area that usually causes a lot of problems are
OOAK records, where a next key is retrieved. We eliminated most of the
deadlocks on these types of records by using a small sub-program as a
separate run-unit, that did an OBTAIN KEEP EXCLUSIVE, updated the
record, FINISHED, and returned the next key to the caller. Another
deadlock avoidance methodology would be to at retry logic to troublesome
programs (remember that currencies must be restored and the run unit
rebound and readied).

Here some other pointers:

Situations which Encourage Deadlocks
------------------------------------
1. Holding many resources
a. Batch programs without commit logic
b. Online ""hogs""

2. Holding resources too long
a. Conversational programs
b. I/O Intensive applications

3. Holding scarce resources
a. OOAK (One of a Kind) Records
b. FOAK (Few of a Kind) Records
c. Holding Resources Unnecessarily
d. Unnecessary IDMS calls

Avoiding Deadlocks
------------------

1. In batch programs, use commit logic as instructed.

2. In online programs:

a. Code efficiently as possible.
b. Avoid conversational mode (applicable only for DC COBOL).
c. Minimize I/O by saving data in working storage or at least
save DBKey's.
d. Don't use Entry Point records and walk long sets (use CALC or
INDEX keys if possible).
e. Do update towards end of program (records won't be held as long).
f. Don't do unnecessary OBTAINS when FINDs will do.
g. Don't do FIND CURRENT if you don't have to -- learn how currency
works!
h. Walk sets intelligently! If the data is most likely at the end
of the set, walk the set backwards using OBTAIN PRIOR.

Dan Miley
Lockeed Martin

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
"I would agree that ADSO Retrieval Locking is a much more troublesome
issue that we realize . . . I should say, than I realized before
embarking on this last tuning effort: they CAN cause deadlocks and
waits, so it's not a simple matter of making sure that an Update Dialog
Readies areas-which-it-does-not-update in Retrieval mode, especially in
a high-transaction-volume system.

I am attaching a Custom SMF report we have been using to identify the
top candidates for tuning. SMF data lumps all types of locks intogether
so it could be argued that for online tasks, this report is misleading.
On the other hand, if one takes the time to specify Retrieval Locks Off
where possible, that stats will show improvement when the change is
made, and the stats will properly reflect an improved environment. . .

(LISTLOG# preformats some shared data, LISTLOCK produces the report)

dem

Outcomes