|
View previous topic :: View next topic
|
| Author |
Message |
paulkk2
New User
Joined: 11 Dec 2024
Posts: 4
Location: USA
|
|
|
|
Hello, a Few of the batch jobs failing because the files opening after the CICS regions comes up. Jobs run okay after we manually closes the file. Issue started happening after we upgraded from Mackinney batch to CICS 2.1 to 2.2. Anyone has ran into similar issue? any advice?
.IGD01007I *** DCACS000 PROD SELECT USED. ***
.IGD17101I DATA SET PROD.PM.DVOM.AGCYMST
.NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
.RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
.IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
.PROD.PM.DVOM.AGCYMST
.IDC3013I DUPLICATE DATA SET NAME
.IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEH-38
.IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 |
|
| Back to top |
|
 |
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 592
Location: London
|
|
|
|
You seem to be confused or don't understand what is going on.
If there was a 'upgrade' from 'Mackinney' batch whatever that is to CICS (was it 2.1 or 2.2, make up your mind! Bear in mind CICS is now up to ~V6.1 now), then surely it would have been analysed to see what changes might be needed for that implementation? This just sounds like you really don't understand what happened at all and should speak to your local experts to find out.
These IGD* messages have nothing to do with CICS, they are SMS messages, simply a result of trying to allocate a dataset as new but it already exists. |
|
| Back to top |
|
|
paulkk2
New User
Joined: 11 Dec 2024
Posts: 4
Location: USA
|
|
|
|
MacKinney Batch to CICS (MBC) is an utility lets you batch access and control of CICS. you can send commands from your batch jobs to your CICS regions to coordinate file access, dynamically enable or disable programs, transactions, and TDQs, launch transactions, send terminal messages, and etc...
We upgraded from 2.1 to 2.2 version |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 592
Location: London
|
|
|
|
| OK so it's now clearer what MacKinney is thanks. So if that controls CICS regions file access etc, what is the difference in your settings between 2.1 and 2.2? Maybe 2.1 was issuing some commands to CICS to close and deallocate the CICS files that your batch jobs needed to update and that hasn't been replicated into 2.2? We can only speculate really, especially as the only messages provided are SMS and IDCAMS ones and you have not put any context around those at all. Are they produced by the failing job or what? |
|
| Back to top |
|
|
paulkk2
New User
Joined: 11 Dec 2024
Posts: 4
Location: USA
|
|
|
|
| paulkk2 wrote: |
.IGD01007I *** DCACS000 PROD SELECT USED. ***
.IGD17101I DATA SET PROD.PM.DVOM.AGCYMST
.NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
.RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
.IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
.PROD.PM.DVOM.AGCYMST
.IDC3013I DUPLICATE DATA SET NAME
.IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEH-38
.IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 |
This is from a failed job. We have a batch job that opens files after the CICS regions come up. The failed job runs before the open job, which is supposed to update the file when it's closed. However, the job is failing after the upgrade because the file is open by mackinney when the region comes up, but before the open job runs. I can't seem to figure out what setting needs to be changed to fix this issue. I hope that makes sense.
The upgrade was straightforward, and I successfully completed everything outlined in the guide. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1316
Location: Vilnius, Lithuania
|
|
|
|
And we can discus this further ad nauseam...
Why the flipping 'ell don't you contact MacKinney? |
|
| Back to top |
|
|
paulkk2
New User
Joined: 11 Dec 2024
Posts: 4
Location: USA
|
|
|
|
I am about to. Just want to see if there is any quick fix |
|
| Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006
Posts: 2598
Location: Silicon Valley
|
|
|
|
I do not know anything about MacKinney...
but the error might be a situation where the data portion of a VSAM data set already exists so when you issue DEFINE VSAM, it does not work (or vicea-versa)
Sometimes that happens when you switch to a new user catalog and the data portion still remains on a volume. I suggest trying DEFINE VSAM with RECATALOG parameter. And then delete it before trying DEFINE VSAM again. |
|
| Back to top |
|
|
|
|
