|
View previous topic :: View next topic
|
| Author |
Message |
Ivan P
New User
Joined: 08 Jun 2009
Posts: 63
Location: Europe
|
|
|
|
Hello everyone 
I'm wondering about a problem encountered by DFSMShsm, so maybe someone here has a good idea?
While hsm is trying to backup a zFS dataset, like so:
| Code: |
DUMP DATASET(INCLUDE(SOME.DATASET)) -
OUTDDNAME(SYS01111) CANCELERROR OPTIMIZE(2) -
SPHERE -
SHARE -
CONCURRENT |
it fails with RC=68 and a specific reason code. The cause of the problem is in the ADR980E. message.
In short: This message can be received if a source zFS data set is unmounted while DFSMSdss is attempting to serialize the data set.
(but the dataset is constantly mounted?)
If the same dataset is copied-renamed (with a job, PGM=ADRDSSU), like so:
| Code: |
COPY DATASET(INCLUDE(SOME.DATASET)) -
CANCELERROR OUTDDNAME(OUTVOL1) PERCENTUTILIZED(100) -
CATALOG RENAMEUNCONDITIONAL(SOME.DATASET, SOME.DATASET2) -
TGTALLOC(SOURCE) TOL(ENQF) FASTREP(PREF) WAIT(2,2) |
it's all OK.
Does anyone know is there a way to force hsm into using different parameters, which would result in a successful backup? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Your post is extremely confusing. You mention DFSMShsm, but nothing else after the first sentence is in any way related to HSM. ADRDSSU is not HSM, and HSM is not ADRDSSU.
Furthermore, you indicate the ADR980E message is
| Quote: |
| received if a source zFS data set is unmounted while DFSMSdss is attempting to serialize the data set. |
This is absolutely untrue. zFS files cannot be reliably backed up while active updates are allowed. To ensure a good backup is taken, the zFS file is quiesced so no update activity can occur while the backup is underway. The ADR980E message means the quiesce failed for some reason. The message may mean that the zFS file was unmounted while the quiesce was underway, but you can also receive this message if you attempt to back up a zFS file that is allocated to another LPAR, for example -- there are multiple reasons the quiesce may fail without any unmount attempts being made. |
|
| Back to top |
|
|
Ivan P
New User
Joined: 08 Jun 2009
Posts: 63
Location: Europe
|
|
|
|
Hello Robert, thanks for Your response.
| Robert Sample wrote: |
| Your post is extremely confusing. You mention DFSMShsm, but nothing else after the first sentence is in any way related to HSM. ADRDSSU is not HSM, and HSM is not ADRDSSU. |
I'm aware that ADRDSSU is not HSM and vice-versa. I thought the post was clear about the problem - HSM is using ADRDSSU DUMP utility which cannot backup a specific zFS data set. I'm sure the same result would be, if ADRDSSU DUMP was used from a job with those same parameters.
 If you know a clearer way to ask this question, PLEASE send it to me (via PM or similar), so I can understand why the posts are confusing.
