David Magee wrote:
[...]
If for some reason an entry in group A does not roll off (i.e., an
expiration date is changed so that the entry doesn't expire in a timely
matter, etc.), group B will not have it's wrap bits turned off. When group
B gets to G0999V00, then next attempt to create an entry by using
DSN=...(+1) will fail. Manual intervention is required by the user to
correct all the existing entries in the GDG before any new entries can be
created. Good doc from IBM about how to correct the problem is not easily
found. At 3:00 AM Sunday morning, this could really be FUN!!
Actually, I think, the problem is theoretical. How often do you create
new generation? Usually it's being created daily (weekly, monthly). One
generation a day means 10000 days to overlap.
That's 27 years! Even if you are still working here, there is small
chance that application didn't change and this GDG is dropped.
Of course it is possible to use GDGs for cyclic jobs running hourly
(still over year) or even more frequently. It is also possible that for
such jobs real GDG is used, not some "autoedit" feature of batch
scheduler (like %%ODATE in ControlM).
But I think it is uncommon.
Last but not least: uncommon processing x uncommon error...
My €0.02
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi
118.642.672 zote i zosta w caoci wpacony.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
