|
|
| Author |
Message |
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 8724
Location: 221 B Baker St
|
|
|
|
Hello,
It might help if you post a "mini" set of the jcl - wouldn't need all of the jcl for every step, just the step exec and the "problem" dd(s).
The reason i didn't mention the copy step versus the delete step was that i was focused on the process rather than that specific.
I'm not a fan of IDCAMS for this type of work.
Without seeing your "mini" set of jcl, i believe the old,delete,keep in the copy step will be basically the same as an old,delete,keep in a following step.
I'll be checking over the weekend, so if you post again, you'll hopefully get replies before nexe week  |
|
| Back to top |
|
 |
References
|
|
 |
jasorn
Active User
Joined: 12 Jul 2006
Posts: 109
|
|
|
|
| Sure, I'll post jcl in the morning. |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 663
|
|
|
|
Hi Jasonr,
personally I think you should handle this thru your scheduling tool.
Having said that, I'm against using DISP=(OLD,DELETE,KEEP) in the COPY step especially using IEBGENER , this very is dangerous, an incorrect or missing DDNAME such as SYSPRINT will result in a RC of 12 thus blowing away all the datasets without copying them.
Separate steps will always be proned to loss of data.
I have a suggestion which maybe a bit ugly
| Code: |
//RENAME EXEC PGM=IDCAMS
//DD1 DD DSN=CSCSGLC.FILE01,DISP=OLD ** LOCKS OUT OTHER JOBS **
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER CSCSGLC.FILE01.G0001V00 -
NEWNAME(CSCSGLC.FILE02.G0001V00)
ALTER CSCSGLC.FILE01.G0002V00 -
NEWNAME(CSCSGLC.FILE02.G0002V00)
ALTER CSCSGLC.FILE01.G0003V00 -
NEWNAME(CSCSGLC.FILE02.G0003V00)
etc
|
The job that reads and deletes the GDG base will need to run against the renamed files.
Gerry |
|
| Back to top |
|
|
jasorn
Active User
Joined: 12 Jul 2006
Posts: 109
|
|
|
|
gcicchet,
Actually, I mixed up two of my threads that are related to this problem. I should have posted that to this thread instead of here.
http://ibmmainframes.com/viewtopic.php?t=29062&highlight=
The solution I posted was to address the many jobs that write to the same gdg base while this thread is to address the job that processes the gdg base and deletes the generations. We still haven't decided how to handle this case and I'll check your suggestion out.
Thanks.
Moderators: You can remove my post dated "Fri May 16, 2008 9:35 am" if you please. (Done) |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 663
|
|
|
|
Hi Jasonr,
another way is before running JOBB is to run another job to LISTC the gdg's and build 2 members.
Member1 will look something along these lines
| Code: |
//SYSUT1 DD DSN=File1.G0001V00,DISP=SHR
// DD DSN=File1.G0002V00,DISP=SHR
// DD DSN=File1.G0003V00,DISP=SHR
etc |
Member2 will delete the files
| Code: |
//KILLFILE DD DSN=File1.G0001V00,DISP=(OLD,DELETE,DELETE)
// DD DSN=File1.G0002V00,DISP=(OLD.DELETE,DELETE)
// DD DSN=File1.G0003V00,DISP=(OLD,DELETE,DELETE)
etc |
JOBB will use the INCLUDE statement for above members.
First INCLUDE Member1 to copy the files, and second INCLUDE to Delete the files.
If JOBB now fails it can be rerun without the worry of new files having been created.
Gerry |
|
| Back to top |
|
|
dbzTHEdinosauer
Senior Member
Joined: 20 Oct 2006
Posts: 1633
Location: germany
|
|
|
|
Jason,
you will always have the problem: if the copy job goes bust and abends, leaving the GDGs unprotected (NOT exclusively locked ), the +1 jobs are going pee on your parade.
your reluctance to 'program' the scheduler - job dependencies - leaves you in a no-win situation. Schedulers were created to solve this (and many other) production processing problems. Using job dependencies (relying on the EOJ return code of a previous job) provides you with a map of how things are interrelated.
Most shops i have been in are of the
'as few as possible steps per job mentality'
- which means you have a gazillion jobs but the scheduler does not care, and if you fully use all the options of the scheduler, you can really lock down your shop and prevent this ripple type event from occurring. Even if you had a 1000 jobs, two people could schedule them in a couple of days. how long have you been playing around trying to solve this with disp parms/intermediate dependent jobs ?
plus, once you have it done, adding or deleting one new job is not that resource intensive. |
|
| Back to top |
|
|
jasorn
Active User
Joined: 12 Jul 2006
Posts: 109
|
|
|
|
| dbzTHEdinosauer wrote: |
Jason,
you will always have the problem: if the copy job goes bust and abends, leaving the GDGs unprotected (NOT exclusively locked ), the +1 jobs are going pee on your parade.
|
Yes the copy job has this risk but since we might have one copy job abend in a year, resolving a copy job abend is fast, and the many jobs which write to the gdg base don't typically run during the time the copy step runs, and we have a process to detect when generations were dropped, it seems to be worthwhile verses trying to manage 300-500 jobs turning over constantly in a scheduler.
| Quote: |
your reluctance to 'program' the scheduler - job dependencies - leaves you in a no-win situation. Schedulers were created to solve this (and many other) production processing problems. Using job dependencies (relying on the EOJ return code of a previous job) provides you with a map of how things are interrelated.
|
There is no reluctance. The 300-500 jobs that write to the gdg base can't be coded as conflicts with the copy job because the limit of conflicts is 255.
And as far as the 300-500 being part of some schedule where they're dependent upon one another, that isn't an option because they absolutely are not dependent upon one another. They have totally independent schedules are run based on when outside firms send us files.
But this isn't an issue as modding the +1 generation and then checking to see if it's empty works perfectly and is contained with the job and isn't dependent upone external forces. The copy job that runs once a day being the exception. But that's not an issue as discussed above.
| Quote: |
Even if you had a 1000 jobs, two people could schedule them in a couple of days. how long have you been playing around trying to solve this with disp parms/intermediate dependent jobs ?
|
I've posted a bit and asked around but I've spent about a day working out a solution once I finally concluded none of the solutions anyone offered solved the problem.
| Quote: |
plus, once you have it done, adding or deleting one new job is not that resource intensive. |
That's not true at our shop. Even if there is a way to put these into the scheduler and that would prevent the generations from being overwritten, it takes us half a day to modify one job in the schedule. Given our JOB turnover, that's too expensive.
But all of the solutions using a scheduler all were based on holding up the other jobs while the one that abended was down. Not only do we not want to hold the other jobs up, we can't as they're indenedent jobs and have data from other firms that need to be processed. |
|
| Back to top |
|
|
Bill Dennis
Senior Member
Joined: 17 Aug 2007
Posts: 313
Location: Iowa, USA
|
|
|
|
| Use DISP=(OLD,DELETE,KEEP) in the copy and get rid of the separate DELETE step. Just be sure the job will actually ABEND on an error. For example, if you use SORT to do the copy/delete it might just pass CC=16 on an error and the files could delete! Two copy steps would even be better, OLD,KEEP on the first and OLD,DELETE,KEEP on the next. |
|
| Back to top |
|
|
jasorn
Active User
Joined: 12 Jul 2006
Posts: 109
|
|
|
|
| Bill Dennis wrote: |
| Use DISP=(OLD,DELETE,KEEP) in the copy and get rid of the separate DELETE step. Just be sure the job will actually ABEND on an error. For example, if you use SORT to do the copy/delete it might just pass CC=16 on an error and the files could delete! Two copy steps would even be better, OLD,KEEP on the first and OLD,DELETE,KEEP on the next. |
Yes, this is the original solution I proposed for the copy job. Not clear to me if we're going to do this or not. |
|
| Back to top |
|
|
|
|
|
