View previous topic :: View next topic
|
Author |
Message |
Biswajit Pattanayak Currently Banned New User
Joined: 24 Apr 2013 Posts: 15 Location: India
|
|
|
|
Hi,
In our mainframe site , dataset get deleted after one day because of the default management class which is allows only one day for the dataset.
To alter the management class I am using the alter command .
But some times I forget to alter the management class and my datasets get deleted.
I want to create a rexx tool to gather all the dataset created by the userid and alter its management class at one go at the end of the end.
But the problem here is some of the datasets are created by the job not by the user(like output datasets created in spufi) , so it is difficult to capture this dataset and change its management class.
Is there any way to find out the datasets created in the mainframe session? |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
you can always run a dslist for datasets for your userid as hlq.
you can also run dslists for datasets created by a userid
(i think you have to access all datasets and the look at the userid of each,
not sure if dslist has a filter for creator,
but you can find out by looking in the rexx manual for dslist.)
but,
professional advice.
learn to create datasets with the appropriate management class
and change the jcl for datasets created in jobs. |
|
Back to top |
|
|
Biswajit Pattanayak Currently Banned New User
Joined: 24 Apr 2013 Posts: 15 Location: India
|
|
|
|
Thanks Dick,
Most of the time I ceate the dataset with with proper management class but the problem is with the dataset created by the jobs i.e output dataset of spufi.
And another problem is most of the dataset doesn't have hql as their userid
e.g tenv.output.dataset created by user id "User1"
Is there any possible way to find this dataset and change its management class through rexx? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
You need to speak with your storage management people. If this is a problem for you, it is probably a problem for others. The storage management people should be able to tell you what is needed or a different way to get the output you want. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
As said by Dick, speak to your storage management people. They build the SMS routines for a reason. |
|
Back to top |
|
|
Biswajit Pattanayak Currently Banned New User
Joined: 24 Apr 2013 Posts: 15 Location: India
|
|
|
|
Thanks Dick and expat.
Storage management people will not change the configuration for me.
I think I have to manualy alter the management class.
Thanks anyway. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
Dick ans expat are correct, however, if you're authorized to do it and you'll know it from Storage management people - migrate and recall the dataset.
An after thought, I put a small snippet to show how to do that but then removed. Somehow I felt it's not wise to advise that upfront. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
|
|
|
|
Biswajit Pattanayak wrote: |
Thanks Dick and expat.
Storage management people will not change the configuration for me.
I think I have to manualy alter the management class.
Thanks anyway. |
This sounds very suspicious to me. In my shop, the one instance in which the retention period is specified by management class is for PS data sets with a TSO ID as HLQ. Such data set are caused to be volatile (i.e., expire at midnight) precisely because junior IT personnel cannot be trusted to give those data sets a reasonable retention period. If your policy causes DASD to be filled with abandoned data sets, used once and retained for years, I suspect that storage management will be very displeased with you. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
There is a term commonly used for people who decide the rules at their site do not apply to them -- that term is "ex-employee". The SMS policies in effect at your site were determined by people with plenty of experience in creating and using data sets; if you don't like the rules you need to either work to get them changed or accept them as they are. Manually overriding them is NOT a career-enhancing move. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
The shop where I work has a simple solution that has been in place for many years, even predating SMS. We use UNIT=DISK to request temporary DASD (which is scratched overnight) and UNIT=TSS1 to request permanent DASD, which retains the data set subject to the rules established for the test environment. That's all the programmer needs to know, as far as the test environment is concerned. Nowadays this is all managed by SMS and ACS routines, but these are generally transparent to the average programmer. |
|
Back to top |
|
|
Biswajit Pattanayak Currently Banned New User
Joined: 24 Apr 2013 Posts: 15 Location: India
|
|
|
|
Is there any to capture the dataset created during the session using rexx or jcl utilities and then altering their management class is easy.
The TSO session job which runs till the session ends has the log of everything done in that session, may be we can read this and find all the dataset ceated/edited and then alter their management class.
I think we can implement it. What say? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
I'd say you have not been paying proper attention . . .
There is no good (accreptable) reason to work ouside what the storage people will support.
Why do you believe your "stuff" should be treated differently? |
|
Back to top |
|
|
|