Runstats Command Question

[Todd McNeill]

Hi-

Something was just pointed out to me this morning. According to the
V8 Command Reference, the RUNSTATS command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses, and it looks to be replaced with ALLOW
READ/WRITE ACCESS. Is SHRLEVEL still a valid clause and
interchangable with ALLOW..., or has it been deprecated and is it, or
will it eventually become, invalid? We currently are not seeing any
errors using SHRLEVEL in our scripts that we've migrated from V7.

Thanks,
Todd

[Rhino]

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...

Hi-

Something was just pointed out to me this morning. According to the
V8 Command Reference, the RUNSTATS command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses, and it looks to be replaced with ALLOW
READ/WRITE ACCESS. Is SHRLEVEL still a valid clause and
interchangable with ALLOW..., or has it been deprecated and is it, or
will it eventually become, invalid? We currently are not seeing any
errors using SHRLEVEL in our scripts that we've migrated from V7.

<rant>
I wish people posting questions to this newsgroup would identify which
version of DB2 they are using and what OS they are running on! I just spent
20 minutes searching for z/OS documents that proved SHRLEVEL still exists in
DB2 UDB V8 for z/OS and that ALLOW READ/WRITE ACCESS doesn't when I thought
to check the DB2 UDB V8 for Linux/Unix/Windows docs and found out that the
question is valid after all, at least for Linux/Unix/Windows!
</rant>

Unfortunately, the V8 docs for Linux/Unix/Windows don't mention SHRLEVEL at
all so only the IBM developers can tell us how much longer the SHRLEVEL
clause will be supported. Frankly, I'm surprised that it works at all in V8;
I would have expected to get an error message if I used a clause that wasn't
documented in the manual.

Unless someone from IBM can be persuaded to tell us how much longer the
SHRLEVEL clause will be supported, I think the smart move would be to modify
your scripts to use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause. Otherwise, you may find that you install a
fixpack and suddenly your scripts won't work any more.

Rhino

[Todd McNeill]

My bad. We're using DB2 V8.1 FP6 Workgroup on Solaris 8. Consider me
sufficiently chastised.

I'll take your advice into account and also open up a support ticket
with IBM to see if I can get an answer. It won't be that difficult to
change the scripts.

Thanks,
Todd

"Rhino" <rh****@NOSPAM. sympatico.ca> wrote in message news:<me******* **************@ news20.bellglob al.com>...

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...

Hi-

Something was just pointed out to me this morning. According to the
V8 Command Reference, the RUNSTATS command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses, and it looks to be replaced with ALLOW
READ/WRITE ACCESS. Is SHRLEVEL still a valid clause and
interchangable with ALLOW..., or has it been deprecated and is it, or
will it eventually become, invalid? We currently are not seeing any
errors using SHRLEVEL in our scripts that we've migrated from V7.

<rant>
I wish people posting questions to this newsgroup would identify which
version of DB2 they are using and what OS they are running on! I just spent
20 minutes searching for z/OS documents that proved SHRLEVEL still exists in
DB2 UDB V8 for z/OS and that ALLOW READ/WRITE ACCESS doesn't when I thought
to check the DB2 UDB V8 for Linux/Unix/Windows docs and found out that the
question is valid after all, at least for Linux/Unix/Windows!
</rant>

Unfortunately, the V8 docs for Linux/Unix/Windows don't mention SHRLEVEL at
all so only the IBM developers can tell us how much longer the SHRLEVEL
clause will be supported. Frankly, I'm surprised that it works at all in V8;
I would have expected to get an error message if I used a clause that wasn't
documented in the manual.

Unless someone from IBM can be persuaded to tell us how much longer the
SHRLEVEL clause will be supported, I think the smart move would be to modify
your scripts to use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause. Otherwise, you may find that you install a
fixpack and suddenly your scripts won't work any more.

Rhino

[Rhino]

Sorry, I hope you didn't take my "rant" as a personal attack. It's a pet
peeve of mine that many users of this newsgroup don't bother to identify
which DB2 and platform they are using which means that responders either
have to guess or ask that question before they can begin to help.

I have more experience with Runstats on z/OS than on Windows/Linux/Unix and
forgot that SHRLEVEL was present on the Windows/Linux/Unix version of
Runstats so I assumed the question was a z/OS question. But that's *my*
fault for jumping to conclusions, not yours ;-)

---

I had hoped that Serge Rielau or another of the IBMers would jump in and
tell us how long the SHRLEVEL clause will be supported but he didn't so I
guess the support ticket is the way to go. If you think of it, could you
post a short note with what you find out? It might be of interest to others
on this newsgroup.

Rhino

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...

My bad. We're using DB2 V8.1 FP6 Workgroup on Solaris 8. Consider me
sufficiently chastised.

I'll take your advice into account and also open up a support ticket
with IBM to see if I can get an answer. It won't be that difficult to
change the scripts.

Thanks,
Todd

"Rhino" <rh****@NOSPAM. sympatico.ca> wrote in message

