Hi,
Can I give more length for GDG than previous one?
GDG LRECL for different generations.
- Robert Sample
- Global Moderator
- Posts: 1900
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: GDG LRECL for different generations.
Yes. Each generation of a GDG can be considered as a separate data set. Note that doing so may cause problems if you have jobs that reference the GDG base instead of relative or absolute generation.
Re: GDG LRECL for different generations.
If it is so - then what are the practical uses of GDGs? Why can't we just use a simple sequential file?
- Robert Sample
- Global Moderator
- Posts: 1900
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: GDG LRECL for different generations.
A GDG is actually quite handy. Consider a job run daily that backs up a file (or volume) to tape. For such backups, you normally want to keep a number of copies around (in case you need to recover from a day other than yesterday). If you want to be able to go back two weeks, define a GDG with 14 generations and set up your JCL to back up to HLQ.DATA.GDG(+1). You don't have to change the JCL to pick up a new name every day, you don't have to have 14 versions of the JCL to back up to 14 different files, yet you can easily recover from yesterday's backup or last Monday's backup.
Other applications where a GDG comes in handy is financial data, where you may need to keep data for up to 7 years for auditing purposes (daily / weekly, monthly, and yearly GDGs come in handy for that), and transactional data where you may want to keep the precise data entered for some period of time to be able to go back and check what was entered against what is in the data repository.
Operational mainframe systems typically are around for years (if not decades). Development should, in such a case, be focused on making things as easy as possible to maintain and change since the developer may have moved on to another company when the need to make a change comes up. I did a study in 2009 about our applications; the oldest production program I found was last compiled in 1977. There were a number of programs last compiled prior to 1985. The environment has changed -- a lot -- since then, but the programs (due to IBM's commitment to backwards compatability) continue to execute the same more than 30 years later. Using a GDG simplifies the system and quickly becomes normal.
Other applications where a GDG comes in handy is financial data, where you may need to keep data for up to 7 years for auditing purposes (daily / weekly, monthly, and yearly GDGs come in handy for that), and transactional data where you may want to keep the precise data entered for some period of time to be able to go back and check what was entered against what is in the data repository.
Operational mainframe systems typically are around for years (if not decades). Development should, in such a case, be focused on making things as easy as possible to maintain and change since the developer may have moved on to another company when the need to make a change comes up. I did a study in 2009 about our applications; the oldest production program I found was last compiled in 1977. There were a number of programs last compiled prior to 1985. The environment has changed -- a lot -- since then, but the programs (due to IBM's commitment to backwards compatability) continue to execute the same more than 30 years later. Using a GDG simplifies the system and quickly becomes normal.
Create an account or sign in to join the discussion
You need to be a member in order to post a reply
Create an account
Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute