|
View previous topic :: View next topic
|
| Author |
Message |
Rajesh N P
New User
.jpg)
Joined: 09 Aug 2011
Posts: 1
Location: india
|
|
|
|
| I need a JCL or any other program to do HRECALL of multiple PDS at once, can you please give a sloution to it. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Use a batch TSO job with multiple HRECALL commands. |
|
| Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007
Posts: 1399
Location: IL, USA
|
|
|
|
HRECALL is command. just find how to run tso command in batch...
and for multiple PDS... HRECALL accepts dataset wildcard LIKE abc.xyz.* |
|
| Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007
Posts: 1399
Location: IL, USA
|
|
| Back to top |
|
|
Nanda kumaar
New User
Joined: 09 Jul 2011
Posts: 8
Location: India
|
|
|
|
You can use below for recalling the multiple PDS through JCL.
| Code: |
//SAMPLE EXEC PGM=IKJEFT01
//SYSTSPRT DD *
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSTSIN DD *
HRECALL 'PDS1'
HRECALL 'PDS2'
HRECALL 'PDS3'
HRECALL 'PDS4'
/*
|
|
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
i wrote a REXX script to accomplish this. It can be improved, but it works for me:
| Code: |
/* REXX */
/* */
/* TSO DBZHLIST HLQ.BRENHOD */
/* WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.BRENHOD */
/* */
/* TSO DBZHLIST HLQ.WORK */
/* WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.WORK */
/* */
/* TSO DBZHLIST HLQ.UNIT */
/* WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.UNIT*/
/* */
/* */
ARG DUH_DS
IF LENGTH(DUH_DS) < 1 THEN
DO
ZEDSMSG = "NO HLQ ENTERED"
ZEDLMSG = "YOU MUST ENTER A HLQ.NLQ ETC../TSO DBZHLIST HELP"
ADDRESS ISPEXEC "SETMSG MSG(ISRZ001)"
EXIT
END
IF DUH_DS = 'HELP' THEN
DO
SAY ' TSO DBZHLIST HLQ.BRENHOD '
SAY ' WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.BRENHOD* '
SAY ' '
SAY ' TSO DBZHLIST HLQ.WORK '
SAY ' WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.WORK* '
SAY ' '
SAY ' TSO DBZHLIST HLQ.UNIT.LG1 '
SAY ' WILL GENERATE HRECALLS FOR ALL DATASETS HLQ.UNIT.LG1* '
SAY ' '
SAY ' DO NOT USE * FOR WILDCARD '
EXIT
END
DUH_USER = USERID()
DSN = DUH_USER !! '.TEST'
ADDRESS ISPEXEC 'CONTROL ERRORS RETURN'
ADDRESS TSO 'ALLOC F(OUT) DA('DSN') MOD DELETE TRACKS SPA(15 15) ' ,
' LRECL(80) RECFM(F B) BLKSIZE(0) DSORG(PS)'
IF RC > 0 THEN
DO
SAY 'DELETE ALLOCATION FAILED RC=:' RC
ADDRESS TSO 'FREE F(OUT)'
EXIT
END
ADDRESS TSO 'FREE F(OUT)'
/* */
/* FIND ALL MIGRATION LEVELS USE ML2 */
/* */
ADDRESS TSO
"HLIST LEVEL("DUH_DS") SELECT(ML2) OUTDATASET("DSN")"
INPUT1_STEM. = ''
DSN_STEM. = ''
DSN_STEM.0 = 0
ADDRESS TSO 'ALLOC F(IN) DA('DSN') OLD KEEP '
IF RC > 0 THEN
DO
SAY 'ALLOCATION FOR ML2 FAILED RC=:' RC
ADDRESS TSO 'FREE F(IN)'
EXIT
END
ADDRESS TSO 'EXECIO * DISKR IN (STEM INPUT1_STEM. FINIS)'
ADDRESS TSO 'FREE F(IN)'
/* TRACE ?R */
J = 0
DO I = 1 TO INPUT1_STEM.0
IF POS(DUH_DS,INPUT1_STEM.I) > 0 THEN
DO
PARSE VAR INPUT1_STEM.I DSN_FOR_INCLUSION .
J = J + 1
DSN_STEM.J = DSN_FOR_INCLUSION
END
END
DSN_STEM.0 = J
/* */
/* */
/* FIND ALL MIGRATION LEVELS USE ML1 */
/* */
ADDRESS TSO
"HLIST LEVEL("DUH_DS") SELECT(ML1) OUTDATASET("DSN")"
INPUT2_STEM. = ''
ADDRESS TSO 'ALLOC F(IN) DA('DSN') OLD KEEP '
IF RC > 0 THEN
DO
SAY 'ALLOCATION FOR ML1 FAILED RC=:' RC
ADDRESS TSO 'FREE F(IN)'
EXIT
END
ADDRESS TSO 'EXECIO * DISKR IN (STEM INPUT2_STEM. FINIS)'
ADDRESS TSO 'FREE F(IN)'
/* TRACE ?R */
DO I = 1 TO INPUT2_STEM.0
IF POS(DUH_DS,INPUT2_STEM.I) > 0 THEN
DO
PARSE VAR INPUT2_STEM.I DSN_FOR_INCLUSION .
SCHON_DA = 'N'
DO M = 1 TO J
IF DSN_STEM.M = DSN_FOR_INCLUSION THEN
DO
SCHON_DA = 'J'
LEAVE
END
END
IF SCHON_DA = 'N' THEN
DO
J = J + 1
DSN_STEM.J = DSN_FOR_INCLUSION
END
END
END
DSN_STEM.0 = J
/* */
/* */
OUTPUT_STEM. = ''
OUTPUT_STEM.1 = '//STEP1 EXEC PGM=IKJEFT01,REGION=512K'
OUTPUT_STEM.2 = '//SYSPRINT DD SYSOUT=*'
OUTPUT_STEM.3 = '//SYSTSPRT DD SYSOUT=*'
OUTPUT_STEM.4 = '//SYSTSIN DD *'
J = 4
DO I = 1 TO DSN_STEM.0
J = J + 1
OUTPUT_STEM.J = ' HRECALL ' !! '7D'X !! DSN_STEM.I !! '7D'X
END
OUTPUT_STEM.0 = J
ADDRESS TSO 'ALLOC F(OUT) DA('DSN') OLD KEEP'
IF RC > 0 THEN
DO
SAY 'ALLOCATION FAILED RC=:' RC
ADDRESS TSO 'FREE F(OUT)'
EXIT
END
ADDRESS TSO 'EXECIO * DISKW OUT (STEM OUTPUT_STEM. FINIS)'
ADDRESS TSO 'FREE F(OUT)'
ADDRESS ISPEXEC "EDIT DATASET('HLQ."DUH_USER".TEST') MACRO(JOBCARD)"
EXIT
|
couple of notes:
1. found that if I ran ml1 list after the ml2, i received the ml1, also,
so that is why the duplicate check. someone with better understanding of hl.... can provide suggestions.
2. hlq.duh_user.test is invoked view edit,
you can delete those that you don't want to recall.
3. MACRO jobcard, is a simple macro that inserts a jobcard at the beginning of the job (hlq.duh_user.test).
so, tso dbzhlist hlq.(mlq.llq)
delete what you don't want to recall
submit,
end
no, I will not explain one line of code. |
|
| Back to top |
|
|
BrantleyL
New User
Joined: 03 Jun 2010
Posts: 14
Location: Dallas TX
|
|
|
|
Here's an easier way to do it... We have a job that uses dfdss to backup datasets. Unfortunately, dfdss won't recall datasets so the backup just posts a bad rc.
Our job has a prior step that refers to all the datasets we are going to back up:
| Code: |
//NMPS0005 EXEC PGM=IEFBR14
//DD01 DD DSN=DATA.SET1(+0),DISP=SHR
//DD02 DD DSN=DATA.SET2(+0),DISP=SHR
//DD03 DD DSN=DATA.SET3(+0),DISP=SHR
//DD04 DD DSN=DATA.SET4(+0),DISP=SHR
...ETC
|
|
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| BrantleyL wrote: |
Here's an easier way to do it... We have a job that uses dfdss to backup datasets. Unfortunately, dfdss won't recall datasets so the backup just posts a bad rc.
Our job has a prior step that refers to all the datasets we are going to back up:
| Code: |
//NMPS0005 EXEC PGM=IEFBR14
//DD01 DD DSN=DATA.SET1(+0),DISP=SHR
//DD02 DD DSN=DATA.SET2(+0),DISP=SHR
//DD03 DD DSN=DATA.SET3(+0),DISP=SHR
//DD04 DD DSN=DATA.SET4(+0),DISP=SHR
...ETC
|
|
great, but the TS wants to recall a dataset that has been backed-up.
glad to see you are on your toes.
plus the IEFBR14 stupidity as a job stays active until the recalls are complete.
using the HRECALL, the job finishes as soon as the parms are sent,
and then the datasets are recovered in their own time,
without a job sitting active.
 |
