In both the functioning (month-end & daily) input GDG is XXXX.XX.AAA.BALTOTAL(+6); if month-end is there //AATOTNXT is created else //AATOTFLO. This JOB works well in production but when tried in Test region & I checked for syntax errors, it shows:
Code:
FILE IS ALREADY CATALOGED
for the DD name //AATOTNXT... why so.. . Please advise.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
One solution that shoud work in both enviroments would be to change the 2 output files to temporary datasets rather than the +7 as specified now. Pgm AAA "knows" if this is the monthly or the daily run and could set a condition code accordingly.
That condition code would then be checked by 2 new "copy" steps that would read the appropriate temporary file and at that time create the +7(see below) generation.
The reason it currently works in production may be due to interaction with the scheduling software.
IMHO, having multiple dd statements "create" a new generation of the same gdg in a single step is a design flaw. I also would question why a job is creating 7 (or more?) generations of the same gdg. I suspect that this causes considerable confusion when trying to plan a restart. What good are the intermediate generations? It appears that the intermediate generations would be difficult (at best) to even use. . .
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Hi Dick,
Quote:
having multiple dd statements "create" a new generation of the same gdg in a single step is a design flaw.
There is an old saying, "if a 'machine' is working fine, don't distrub it"...Yes, it might be a design flaw, if I report it to My P.M. he would not be in a ready mood to allow me to fix because My current motive is to test a 'change' using this JOB & let the other 'things' as it is.
Quote:
I also would question why a job is creating 7 (or more?) generations of the same gdg.
They call it Business Balance file, it flows through the JOB to capture today's activity. Each program has some entries to update in this file..so this many generations, might sound little stupid.
Quote:
I suspect that this causes considerable confusion when trying to plan a restart. What good are the intermediate generations? It appears that the intermediate generations would be difficult (at best) to even use. . .
Well, they make use of UC11RMS, it comes with CA-11 sechduler. It 'creates' a 'system' dataset , RMSRPT, in SYSOUT, which allows to look for how many generation were created in the respective JOB.
Might be it's something to do with sechduler software in use, but the one in production the same is in use in test region, then why the problem is only in test & why not in production..however I run this job 'individually' in test.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hi Anuj,
Quote:
then why the problem is only in test & why not in production
Because they are not the same? Look at the de-allocation from a production run and i suspect you will see that the production run does not try to "create" two +7 generations. Something in the production environment "knows" and circumvents the "duplicate" error. The test run is reacting to the jcl as submitted - which is incorrect.
Quote:
"if a 'machine' is working fine, don't distrub it"...
It does not sound like it is "workikng fine" to me. . .
Quote:
might sound little stupid
Not stupid - just poorly designed and implemented. As i mentioned before, how can these multiple intermediate generations ever be used? If they cannot be used without jumping thru hoops, i'd suggest they not participate in that gdg. It is easily understandable that different parts of the process would incrementally modify the overall content, but i do not see why they all need to be part of the same gdg.
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Hi Dick,
dick scherrer wrote:
Look at the de-allocation from a production run and I suspect you will see that the production run does not try to "create" two +7 generations. Something in the production environment "knows" and circumvents the "duplicate" error.
Yes, this is what I'm searching for..
Quote:
It does not sound like it is "working fine to me . . .
I meant in Production it is.
Quote:
Not stupid - just poorly designed and implemented.
These systems are in Production much before since my birth. I think I'm too new to comment on their design. Sometimes, I've better suggestion on older designs with a perfect comparison of CPU statistics but they can't implement them right away, until we get some billability for that, it's business..huh..
. Please advise.