I mentioned HSM, because my final question is related to it:
| Ivan P wrote: |
| Does anyone know is there a way to force hsm into using different parameters, which would result in a successful backup? |
| Robert Sample wrote: |
| This is absolutely untrue. zFS files cannot be reliably backed up while active updates are allowed. |
I quoted what I found following the error messages and IBM literature.
| Robert Sample wrote: |
| To ensure a good backup is taken, the zFS file is quiesced so no update activity can occur while the backup is underway. The ADR980E message means the quiesce failed for some reason. The message may mean that the zFS file was unmounted while the quiesce was underway, but you can also receive this message if you attempt to back up a zFS file that is allocated to another LPAR, for example -- there are multiple reasons the quiesce may fail without any unmount attempts being made. |
Thank You for the explanation.
Problem is the one You mention - zFS data set is mounted on a different LPAR, from the one that's running DFSMShsm.
Is there anything that can be done, in HSM configuration, to bypass this problem?
Or, is mounting the zFS data set on the LPAR which is running HSM the proper way? |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Have you tried adding the TOL(ENQF) parameter to the dump command |
|
| Back to top |
|
|
Ivan P
New User
Joined: 08 Jun 2009
Posts: 63
Location: Europe
|
|
|
|
| nevilh wrote: |
| Have you tried adding the TOL(ENQF) parameter to the dump command |
Please note that the goal is to make HSM do the backup, not to do it with a job. Is there a way to configure HSM to use TOL(ENQF) parameter? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
I found this in the documentation
| Quote: |
APAR Identifier ...... OA06297
PROBLEM DESCRIPTION: If a backup is attempted on a zFS
aggregate in a sysplex from a
non owning system,the backup
will fail. |
It looks like mounting the ZFS on the LPAR where HSM is running is the way forward |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Also, if you have TSM installed (Formerly ADSM), this would be a better backup solution as it was designed as a sort of non mainframe HSM. |
|
| Back to top |
|
|
Ivan P
New User
Joined: 08 Jun 2009
Posts: 63
Location: Europe
|
|
|
|
Thank You Peter, it is helpful.
I'll put a quote here, for archiving reasons of the forum..
| IBM wrote: |
In addition to these three levels, the LFS also uses a quiesce latch, which is assigned to any file system that is:
•Quiesced by the BPX1QSE callable service, which is used by HSM and other utilities to backup or dump file systems.
•For sysplex operations that operate against the file system as a whole, such as moving and recovering.
When a file system is quiesced, normal operations are suspended, and threads wait suspended for the file system's quiesce latch. The system may hold the quiesce latch for longer than the duration of a system call. Note that HSM does not use the quiesce latch for zFS file systems.
Use the DISPLAY OMVS,FILE command to look for quiesce latch contention on your system. |
| nevilh wrote: |
| It looks like mounting the ZFS on the LPAR where HSM is running is the way forward |
Yes.. it seems there's no other way. Thank You for the information.
| expat wrote: |
| Also, if you have TSM installed (Formerly ADSM), this would be a better backup solution as it was designed as a sort of non mainframe HSM. |
Yes, that would be better.. no TSM installed unfortunately, thank You for the hint. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| As far as I know, there is no way to configure HSM to quiesce a file system mounted on another LPAR -- either HSM cannot back up the file, or the zFS file system must be mounted on the same LPAR. You might search the IBM problem data base to see if they've come up with some way to do this, but if they have I haven't heard about it yet. |
|
| Back to top |
|
|
Ivan P
New User
Joined: 08 Jun 2009
Posts: 63
Location: Europe
|
|
|
|
Here's an update..
After enabling HSM to run on the system where the zFS dataset is mounted, it's the same result...
Here's the output:
| Code: |
ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES
DUMP DATASET(INCLUDE(OMVS.DATASET)) -
OUTDDNAME(SYS06472) CANCELERROR OPTIMIZE(2) -
SPHERE -
SHARE -
CONCURRENT
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP '
ADR109I (R/I)-RI01 (01), 2010.042 23:02:53 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE
ADR035I (001)-PRIME(50), INSTALLATION EXIT ALTERED TAPE BLOCK SIZE DEFAULT TO 32 K-BYTES
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
ADR006I (001)-STEND(01), 2010.042 23:02:53 EXECUTION BEGINS
ADR980E (001)-DTDSC(01), THE BPX1PCT PROGRAM FAILED DURING QUIESCE
PROCESSING FOR DATA SET OMVS.DATASET WITH
RETURN CODE 0000009C AND REASON CODE 0B0C00FA
ADR801I (001)-DTDSC(01), DATA SET FILTERING IS COMPLETE. 0 OF 1 DATA
SETS WERE SELECTED: 1 FAILED SERIALIZATION AND 0 FAILED FOR
OTHER REASONS.
ADR734I (001)-DTDSC(01), 2010.042 23:03:07 CONCURRENT COPY INITIALIZATION SUCCESSFUL FOR 0 OF 0 SELECTED DATA SETS. THE
INTERMEDIATE RETURN CODE IS 0008.
ADR415W (001)-DTDSC(04), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME
ADR006I (001)-STEND(02), 2010.042 23:03:07 EXECUTION ENDS
ADR013I (001)-CLTSK(01), 2010.042 23:03:07 TASK COMPLETED WITH RETURN CODE 0008
ADR012I (SCH)-DSSU (01), 2010.042 23:03:07 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0008 FROM:
TASK 001
ARC0734I ACTION=BACK-UP FRVOL=MYVOL TOVOL=MYTAPE TRACKS= 20880 RC= 68, REASON= 980, AGE= 140,
DSN=OMVS.DATASET
ARC0723I BACKUP ENDING ON VOLUME MYVOL AT 23:03:07, 00000000 DATA SETS BACKED UP |
Suggestions welcome, thanks! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Check IBM APAR OA23236. I suspect there's an issue with RACF since return code 0000009C and reason code 0B0C00FB (very close to what you're seeing) appear when someone without an OMVS segment attempts to use ishell. The APAR says some changes were made to HSM and ADRDSSU that may require RACF changes at your site to get this to work. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
I agree with Robert my docs have the following
| Quote: |
The 0B0C00FA return code indicates that the current group is
not authorized to use OpenMVS. |
|
|
| Back to top |
|
|
|
|
