Kees, Of course a big (huge) part of this is that while your DASD management product will make backups of your DASD data sets; it does not make backups of TAPE data sets. And as Lizette indicated, you also have MUCH more flexability in terms of retention of TAPE data sets then you do on DASD. For example, on DASD it is normally a case of "keep until un-cataloged or specifically expired"; while TAPE has retention periods, cycle control and even days-since-last-use in addition to CATALOG control.
One option that you might consider would be use of the R9 option and putting these files under catalog control. This way, they would be retained as long as they are cataloged (must like when they were on DASD) and after they have been un-cataloged (and no longer available through simple DSN= processing) they could STILL be retained for the xxx days specified in the R9 option (30 days for example). So, when the file is no longer cataloged and the user (after getting a JCL error because the file is gone) realizes the file has been un-cataloged and is gone and calls in a panic; you can simply re-catalog the file and get your "thank you" gift. The down-side of the R9 option is that it will apply to ALL TAPE files that are under catalog control. At this time, we do not have an option to apply a longer R9 value to some files and not to other files. However, that would be something that could be done with an exit if you wanted a "long grace period" to be applied to only selected tape files. This however then brings up the question of which files do you want protected with a "long grace period" and which ones do you not care about and want to scratch as soon as they are un-cataloged? That might then become another large discussion. Russell Witt CA 1 Principal Software Architect ----------------------------------------------------------------------------------------------------------------------------------------------------------- On 07/31/13, Vernooij, CP - SPLXM<kees.verno...@klm.com> wrote: Hello group, I am looking for a feature in CA-1, that I wished to be there, but that is not there as far as I can find. Maybe someone has a good idea. I am looking at implenting disk-tape conversion for large datasets, i.e. write them directly to tape i.s.o. to disk. Since we have a VTS, with more than sufficient virtual units and more than sufficient performance, we have a potential group of large datasets, that can well be placed on tape. It has some restrictions of course, like dsorg and parallel access, but that is no problem. There is only one issue, that bothers me when the dataset is under CA-1 control i.s.o. SMS control. Under SMS, I can specify, with 'retain days only backup', how long the last backup should be retained after the dataset has been expired, scratched or removed in some way. This enables panic questions "the dataset is correctly expired, but yet I suddenly need it after one month" to be answered and even sometimes produces edible or drinkable presents from happy clients. I am looking for a similar feature under CA-1 control, but I cannot find it. The extended retention options do not give the same result, the dataset is available and cataloged, while under SMS it will be uncataloged and virtually gone. In the CA-1 situation the user can process the dataset and is not aware of the fact that the data was not planned to be available, which he/she would have noticed under SMS control. Looking through the CA-1 options, I can't find an equivalent of SMS's 'retain days only backup' option. Is there a similar feature in CA-1? Thanks, Kees. ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
