Anybody remember my problem of a dataset ENQ conflict message which we
couldn't figure out? The one where an IDCAMS step with a DELETE said the
DSN was in use, but we couldn't find out who was using it? I reproduced
the problem with the following JCL:
jcl
//STEP1EXEC PGM=IDCAMS,COND=(0,NE)
On Mon, 17 Mar 2008 08:05:09 -0500, McKown, John
[EMAIL PROTECTED] wrote:
This previous Sunday's sysplex test went very well. We only have a few
problems left, and they are minor.
Good to hear.
Does that mean you backed out of sysplex when you were done testing?
If you are still running 2
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Monday, March 17, 2008 8:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DSN ENQ conflict - debugging after the fact.
(confessions of an idiot)
On Mon, 17 Mar 2008 08
We tried, and failed, to migrate from our MONOPLEX to a two system basic
sysplex yesterday. There were a number of problems. One really weird one
occurred after I had taken down the new z/OS image and done the
appropriate shutdown of it (V XCF,...,OFFLINE, reply DOWN on the
remaining system, after
, 2008 9:53 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: DSN ENQ conflict - debugging after the fact.
We tried, and failed, to migrate from our MONOPLEX to a two system basic
sysplex yesterday. There were a number of problems. One really weird one
occurred after I had taken down the new z/OS image and done
On Mon, 10 Mar 2008 08:53:10 -0500, McKown, John
[EMAIL PROTECTED] wrote:
quote
DELETE (PRIMV.PPO.XDF)
0IKJ56241I DATA SET PRIMV.PPO.XDF NOT ALLOCATED
IKJ56241I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IDC0551I ** ENTRY PRIMV.PPO.XDF NOT DELETED
0IDC0001I FUNCTION COMPLETED, HIGHEST
I think most shops have ISRDDN as it is shipped with ISPF.
Just issue TSO ISRDDN on the command line.
Then issue ENQ
You can then put in the dataset name or just look and see what is enqueued.
Lizette
quote
DELETE (PRIMV.PPO.XDF)
0IKJ56241I DATA SET PRIMV.PPO.XDF NOT ALLOCATED
Lizette Koehler wrote:
Just issue TSO ISRDDN on the command line.
These days, you simply issue the DDLIST command directly to ISPF. No TSO
command needed.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL
is
would make it easier
Jack Kelly
202-502-2390 (Office)
Mark Zelden [EMAIL PROTECTED]
Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
03/10/2008 10:34 AM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: DSN ENQ conflict
On Mon, 10 Mar 2008 08:14:45 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
Lizette Koehler wrote:
Just issue TSO ISRDDN on the command line.
These days, you simply issue the DDLIST command directly to ISPF. No TSO
command needed.
I just issue DD - but it is in my site commands as an alias
On Mon, 10 Mar 2008 11:42:57 -0400, Jack Kelly
[EMAIL PROTECTED] wrote:
The WhoHas generally checks the SYSDSN enque and if the file is enqueued
on another resource, it won't be found, eg enqueued to PDF edit( I know
that's not germane to this example) doesn't show on most WhoHas's. So a
check of
PROTECTED]
Subject: Re: DSN ENQ conflict - debugging after the fact.
To: IBM-MAIN@BAMA.UA.EDU
The WhoHas generally checks the SYSDSN enque and if the file is enqueued
on another resource, it won't be found, eg enqueued to PDF edit( I know
that's not germane to this example) doesn't show
I tried DDLIST on both my production 1.4 system and my 1.7 test lpar. It
doesn't work on either. I looked in my SITE commands in ISPF 3.9, and found
the following entry:
DDN 0 SELECT CMD(ISRDDN) NEWAPPL(DDN)
Is that the same thing that you were talking about?
Edward Jaffe
On Mon, 10 Mar 2008 12:07:36 -0600, Eric Bielefeld [EMAIL PROTECTED]
wrote:
I tried DDLIST on both my production 1.4 system and my 1.7 test lpar. It
doesn't work on either. I looked in my SITE commands in ISPF 3.9, and found
the following entry:
DDN 0 SELECT CMD(ISRDDN) NEWAPPL(DDN)
14 matches
Mail list logo
