|
View previous topic :: View next topic
|
| Author |
Message |
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hello,
We have defined a GDG dataset trigger on CA7 for a job, the trigger GDG(+1) is created by a FTP put.
During certain occasions, there is a difference between CA7 catalog and the actual catalog. So the job gets triggered eventhough the dataset is not actually present.
The LCTLG,DSN=WELLS.TRIGGER.GDG shows that 182 is the latest GDG generation. But actually the latest generation on ISPF 3.4 DSLIST is 181.
| Code: |
--------------- DATASET NAME --------------- DSNBR POSTTM TYPE
DATE TIME GDG# #VOL VOLSER DEV-TYPE SEQ
WELLS.GDG ........................ DS00000352 JTERM GDG,AUTO
12223 0108 0182 001 A78121 78048081 0001
12222 0302 0181 001 A21012 78048081 0001
12221 0324 0180 001 A87987 78048081 0001
|
Why is this difference? :S
My GUESS is that there was a FTP failure in dataset trigger creation and the FTP CONDDISP=DELETE deleted the 182 generation on DASD but CA7 still thinks that 182 exists and kicks off the trigger job.
Could you please let me know if this a known issue with CA7 dataset trigger or am I doing something incorrect. Are there any other things to lookout for in dataset trigger setup in CA7.
Thanks & Regards, |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Vasanth,
Any chance the +1 was created but due to some data error in the file (or some other condition) it was deleted after creation? CA-7 would "know" about the generation, but possibly not that it had been deleted? |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
| Quote: |
| +1 was created but due to some data error in the file (or some other condition) it was deleted after creation? |
Hello D,
Thanks for your time. I dont know if I understood your thought correctly. If you mean 'it was deleted by someone or some job' then I am sure that no job/no one has deleted the file(that LPAR is sort of dedicated to only my work)
Im having difficulty confirming if it was due to FTP failure since a lot of FTP process happens and many are automated, so struggling with it.
Regards, |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
You're welcome.
Must be nice to have your own z/OS "machine" on a real mainframe 
Sorry the "deleted" thought wasn't of use . . . Do let us kinow what did happen when it is discovered.
d |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hello,
| Quote: |
| Must be nice to have your own z/OS "machine" on a real mainframe |
Its nice :-) but sometimes hard to show code to people and get help, sysprogs login though, from time to time.
Performed a FTP from LPAR X to LPAR X(same LPAR) by doing a PUT
| Code: |
| PUT 'TEST.LARGE.DATASET' 'TRIGGER.GDG.DASD.FILE(+1)' |
And cancelled the FTP when partial transfer has happened, the GDG generation was deleted from DASD, but CA7 recorded the new entry :S possibly a bug.
I thought that this happens only to Tape GDG, but it happens to DASD datasets as well.
Regards, |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Good to hear it is now at least understood
d |
|
| Back to top |
|
|
|
|
