IBM Mainframe Forum

Hi All,

I am trying to create a Tape files with retention period of 99 years from a monthly job. Following is the scenario.
Eg:
Job runs on year : retention period(year)
2013 : 2112
2014 : 2113

Known key words are RETPD and EXPDT
RETPD: is supporting upto 27 years only.
EXPDT : With using of EXPDT=99000, Its became like hard coding of retention period which is not the case I required.

Please let me know is there any other key words available which can satisfy my requirement. Please help in creating a tape files with retention period of 99 years from the date of execution of job.

There are no other keywords, as a brief perusal of the JCL Reference would have told you. Note that specifying EXPDT=99000 does not retain the tape for 99 years; this is an invalid date which has significance to various tape management systems. If you really find coding the expiration too tedious for words, your scheduling package or, at worst, a programette or a *Sort control card ought to modify it suitably.

• It used to be that data on tape deteriorated fairly quickly. After a few years (5?) the chances of retrieving the data became quite low. Sometime in the last 10 years I recall reading an article about a project to retrieve data from tapes created in the 1960s had quite a lot of trouble with
  • Media deterioration.
  • The data was recorded in EBCDIC, but they were using ASCII machines.
  • Finding tape drives that would read the tapes was difficult.
  • Documentation about the format of the data was poor.
• It seems to me that tape drives in 2112 (if tape type technology is still being used) will not be able to read the tape.

I Agree with you Steve. But its is the requirement and hv to satisfy it . We are searching for different options to get it done.

Hi Akatsukami,
I tried with EXPDT= 99002, 99360. Tapes are getting created but every time the retention is fixing to 2099 year only. its not picking to 2112.

What other design can we implement to get it done.

EXPDT is expiration date, not retention period. Unless you have windowing options set, a 2-digit year will be implicitly prefixed with "20", thus the behavior that you see.

As I said, write a tiny piece of Rexx or a *Sort control card to modify the JCL.

If your site is using a tape management system, find out how to code a tape for permanent retention. This is not going to be 99 years, but then there is no way that I am aware of under the current z/OS environment to accomplish what you want to do, anyway.

And back in the 80's I had to access some tapes that were 5 to 10 years old. IIRC, the success rate for reading tapes 5 to 10 years old was about 40% -- and it dropped off as the tape aged. Realistically, if your tapes are readable in the year 2023, you will be very lucky -- forget 2112.

Robert Sample wrote:If your site is using a tape management system, find out how to code a tape for permanent retention.

I don't believe that a tape management system is required; the bogus date 99366 is interpreted as "never scratch",

EXPDT=2113/001 might work.

Expdt=99366 is just like non exist date and tape dataset will never get delete.
EXPDT=2113/001 is hard coding the date. It will work for today. If the job executed after 1 month this option will not be correct.

Ribbono shel Olam! I can't believe, even in this day and age, that no one at your site is capable of handling so trivial a piece of programming What does your JCL have, if anything, for EXPDT or RETPD now?