A couple other folks have commented on the SHRLEVEL default, but I
didn't want to overlook the STOP that was issued, which I believe
was the larger issue here. The STOP shouldn't be needed just
because the copy is running shrlevel reference, but I believe BMC
Copy issues a STOP to reset modified page bits. If this was the
reason for the STOP then you should be able to eliminate it by
including "RESETMOD NO" on your copy statement.
STOPP is a fairly nasty status and it's possible to get into
situations like you mentioned where a DISPLAY just hangs waiting
behind the STOP. I believe V9 was the first release that did allow
the STOP to be cancelled, so that should have been an option to get
out of it.
From: Balasubramaniyan Rengan [mailto:[login to unmask email]
Sent: Friday, August 03, 2012 12:36 PM
To: [login to unmask email]
Subject: [DB2-L] - DB2 for z/OS BMC Image Copy
We are running DB2 for z/OS V9 in CM with BMC Utilities. We
recently had an incident where a BMC Image copy was run on one of
the busiest production tablespaces during business hours without
specifying any SHRLEVEL option. This took the default option for
SHRLEVEL as REFERENCE and issued a STOP at UTILTERM phase. As there
was a long running batch job holding a MDEL lock on that
tablespace, the STOP couldn't succeed and the tablespace went to
STOPP status. The TSO ids which issued a DISPLAY on that tablespace
via BMC Catalog Manager hanged and we couldn't cancel them.
Finally, we looked the status through Omegamon, cancelled the long
running job so the table went to STOP and started manually.
This incident prompted many questions.
1) Why would BMC have a default option for SHRLEVEL as REFERENCE
when we have CHANGE? If I would like a consistent copy, I will code
the SHELEVEL explicitly anyway. It would be great to have this
default changed to SHRLEVEL CHANGE unless there is a strong reason
to have REFERENCE as a default?!
2) Why Catalog Manager hanged and refused to show the status of the
3) The object was in STOPP status for almost around an hour. I read
in the command reference that if the STOP cannot get the drain
locks on the first request, it repeatedly tries again and the
command fails if it times out more than 15 times trying to get the
locks. I wonder why this did not occur here and how long the STOP
will be trying to get the locks per try?
4) Would cancelling the thread of the STOP command (020.STOPDB09)
help in similar situation rather than cancelling the batch job
which was holding the STOP?
Thanks in advance.
-----End Original Message-----
This e-mail message is intended only for the use of the individual
entity to which it is addressed, and may contain information that
privileged, confidential and exempt from disclosure under
If you are not the intended recipient, any dissemination,
copying of this communication is strictly prohibited. If you
received this communication in error, please notify us immediately
reply email to [login to unmask email] and delete or destroy all
the original message and attachments thereto. Email sent to or from
Principal Financial Group or any of its member companies may be
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic
for purposes of the Uniform Electronic Transactions Act (UETA) or
Electronic Signatures in Global and National Commerce Act
unless a specific statement to the contrary is included in this
While this communication may be used to promote or market a
or an idea that is discussed in the publication, it is intended to
general information about the subject matter covered and is
the understanding that The Principal is not rendering legal,
or tax advice. It is not a marketed opinion and may not be used to
penalties under the Internal Revenue Code. You should consult
appropriate counsel or other advisors on all matters pertaining to
tax, or accounting obligations and requirements