IBM Mainframe Forum

Hi guys
i want to delete members(-1,-2) from a GDG group which was defined with limit(5); but seems i got (-1, -3) were deleted.
suppose the members are (1,2,3,4,5) and 5 is current position.
//STEP10 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT=*
//SYSDEL DD DSN=DATA.TEST.GDG(-1), ## here i wish '4' was deleted
// DISP=(MOD,DELETE,DELETE)
//******************************************
//STEP20 EXEC PGM=IEFBR14
//SYSOUT DD SYSOUT= *
//SYSDEL DD DSN=DATA.TEST.GDG(-2), ## here i wish '3' was deleted
// DISP=(MOD,DELETE,DELETE)
I wish I can get result is (1,2,5), but in fact (1,3,5) was left, member 2 and member 4 was deleted ? It seems after step STEP10, there is a commit operation, can anybody help ?
Thanks.

What do you think the catalog entries looked like before step 1? Yes, G0005V00 (0), G0004V00 (-1), G0003V00 (-2), G0002V00 (-3), G0001V00 (-4)
Step one deletes (-1) - your catalog now looks like this G0005V00 (0), G0003V00 (-1), G0002V00 (-2) and G0001V00 (-3)
Step 2 comes along and deletes (-2) which is G0002V00 so you are left with G0005v00, G0003V00 and G0001V00 which is as expected Aand what you got.

Next time try specifying absolute generations nd not relative generations - even in the same step.

It seems slightly odd though that a (+1) created during a job must be referenced later in the job as the (+1) and does not become the (0) until the job has completed.

Whereas when deleting a (-1), other relative generations are updated immediately. Understandable confusion I would have said.

Deleting the (-1) and the (-2) in the same step gives the expected results, ie; G0001V00, G0002V00 and G0005V00 remain.

Deleting the (-1) and the (-2) in the same step gives the expected results, ie; G0001V00, G0002V00 and G0005V00 remain.

unless someone creates G0006V00 between job creation time and job start time hence the suggestion to use absolute values.

NicC wrote:What do you think the catalog entries looked like before step 1? Yes, G0005V00 (0), G0004V00 (-1), G0003V00 (-2), G0002V00 (-3), G0001V00 (-4)
Step one deletes (-1) - your catalog now looks like this G0005V00 (0), G0003V00 (-1), G0002V00 (-2) and G0001V00 (-3)
Step 2 comes along and deletes (-2) which is G0002V00 so you are left with G0005v00, G0003V00 and G0001V00 which is as expected Aand what you got.

Next time try specifying absolute generations nd not relative generations - even in the same step.

Thank you for your answer, however, i am still confused with that, it seems after the first step, there should be an implicit commit operation.But if we try to delete the (0) GDS (which should be G0005V00) in first step, then the delete (-2) operation in second step should delete G0002V00, because after G0005V00 was deleted in first step, the GDG member should as
G0004V00 (+0),
G0003V00 (-1),
G0002V00 (-2),
G0001V00 (-3)
But the real result is that G0003V00 was deleted, not G0002V00 was deleted.

the main issue is that the delete(-2) in second step is uncertain, it depends on the delete operation on step 1:
when delete(0) on step 1, delete(-2) on step 2 will delete G0003V00, but
when delete(-1) on step 1, delete(-2) on step 2 will delete G0002V00.

NicC wrote:unless someone creates G0006V00 between job creation time and job start time hence the suggestion to use absolute values.

no, there is no other people/process are accessing these files.

What you do not seem to understand is that the mapping between a relative generation and the true generation exists for the duration of the job. For example.This map is established when the job starts. No other job can access the GDG while your job executes, which means no other job can alter this map. Now if your job deletes relative generations -1 and -3, the remaining members in the GDG still follow the map created when the job started. The next job that uses the GDG creates a new map, for that job:If this second job creates true generation G0004V00 it cannot use it as a relative generation because it's not in the map, but it will be in the map when a third job is subsequently run.

These users thanked the author steve-myers for the post:

Akatsukami (Tue Oct 15, 2013 7:32 pm)

If it was a delete of -1 and -2 as per the original post and the map is "static" for the duration of the job then I would expect generations 0, -3 and -4 to be still in the map ie generations G0005V00, G0002V00 and G0001V00 but OP is saying G0003V00 was NOT delete but G0002V00 was. If the reported facts are true then the map got updated after step10.

So...who is correct? Has the catalog update processing changed since Steve learnt it or were we given incorrect information to start with?

Also, Hihui, just because there is nothing else that can affect the catalog for that GDG at the moment does not mean that the will not be in the future. And what about other GDGs - if you do not specify absolute then one day you will get in trouble as the wrong dataset gets lost.

The JCL User's Guide explains:

For example, if you create a generation data set with a relative generation number of (+1), the system recognizes any subsequent reference to (+1) throughout the job as having the same absolute generation number. Relative generation numbers are obtained from the catalog as it existed:
For JES2, at the beginning of the first step that specifies the generation data set by relative generation number.

Hi Robert

Is there a bit missing in that quote?

Anyway, am I interpreting correctly that STEP10 refers to -1 so there is a catalog look up, STEP20 refers to -2, this is different from -1 so another catalog look up is done? But the catalog has been updated with the first deletion so -2 refers to G0002V00 as G0004V00 has 'gone'?

I can see the need for a bit of educational playing coming up after work!