|
View previous topic :: View next topic
|
| Author |
Message |
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
Hi,
I have a JCL xxxx which is scheduled in such a way, the job will get triggerred on below conditions.
1) arrival of dataset AAA -- GDG version
2) availability of dataset BBB (in CA7 catalog) -- GDG version
At the end of the JCL, A IEBGENER step will create an empty version of both the trigger and dependent datasets. Because of this the job is going in loop. As per my understanding the IEBGENER copy step will not catalog the trigger dataset in CA7 So I am very confused why the job is going in loop. Can some one suggest me how to stop the IEBGENER step cataloging the trigger dataset to CA7.
Please let me know if I can provide any other information. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| to stop the IEBGENER step cataloging the trigger dataset to CA7 |
???
iebgener interacts just with NOBODY...
it reads a file, writes a file, according to the SYSIN specs.
nothing more nothing less
furthermore the only place where JCL <catalogs> things is in the appropriate
<system/user> catalog
... speak with Your CA7 support |
|
| Back to top |
|
|
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
Hi Enrico,
Thanks for your response. i checked with our CA7 support team, Even they are not sure about this behaviour. Even I showed them a existing prod job (running fine) which does the same copy step of trigger dataset, but still they could not find the solution. Do we have any CA7 experts in our forum who can solve my problem. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| Do we have any CA7 experts in our forum who can solve my problem. |
You should remember that replying on a forum is
on voluntary base, on our time, free of charge
no commitment for anybody to reply
no expectation to get an answer
anyway the topic as posted does not fit for a forum <solution>
too many things to investigate, too many test to run
but why in heaven not contact CA ??? |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hello,
You say that the two dataset trigger generations for the job are created at the end of the same job. So it is completely normal that the JCL gets submitted by CA7 repeatedly.
| Quote: |
| As per my understanding the IEBGENER copy step will not catalog the trigger dataset in CA7. |
I believe that this assumption is incorrect. CA7 will catalog all dataset creation activity and store it in its catalog.
To test this,
1) Issue LCTLG,DSN command and note down the latest GDG generation on CA7.
2) Run a IEBGENER step and create a +1 generation of the dataset.
3) Issue LTCLG,DSN command and note the latest GDG generation to complete the test.
You would require a slight design change to resolve the issue. |
|
| Back to top |
|
|
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
Hi Enrico.. I was really happy for your quick reply..  |
|
| Back to top |
|
|
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
Hi Vasanth,
This doubt came to me because we have a similar kind of job which is running in production. That job also creates a empty version of the trigger dataset at end of the job. But it is not going in loop. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hi,
As Enrico mentioned you could contact CA support themselves for the right solution.
Just for the sake of my curiosity, Could you please post answer to the below question in underlined.
You say that there is a similar production job which runs fine and does not catalog the +1 empty dataset on CA7.
Is that production job using IEBGENER to create the +1 generation or some other utility like IEFBR14?
I think CA7 detects dataset creation only by the SMF record corresponding to dataset-close. So the utility name will be useful to understand how things work. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Suggest you look at how everything is defined for the process that works correctly and how everything is defikned for the problem process.
From what you have posted, it sounds like it is working as advertised.
I don't understand the difference to ca7 concerning the "arrival" versus the "availability" of a dataset to trigger the job. Do any of the processes that work as you want do this also? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
I have ALWAYS seen triggered <processes> read and delete the <triggering> dataset,
NEVER creating a new one with the <same> name ( same gdg.base)
and the topic confirms my opinion
creating in the triggered <process> a new <self referencing> <trigger> dataset is just looking out for troubles |
|
| Back to top |
|
|
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
| Yes enrico I agree this is bit trouble some, but our business wants this job to be run only once (only when both the datsets are available). So we are working on this troublesome approach. As of now, to have a empty dataset at end of the job, I am deleting the current version of my two datasets based on the empty status. Designing in such a way my previous version also points to a manually created empty dataset (one time). This really solved my problem. |
|
| Back to top |
|
|
Suresh Kumar.N
New User
Joined: 16 Oct 2012
Posts: 7
Location: India
|
|
|
|
| Hi Vasanthz.. we are using IEBGENER utility.[/code] |
|
| Back to top |
|
|
|
|
