Carol has the source for patquery in the IPN CVS tree at patquery.common. You see it Rick, at ~jasper/ipn-CVS/patquery.common/patquery.c. Carol uses the /afs/d/projects/search/patquery.fcgi.* directories to make the different versions of patquery. Carol flip-flops between two names in order to have a test & production version possible on a system. For example, the /afs/d/projects/search/patquery.fcgi.japio directory has two versions of the patquery files (the bind & binary), - pqjp.bnd & patquery.db.pqjp, and - pqjp2.bnd & patquery.db.pqjp2 What I do is take the latest version, copy it to my ips-CVS directory, check it into the IPS CVS tree, then tar it up and ship it to Servaas. As jasper, $ipscvs cd ~/ips-CVS/ips/fcgi-bin And then either cp -p /afs/d/projects/search/patquery.fcgi.japio/pqjp.bnd . cp -p /afs/d/projects/search/patquery.fcgi.japio/patquery.db.pqjp . tar cvf - pqjp.bnd patquery.db.pqjp | compress > patquery.tar.Z and send Servaas patquery.tar.Z, or cp -p /afs/d/projects/search/patquery.fcgi.japio/pqjp2.bnd . cp -p /afs/d/projects/search/patquery.fcgi.japio/patquery.db.pqjp2 . tar cvf - pqjp2.bnd patquery.db.pqjp2 | compress > patquery2.tar.Z and send Servaas patquery2.tar.Z. ============================================================================= To bind patquery, (Note that these details are similar but different than binding a new gateway. Don't confuse the two.) Logon to the database machine as ipsadmin, db2 connect to patent user ipsrun using inst1_password cd /dfs/prod/ips/fcgi-bin (or /dfs/test/ips/fcgi-bin) db2 bind pqjp.bnd (or db2 bind pqjp2.bnd) The output should be something like LINE MESSAGES FOR pqjp2.bnd ------ -------------------------------------------------------------------- SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. To query the package before you grant permissions on it, you can db2 "select substr(pkgschema,1,10) as PKGSCHEMA,pkgname,substr(boundby,1,9) \ as boundby,last_bind_time,explicit_bind_time from syscat.packages \ where pkgname like 'PQ%'" You'll see something like PKGSCHEMA PKGNAME BOUNDBY LAST_BIND_TIME EXPLICIT_BIND_TIME ---------- -------- --------- -------------------------- -------------------------- IPSRUN PQCH IPSRUN 2000-12-14-11.43.03.235460 2000-12-14-11.43.03.235460 IPSRUN PQJP IPSRUN 2001-03-30-02.48.15.344762 2001-03-30-02.48.15.344762 IPSRUN PQJP2 IPSRUN 2001-11-20-06.05.14.563458 2001-11-20-06.05.14.563458 The one I just bind-ed (bound?) was the PQJP2 one. To allow anybody to use it, To see the permissions on these packages, you can db2 "select substr(grantor,1,11)as grantor,pkgname,granteetype,substr(grantee,1,11) as grantee, \ controlauth,bindauth,executeauth from syscat.packageauth where pkgname like 'PQ%'" You'll see something like GRANTOR PKGNAME GRANTEETYPE GRANTEE CONTROLAUTH BINDAUTH EXECUTEAUTH ----------- -------- ----------- ----------- ----------- -------- ----------- SYSIBM PQCH U IPSRUN Y Y Y IPSRUN PQCH G PUBLIC N N Y SYSIBM PQJP U IPSRUN Y Y Y SYSIBM PQJP2 U IPSRUN Y Y Y 4 record(s) selected. Normally, the Verity web server runs as user=IPSRUN, so since you bounded this program as IPSRUN, it has EXECUTEAUTH already. But there are lots of times, for debugging purposes, where you want to be able to run patquery by hand say, as a different userid, so it's a good idea to automatically grant execute privileges to anybody (PUBLIC). To do so, db2 grant execute on package pqjp to public or db2 grant execute on package pqjp2 to public ============================================================================= The idea behind having two names for the patquery files, is so that one could bind the new patquery without affecting the old one. When you're ready to swap the new for the old, you can change the /ips/fcgi-bin/patquery link, which should be pointing to either patquery -> patquery.db.pqjp or patquery -> patquery2.db.pqjp ============================================================================= The /afs/d/projects/search/patquery.fcgi.japio versions of patquery are good for either JAPIO or the Dutch patent office (NIPO, aka BIE). The Swiss patent office, before March, 2002, were still on DB/2 version 5 and needed their patquery specially compiled on a system that had DB/2 version 5 libraries, e.g. Carol's machine named sleepy. But they're on DB/2 version 7 now, so this is no longer a problem. ========================================================================= In Japan, I saw these errors in the Verity web server error log, this one time when I recycled the server, [Sat Mar 23 01:59:55 2002] [error] [client 192.168.10.4] FastCGI: server "/dfs/test/ips/fcgi-bin/patquery" stderr: Patquery: SQLCODE=-818 (SQL0818N A timestamp conflict occurred. SQLSTATE=51003 and this one when I tried to do a search, [Sat Mar 23 01:59:55 2002] [error] [client 192.168.10.4] FastCGI: server "/dfs/test/ips/fcgi-bin/patquery" stderr: Patquery error(-818) on: ((318637) NC) The SQL0818N messages says there's a time conflict between the timestamp on the patquery module, and what was bound in DB2. Turns out the patquery module was changed, but not bound to DB2. When I tried to bind it when following the directions from my verity file, not this one, I got db2 bind pqjp2.bnd LINE MESSAGES FOR pqjp2.bnd ------ -------------------------------------------------------------------- SQL0061W The binder is in progress. 1110 SQL0204N "INST1.HITLISTS" is an undefined name. SQLSTATE=42704 1127 SQL0204N "INST1.HITLISTS" is an undefined name. SQLSTATE=42704 1407 SQL0204N "INST1.HITLISTS" is an undefined name. SQLSTATE=42704 1416 SQL0204N "INST1.HITLISTS" is an undefined name. SQLSTATE=42704 SQL0082C An error has occurred which has terminated processing. SQL0092N No package was created because of previous errors. SQL0091N Binding was ended with "6" errors and "0" warnings. Carol had to set me straight. I needed to connect to DB/2 as ipsrun, not inst1. ========================================================================= Some sleuthing in a Patolis patquery dump on March 17, 2004. This was on their test server on ips05i, so the dump was in /ips/test/fcgi-bin. Some thread clobbered free storage and the result was a branch to 0. dbx /ips/test/fcgi-bin/patquery.db.pqjp2.unstripped core040312 Type 'help' for help. reading symbolic information ... [using memory image in core040312] Illegal instruction (reserved addressing fault) in . at 0x0 ($t9) 0x00000000 01000000 Invalid opcode. (dbx) thread thread state-k wchan state-u k-tid mode held scope function $t1 run blocked 76677 u no sys _pthread_ksleep $t2 run running 68577 u no sys $t3 run running 34231 u no sys EvUtlConvert $t4 run running 24727 u no sys vos_lseek $t5 run blocked 73341 u no sys _pthread_ksleep $t6 run running 36779 u no sys vos_lseek $t7 run running 41839 u no sys EvUtlConvert $t8 run running 71441 u no sys vos_lseek >$t9 run running 55259 k no sys $t10 run blocked 42093 u no sys _pthread_ksleep $t11 run running 32811 u no sys EvUtlConvert (dbx) where warning: could not locate trace table from starting address 0x0 vctaux_bread(0x2173c558, 0x0, 0x0, 0x2f42c00, 0x1100110, 0x21b214b0, 0x21b214b4) at 0x100699e0 vctaux_sread(0x2173c558, 0x0, 0x0, 0x2f42e67, 0x35a7, 0x210a9398) at 0x10069f40 VCT_read(0x2173c558, 0x0, 0x2f42e67, 0x35a7, 0x210a9398) at 0x1005f988 VDBu_vct_read(0x2173c558, 0x21aff850, 0x0, 0x2f42e67, 0x35a7, 0x210a9398) at 0x100db3a0 vwd_readh(0x2173c558, 0x21aff850, 0x21a1bc00, 0x838c4, 0x210a9398, 0x35ab) at 0x100de944 VDBF_read_huge(0x2173c558, 0x21aff850, 0x10, 0x838c4, 0x210a9398, 0x35ab) at 0x100c2cd0 FwWrdRead(0x2173c558, 0x22294d08, 0x203ec0ac, 0x0, 0x0, 0x4) at 0x1016ea10 ZoneDrvRead(0x2173c558, 0x22294d08, 0x203ec0ac, 0x0, 0x0) at 0x10177d6c ZoneDrvMultiplex(0x2173c558, 0x22294d08, 0x203ec0ac) at 0x10176170 FwWrdMultiplex(0x0, 0x0, 0x0, 0x0, 0x0) at 0x10170cb0 warning: could not locate trace table from starting address 0x0 (dbx) Working from the 21aff850 you see as the second passed parameter to those 3 subroutines in the middle clump there (VDBu_vct_read, vwd_readh, & VDBF_read_huge), you see (dbx) 0x21aff850/20X 0x21aff850: 21a1b240 21aff820 21aff839 21aff8d8<---\ 0x21aff860: 00000000 4100001a 00402000 00010000 | 0x21aff870: c008d802 00000000 6a756c79 00000000 | 0x21aff880: c008d802 00000000 61756775 73740000 | 0x21aff890: c008d802 00000002 6f63746f 62657200 | (dbx) 0x21aff898/8s <------------------------------/ Get 8 strings from here 0x21aff898: "october" 0x21aff8a0: "\300^X\330^B" 0x21aff8a5: "" 0x21aff8a6: "" 0x21aff8a7: "" 0x21aff8a8: "/ips/coll/coll_wo2/parts/00000295.did" 0x21aff8ce: "" 0x21aff8cf: "" A useful Carol tool was listkeys.pl, which told you the active pieces/parts of a collection. For example, first determine the name of the pdd file. It'll be the numerically-biggest. ls -l coll_us1/pdd total 72 -rw-rw-rw- 1 ipsadmin www 11264 Apr 18 2002 00000044.pdd -rw-rw-rw- 1 ipsadmin www 11264 Apr 18 2002 00000045.pdd -rw-rw-rw- 1 ipsadmin www 11264 Apr 18 2002 00000046.pdd so in this case, 00000046.pdd. Then listkeys.pl _PDD_NUMDOCS _PDD_LIVEDOCS /ips/coll/coll_us1/pdd/00000046.pdd _PDD_PARTNAME _PDD_NUMDOCS _PDD_LIVEDOCS 00000001 32768 32768 00000002 32768 32768 00000003 32768 32768 ... 00000041 32768 32768 00000042 32768 32768 00000047 59270 59269 tells you the last 3 active parts were 41, 42, and 47 despite the fact that there was other junk in that parts directory ls -ltr |tail -rw-rw-rw- 1 ipsadmin www 18146114 Mar 22 2002 00000042.did -rw-rw-rw- 1 ipsadmin www 4738974 Mar 22 2002 00000042.ddd -rw-rw-rw- 1 ipsadmin www 25895260 Mar 30 2002 00000045.did <- Junk -rw-rw-rw- 1 ipsadmin www 8152181 Apr 18 2002 00000045.ddd <- Junk -rw-rw-rw- 1 ipsadmin www 9216 Apr 18 2002 00000046.did <- Junk -rw-rw-rw- 1 ipsadmin www 12288 Apr 18 2002 00000046.ddd <- Junk -rw-rw-rw- 1 ipsadmin www 8152197 Apr 18 2002 00000047.ddd -rw-rw-rw- 1 ipsadmin www 25895504 Apr 18 2002 00000047.did -rw-rw-rw- 1 ipsadmin www 0 Apr 18 2002 00000046.mrg <- Junk -rw-rw-rw- 1 ipsadmin www 0 Apr 18 2002 00000045.mrg <- Junk A mkvdk cleared that junk up. mkvdk -collection coll_us1 One anamoly we saw in the wo2 parts directory, was parts files not numbered sequentially. listkeys.pl _PDD_NUMDOCS _PDD_LIVEDOCS /ips/coll/coll_wo2/pdd/00000399.pdd _PDD_PARTNAME _PDD_NUMDOCS _PDD_LIVEDOCS 00000287 61878 61955 00000288 62714 62745 00000289 63995 63995 00000260 63981 63980 <--- How did 260 & 261 get out of order? 00000261 63978 63973 <--- Carol couldn't explain it, but maybe 00000290 63929 63929 this is the cause of the dumps? 00000291 63889 63885 00000292 47770 47700 00000293 44860 44308 00000294 48110 47523 00000295 54873 53499 00000408 64849 52919 00000409 64093 59481 00000410 65293 60782 00000420 65092 60795 00000439 36149 24489 00000440 3195 3195 =========================================================================