You have Javascript disabled. While you will be able to browse this site without Javascript, some functionality on this site will not work without it. We strongly recommend enabling Javascript in your browser. This site uses cookies and collects data about visitor behavior for improving user experience, identifying returning visitors, and providing personalized offers. Your continued use of this site indicates your consent to this. See Privacy Policy for details or if you wish to disable cookies.

Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

This site uses cookies and collects data about visitor interaction for improving user experience, identifying returning visitors, and providing personalized offers. Your continued use of this site indicates your consent to this. See Privacy Policy for details or if you wish to disable cookies.

Accessing Generation Data Groups (GDG)

Tectia file transfers are atomic. Running "sget gdg.base(0) file1" two times in succession might retrieve different files. A loop of "sput file1 gdg.base(+1)" commands might fill the GDG with identical files and roll off all the previous generations.

In the examples below, sshd2 means server functions on z/OS that can be used by any remote client.

Navigating

sshd2 allows you to navigate to a GDG base and to a prefix of a base. The name of the GDG base is returned to the client with a period at the end, the same way as for prefixes.

Listing

sshd2 shows GDG bases with the type GDG. Generation data sets (GDS) are shown with their absolute data set names.

GDSs are normal data sets. The long name format (ls -l) will show all details.

Listing a base with -l will show full details of the GDSs. The listing may contain data sets that are not in the GDG index but do have data set names that have the GDG name as a prefix.

It is possible but not recommended to use data set names which have the GDG base name as a prefix but are not GDS names. For example:

You cannot navigate to a prefix that ends in a GnnnnVnn qualifier. Thus you cannot do "cd G0006V00" or "ls //'USER1.GENGRP.G0006V00'" in the example above.

If the GDG has the NOSCRATCH option, GDSs are retained when they are rolled off.

sshd2 shows data sets based on the prefix - it does not show which data sets are in the GDG and which are not.

Transferring Generation Data Sets

Tectia Server for IBM z/OS does not serialize access to data sets and many clients do not wait for an acknowledgment to the close command. The client will proceed to the following command when the network transfer is completed. In most cases, the server stages the data in a memory file and copies it into the data set after the network transfer ends. This may lead to unexpected results if several transfers add or replace GDSs in the same GDG. The Tectia Client versions 4.4.8 and 5.2.1 and later serialize transfers and handle the acknowledge to the close command properly, and thus avoid this problem.

Access by Relative DSN

sshd2 gives full access with relative generation numbers for reading and writing.

The following formats can be used for the relative GDS name abc.xyz(relno) (relno must be 0, +1, or -nn):

abc.xyz(relno)
abc.xyz./relno
abc.xyz/relno
abc.xyz.relno

Access by Absolute DSN

With absolute GDS names you can do all the things possible with other data sets.

Writing a data set with a last qualifier with the GnnnnVnn format requires that there exists a suitable GDG base. If the generation exists it is overwritten. If if does not, the new file is inserted in its place in the GDG and older GDGs are rolled off, if necessary.