I don't think that's entirely correct, MrSpock. There shouldn't be an enqueue against the GDG base, because a GDG base is nothing more than a catalog entry.
I think what's happening here is that one request is being sent to the FTP server, which dynamically allocates a new generation. Before dynamic deallocation is complete, the FTP server receives an identical request, and it interprets that request as being for the same generation it's already using.
OR... and this is what I think is more likely... the new generation isn't cataloged until the dataset is deallocated. Therefore, if you have two different threads running, the first one is dynamically allocated as GDG.G0238V00, and the next request hits the catalog, and since GDG.G0238V00 hasn't been cataloged yet, that's the DSN the catalog returns for the next generation. If that's the case, you might have to run VTOC queries to see where the uncataloged version is, because chances are it didn't get overwritten, it's just orphaned somewhere.
I don't make any claims to expertise in this area, either. But I have had some experiences with this sort of thing.
I do agree that the best solution would be to key off of some other unique property and abandon the use of GDGs for this process. Date and time stamps are usually a good place to start.