473,287 Members | 1,574 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

Runstats Command Question

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
Nov 12 '05 #1
7 7362

"Todd McNeill" <to********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
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
Nov 12 '05 #2
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.bellglobal.co m>...
"Todd McNeill" <to********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
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

Nov 12 '05 #3
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********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
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.bellglobal.co m>...
"Todd McNeill" <to********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
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

Nov 12 '05 #4
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
Nov 12 '05 #5

"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

Nov 12 '05 #6
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.bellglobal.co m>...
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********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
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.bellglobal.co m>...
"Todd McNeill" <to********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
> 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

Nov 12 '05 #7
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message news:<eCacd.70892
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.
Nov 12 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Charles Cantrell | last post by:
I have recently set up mySQL on a Mandrake release of Linux (Version 7 of Mandrake, I believe), using the binary 4.0.13 standard release. The set up and start up all were normal, as far as I...
1
by: John S | last post by:
Hi All, What is the SQL command for creating a direcotry c:\mydata\data1 on my server. Thanks in advance John S
1
by: dkalsow | last post by:
Does anyone know the syntax in vb.net that I can open the "Windows Picture and Fax Viewer" in VB.Net and pass it a variable that contains the name of the file I want to view. I have tried...
0
by: Rich Villanova | last post by:
I am trying to call a stored procedure using DB2 connect 7.2, first from the the command line then, from within SQL Server. However, whenever I call a stored procedure with an output parameter it...
2
by: bwmiller16 | last post by:
Guys - Does the PRUNE logfile command do anything other than just do a simple delete of the files? Or is there more to it internally in DB2? Thanks in Advance, -B
5
by: Keith | last post by:
Good Morning, I am new to .Net so forgive me if this is question is kind of out there. Is there a way to consolidate multiple Dim statements for Sql Commands? I have a page that has around 50 Dim...
1
by: Chad | last post by:
I am using SQL Server 2000. In Enterprise Mgr, under Management/Current Activity, I see a list SPIDs. I have a multi-tiered .NET web app that uses ADO.NET to connect to the database. Each time a...
1
by: Mike Cook | last post by:
Can someone give me the command to check who is logged onto the the server
0
by: V4D3R | last post by:
Hey guys, this is my first post here! I have an assignment due on Tuesday and I have to create a command that will make it easier on noobs to change permissions and delete files, etc. I call...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.