将文件与similardsn串联
请如何使JCL与名称相似但上一个预选赛不同的各种数据集加入？我们将每个录制日期作为DSN的最后一个预选赛。我的问题是我不知道它何时被执行，也无法编写每个文件的日期。
示例：aaaaa.bbbbbb.ccccc.f090622
AAAAA.BBBBB.CCCCC.F100622
AAAAA.BBBBB.CCCCC.F110622
我的问题是：有没有办法在我的jcl中仅写一个dsn aaaa.bbbbb.cccc.f*，以使所有DSN constentate上述所有DSN描述？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您的意思是说：
代表：
在JCL中无法完成。
If you mean somthing like:
to represent:
that can not be done in JCL.
我了解的生成数据组的用
例如下：
如果假设是正确的，则使用“生成数据组” 可能是将数据集名称与日期预选赛一起使用的替代方法。
参见，和 Z/OS MVS JCL参考有关详细信息。
生成数据组简要解释了
生成数据组，Short gdg ，是一组数据集，称为生成数据集，Short Short GDS ，由其在小组中的位置提及。该位置由括号中包含的相对位置指定，并在JCL中指定DSN时附加到数据集名称。 （您不能在TSO/ISPF中使用此符号）。
gdg 是数据集目录中的特殊条目。它定义了GDSS的基本名称，即任何时间可能存在的最大世代数，最古老的一代会发生什么，达到最大值时，创建了另一个新的GDS，以及更多选项。
该系统在创建和删除GDS时会跟踪它们，并且在GDG基础条目的帮助下，本书保留，以及一个自动附加到DSN的其他预选赛。此预选赛的形式为g nnnn v00，其中 nnnn 是实例的生成编号，每个新的GD都会增加一个。
通过指定GDG基础中指定的DSN并将相对生成编号作为正整数来创建新的GDS。作业中的第一个新GDS具有相对位置+1，第二个新的GDS中的第二个新gds 具有相对位置+2。在作业开始执行之前存在的最新GD的相对位置零（0），这是在此之前的postition -1。
说，您定义具有名称
Z08593.GDGTEST的GDG。然后，您将在JCL中创建一个新的GDS实例，如下所示：您将在整个作业中指定具有位置（+1）的实例。如果您需要阅读作业开始之前的最新
实例（+2）。第二个但最新的实例由
dsn = z08593.gdgtest（-1）等提及。默认情况下，系统在启动作业之前采用了现有一代的“快照”，并且整个作业执行过程中的所有相对引用均固定在此快照上。GDG和GDS的背后还有更多，以及如何处理它们。仔细阅读JCL用户指南（请参见上文），以更好地了解这一点，并考虑处理诸如AID -AFENDS的处理异常工作（因为它有问题）等。
将所有现有的世代阅读为一个数据集（CONTATENATION）
，这就是GDGS Migth对您很重要的原因：您可以轻松地将所有当前实例或几代人置于JCL中具有单个
dd语句的GDG。只需指定DSN，但不要指任何相对生成：系统将为您在现场创建DD串联。您甚至可以指定数据集应加入的顺序：lifo或fifo：
lifo为默认值。
我希望，示例JCL和流刊
是一个例子，由此产生的作业日志有助于获得这个想法。
创建生成数据组
这是一次工作。创建GDG条目后，它将存在直到明确删除为止。
该作业定义了一个称为 z08593.gdgtest 的GDG，并指定任何时间可能不超过35个生成数据集实例。它还指定将创建第36代时，将删除最古老的一代（
scratch）。noempty表示只有最古老的GD会被删除。有关详细信息，请参见访问方法服务命令手册。可以检查最终的GDG输入。例如在ISPF 3.4中，通过在DGD行中输入命令
listc ent（/）所有。结果看起来与此相似：创建一个新一代数据集
此作业将定期运行，也许每周或每周运行，并且每次运行时都会创建一个新的GDS实例。
实际上，该程序每次作业运行，对其进行处理并将结果写入新的GDS时都会读取不同的输入。出于测试目的，我正在使用IEBGENER，它只需将输入（
// sysut1）复制到输出（// sysut2）。您可能需要编辑“记录”，例如BA每次运行的数字增加。在这项作业的第一次运行日志中，可以看到新的GDS的名称：
在第二次运行中，看起来像这样：
等等。三次运行后，您会在ISPF 3.4中看到以下内容：
如您所见，系统将在每个数据集中添加了上述的生成预选程序。
Note 虽然您无法使用ISPF中的相对生成语法，但您始终可以使用如下所示的完整数据集名称使用。如果您经常需要与ISPF中的人员一起工作，那就不是那么有用：您无法轻松地说出在哪个日期创建了哪一代。
立即处理所有现有的几代人，
因此现在该运行作业来处理自上次运行以来创建的所有世代。这是此作业的JCL：
您指定了一个单个DD语句，该语句以其基本名称指代GDG。该系统将将其扩展到DD串联，这是在作业开始时存在的每一代DD。在作业日志中，您可以轻松确认这一点：
成功处理所有世代后，一旦处理作业成功地在所有世代上工作后，将GDG重置
，您想删除所有这些，以开始下一个周期。同样，一个看起来像这样的简单工作：
作业日志的相关部分显示了数据集已删除：
Note 重要的是要了解只有GDS仅删除了GDS，GDG base是< em>不是。
Use Case for Generation Data Groups
I understand that the requirement is as follows:
If the assumptions are correct, using Generation Data Groups might be an alternative to using data set names with a date qualifier.
See z/OS DFSMS Access Method Services Commands, z/OS MVS JCL User's Guide, and z/OS MVS JCL Reference for details.
Generation Data Groups Explained Briefly
A Generation Data Group, short GDG, is a group of data sets, called Generation Data Sets, short GDS, that are referred by their position in the group. This position is specified by a relative position, enclosed in parenthesis, and appended to the data set name when specifying the DSN in JCL. (You cannot use this notation in TSO/ISPF).
The GDG is a special entry in the data set catalog. It defines the base name for the GDSs, the maximum number of generations that may exist at any time, what happens to the oldest generation, when that maximum is reached, and yet another new GDS is created, plus some more options.
The system keeps track of GDSs as they are created and deleted, and this book keeping is done with the help of the GDG base entry, and an additional qualifier that is appended to the DSN automatially. This qualifier is of form GnnnnV00, where nnnn is the generation number of the instance, incremented by one for each new GDS.
New GDSs are created in JCL by specifying the DSN as specified in the GDG base, and appending the relative generation number as a positive integer. The first new GDS in a job has relative position +1, the second new GDS in the same job has relative position +2. The latest GDS that existed before the job started to execute has relative position zero (0), the one before that has postition -1.
Say, you define a GDG with name
Z08593.GDGTEST. You would then create a new GDS instance in JCL as follows:and you would refer to this instance with position (+1) throughout the job. If you need to read the latest instance that existed before the job started, you would refer to it as:
As second new instance created within the same job is referred to by
DSN=Z08593.GDGTEST(+2). The second but latest instance is referred to byDSN=Z08593.GDGTEST(-1), and so on. By default, the system takes kinda "snapshot" of existing generations just before a job is started, and all relative references throughout the job's execution remaind fixed towards this snapshot.There is more behind GDGs, and GDSs, and how to handle them. Carefully read the JCL User's Guide (see above) to get a better idea of this, and think about handling exceptions like ABENDs, dulicate runs of a job (because there was a problem with it), etc.
Reading All Existing Generations as One Data Set (Contatenation)
And here is the reason why GDGs migth matter for you: You can easily concatenate all current instances, or generations, of a GDG with a single
DDstatement in JCL. simply specify the DSN but don't refer to any relative generation:The system will create a DD concatenation for you behind the scene. You can even specify in which order the data sets shall be concatenated: LIFO or FIFO:
with LIFO being the default.
Sample JCLs and JOBLOGs
An example and the resulting job logs help to get the idea, I hope.
Creating the Generation Data Group
This is a one time job. Once the GDG entry has been created, it will exist until deleted explicitly.
This job defines a GDG called Z08593.GDGTEST, and specifies that there may be no more than 35 generation data set instances at any time. It also specifies that the oldest generation will be deleted (
SCRATCH) when a 36th generation will be created.NOEMPTYmeans that only the single oldest GDS will be deleted. See the Access Method Services Commands manual for details.The resulting GDG entry can be inspected. e.g. in ISPF 3.4 by entering the command
LISTC ENT(/) ALLon the line of the DGD. The result looks similar to this:Creating a New Generation Data Set
This job will run periodically, maybe daily or weekly, and will create a new GDS instance every time it runs.
In reality, the program would read a different input each time the job runs, process it, and write the result to the new GDS. For testing purposes, I'm using IEBGENER which simply copies input (
//SYSUT1) to output (//SYSUT2). You might want to edit the "record", e.g. ba incrementing the number for each run.In the log of the first run of this job, one can see that the new GDS's name:
In the second run, it looks like this:
and so on. After three runs, you would see the following in ISPF 3.4:
As you can see, the system adds a generation qualifier as described above to each data set.
Note while you cannot work with the relative generation syntax in ISPF, you can always work with the full data set name as shown here. It's just not so useful if you need to often work with those in ISPF: You cannot easily say which generation was created on what date.
Processing all Existing Generations at Once
So now it is time to run the job to process all the generations that had been create since last time this job was run. Here is the JCL for this job:
You specify a single DD statement referring to the GDG by its base name. The system will expand this to a DD concatenation, one DD per generation that exist at the time the job is started. In the job log you can easily confirm this:
Resetting the GDG after Successful Processing all Generations
Once the processing job has successfully worked on all the generations, you want to delete all of them to start the next cycle. Again, an easy job that looks like this:
The relevant part of the job log shows the data sets have been deleted:
Note it is important to understand that only the GDSs are deleted, the GDG base is not.