|
| Back to top |
|
|
BrantleyL
New User
Joined: 03 Jun 2010
Posts: 14
Location: Dallas TX
|
|
|
|
All true Dick, but our job needs to do a backup immediately. Sometimes the datasets get migrated, sometimes (usually) not. So waiting on the recall is necessary - not a problem. More likely to be migrated if the job is a weekly one.
A "normal" job (where the date set is referred to in the JCL) will recall a data set, but DFDSS does not (since it is in an input card). |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
i see what you are doing and agree, you have to do it that way.
but, why are ds that are scheduled for backup, being migrated before the backup?
I interpreted the TS's question:
how do i easily recalled migrated ds? |
|
| Back to top |
|
|
BrantleyL
New User
Joined: 03 Jun 2010
Posts: 14
Location: Dallas TX
|
|
|
|
| HSM has control of the migration of datasets. Sometimes, it seems random when it actually migrates them. Some datasets are not used daily. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
far as I am concerned, a migrated ds is "backed-up".
I know that HSM controls the migragtion. It has controlling parms.
My question is if a ds is so important that it needs to be backed-up,
why is it on the migration list? |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
|
|
Hi,
recalling datasets via IEFBR14 is still a dumb idea as it recalls one dataset at a time.
If you have have thousands of datasets to recall it can take hours, the same ML2 volume could be mounted hundreds of times.
I would generate HRECALL statements with NOWAIT and submit the job.
You can then still run the IEFBR14 job a little later but by now most if not all of the datasets would have been recalled.
The link below might also help
ibmmainframes.com/viewtopic.php?t=55303&highlight=hrecall
Gerry |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| far as I am concerned, a migrated ds is "backed-up". |
I <mildly> disagree 
a migrated dataset is a migrated dataset period
for an active or a migrated dataset only one copy exists
from dataset management point of view a migrated dataset it is treated as a normal dataset
when it is deleted it is gone.
when a dataset is backed up, there are multiple copies around,
and deleting the <primary> occurrence, that might be migrated, will leave the backups around for a recovery . |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
yeah, i overspoke there. migragted is not backed-up.
i lost concentration on my central point by making that comment.
quick question: when a back-up is made, is the access of the DS by the utility
counted by migration-process?
key issue is why make back-ups periodically? why not everyday?
i work in a migration-obsessed shop,
yet there are DSs that are not accessed everyday by me or my co-workers
yet are never migrated.
that indicates to me either there is an migration exclusion or the daily back-ups
affect the migration process (prevent). |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
SMS and HSM do work together quite well, just so long as all the parameters are defined correctly.
Usually, he says tongue in cheek, things do go quite well. However there is the odd scenario when fingers intervene and spoil it all. Depending on the settings ML1 migrated datasets will be backed up if the SMS rules say so and the HSM parameter agrees with it.
I once changed the HSM parameter to ensure that at least one backup copy existed for all DASD resident datasets and by doing so stopped the ML1 dataset backup process, and then spent some hours wondering why on earth the ML1 volumes were so full  and quickly changed back, done the ML1 backups and migrated all to ML2.
Also depends on the SMS settings if a dataset can be migrated to ML2 without backup, which can be a PITA when you want to do backups outside of an application.
For the example above of doing the IEFBR14 recalls before the DFdss backup, why not do the backups at the end of the application which gives a PIT backup for that application.
Or, why not allow HSM to perform and maintain backups of GDS. |
|
| Back to top |
|
|
|
|
