question on strange incident using Ditto/FS

[Michael Rosinger]

List,

For all those who have Ditto/FS -- I have a question for you. Yesterday,
we had a strange incident involving Ditto/FS. One of our programmers had
started a Ditto/FS session from production CICS logged on as XXXX. Ditto
started a batch job in dynamic class Y1 as DITEXXXX. Then, the same user
started a second Ditto/FS - this time from our *test* CICS. He was
logged in to the test CICS also as XXXX - same user id as in production.
He then started a second Ditto/FS session from test CICS. Ditto started
a second batch job in Y2 as DITEXXXX.

Some time later, I noticed that the system had become sluggish. I saw
that the Ditto job running in Y2 was gobbling up CPU without ceasing. I
thought something was amiss, so I questioned the user. They hadn't
realized what they had done. They no longer had the session to the test
CICS and couldn't remember when they closed it.

It was clear that the 2nd Ditto job had become orphaned from its' CICS
transaction. I had to cancel the job. It must have been looping.

My question is this: is there any known limitation that would prevent a
2 Ditto/FS jobs with the same name, running in different partitions
against different CICS regions? Should it have worked or is there a
problem that I should pursue with IBM?

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Kevin Corkery]

There is no requirement for unique job names in VSE, you'll need another operating system to enforce that :-) Also, the user-id only needs to be unique within a CICS not between systems (huummm, a WAVV requirement?). I've seen the looping before and it's not due to the "abandoning" of the session, it's ususally do to a problem within a VSAM file being browsed (bad sequence set chaining). Most likely you programmer got tired of wainting for DITTO to respond and just disconnected his/her telnet session.

--
Kevin Corkery
Independent Consultant
Voorhees, New Jersey

-------------- Original message --------------

Post by Michael Rosinger
List,
For all those who have Ditto/FS -- I have a question for you. Yesterday,
we had a strange incident involving Ditto/FS. One of our programmers had
started a Ditto/FS session from production CICS logged on as XXXX. Ditto
started a batch job in dynamic class Y1 as DITEXXXX. Then, the same user
started a second Ditto/FS - this time from our *test* CICS. He was
logged in to the test CICS also as XXXX - same user id as in production.
He then started a second Ditto/FS session from test CICS. Ditto started
a second batch job in Y2 as DITEXXXX.
Some time later, I noticed that the system had become sluggish. I saw
that the Ditto job running in Y2 was gobbling up CPU without ceasing. I
thought something was amiss, so I questioned the user. They hadn't
realized what they had done. They no longer had the session to the test
CICS and couldn't remember when they closed it.
It was clear that the 2nd Ditto job had become orphaned from its' CICS
transaction. I had to cancel the job. It must have been looping.
My question is this: is there any known limitation that would prevent a
2 Ditto/FS jobs with the same name, running in different partitions
against different CICS regions? Should it have worked or is there a
problem that I should pursue with IBM?
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Frank M. Ramaekers]

I don't really see why there should be any confusion. If you look at the running DITTO job in your batch partition, you'll see something like:

* $$ LST CLASS=A,DISP=L
* $$ PUN DISP=L
// JOB DITEDP41 DITTO/FS
// LIBDEF *,SEARCH=AISYS.TEST,CATALOG=PRD2.CONFIG
// OPTION NODUMP,NOSYSDUMP
// EXEC DITTO,PARM='XPCCID=DITE0076,A,L, '
/&

See the PARM= has a unique XPCCID (for XPCC) and shouldn't get confused.

Frank M. Ramaekers Jr.
Systems Programmer; MCP, MCP+I, MCSE & RHCE
American Income Life Insurance Company
Phone: [phone] Fax: [phone]

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of Kevin Corkery
Sent: Tuesday, March 15, 2005 10:55 AM
To: VSE Discussion List
Subject: Re: question on strange incident using Ditto/FS

There is no requirement for unique job names in VSE, you'll need another operating system to enforce that :-) Also, the user-id only needs to be unique within a CICS not between systems (huummm, a WAVV requirement?). I've seen the looping before and it's not due to the "abandoning" of the session, it's ususally do to a problem within a VSAM file being browsed (bad sequence set chaining). Most likely you programmer got tired of wainting for DITTO to respond and just disconnected his/her telnet session.

--
Kevin Corkery
Independent Consultant
Voorhees, New Jersey

-------------- Original message --------------

Post by Michael Rosinger
List,
For all those who have Ditto/FS -- I have a question for you. Yesterday,
we had a strange incident involving Ditto/FS. One of our programmers had
started a Ditto/FS session from production CICS logged on as XXXX. Ditto
started a batch job in dynamic class Y1 as DITEXXXX. Then, the same user
started a second Ditto/FS - this time from our *test* CICS. He was
logged in to the test CICS also as XXXX - same user id as in production.
He then started a second Ditto/FS session from test CICS. Ditto started
a second batch job in Y2 as DITEXXXX.
Some time later, I noticed that the system had become sluggish. I saw
that the Ditto job running in Y2 was gobbling up CPU without ceasing. I
thought something was amiss, so I ! questioned the user. They hadn't
realized what they had done. They no longer had the session to the test
CICS and couldn't remember when they closed it.
It was clear that the 2nd Ditto job had become orphaned from its' CICS
transaction. I had to cancel the job. It must have been looping.
My question is this: is there any known limitation that would prevent a
2 Ditto/FS jobs with the same name, running in different partitions
against different CICS regions? Should it have worked or is there a
problem that I should pursue with IBM?
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

----------------------------------------
This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at ***@ailife.com.

[g***@escape.net.au]

Michael,

The Ditto/VSE change team have told me :

"We will be introducing a change that will almost eliminate completely the
chances of duplicate XPCC IDs from being used. This change will be rolled
into the PTF for APAR PK02485."

Regards,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth,WA

[Martin]

Garry,

Considering your posting (citing that DITTO change-team will do
something about XPCC-ids):

Does that mean that the change-team does see a slight chance of dupes
and that this dupe might have caused the loop/delay/CPU-hog Michael saw?

Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de

[garry hasler]

Martin,

Post by Martin
Considering your posting (citing that DITTO change-team will do
Does that mean that the change-team does see a slight chance of dupes
and that this dupe might have caused the loop/delay/CPU-hog Michael saw?

Yes. About a 1 in 10,000 chance. But it can happen and they want to
reduce the chances of it happening even further.

Cheers,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth,WA

Post by Martin
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de

[Michael Rosinger]

Garry,

Thank you for the follow up on this. At least I know I wasn't imagining
things. I believe what you described is what indeed happened on our system. I
suppose we just got *lucky* and hit that 1 in 10,000 chance ;-)

Post by garry hasler
Martin,

Post by Martin
Considering your posting (citing that DITTO change-team will do
Does that mean that the change-team does see a slight chance of dupes
and that this dupe might have caused the loop/delay/CPU-hog Michael saw?

Yes. About a 1 in 10,000 chance. But it can happen and they want to
reduce the chances of it happening even further.
Cheers,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth,WA

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com