I'm having doubts about a certain procedure, so I'm writting here in hope someone could help.
We're removing tapes from an old library and currently using this procedure:
1. Erase the tape using DITTO secure erase (with JCL)
2. Check the tape contents just to make sure (with DITTO)
3. Eject the tapes (with ISMF)
As you probably guess, this takes alot of time when the number of tapes is big. I couldn't find a way to make DITTO's JCL utility process more than one tape per job
OT: Also, how secure is DITTO's secure erase?
Any suggestion/idea how to make this the proper way is very welcome!
PS. I'm quite new to the MF world, so please don't hate me if I posted under the wrong forum. I noticed there's also a students forum, but I figured this subject isn't suitable there...
The only way to get it done a little more quickly would be to process multiple erase jobs in parallel.
Yes, idealy, I would run a certain job and erase multiple tapes in parallel (sending it to various control units which can erase the tapes in parallel) and another job which would browse the contents of the tapes and make a report to a DS.
I've tryed this with DITTO, but I can't seem to get it working for multiple tapes per job, and also it seems the TB (Tape Browse) function is only available in panel-mode, not JCL...
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Notice "process multiple erase jobs" implies you are submitting MORE than one job -- you could submit as many jobs as you have tape drives, potentially (assuming, of course, that no one else wants to run a tape job at the same time).
Notice "process multiple erase jobs" implies you are submitting MORE than one job -- you could submit as many jobs as you have tape drives, potentially (assuming, of course, that no one else wants to run a tape job at the same time).
That is how I'm doing it now, but that includes editing 3 variables in each job before submiting (jobname, control unit and tape id). So I'm editing one job all the time and submitting it (while looping jobname from 1 to 5, since there are only 5 usable CU's).
It takes quite a while when the number of tapes is big (500 or more).
Also, browsing each tape in DITTO is quite time consuming...
I was wondering if any segment of the process could be optimised/automatised...
If you have a file with the info in it, then just feed it through a REXX to build the JCL and submit them.
Yes, that could work nicely. It's just that I'm a complete REXX newbie, and if anyone has a sample code that does this (build JCL dynamicaly with changing some variables + submitting), I would be very grateful.
@enrico
Thnx for responding to the security part of the question!
I'm familiar with DoD procedures (and I'm a fan of DBAN btw), but how to implement those in z/OS?
I've been searching and it turns out that only DITTO has the "security erase" (which is basicly - overrun the tape with zeroes, I guess).
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
Quote:
Yes, idealy, I would run a certain job and erase multiple tapes in parallel (sending it to various control units which can erase the tapes in parallel) and another job which would browse the contents of the tapes and make a report to a DS.
I've tryed this with DITTO, but I can't seem to get it working for multiple tapes per job, and also it seems the TB (Tape Browse) function is only available in panel-mode, not JCL...
Multiple tapes per job should be doable (maybe not in parallel) Also most thing done in "panel-mode" can also be done in batch. Show us what you have tried and what problems you have had and maybe we will be able to help you.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
I've butchered a similar task to try to fit your needs and even tested it too
You will need to allocate a PDS (FB 80) and whatever you name it, change the XXXXXXX in the REXX to be the same.
In that PDS put your JCL - With the last character of the jobname being &JNM. In the REXX below, change the word MEMBER for whatever you call the JCL in the PDS.
For the volser use &VOLSER. and for the unit use &UNIT.
Please note that the trailing . (full stop, or dot) should not be dropped but kept in the JCL
e.g.
DD DSN=Whatever,VOL=SER=&VOLSER.,UNIT=&UNIT.,DISP=SHR
PARSE VAR STNAME.AA VOLSER UNIT
Splits the input records into variables named VOLSER and UNIT, obviously if the dataset has them the other way around you can change this.
Substitute YYYYYYYYYY for the dataset that contains the volser and unit information.
The jobname changes automatically from 1 >> 5 and then resets to 1 again.
And run the REXX. Might be an idea to test it with one or two lines of input.
Good luck.
Code:
/* REXX *** READ CARDS AND GENERATE JCL */
SIGNAL ON SYNTAX NAME ERR
"FREE FI(ISPFILE,INDD)"
"ALLOC FI(INDD) DA('YYYYYYYYY') SHR"
"DEL '"SYSUID".ISPFILE'"
"ALLOC FI(ISPFILE) DA('"SYSUID".ISPFILE') NEW TRACKS SPACE(10 10)
RECFM(F B) LRECL(80)"
JNM = 1
"EXECIO * DISKR INDD ( STEM STNAME. "
DO AA = 1 TO STNAME.0
PARSE VAR STNAME.AA VOLSER UNIT
VOLSER = STRIP(VOLSER)
UNIT = STRIP(UNIT)
"ISPEXEC FTOPEN"
"ISPEXEC FTINCL TEST00"
"ISPEXEC FTCLOSE"
"SUBMIT '"SYSUID".ISPFILE'"
JNM = JNM + 1
IF JNM = 6 THEN JNM = 1
END
"FREE FI(ISPFILE,INDD)"
"DEL '"SYSUID".ISPFILE'"
EXIT
ERR:
SIGNAL OFF SYNTAX
SAY "ERROR ROUTINE OUTPUT STARTING"
SAY "ERROR ROUTINE OUTPUT STARTING"
SAY " "
SAY RIGHT(SIGL,6) ">>>" SOURCELINE(SIGL)
SAY " "
TRACE I
INTERPRET SOURCELINE(SIGL)
Multiple tapes per job should be doable (maybe not in parallel) Also most thing done in "panel-mode" can also be done in batch. Show us what you have tried and what problems you have had and maybe we will be able to help you.
Here's what I'm using at the moment (without the jobcard):
But it doesn't work... Returns an ABEND code (if I remember correctly)...
If the EOJ command is inserted after each ERT command it terminates the job on the first execution (ie. after erasing the first tape).
I've been looking through the DITTO book for several days now, it lacks examples. :/
Also, I haven't been able to find a way how to verify that the tapes are really empty, because the TB command is panel-mode only..
@expat
Thank you very much!!
This will also be a nice way for me to learn something useful about REXX, great!
@expat
Sorry for bumping this topic... I have a few questions about the REXX you posted.
I've been reading some REXX books and figuring out what's what.
"ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID()""
"ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('XXXXXXXX')" STACK"
Why is STACK used at the end of the statement? And why is the first line necessary?
"ISPEXEC FTINCL TEST00"
How is TEST00 processed? It says FTINCL is an ISPF command for processing skeleton's, but TEST00 is never declared?
Could you please explain a bit the ERR procedure? Why are there two identical statements at the beginning? What does it do to the trapped synthax errors? (Outputs the faulty line?)
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
Quote:
"ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID()""
"ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('XXXXXXXX')" STACK"
Why is STACK used at the end of the statement? And why is the first line necessary?
The first line clears any pre existing LIBDEF statements
Can not recall why I used STACK but it is explained in the manuals.
The manuals are easily reached from the sticky at the top of the forum topics in the REXX/CLIST forum.
Quote:
"ISPEXEC FTINCL TEST00"
How is TEST00 processed? It says FTINCL is an ISPF command for processing skeleton's, but TEST00 is never declared?
TEST00 is a JCL skeleton stored in the ISPSLIB referenced by the LIBDEF.
Quote:
Could you please explain a bit the ERR procedure? Why are there two identical statements at the beginning? What does it do to the trapped synthax errors? (Outputs the faulty line?)
Two identical statements - originally for foreground use, issue the error message twice - bit more of an eye catcher.
Basically the procedure executes the line in error as the last thing before the exec stops - but uses TRACE I which is the most informative form of the TRACE command and shows all of the substitutions as they happen giving maximum info about the failure.
Can not recall why I used STACK but it is explained in the manuals.
I've been reading mostly REXX Reference and Users's Guide, and haven't been able to find it there. In the REXX Reference book, under ADDRESS there is no mention of STACK, just the environment and the expression, but it's clear that STACK is outside the expression here.
expat wrote:
TEST00 is a JCL skeleton stored in the ISPSLIB referenced by the LIBDEF.
Does it mean LIBDEF creates this skeleton with the ISPEXEC command at the beginning? (because it doesn't exist in ISP.SISPSLIB by default)
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
Quote:
I've been reading mostly REXX Reference and Users's Guide, and haven't been able to find it there. In the REXX Reference book, under ADDRESS there is no mention of STACK, just the environment and the expression, but it's clear that STACK is outside the expression here.
Take a look in the ISPF services manual, it explains LIBDEF in more detail.
Quote:
Does it mean LIBDEF creates this skeleton with the ISPEXEC command at the beginning? (because it doesn't exist in ISP.SISPSLIB by default)
No, the skeleton is created by you. The LIBDEF only tells ISPF which library to search for the skeleton before the normal ISPF concatenation.
I've been reading mostly REXX Reference and Users's Guide, and haven't been able to find it there. In the REXX Reference book, under ADDRESS there is no mention of STACK, just the environment and the expression, but it's clear that STACK is outside the expression here.
STACK is not REXX related, is a parm/option related to ISPF LIBDEF
so the explanation would rather be in the ISPF manual
No, the skeleton is created by you. The LIBDEF only tells ISPF which library to search for the skeleton before the normal ISPF concatenation.
Oh, I misunderstood... I thought XXXXXXX is a sequential data-set, not a library, sorry! (newbie...)
So, TEST00 is a member in XXXXXXX dataset. Hope I got it right this time.
6 *-* ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID()"
+++ RC(-3) +++
7 *-* ADDRESS ISPEXEC "LIBDEF ISPSLIB DATASET ID('MYUSER.PRIVLIB')" STACK
+++ RC(-3) +++
IKJ56247I FILE ISPFILE NOT FREED, IS NOT ALLOCATED
IKJ56247I FILE INDD NOT FREED, IS NOT ALLOCATED
IDC3012I ENTRY MYUSER.ISPFILE NOT FOUND+
IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
IDC0551I ** ENTRY MYUSER.ISPFILE NOT DELETED
IDC0014I LASTCC=8
......
IKJ56265I INPUT DATA SET MYUSER.ISPFILE NOT USABLE+
IKJ56265I THE DATA SET IS EMPTY
......
IKJ56861I FILE INDD NOT FREED, DATA SET IS OPEN
IDC0550I ENTRY (A) MYUSER.ISPFILE DELETED
READY
END
"......" means those two messages are repeated as many times as there are VOLSERs in the RES data set.
First few messages are harmless, but I guess the "NOT USABLE" message is critical - it means the generated JCL isn't saved to the ISPFILE?
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
You are running ISPF under TSO, and will need to allocate the required ISPF libraries to your batch job.
TSO ISRDDN on the command line will show all of the alllocated ISPF libraries for your foreground session. These will need to be replicated in your JCL.
Here is what I usually use. Although there may be some subtle differences from site to site, this should suffice almost anywhere.
The concatenation from ISRDDN is quite long for some libs...
I guess all those datasets aren't really necessary in this case...?
For example, isn't SYSPROC and SYSEXEC concatenation useless here, because the only exec is in my REXX lib?
I tried the example you provided, but didn't put all the datasets from ISRDDN (didn't use some with unusual HLQ), and it's still the same error (ISPFILE isn't populated with the generated job).
Is there a shorter allocation of libs in this case? 3 or 4 maybe on which to focus on?
.jpg)
