GDG's were designed to solve this exact problem. Stop thinking DISP=MOD. Instead, Think CATALOG to keep the new version and DELETE without cataloging to discard the unwanted version. Creating a new GDG entry requires use of (+1) and it only available once it has been cataloged. This occurs when and if you want.
In the past, we used //MYGDG DD DISP=(NEW,CATLG,DELETE),DSN=MY.GDG(+1),SPACE=(TRK,(1,1)) which is the standard method that deletes without cataloging if the step abends otherwise catalog it at the end of the step. In this case, your program would issue a USER ABEND code if there was a problem. Today, it's a little different because we avoid abend codes. You didn't say how you download the file, so the following shows you a couple of methods for checking the return code for success / failure to cause CATALOG / DELETE: If JCL is being used, then multiple steps are needed. The first step creates the GDG dataset with DISP=(NEW,PASS). The second step is run if download successful (based on the return code from the first step) and would catalog the dataset with DSN=*.firststep.ddname,DISP=(OLD,CATALOG). The third step is run if the download failed and would use ,DSN=*.firststep.ddname,DISP=(OLD,DELETE,DELETE). Note that PASS is required to retain control of the new GDG entry for the length of the job otherwise another job could sneak in between steps and cause problems. If a TSO exec is being used, then use of FREE DDN(xxxx) CATALOG would achieve what is needed. By specifying DSN=xxx(+1),DISP=(NEW,DELETE,DELETE), the new GDG entry will be deleted as a default and will never be seen. When your exec successfully downloads the file, your exec would FREE CATALOG to make it available. Job's that want to reference the current GDG will use (0). Creating the new version (+1) does not delay use of (0). If you require others wait for the new version (+1), then you will need DISP=OLD for the (0) GDG while creating the new version. GDG's (0), (+1), (+2), ... (-1), (-2),.. are each unique datasets. The only commonality is they are referenced thru the GDG name. Treat them as different datasets. TSO ALLOC does not support the use of (0) and (+1) in the dataset name. Instead use BPXWDYN which does support it. As for the number of GDG entries, you need to consider that datasets that drop off are uncataloged and if not in use, will be deleted. In other words, there is a potential for uncataloged versions. You should make the number large enough that no one is using the version that is dropping off so it will be deleted. So you definitely don't want to use 1. If the dataset is never referenced longer than 10 minutes and your update interval is 2 hours, then 2 will work fine. If on the other hand, the dataset is referenced several hours, then you will need a larger number. It sounds like the file is a complete file (not an update to the existing file). If that's true, then DISP=MOD is not helping. DISP=MOD only appends data to the end of a dataset for GDG's (does not create a new dataset as with standard datasets)., it's only benefit for GDG's would be if multiple OPEN / CLOSE occur. Jon Perryman ----- Original Message ----- > From: Phil Smith <p...@voltage.com> > > We have a data set that gets fetched from the network and changes > occasionally. > I'd like to untie this update from normal operation-that is, on the > off-chance that the network is down at the precise instant that we check for > the > data set, I'd like things to continue operating. So I'm thinking that if > we cache a copy of the data set on disk (the contents aren't sensitive), we > could try to fetch; if we can't fetch, we shrug and continue; if we can, we > compare the data read with the existing data (there's a timestamp) and only > rewrite if it's changed. > > But the data is also shared across tasks, so we don't want a window where > it's half-written and some task tries to read it. > > A GDG seems like it would work great for this: the number of generations > could > be defined as low as two, so the update would write the "other" copy, > and the next time one of the tasks tries to read it, it would get the newer > one. > > So here's my question (aside from the obvious one of "Am I missing > something above that makes this dumb"): > > If a jobstep runs with a DD for a GDG that's got DISP=MOD, and the jobstep > reads but never tries to write the file, does a new, zero-length GDG get > created? I'm of course hoping the answer is "No". ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
