DB2 question
To list; This is probably not the forum to post this question but I have a basic question. I am getting a DSN106E message on a plan name. The analysis states that I should do a GRANT EXECUTE on the plan name. Is this a command that can be entered via the console or SDSF , do it in a batch job, or is either way acceptable. Thank you and regards, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 question
Try joining the DB2 Newsgroup (IDUG) its free Site Links: View post online View mailing list online Send new post via email Unsubscribe from this mailing list Manage your subscription Use of this email content is governed by the terms of service at: http://www.idug.org Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 question
On Tue, 9 Aug 2011 09:19:36 -0700, william janulin wrote: This is probably not the forum to post this question but I have a basic question. I am getting a DSN106E message on a plan name. The analysis states that I should do a GRANT EXECUTE on the plan name. Is this a command that can be entered via the console or SDSF , do it in a batch job, or is either way acceptable. GRANT EXECUTE is a SQL statement and not a command that can be entered via the console or SDSF. You can enter and execute SQL statements either interactively in TSO via SPUFI, QMF, ... or with a batch job (DSNTEP2/4, DSNTIAD, ...). Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 question
Hi William, No, it cant be entered directly via the console or SDSF, its an SQL statement : GRANT EXECUTE ON PLAN TESTPLAN TO JOESOAP ; The above statement grants execute authority on plan TESTPLAN to user JOESOAP. You can use SPUFI to execute the SQL interactively, or in batch you can use the IBM supplied sample programs DSNTIAUL or DSNTEP. But you need to have the relevant authority to issue a grant. I would talk to your DBA's about it. Regards, Ron From: william janulin wjanu...@yahoo.com To: IBM-MAIN@bama.ua.edu Date: 10/08/2011 12:45 AM Subject:DB2 question Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To list; This is probably not the forum to post this question but I have a basic question. I am getting a DSN106E message on a plan name. The analysis states that I should do a GRANT EXECUTE on the plan name. Is this a command that can be entered via the console or SDSF , do it in a batch job, or is either way acceptable. Thank you and regards, Bill J. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ This email has been scanned by the Bankwest Email Security System. ___ ___ Unencrypted electronic mail is not secure and may not be authentic. If you have any doubts as to the contents please telephone to confirm. This electronic transmission including any attachments is intended only for those to whom it is addressed. It may contain copyright material or information that is confidential, privileged or exempt from disclosure by law. Any claim to privilege is not waived or lost by reason of mistaken transmission of this information. If you are not the intended recipient you must not distribute or copy this transmission and should please notify the sender. Your costs for doing this will be reimbursed by the sender. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. ___ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 question
Hello Experts, I am asking for opinions on the ramifications or value of using the MODE C (compress) command within generic ZOS batch FTP. I am not a SYSPROG and do not have full access to SMF and RMF. My brief testing showed 3 to 10 times faster run time when using MODE C before the PUT or GET. I assume this saves bandwidth and the data is transmitted not in clear text for those that do not have encryption software. I suspect there is more over head in TCPIP or some STC. I plan to recommend this to our tech staff unless there is a major reason not to implement. Also, I tested FTP of a ps file, a ps-e file, an IBM Terse file and MODE C was the fastest followd by PS-E then terse. David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Another DB2 question...SYSIBM.SYSPLANDEP...how is this updated
I can't find in any manual where it states how SYSIBM.SYSPLANDEP is updated. I made the assumption it would be done at BIND time. I have a DBRM that contains both dynamic and static SQL. This DBRM is bound into a plan. I can run the program and the SQL will execute successfully. However, when I query SYSIBM.SYSPLANDEP, there are no rows for my plan. I used SPUFI to query. Once with a WHERE clause specifying my plan name, and another without the WHERE clause. With the WHERE clause returned no rows. Without the WHERE clause returned rows, but a search of the rows did not contain my plan name in the DNAME column. I have completed the sign-up for the DB2-L list, but don't have access to it yet. I guess they will process this in due time, but I thought someone on this list might know what causes this catalog table to be updated. Thanks for the help. --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another DB2 question...SYSIBM.SYSPLANDEP...how is this updated
Basic DB2 structure - 1. very old DB2 - plans contained DBRM's - BIND PLAN MEMBER(list of DBRM's) - DBRM dependencies for these DBRM's are stored in SYSPLANDEP 2. new DB2 (last 15 years) - plans contain package list entries - BIND PLAN PKLIST(list of package names) No dependendies stored in SYSPLANDEP only created when you bind the package then stored in SYSPACKDEP. If you want to pull data by plan, you need to join syspacklist to SYSPACKDEP unless your PKLIST specifies collid.* which means all members in the collid are potential for the plan then you get to join on just collid which makes a big report with lots of invalid data. Mike On Sat, Aug 6, 2011 at 11:44 AM, Dave Day david...@consolidated.net wrote: I can't find in any manual where it states how SYSIBM.SYSPLANDEP is updated. I made the assumption it would be done at BIND time. I have a DBRM that contains both dynamic and static SQL. This DBRM is bound into a plan. I can run the program and the SQL will execute successfully. However, when I query SYSIBM.SYSPLANDEP, there are no rows for my plan. I used SPUFI to query. Once with a WHERE clause specifying my plan name, and another without the WHERE clause. With the WHERE clause returned no rows. Without the WHERE clause returned rows, but a search of the rows did not contain my plan name in the DNAME column. I have completed the sign-up for the DB2-L list, but don't have access to it yet. I guess they will process this in due time, but I thought someone on this list might know what causes this catalog table to be updated. Thanks for the help. --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another DB2 question...SYSIBM.SYSPLANDEP...how is this updated
Dave, Is the DBRM bound into a plan, or is the DBRM bound into a PACKAGE, then the plan is bound with the PACKLIST parm? In the former case (which is no longer supported as of DB2 V10 btw) SYSPLANDEP will be updated when the BIND PLAN is performed. However, in the latter case, SYSPLANDEP will be empty, and the dependancies will be recorded in SYSPACKDEP. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Dave Day david...@consolidated.net To: IBM-MAIN@bama.ua.edu Date: 08/06/2011 11:44 AM Subject: Another DB2 question...SYSIBM.SYSPLANDEP...how is this updated Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I can't find in any manual where it states how SYSIBM.SYSPLANDEP is updated. I made the assumption it would be done at BIND time. I have a DBRM that contains both dynamic and static SQL. This DBRM is bound into a plan. I can run the program and the SQL will execute successfully. However, when I query SYSIBM.SYSPLANDEP, there are no rows for my plan. I used SPUFI to query. Once with a WHERE clause specifying my plan name, and another without the WHERE clause. With the WHERE clause returned no rows. Without the WHERE clause returned rows, but a search of the rows did not contain my plan name in the DNAME column. I have completed the sign-up for the DB2-L list, but don't have access to it yet. I guess they will process this in due time, but I thought someone on this list might know what causes this catalog table to be updated. Thanks for the help. --Dave Day -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REXX + DB2 question
On 2/10/2011 12:18 AM, karolf Gazeta.pl wrote:
Sorry, but WHEN command works only after CALL/LOADGO TSO commands, not after
CALL DSN subcommand.
Karol Filipowicz
I was afraid of that. I thought it was only an outside chance.
Thanks for reporting back.
2011/2/10 Steve Comstockst...@trainersfriend.com
On 2/9/2011 2:07 AM, karolf Gazeta.pl wrote:
Hi!
I have a Rexx script where I run DB2 applications by DSN+CALL commands:
ret_codes.=''
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
queue END
DSN SYSTEM(DB2X)
ret_codes.pgm.i=pgmname
ret_codes.plan.i=planname
ret_codes.retcode.i=RC
'DELSTACK'
end
The above solution is bad from performance's point of view.
Best solution would be to build the stack and then run DSN command only
once:
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
end
queue END
DSN SYSTEM(DB2X)
'DELSTACK'
The thread will be created only once. But there is one difficulty. I
don't
know how to take over return codes of all
running programs (but the last).
Anybody knows the solution? (or address where TSO saves RC after running
CALL program).
regards
Karol Filipowicz
TSO doesn't save all the RCs. Remember, when you queue commands
those commands are not run until after the exec ends!
Since the DSN command runs under TSO as a command processor,
perhaps you could queue some WHEN commands (I don't know if
WHEN commands will work after DB2 subcommands, but it might
be worth a try). Maybe:
queue when sysrc(= 0) se 'return from job 1 successful' u(*)
queue (q1) (q2)
WHEN commands are documented for use after TSO CALL, so I
don't know if this will work; also, you might have to put
the send command in a REXX exec or CLIST to make it work.
Bit of a stretch. Let me know how that works, if at all.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
REXX + DB2 question
Hi!
I have a Rexx script where I run DB2 applications by DSN+CALL commands:
ret_codes.=''
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
queue END
DSN SYSTEM(DB2X)
ret_codes.pgm.i=pgmname
ret_codes.plan.i=planname
ret_codes.retcode.i=RC
'DELSTACK'
end
The above solution is bad from performance's point of view.
Best solution would be to build the stack and then run DSN command only
once:
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
end
queue END
DSN SYSTEM(DB2X)
'DELSTACK'
The thread will be created only once. But there is one difficulty. I don't
know how to take over return codes of all
running programs (but the last).
Anybody knows the solution? (or address where TSO saves RC after running
CALL program).
regards
Karol Filipowicz
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REXX + DB2 question
I'm still reeling from the recent realization that my ISPF skills are stuck in
the dark ages (1980's) but this post went all day without being replied to, so
I'll take this to work and run a few tests before saying anything other than
that the RC value is set to the value of the previous statement's completion
code. Didn't see the RC being set in the 2nd example.
Also, I can't tell what input values are changing within the DO loop.
--- On Wed, 2/9/11, karolf Gazeta.pl kar...@gazeta.pl wrote:
From: karolf Gazeta.pl kar...@gazeta.pl
Subject: REXX + DB2 question
To: IBM-MAIN@bama.ua.edu
Date: Wednesday, February 9, 2011, 4:07 AM
Hi!
I have a Rexx script where I run DB2 applications by
DSN+CALL commands:
ret_codes.=''
do i=1 to
.
q1 = RUN PROGRAM(pgmname)
PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
queue END
DSN SYSTEM(DB2X)
ret_codes.pgm.i=pgmname
ret_codes.plan.i=planname
ret_codes.retcode.i=RC
'DELSTACK'
end
The above solution is bad from performance's point of
view.
Best solution would be to build the stack and then run DSN
command only
once:
do i=1 to
.
q1 = RUN PROGRAM(pgmname)
PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
end
queue END
DSN SYSTEM(DB2X)
'DELSTACK'
The thread will be created only once. But there is one
difficulty. I don't
know how to take over return codes of all
running programs (but the last).
Anybody knows the solution? (or address where TSO saves RC
after running
CALL program).
regards
Karol Filipowicz
--
For IBM-MAIN subscribe / signoff / archive access
instructions,
send email to lists...@bama.ua.edu
with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Looking for earth-friendly autos?
Browse Top Cars by Green Rating at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REXX + DB2 question
On 2/9/2011 2:07 AM, karolf Gazeta.pl wrote:
Hi!
I have a Rexx script where I run DB2 applications by DSN+CALL commands:
ret_codes.=''
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
queue END
DSN SYSTEM(DB2X)
ret_codes.pgm.i=pgmname
ret_codes.plan.i=planname
ret_codes.retcode.i=RC
'DELSTACK'
end
The above solution is bad from performance's point of view.
Best solution would be to build the stack and then run DSN command only
once:
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
end
queue END
DSN SYSTEM(DB2X)
'DELSTACK'
The thread will be created only once. But there is one difficulty. I don't
know how to take over return codes of all
running programs (but the last).
Anybody knows the solution? (or address where TSO saves RC after running
CALL program).
regards
Karol Filipowicz
TSO doesn't save all the RCs. Remember, when you queue commands
those commands are not run until after the exec ends!
Since the DSN command runs under TSO as a command processor,
perhaps you could queue some WHEN commands (I don't know if
WHEN commands will work after DB2 subcommands, but it might
be worth a try). Maybe:
queue when sysrc(= 0) se 'return from job 1 successful' u(*)
queue (q1) (q2)
WHEN commands are documented for use after TSO CALL, so I
don't know if this will work; also, you might have to put
the send command in a REXX exec or CLIST to make it work.
Bit of a stretch. Let me know how that works, if at all.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REXX + DB2 question
Sorry, but WHEN command works only after CALL/LOADGO TSO commands, not after
CALL DSN subcommand.
Karol Filipowicz
2011/2/10 Steve Comstock st...@trainersfriend.com
On 2/9/2011 2:07 AM, karolf Gazeta.pl wrote:
Hi!
I have a Rexx script where I run DB2 applications by DSN+CALL commands:
ret_codes.=''
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
queue END
DSN SYSTEM(DB2X)
ret_codes.pgm.i=pgmname
ret_codes.plan.i=planname
ret_codes.retcode.i=RC
'DELSTACK'
end
The above solution is bad from performance's point of view.
Best solution would be to build the stack and then run DSN command only
once:
do i=1 to
.
q1 = RUN PROGRAM(pgmname) PLAN(planname)
q2 = PARM('parm_txt')
queue (q1)(q2)
end
queue END
DSN SYSTEM(DB2X)
'DELSTACK'
The thread will be created only once. But there is one difficulty. I
don't
know how to take over return codes of all
running programs (but the last).
Anybody knows the solution? (or address where TSO saves RC after running
CALL program).
regards
Karol Filipowicz
TSO doesn't save all the RCs. Remember, when you queue commands
those commands are not run until after the exec ends!
Since the DSN command runs under TSO as a command processor,
perhaps you could queue some WHEN commands (I don't know if
WHEN commands will work after DB2 subcommands, but it might
be worth a try). Maybe:
queue when sysrc(= 0) se 'return from job 1 successful' u(*)
queue (q1) (q2)
WHEN commands are documented for use after TSO CALL, so I
don't know if this will work; also, you might have to put
the send command in a REXX exec or CLIST to make it work.
Bit of a stretch. Let me know how that works, if at all.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our new tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Cobol Db2 Question
Hi to all. Does somebody know if it's possible convert a static cursor into dynamic (or both)? Is there a special host-variable where the static cursor is stored to be called dynamically? Regards. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol Db2 Question
Yes it is possible to convert from static sql to dynamic sql. Refer to the DB2 product programming references for examples on how to do it. Talk to your DBA about possible security adjustments and other issues dynamic sql bring to the table. Jeffrey Celander Software Contractor EGS Innovations, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Marco Gianfranco Indaco Sent: Wednesday, August 18, 2010 12:02 PM To: IBM-MAIN@bama.ua.edu Subject: Cobol Db2 Question Hi to all. Does somebody know if it's possible convert a static cursor into dynamic (or both)? Is there a special host-variable where the static cursor is stored to be called dynamically? Regards. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
db2 question
Hi .. few clarifications 1) After Revoking DBADM authority from user, is it necessary to bind all plans and packages associated with that user ? In our system in SYSTABAUTH there are few entries related to packages(grantees) for which AUTHHOWGOT field is D and grantor is user having dbadm authority. In case I remove DBADM authority from GRANTOR, will that affect operations of applications even if Grantor has execute prvilege on all packages. 2) when we say SET CURRENT SQLID = 'XYZ' while exeucuting any query what is mean by this .. Understandably If user ABC is part of group XYZ and database rights are assigned to XYZ then while executing any query thru ABC user we have to give current SQL ID as XYZ. JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: db2 question
Jacky Bright wrote: Hi .. few clarifications 1) After Revoking DBADM authority from user, is it necessary to bind all plans and packages associated with that user ? In our system in SYSTABAUTH there are few entries related to packages(grantees) for which AUTHHOWGOT field is D and grantor is user having dbadm authority. In case I remove DBADM authority from GRANTOR, will that affect operations of applications even if Grantor has execute prvilege on all packages. 2) when we say SET CURRENT SQLID = 'XYZ' while exeucuting any query what is mean by this .. Understandably If user ABC is part of group XYZ and database rights are assigned to XYZ then while executing any query thru ABC user we have to give current SQL ID as XYZ. JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 1) If the SQL in the package/plan was allowed to be bound by virtue of the binder having DBADM on the data bases for tables referenced in the package/plan, then removing DBADM will cause the package/plan to be marked invalid. An automatic rebind will be attempted the next time the package/plan is accessed. The automatic rebind will succeed if all the necessary privileges are present for the package/plan owner; otherwise the automatic rebind will fail. Having the execute privilege on a package allows a prospective plan binder to name the package in the PKLIST parameter of BIND PLAN. A risk-avoiding alternative is to bind the packages/plans under a new owner before revoking the DBADM authority. A hindsight-based alternative is to BIND with an owner that's a group, not an individual. Removing the individual from the group leaves plans/packages with the group as owner unaffected. 2) SET CURRENT SQLID to a group affects subsequent dynamic DDL and DCL statements; privileges needed for the statement are derived from the CURRENT SQLID only. Dynamic DML SQL statements (INSERT/UPDATE/DELETE/SELECT) are normally authorized by the aggregate of privileges for a user and all of his/her groups. You need not set the CURRENT SQLID to avail yourself of this privilege aggregation. Setting the CURRENT SQLID also affects what is used for the owner for unqualified SQL (unless you also use SET SCHEMA). Hunter Cobb -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: lost DBRM [was: DB2 Question]
On 2006-03-30 at 15:05, concerning DB2 Question, WA Stout [EMAIL PROTECTED] wrote to IBM-Main: Is there a way (or tool) to reverse engineer a plan to get a DBRM member? Some of our DBRM's have gotten corrupted and I want to recreate without having to recompile. DBRM's are simply (almost text) members in a library that don't change until re-gen'd. (usually during re-compile) Have you considered restoring the corrupted members from a backup? Especially if they haven't been re-compiled in GT weeks, you won't have much of a inconsistency re: timing issue. There is a location in the DBRM where you can compare the time-stamp (as DB2 does) with the load module but you'll need to check over on DB2-L for such details. Even a google might give the details: Results 1 - 10 of about 826 for DB2 +DBRM +timestamp. -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 Question
DBRM's are temporary, once the plan / package is bound there is no need to recover them ... DB2 does not use them after after bind. Re-compile will not recover the DBRM as you suggested. Both DB2 static statements and DB2 executables are time stamped by actions in the precompile process and at run time the time stamps need to match or a SQL error results. For those on the list who do not understand the process DB2 access is done via an imbeded lanuage called SQL in much the same way a CICS EXEC is an impeded lanuage in the application program. The application source goes through a pre-compile that converts the SQL into constructs consistant with what ever the sournding application code uses. Diffrent than CICS the DB2 precompile also produces the DBRM (Data Base Request Module). The modified application source is input to downstream compiles and links eventully updating a load dataset. The DBRM is input to a down stream SQL BIND updateing the DB2 Catalog. Both are required for the application to run. Neither outpup from the precompiler can be used again ... The DBRM or the modified source and there is no reason to save them ... Some people do save the DBRM so they can use IEHIBALL but I know of no one who saves the modified source. The most helpfull person I know who can advise people on this process (and will sell you a product if you wish but is not very pushy about it) is Gerald Hodge HLS Technologies, Inc. www.hlstechnologies.com The DB2-L list is ofcourse a good option There is some potencial to reconstruct the DBRM from the DB2 catalog statement tables but it is not clear what the value of doing this would be. On Thu, 30 Mar 2006 15:05:01 -0500, WA Stout [EMAIL PROTECTED] wrote: Gang forgive me, I am not a DBA but I need to ask this... Is there a way (or tool) to reverse engineer a plan to get a DBRM member? Some of our DBRM's have gotten corrupted and I want to recreate without having to recompile. Any help would be appreciated. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DB2 Question
Gang forgive me, I am not a DBA but I need to ask this... Is there a way (or tool) to reverse engineer a plan to get a DBRM member? Some of our DBRM's have gotten corrupted and I want to recreate without having to recompile. Any help would be appreciated. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 Question
usually better chance for an answer on DB2 listserv but I lurk here also. The ability to generate a DBRM is dependent on the status of the information in SYSSTMT and SYSPACKSTMT. BIND COPY accross subsystems does not have enough information to rebuild the DBRM. REMOTE binds do not have enough information to create a DBRM It depends on how many you need to rebuild - If you only have a few, there have been REXX code to rebuild DBRM. Otherwize we have a tool that will revuild any number. http://www.hlstechnologies.com/dbrmCheck.html Mike On 3/30/06, WA Stout [EMAIL PROTECTED] wrote: Gang forgive me, I am not a DBA but I need to ask this... Is there a way (or tool) to reverse engineer a plan to get a DBRM member? Some of our DBRM's have gotten corrupted and I want to recreate without having to recompile. Any help would be appreciated. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB2 Question
Is there a way (or tool) to reverse engineer a plan to get a DBRM member? Some of our DBRM's have gotten corrupted and I want to recreate without having to recompile. You're taking a chance with an integrity exposure. Besides, re-compiling would probably be faster! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