news:<me******* **************@ news20.bellglob al.com>...

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...

Hi-

Something was just pointed out to me this morning. According to the
V8 Command Reference, the RUNSTATS command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses, and it looks to be replaced with ALLOW
READ/WRITE ACCESS. Is SHRLEVEL still a valid clause and
interchangable with ALLOW..., or has it been deprecated and is it, or
will it eventually become, invalid? We currently are not seeing any
errors using SHRLEVEL in our scripts that we've migrated from V7.

<rant>
I wish people posting questions to this newsgroup would identify which
version of DB2 they are using and what OS they are running on! I just spent 20 minutes searching for z/OS documents that proved SHRLEVEL still exists in DB2 UDB V8 for z/OS and that ALLOW READ/WRITE ACCESS doesn't when I thought to check the DB2 UDB V8 for Linux/Unix/Windows docs and found out that the question is valid after all, at least for Linux/Unix/Windows!
</rant>

Unfortunately, the V8 docs for Linux/Unix/Windows don't mention SHRLEVEL at all so only the IBM developers can tell us how much longer the SHRLEVEL
clause will be supported. Frankly, I'm surprised that it works at all in V8; I would have expected to get an error message if I used a clause that wasn't documented in the manual.

Unless someone from IBM can be persuaded to tell us how much longer the
SHRLEVEL clause will be supported, I think the smart move would be to modify your scripts to use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause. Otherwise, you may find that you install a fixpack and suddenly your scripts won't work any more.

Rhino

[Serge Rielau]

Comments from "backstage" :
(1) SHRLEVEL CHANGE/REFERENCE are Runstats v7.x and lower releases
option to specify other user's access right when a Runstats command is
executing. In DB2 V8.x we enhanced Runstats utility by implementing new
features and modifies the Runstats API/CLP syntax as well. ALLOW
READ/WRITE ACCESS are V8.x syntax counterpart for SHRLEVEL
CHANGE/REFERENCE in V7.x.
(2) Knowing that many customers are still using down level DB2 UDB
(i.e., <= V7.x releases), Runstats V8.x is still supporting the valid
down level Runstats option (syntax), including SHRLEVEL CHANGE/REFERENCE
clauses. That's why the customer's script still run successfully on V8.
(3) I checked V8 Command Reference, I didn't find any place explicitly
mentioning that RUNSTATS V8 command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses. But also, it is not explicitly mentioned that
Runstats is still supporting the down level option (syntax). Maybe that
causes a bit confusing? Would we that be necessary to open a doc defect
to fix it? I'll consult with my colleagues on this.
(4) I agree with Rhino: a smart move would be to modify the scripts to
use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause, since the customer is using V8 at the
moment. But I would not think that Runstats will stop supporting down
level syntax (option) soon.
My own comments:
From an ID perspective we try to document the preferred language and
have a footnote in the line of:
For compatibility with xxxx DB2 also supports yyyy as a synonym for zzzzz
Seems like that got lost in this case.
At least for SQL I have NEVER seen DB2 desupport an option.
Just look at VALUE

Cheers
Serge

[Rhino]

"Serge Rielau" <sr*****@ca.ibm .com> wrote in message
news:2t******** *****@uni-berlin.de...

Comments from "backstage" :
(1) SHRLEVEL CHANGE/REFERENCE are Runstats v7.x and lower releases
option to specify other user's access right when a Runstats command is
executing. In DB2 V8.x we enhanced Runstats utility by implementing new
features and modifies the Runstats API/CLP syntax as well. ALLOW
READ/WRITE ACCESS are V8.x syntax counterpart for SHRLEVEL
CHANGE/REFERENCE in V7.x.
(2) Knowing that many customers are still using down level DB2 UDB
(i.e., <= V7.x releases), Runstats V8.x is still supporting the valid
down level Runstats option (syntax), including SHRLEVEL CHANGE/REFERENCE
clauses. That's why the customer's script still run successfully on V8.
(3) I checked V8 Command Reference, I didn't find any place explicitly
mentioning that RUNSTATS V8 command no longer uses the SHRLEVEL
CHANGE/REFERENCE clauses. But also, it is not explicitly mentioned that
Runstats is still supporting the down level option (syntax). Maybe that
causes a bit confusing? Would we that be necessary to open a doc defect
to fix it? I'll consult with my colleagues on this.
(4) I agree with Rhino: a smart move would be to modify the scripts to
use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause, since the customer is using V8 at the
moment. But I would not think that Runstats will stop supporting down
level syntax (option) soon.
From your remark in the next paragraph, it doesn't sound like you expect for
SHRLEVEL *ever* to be dropped. In that case, there is not as much point in
modifying the scripts to use ALLOW clause instead. I only suggested changing
the scripts because it struck me as possible that SHRLEVEL was being phased
out and would be disallowed sometime in the near future. As you pointed out
though, no such clause has ever been dropped from DB2 before so there is not
much reason to expect it to happen in the future.

