I was trying to promote a COBOL program and the package in changeman. The BIND parameters in the package has QUALIFIER option in it. But while promoting I get the error "INVALID QUALIFIER SUPPLIED'
So I removed the QUALIFIER option from the BIND parameters and added and QUALIFIER in the SELECT query of the COBOL program. And when promoted it was successful. But when trying to demote, I get the same error which I got before i.e. BIND failed due to INVALID QUALIFIER supplied.
The qualifier used is a valid one in the DB2 subsytem I use. Is there any way to find out why the QUALIFIER is reported as invalid. Is it registered anywhere in SYSIBM tables may be ? I tried to query SYSIBM.SYSSCHEMAAUTH, but couldn't find any useful info. Can anyone shed some light on this.
Related
In a green screen session, caling a program MYLIB/TESTPRG works when my library list is set to QGPL, QTEMP, VENDRLIB1, VENDRLIB2, VENDRLIB3. I can execute call MYLIB/TESTPRG on a green screen command line.
I want to be able to run this command from my Windows client. I created an external stored procedure MYLIB/TESTPROC with external name MYLIB/TESTPRG as I have seen in various articles. My original question stated that I could execute this procedure successfully in STRSQL in a green screen session with my library list as above, but that is false. It does not work. It simply says 'Trigger program or external routine detected an error.' Sorry for the wrong information.
When MYLIB/TESTPROC is called from the client (CALL MYLIB/TESTPROC), it fails with CPF9810 (Library &1 not found). I connected to the database via i Navigator -> Run SQL Scripts. In Connection -> JDBC Settings I had Default SQL schema = 'Use library list of server job' and set Schema list=QGPL,QTEMP,VENDRLIB1,VENDRLIB2,VENDRLIB3. I then executed CALL MYLIB/TESTPROC and got the message as stated above.
What works is when I run the program, i.e. CALL MYLIB/TESTPRG on a green screen command line.
TESTPRG is a C program that takes no arguments. The stored procedure was defined like this:
CREATE PROCEDURE MYLIB/TESTPROC
LANGUAGE C
SPECIFIC MYLIB/TESTPROC
NOT DETERMINISTIC
NO SQL
CALLED ON NULL INPUT
EXTERNAL NAME 'MYLIB/TESTPRG'
PARAMETER STYLE GENERAL ;
CPF9810 - Library &1 not found means that something is trying to access Library &1 (whatever that is, you didn't tell us) and the library as typed is not on the system anywhere. &1 is not the name of the library, it is a substitution variable which will display the library name in the job log. Look at the real library spelling in the job log. Check your spelling. Check the connection to make sure all the libraries are specified correctly. The message will tell you exactly which library is causing the problem.
If indeed the program works in green screen when the library list is set properly, then I would expect the problem to be in your connection where it is trying to set a library list. You cannot add a non-existent library to the library list. That is why it works in green screen, your library is necessarily typed correctly there, or it wouldn't be in the library list. You would get a similar error (same text, different error code) if you tried to add library with a spelling error to the library list in green screen.
Figure out the full text of the message (look in the job log), and you will see just what is throwing the error, and what the library is. Hint, it is not likely SQL throwing the error as those errors all look like SQL#### or SQ#####. More likely a CL command or it's processing program being called by an IBM server that is sending a CPF message.
As you have discovered, you can directly call simple programs without defining an external SQL procedure based on this documentation from IBM:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/db2/rbafzcallsta.htm
I believe the recommendation to create your own external procedure definition for simple programs is primarily to reduce ambiguity. If you have programs and procedures that happen to have matching names, you need to know the rules list to figure out which one is being called for instance.
Also, the rules for external functions are different than external stored procedures and those get confused as well.
Per my comment, I usually make my procedure calls with the library within the call command.
In a terminal session using CALL PGM(MYLIB/TESTPROC). Or in a SQL session using CALL MYLIB.TESTPROC.
This can prevent someone from inadvertently putting your procedure in a personal library or the like. I usually do not specify a session library list on my SQL clients, accepting the system library list.
I had promised to accept Douglas Korinke's comment as an answer. However, I was experimenting a lot and I am no longer sure of what I knew and when I knew it. My problem had something to do with parameter passing to the C program. If I can reproduce it with a simple case I will ask another question.
In a Java program it is possible to set the libraries by using the following method :
ds.setLibraries("list of libraries");
Example :
ds.setServerName("server1");
ds.setPortNumber(1780);
ds.setDatabaseName("DBTEST");
ds.setLibraries("*LIBL,DAT452BS,DAT452BP");
Looking for ideas of how to disable a uvm_warning that occurs in the `uvm_object_utils macro.
UVM_WARNING #0: reporter [TPRGED] Type name 'xxx_packet' already registered with factory. No string-based lookup support for multiple types with the same type name.
I don't care about string-based lookup and I'd like to be able to use the same class name in multiple tests (I'm using per-test packages to make this work). So I'd really like to disable this warning. However, even the command the command line disable doesn't seem to help.
I tried:
+uvm_set_action=*,TPRGED,UVM_WARNING,UVM_NO_ACTION
This works for other warnings, but in this case the warning seems to occur even before command line arguments are processed.
These messages come because of static initializations, you will not be able to turn them off.
If you don't want register string names with the factory, use the `uvm_object_param_utils macro instead of the `uvm_object_utils The only difference that is does not register a string with the factory. See http://go.mentor.com/mcem for more information.
Lets say like PGM1(cobol) calls--> PGM2(cobol-db2) calls--> PGM3(cobol)--> calls PGM4(cobol-db2).
1Q. PGM3 is modified, which is purely COBOL progam. Do we compile only PGM3 and promote it to production or should we do a BIND again as its being called by and calls cobol-db2 program.
2Q. If PGM4 is modifieed, then what has to be done. (I'm using PACKAGE -> PLAN concept) ?
Also, can any one please explain me bind with package concept when we have cobol-cobol/db2 call.
Ashok,
Its definitely a question of how you making calls.A call can be static and dynamic.
With Dynamic call you do not need to compile main program is sub program changes.
But with Static call you need to compile Main program too.
Ans1 :- Static call in all calls - yes you must compile all programs.
Dynamic call used - just compile sub program.
Ans 2 :- See full details below for package and plan concept.
If you bound the old versions of DBRMs directly into your plan,
· Identify all the DBRMs that are bound directly into that plan for both the changed programs and any unchanged programs, and bind them all into the plan again.
·While you are binding the DBRMs into the plan, applications cannot use the plan to access DB2.
If you bound the old versions of the DBRMs for the changed application programs into packages
·You do not need to bind any other packages or directly-bound DBRMs into the plan again.
·You simply bind the new versions of the DBRMs for the changed application programs into packages with the same names as the old versions.
·You do not need to bind the plan again--it locates the new versions of the packages.
·While you are changing the packages, application programs can still use the other packages and directly-bound DBRMs in the plan.
Hope this helps!!.
As a rule of thumb, if the "consistency token" changes, you should rebind. That is say, if a new DBRM is produced. Draw a picture. It will help. Linking is really a red herring here. If you don't know what a consistency token is you will after your -805. Ask a peer for help (in the first instance).
Also ask you peers about impact analysis. (What else am I not recompiling that I should ?).
If the subroutine contains static SQL statements then it will produce a DBRM when compiled. This changes the consistency token and thus requires the module to be rebound to the database to avoid an 818 consistency token error. If the subroutine contains no SQL then it does not ever need to be bound to the database because no DBRM is ever created for it.
Even a program that contains only dynamic SQL will still create a DBRM that must be bound to the database. The DBRM itself will be pretty much empty apart from the consistency token.
This holds true regardless of whether this is mainframe COBOL or distributed COBOL using DB2 or LUW.
It's been a while since I had to write any COBOL but we always had two relevant rule of thumbs.
Only use Static Calls - your code should be performance tested and if there is no need for a dynamic call for a very specific purpose avoid it at all costs.
Rebind everything when something is changed and check the access paths created PRIOR to putting it live
If you need to wait for a period of outage to complete the task and flip in the updated code in production I would be patient and plan one in and complete the bind then...or get a DBA to do it and get them to confirm it was successful in your outage window or roll back immediately.
If your development environment is sufficiently sophisticated complete the bind in a lower pre-production environment using the stats for the DB2 tables from production (Copy the data in if you can - or get a DBA to do it). And check that none of the access paths for any of the DB2 calls have changed.
Hope this helps
First use this DB2 SQL to get the CONTOKENs
SELECT SUBSTR(COLLID,1,12) AS COLLID ,
SUBSTR(NAME,1,8) AS NAME ,
HEX(CONTOKEN) AS CONTOKEN ,
SUBSTR(OWNER,1,8) AS OWNER ,
SUBSTR(CREATOR,1,8) AS CREATOR ,
PDSNAME ,BINDTIME
FROM SYSIBM.SYSPACKAGE
WHERE NAME= 'program name';
Get the DB2 CONTOKEN (example below)
1ADB70E30768F694
0768F6941ADB70E3 (then reversed contoken 4bytes+4bytes)
Check #1 use reversed token search
Use token 0768F6941ADB70E3 (reversed)
CONTROL.???????.CICSLIB
Should be found
Check #2 use non-reversed token into DBRMLIB
CONTROL.????????.CIC.DBRMLIB
-Use token 1ADB70E30768F694
Should be found
If found then your bind is good.
How can I create a transient domain using libvirt? (Using QEMU/KVM as back-end)
The documentation discusses the difference between transient and persistent domains at this link: http://wiki.libvirt.org/page/VM_lifecycle#Transient_guest_domains_vs_Persistent_guest_domains
Still, I haven't found any concrete example on how to create one.
The only pointer I found is in this email: https://www.redhat.com/archives/libvirt-users/2011-August/msg00057.html, where the maintainer suggests to add the <transient/> tag in the <disk> field of the XML's description.
When I tried, I got this disappointing answer: "libvirtError: unsupported configuration: transient disks not supported yet".
Is this feature really "not supported yet", or am I missing something? The documentation makes me think that this should be supported.
Any answer related to the C or Python binding, virsh, or virt-manager will be highly appreciated!
Using virsh
If you are using virsh, than there are commands:
define -- This command takes an XML file as it's parameter and makes the domain known to libvirt (you can reference that domain by using its name or UUID).
start -- This command takes the domain name or UUID as its parameter and starts (boots) the domain.
create -- This command takes an XML file as it's parameter and creates (starts) the domain with settings described in that file. Depending on whether the domain is known to libvirt (previously defined with that UUID) it may result in two things:
if it is already defined, the known domain is marked as started, it is persistent domain, but it is started with the settings supplied and not those it was defined with).
in case it is not defined, the domain started is now a transient domain (it disappears when it is destroyed, shuts down, etc.).
undefine -- This command takes a domain name or UUID (or ID if it's started) and makes it unknown to libvirt, but if that domain is running it doesn't destroy it, just marks it transient.
C functions
In C, the APIs that virsh is using for these commands are:
define -- virDomainDefineXML
start -- virDomainCreate
create -- virDomainCreateXML
undefine -- virDomainUndefine
Notes:
The names may be a little bit confusing, but due to backward compatibility it is kept from Xen times.
Most of those mention commands have parameters which may alter the behavior, these may cause using different C functions for the purpose.
I have two workflow foundation (.NET 3.5 SP 1) application which compiles fine. It has two declarative rule conditions in it. Both are very simple, examples:
- !this.Shutdown
- this.Runtime == null
The project builds correctly without error or warning, however when I run the application it fails with the exception: error 1342: Activity 'whileNotShutdown' validation failed: Can not find the condition "Shutdown not requested".
In the other application I am using a more complex ruleset in policy which generates the following exception: error 1398: Activity 'Defaults' validation failed: Can not find the rule set "Rule Set1". Check if rule set is defined in the rules file.
I have tried removing the .rules file and recreating it by recreating the two rules and that did not help.
The question is: What is wrong that is causing this error?
Some things I have tried:
Placing the workflow rules in the larger workflow makes no difference to the issue.
The issue is effecting all workflows in the solution now (even those that used to work).
Using a code rule condition doesn't have the same problem - the issue is related to the rules file somehow.
Rebuilding workflow didn't help
Declarative workflow rules are not checked by the compiler so there is no help there. When you reference 'this' in rule it means the workflow. So your properties Shutdown and Runtime must be declared at the workflow level. I presume the Runtime refers to the WorkflowRuntime and that is kind of unusual, and not recommended, to have inside of your workflow so there may be a design issue here.
Eventually found the cause - it was caused by spaces in the class name, which causes the rules file to have spaces in it, which seems to cause the issue.
For example this will cause the error:
alt text http://img512.imageshack.us/img512/661/clipboard01wdu.png
However this will not:
alt text http://img140.imageshack.us/img140/9366/clipboard02t.png