inconsistent behavior when delete 2 GDG member



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

inconsistent behavior when delete 2 GDG member

Postby hihui » Mon Oct 14, 2013 1:05 pm

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.
hihui
 
Posts: 9
Joined: Mon Oct 14, 2013 12:34 pm
Has thanked: 2 times
Been thanked: 0 time

Re: inconsistent behavior when delete 2 GDG member

 

Re: inconsistent behavior when delete 2 GDG member

Postby NicC » Mon Oct 14, 2013 3:27 pm

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.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: inconsistent behavior when delete 2 GDG member

Postby Blackthorn » Mon Oct 14, 2013 4:07 pm

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.
Blackthorn
 
Posts: 98
Joined: Tue Feb 01, 2011 7:12 pm
Has thanked: 0 time
Been thanked: 2 times

Re: inconsistent behavior when delete 2 GDG member

Postby NicC » Mon Oct 14, 2013 4:27 pm

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.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: inconsistent behavior when delete 2 GDG member

Postby hihui » Tue Oct 15, 2013 6:13 pm

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.
hihui
 
Posts: 9
Joined: Mon Oct 14, 2013 12:34 pm
Has thanked: 2 times
Been thanked: 0 time

Re: inconsistent behavior when delete 2 GDG member

Postby hihui » Tue Oct 15, 2013 6:14 pm

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.
hihui
 
Posts: 9
Joined: Mon Oct 14, 2013 12:34 pm
Has thanked: 2 times
Been thanked: 0 time

Re: inconsistent behavior when delete 2 GDG member

Postby steve-myers » Tue Oct 15, 2013 7:09 pm

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.
 Relative     True
Generation Generation
    0       G0005V00
   -1       G0004V00
   -2       G0003V00
   -3       G0002V00
   -4       G0001V00
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:
 Relative     True
Generation Generation
    0       G0005V00
   -1       G0003V00
   -2       G0001V00
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)
steve-myers
Global moderator
 
Posts: 1885
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times

Re: inconsistent behavior when delete 2 GDG member

Postby NicC » Tue Oct 15, 2013 8:19 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 problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: inconsistent behavior when delete 2 GDG member

Postby Robert Sample » Tue Oct 15, 2013 8:20 pm

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: inconsistent behavior when delete 2 GDG member

Postby NicC » Tue Oct 15, 2013 8:42 pm

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!
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Next

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post