Mind you, if the SHRLEVEL and ALLOW clauses do exactly the same thing, I
have to wonder why the change was made in the first place. But that's "water
under the bridge". I expect it would cause all sorts of grief to drop the
ALLOW clause now, especially among people who have already converted their
scripts to use it.
My own comments:
From an ID perspective we try to document the preferred language and
have a footnote in the line of:
For compatibility with xxxx DB2 also supports yyyy as a synonym for zzzzz
Seems like that got lost in this case.
At least for SQL I have NEVER seen DB2 desupport an option.
Just look at VALUE
If the SHRLEVEL clause is likely to be supported for the foreseeable future,
I think it would be a good idea to document the availability of this clause
in the documentation. Otherwise, you're bound to get other people scratching
their heads like Todd and I did when they see that SHRLEVEL still works,
even though it is not even mentioned in the V8 manuals.

Just my two cents worth.

Rhino Cheers
Serge

[Todd McNeill]

No worries. I had made the (obviously bad) assumption that all
flavors of DB2 use the same command syntax. I guess I'm taking the
"Universal" part of UDB too much to heart :)

Todd
"Rhino" <rh****@NOSPAM. sympatico.ca> wrote in message news:<EN******* **************@ news20.bellglob al.com>...

Sorry, I hope you didn't take my "rant" as a personal attack. It's a pet
peeve of mine that many users of this newsgroup don't bother to identify
which DB2 and platform they are using which means that responders either
have to guess or ask that question before they can begin to help.

I have more experience with Runstats on z/OS than on Windows/Linux/Unix and
forgot that SHRLEVEL was present on the Windows/Linux/Unix version of
Runstats so I assumed the question was a z/OS question. But that's *my*
fault for jumping to conclusions, not yours ;-)

---

I had hoped that Serge Rielau or another of the IBMers would jump in and
tell us how long the SHRLEVEL clause will be supported but he didn't so I
guess the support ticket is the way to go. If you think of it, could you
post a short note with what you find out? It might be of interest to others
on this newsgroup.

Rhino

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...

My bad. We're using DB2 V8.1 FP6 Workgroup on Solaris 8. Consider me
sufficiently chastised.

I'll take your advice into account and also open up a support ticket
with IBM to see if I can get an answer. It won't be that difficult to
change the scripts.

Thanks,
Todd

"Rhino" <rh****@NOSPAM. sympatico.ca> wrote in message

news:<me******* **************@ news20.bellglob al.com>...

"Todd McNeill" <to********@yah oo.com> wrote in message
news:9c******** *************** ***@posting.goo gle.com...
> Hi-
>
> Something was just pointed out to me this morning. According to the
> V8 Command Reference, the RUNSTATS command no longer uses the SHRLEVEL
> CHANGE/REFERENCE clauses, and it looks to be replaced with ALLOW
> READ/WRITE ACCESS. Is SHRLEVEL still a valid clause and
> interchangable with ALLOW..., or has it been deprecated and is it, or
> will it eventually become, invalid? We currently are not seeing any
> errors using SHRLEVEL in our scripts that we've migrated from V7.
>
<rant>
I wish people posting questions to this newsgroup would identify which
version of DB2 they are using and what OS they are running on! I just spent 20 minutes searching for z/OS documents that proved SHRLEVEL still exists in DB2 UDB V8 for z/OS and that ALLOW READ/WRITE ACCESS doesn't when I thought to check the DB2 UDB V8 for Linux/Unix/Windows docs and found out that the question is valid after all, at least for Linux/Unix/Windows!
</rant>

Unfortunately, the V8 docs for Linux/Unix/Windows don't mention SHRLEVEL at all so only the IBM developers can tell us how much longer the SHRLEVEL
clause will be supported. Frankly, I'm surprised that it works at all in V8; I would have expected to get an error message if I used a clause that wasn't documented in the manual.

Unless someone from IBM can be persuaded to tell us how much longer the
SHRLEVEL clause will be supported, I think the smart move would be to modify your scripts to use the ALLOW READ ACCESS or ALLOW WRITE ACCESS clauses
instead of the SHRLEVEL clause. Otherwise, you may find that you install a fixpack and suddenly your scripts won't work any more.

Rhino

[Mark]

"Rhino" <rh****@NOSPAM. sympatico.ca> wrote in message news:<eCacd.708 92

From your remark in the next paragraph, it doesn't sound like you expect for
SHRLEVEL *ever* to be dropped. In that case, there is not as much point in
modifying the scripts to use ALLOW clause instead. I only suggested changing
the scripts because it struck me as possible that SHRLEVEL was being phased
out and would be disallowed sometime in the near future. As you pointed out
though, no such clause has ever been dropped from DB2 before so there is not
much reason to expect it to happen in the future.

I believe he said that no SQL syntax has ever been dropped. That is
not true for DB2 commands, and even though there are no immediate
plans to get rid of SHRLEVEL, don't expect it to remain valid forever.

Aside from SHRLEVEL, there are other changes to Runstats that deserve
review by DBA's to get the best results, so in most cases, the command
syntax should be rewritten anyway.