2010-07-21T00:00:30 *** dbs has quit IRC 2010-07-21T00:03:40 *** mck9 has left #evergreen 2010-07-21T01:36:21 *** leed- has joined #evergreen 2010-07-21T01:37:02 *** leed has quit IRC 2010-07-21T02:49:00 *** Callender_ has joined #evergreen 2010-07-21T02:52:59 *** Callender has quit IRC 2010-07-21T02:53:07 *** Callender_ is now known as Callender 2010-07-21T04:06:29 *** atz has quit IRC 2010-07-21T04:06:54 *** atz has joined #evergreen 2010-07-21T04:35:24 *** Callender has quit IRC 2010-07-21T04:35:24 *** kbeswick has quit IRC 2010-07-21T04:36:46 *** Callender has joined #evergreen 2010-07-21T04:36:47 *** kbeswick has joined #evergreen 2010-07-21T06:11:49 *** alxp has joined #evergreen 2010-07-21T06:42:34 *** Dyrcona has joined #evergreen 2010-07-21T07:20:36 *** magnusenger has joined #evergreen 2010-07-21T07:39:35 *** sfortin has joined #evergreen 2010-07-21T07:43:59 *** alxp_ has joined #evergreen 2010-07-21T07:54:49 *** mck9 has joined #evergreen 2010-07-21T08:00:23 * Dyrcona is thinking that in-db ingest is detrimental to large bib loads, like those that happen during a migration. 2010-07-21T08:19:01 *** shopkins has joined #evergreen 2010-07-21T08:27:06 *** dbs has joined #evergreen 2010-07-21T09:10:55 *** Meliss has joined #evergreen 2010-07-21T09:14:23 *** jenny has joined #evergreen 2010-07-21T09:15:48 *** shopkins has quit IRC 2010-07-21T09:15:48 *** ISL-rjackson has quit IRC 2010-07-21T09:20:23 *** bshum has joined #evergreen 2010-07-21T09:24:28 *** yboston has joined #evergreen 2010-07-21T09:25:11 *** yboston has quit IRC 2010-07-21T09:25:11 *** yboston has joined #evergreen 2010-07-21T09:26:26 *** yboston_ has joined #evergreen 2010-07-21T09:29:16 *** dbs has quit IRC 2010-07-21T09:29:48 *** yboston has quit IRC 2010-07-21T09:31:19 *** dbs has joined #evergreen 2010-07-21T09:36:50 Dyrcona: sounds more to me like more optimization, compartmentalization and tuning is needed. and that was expected (by me, at least). full details on what you're doing and how you're doing it, and the performance profile at different points in the process, would be needed for others to help in that area 2010-07-21T09:40:20 * dbs will go read the logs, but sounds like Dyrcona was continuing to have massively long loading times - and dbs concurs that without an investment in db tuning, loading times will suck 2010-07-21T09:42:17 Only thing left that I could do are to increase maintenance_work_mem, possibly drop more indexes, and disable archiving of WAL files (if that's even really a consideration). 2010-07-21T09:43:10 dbs: yes, that's what I took too, but we don't have details to work with ... the only analysis (that I'm aware of) has been done by gmcharlt and myself ... we need more detail 2010-07-21T09:43:52 Dyrcona: IMO, for migration (a one-time thing), everything is on the table, up to and including disabling fsync during the load 2010-07-21T09:43:52 note to self or good samaritan, seed the UPDATE_HOLD_REQUEST_TIME permission 2010-07-21T09:44:38 Dyrcona: but the code can get smarter and faster ... we just need to know /where/ to improve it 2010-07-21T09:45:23 All my code does is parse the marc output from my legacy ILS and massage it a bit to get rid of some obvious errors. 2010-07-21T09:46:33 It then writes out sql files that copy biblio.record_entry from some files. The files are also generated by the code and contain the required fields for biblio.record_entry. 2010-07-21T09:46:45 These can be loaded individually or in batches. 2010-07-21T09:47:06 one theory I tested about a month ago was that re-parsing the xml over and over was slowing everything down, so I implemented an in-backend perl caching mechanims and taught the plperl version of all the xpath machinery to use that ... it didn't help except in specific limited circumstances, and batch loading was not one 2010-07-21T09:47:26 *** yboston has joined #evergreen 2010-07-21T09:47:42 *** yboston_ has quit IRC 2010-07-21T09:48:42 I should add my program also converts from MARC21 to marc21slim, but that's not the problem because the preparation steps run in an hour or so. It's loading the copy data that takes about 80 hours for 930,000 or so bibs. 2010-07-21T09:48:44 Dyrcona: I don't recall from our previous conversations ... you've convrimed that the leader/09 is being set to 'a' in the marcxml that's tossed into the COPY files? 2010-07-21T09:49:06 confirmed, even 2010-07-21T09:49:08 No, I've not confirmed that, and what is the significance of that? 2010-07-21T09:50:54 if it's ' ' (space) then MARC::Record will try to convert the record from marc8 encoding to utf8, which is horrendously expensive. and, marc21slim must be utf8 encoded in any case (for evergreen's purposes, and generally speaking because nobody speaks marc8 but us) 2010-07-21T09:50:56 Heh. 2010-07-21T09:51:21 * dbs was just whining about MARC::File::XML's helpfulness in that regard a week or two ago :) 2010-07-21T09:51:27 yes 2010-07-21T09:51:55 dang ol "believing the data" ;) 2010-07-21T09:52:04 classic mistake 2010-07-21T09:52:13 data is tricksy, and is never to be trusted 2010-07-21T09:52:45 In fact, if it's anything _but_ 'a', it will do the conversion, IIRC 2010-07-21T09:53:00 indeed 2010-07-21T09:53:05 I tell marc4j to conver it to unicode, and then have it converted to utf-8 by the xml transformer that writes the records out, but I've not checked the 009. 2010-07-21T09:53:14 This also leads to fun if you have non-ASCII chars :) 2010-07-21T09:53:44 Dyrcona: leader byte 9 (counting from 0), just to be clear. not a tag 009 2010-07-21T09:54:23 I shouldn't say "have it converted to utf-8", rather the transformer is told the charset is to be utf-8 so if its utf-8 already (and it should be) then it just writes it out. 2010-07-21T09:54:33 Oh, OK. I misunderstood. 2010-07-21T09:56:05 right, just need to make sure that the record knows that. thus the leader/09 2010-07-21T09:56:23 it's like an xml processing instruction 2010-07-21T09:57:44 *** shopkins has joined #evergreen 2010-07-21T10:00:32 Dyrcona: oddly enough, I happen to have a query here that will get you a sample of the ldr/09 data: 2010-07-21T10:00:56 select id, substring((xpath('//marc:leader/text()',marc::xml,array[array['marc','http://www.loc.gov/MARC21/slim']]))[1]::text from 10 for 1) from biblio.record_entry limit 10; 2010-07-21T10:01:30 Ok. Thanks, I'll see what's gone in so far, but I should still check before loading anyway. 2010-07-21T10:04:00 They're all blank. 2010-07-21T10:04:23 that's ungood 2010-07-21T10:05:09 sounds like whatever marc tool you're using needs to be taught about updating the leader when setting the record encoding 2010-07-21T10:05:39 * Dyrcona hates MARC. 2010-07-21T10:05:46 luckily, a simple sed script can fix the leader for you in the COPY files, if regenerating them will take a while 2010-07-21T10:05:47 I'll set it in the code, myself. 2010-07-21T10:06:12 Dyrcona: FEEEL THE HATE. LET IT FLOW THROUGH YOU 2010-07-21T10:06:21 I'm not running copy files at the moment. I'm doing something dumber just as an experiment. 2010-07-21T10:06:41 Hmm. Most things are probably slower than COPY 2010-07-21T10:06:49 yep. 2010-07-21T10:07:21 I'm going to have to validate ISBNs in my code, too. One bad ISBN stops a whole file full of records from loading. 2010-07-21T10:07:22 also, I'm not saying this will fix all your pain, but it's certain to improve things any time perl has to parse the records 2010-07-21T10:07:42 It will be good to see the result of having LDR/09 set appropriately. At some point, would be interesting to see if autovacuum is on and interfering with the load. 2010-07-21T10:07:53 Dyrcona: define "bad"? 2010-07-21T10:08:06 I believe auto vacuum is on, but I'd have to check. 2010-07-21T10:08:13 Invalid, not properly formed. 2010-07-21T10:08:45 dbs: appropriately tuned, autovacuum should help (updating stats and such) ... not much dead-tuple action going on during a load 2010-07-21T10:09:04 though, appropriately tuned is easier typed than done ;) 2010-07-21T10:14:07 Yeah. Can't remember if Dyrcona has max_fsm_pages set differently from the defaults, which plays a part in vacuuming efficiently too 2010-07-21T10:14:54 I haven't changed that setting, myself, and I doubt anyone else here has. 2010-07-21T10:16:49 Ooh. If not, then along with the LDR/09 fix, I'm going to go back to saying that a little PostgreSQL tuning in postgresql.conf (and possibly sysctl for shared memory to support a higher max_fsm_pages) will go a long way. 2010-07-21T10:18:05 It might be worthwhile, at some point, to put together an email that describes your hardware, the steps you're taking to preprocess the data, the PostgreSQL tuning that's been done, and the database changes (dropped indexes, etc) that you've tackled, along with a set of sample records, for our perusal 2010-07-21T10:18:18 Can't guarantee anything, of course. 2010-07-21T10:18:28 But it feels like we're stabbing kind of blindly 2010-07-21T10:18:37 Can't guarantee that I'll have time for something like that, unfortunately. 2010-07-21T10:20:44 *** magnusenger has quit IRC 2010-07-21T10:22:18 Okay. Obviously we want to nail down the real cause of your loading performance problems; if there's something we can do on the schema side to improve in-db ingest, great, but if the general PostgreSQL tuning isn't in place, then our efforts would just be wasted time 2010-07-21T10:23:09 Dyrcona: unfortunately, without details nobody can help. FWIW, I can do 100k record in ~4h on an underpowered system and untuned PG, and /all/ I did was turn off a couple global flags to ingest. if yours starts fast and gets progressively slower, that points to db config ... which brings us back to dbs' point :) 2010-07-21T10:24:50 What I mean is, in addition to doing this Evergreen, I still have to do everything that I did before with managing our current ILS, maintaining the network, etc. Don't know when I'll find time to write a detailed email, and you probably don't want war and peace anyway. 2010-07-21T10:27:44 Dyrcona: totally understood ... it's just that we don't have much to go on right now, re what you're seeing specifically 2010-07-21T10:29:06 I understand. I'm OK with the help that I've gotten so far. I'll see what the suggestions today lead to, plus a few other things that I've found via Google. The postrgres docs are OK. I need to spend a bit more time reading the tuning section again. 2010-07-21T10:29:52 In the past, I was always the DB programmer not the DBA, I never had to worry about tuning. That was always someone else's job. 2010-07-21T10:30:07 Now, its my job, too. 2010-07-21T10:31:03 *** dbs has quit IRC 2010-07-21T10:41:36 *** youdonotexist has joined #evergreen 2010-07-21T10:46:11 Here's a question regarding the MARC that is inserted into biblio.record_entry: Should be it be normalized using NFD?--I noticed that the full_rec and other tables are normalized, but didn't see this being done with the MARC, so thought I would ask. 2010-07-21T10:46:43 * Dyrcona is not normalizing the MARC, now, btw. 2010-07-21T10:52:14 what's the difference between l= and ol= in the opac? 2010-07-21T10:53:37 phasefx: l is current location, ol is original location 2010-07-21T10:53:56 i.e. home location 2010-07-21T10:53:58 original location is used if you go Home? 2010-07-21T10:54:01 ah, k, thanks 2010-07-21T10:54:05 *** jeffgreenca has joined #evergreen 2010-07-21T10:57:36 Dyrcona: the MARC21 standard used to say NFD, but now it doesn't specify (IIRC), and browsers have an easier time with NFC, so, IIRC, marc2bre currently uses NFC 2010-07-21T11:00:29 *** dbs has joined #evergreen 2010-07-21T11:02:44 Dibs on 0346 for an upgrade script 2010-07-21T11:36:14 grabbing 0347 2010-07-21T11:45:24 mkier_: Thanks, I'll look a the marc2bre code again. 2010-07-21T11:55:07 Does the current 1.6.0.1 virtual server image already have sample marc records loaded up into the system? It is OK if not, I can grab the marc samples provided by dbs. 2010-07-21T11:55:31 yboston: I honestly don't remember anymore :( 2010-07-21T11:56:11 dbs: I can let you know in a couple of hours :) 2010-07-21T11:56:42 People wanted images with preloaded data, people wanted images without preloaded data, I forget what that one has. Maybe we should just ship two different PostgreSQL databases and make it easy to switch 2010-07-21T11:57:01 s/we/whoever wants to volunteer to produce virtual images/ :) 2010-07-21T12:05:59 speaking of volunteers .... I think it's release time again. shiny goodness just sitting in rel_1_6_[01] 2010-07-21T12:06:06 ANYONE? ANYONE? 2010-07-21T12:11:35 * dbs is slowly working towards automating the OpenSRF release rolling 2010-07-21T12:12:35 dbs++ 2010-07-21T12:31:28 *** dbs has quit IRC 2010-07-21T12:32:36 *** dbs has joined #evergreen 2010-07-21T12:47:44 *** laura_ has joined #evergreen 2010-07-21T12:52:55 *** laura_ has quit IRC 2010-07-21T12:53:42 *** laura_ has joined #evergreen 2010-07-21T12:56:55 miker_: We've been considering a move to 1.6.1 series for our systems. Do you just need folks to test out the latest version? 2010-07-21T12:57:13 (by considering, I really mean that we're hoping to do it sometime later next week) 2010-07-21T12:59:07 bshum: if you're testing the rel_1_6_1 branch, that's perfect. testing the 1.6.1.x upgrade scripts is good, though 2010-07-21T13:00:52 * dbs can't remember if that new index made its way into the 1.6.1.1-1.6.1.2 upgrade script 2010-07-21T13:02:00 which new index? (there are several, including one today ... ) ;) 2010-07-21T13:03:49 miker_: we've done some initial testing to bring our 1.6.0.2 to 1.6.1.1 I believe. I'd have to go back through them for testing the branch anyways. I'll let you know what we find out. 2010-07-21T13:03:53 actually, that would be a great project for someone wanting to learn maintainer stuffs ... create a patch for the 1.6.[01] upgrade scripts that contains the differences between the last release tag and the current parent branch (check out tag and branch, diff the Pg dirs, create SQL from diff) 2010-07-21T13:04:38 s/creat a patch/create a new upgrade script/ 2010-07-21T13:10:24 miker_: right, I was talking about the action_trigger.event index 2010-07-21T13:11:26 I didn't do it ... miker_-- 2010-07-21T13:11:27 miker_: and I think you'll find that there's already a 1.6.1.1-1.6.1.2-upgrade-db.sql in rel_1_6_1 2010-07-21T13:11:42 * dbs tries to keep that in sync as he goes 2010-07-21T13:14:26 dbs++ 2010-07-21T13:15:34 as evidenced by the number of error-correcting patches I also commit, I often make mistakes as I go too 2010-07-21T13:29:27 *** lisppaste has quit IRC 2010-07-21T13:30:44 What server process(es), if any, need to be restarted on the server to pick up on changes to actor.org_unit_setting values? No need to log out/back in or restart the Staff Client, I presume, right? 2010-07-21T13:31:09 open-ils.settings 2010-07-21T13:31:17 prolly 2010-07-21T13:31:40 can't remember if OU settings are one of the things that the staff client caches at log in time 2010-07-21T13:32:32 and then possibly any services that would query & cache actor.org_unit_setting values? heh, I probably shouldn't have said anything at all, I'm no help 2010-07-21T13:34:16 I didn't think you had to restart anything for those. 2010-07-21T13:34:20 I'm pretty sure ou settings are /not/ cached across calls in the backend ... that would be silly. however, staff client might 2010-07-21T13:34:57 Yeah, FM_AOUS_RETRIEVE is called and cached in the staff client at login time 2010-07-21T13:35:00 Well, I know *I* never do anything silly in code I write...;-) 2010-07-21T13:35:02 Ah, I see the SC lists "Retrieved org unit settings" in its message area, so I'll assume a log-out/log-back-in would not hurt. 2010-07-21T13:43:14 2010-07-21T13:43:16 Is there any way, w/in the Staff Client, to see what position a given patron's hold request occupies in the hold request queue? 2010-07-21T13:43:55 Has anyone used something like awstats or other program to analyze Evergreen's logs to determine usage? 2010-07-21T13:44:03 agJohn: in trunk, though queues are sort of a fiction 2010-07-21T13:44:58 Does that go any ways to explaining why they're getting filled out of what seems the rational order? ;-) 2010-07-21T13:45:00 agJohn: you can sort holds by request date (in say, the record display, View Holds) and be mostly right 2010-07-21T13:46:11 That's probably good enough for the librarians. If we've got the org unit setting for the base of the org unit tree set to Holds: FIFO true, that should be completely right, should it not? 2010-07-21T13:48:07 I think so. I can still imagine exceptions (with op-capture and certain classes of patrons getting dibs on certain classes of items, etc.) 2010-07-21T13:48:07 bshum: I think the programs of choice are Perl one-liners 2010-07-21T13:48:43 agJohn: assuming no frozen holds, no cancelled holds, and probably some other minor exceptions -- and timing of capture across all branches, of course 2010-07-21T13:49:21 dbs: Interesting. Can you help point me in the right direction for those? 2010-07-21T13:49:22 * dbs doesn't pretend to understand holds, at all 2010-07-21T13:49:49 it's magic 2010-07-21T13:51:02 bshum: something like http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#generate_counts_for_normalized_query_strings_from_activity.log 2010-07-21T14:03:03 grabbing 0348 2010-07-21T14:03:58 dbs: Neat! Thanks for steering me in the right direction. Now I just have to figure out what that is parsing and how to get it to pull information from activity.log files from several different directories (by day apparently) 2010-07-21T14:04:54 *** dbs has quit IRC 2010-07-21T14:20:35 *** dbs has joined #evergreen 2010-07-21T14:22:00 *** jenny has quit IRC 2010-07-21T14:22:47 *** jeffgreenca_ has joined #evergreen 2010-07-21T14:23:15 *** jeffgreenca has quit IRC 2010-07-21T14:23:27 *** jeffgreenca_ is now known as jeffgreenca 2010-07-21T14:43:04 *** lisppaste has joined #evergreen 2010-07-21T14:46:09 *** _bott_ has joined #evergreen 2010-07-21T15:15:23 oh neat! 2010-07-21T15:15:28 i have a hold ready for pickup. 2010-07-21T15:15:35 problem: said hold is suspended. :-) 2010-07-21T15:15:41 *** jenny has joined #evergreen 2010-07-21T15:17:39 easier to grab if it's held up in the air for you ;) 2010-07-21T15:18:56 * berick plays keepaway 2010-07-21T15:19:34 jeff: perhaps it was suspended after capture? 2010-07-21T15:20:15 Does anyone restart Evergreen and Apache on a periodical basis to clean out memory issues (if any)? 2010-07-21T15:22:00 berick: i placed and suspended it with no activation date. i haven't been able to contact one of the people who handled the copy just before capture, though. 2010-07-21T15:23:35 *** Dyrcona has quit IRC 2010-07-21T15:24:59 moodaepo: not in recent memory ... in 1.2, perhaps, but only if issues actually cropped up 2010-07-21T15:25:20 We had an interesting even yesterday. We run the evergreen/apache server on a virtual server (vmware cluster) and there was a spike in memory use. Well since the vmware cluster couldn't communicate with the this virtual machine it shut the server down, it was supposed to bring it back up but it did not. We can't tell what caused the spike from the logs (any and all). 2010-07-21T15:25:37 s/interesting even/interesting event/ 2010-07-21T15:25:42 *** yboston has quit IRC 2010-07-21T15:27:30 The postgres server which runs on it's own virtual machine was chugging along just fine and didn't even need to be touched. 2010-07-21T15:29:04 moodaepo: not here. we do see occasional CPU spikes on apache where a given process will churn along at 99.9% (usually when someone requests a record with thousands of items attached) 2010-07-21T15:29:25 in which case "kill " suffices 2010-07-21T15:30:05 btw, miker_, is there a better solution than the patch in https://bugs.launchpad.net/evergreen/+bug/491594 yet in trunk? 2010-07-21T15:30:22 * miker_ REALLY wants someone to take on the "port supercat modperl to C" project ;) 2010-07-21T15:31:17 maybe the better solution is "use dbwells's new serials stuff" 2010-07-21T15:32:16 dbs: IMO, yes. replace the copy summary section with a paging bibtemplate implementation -- one call per page-of-copies for all the info you need, and you get to choose how big the pages are 2010-07-21T15:33:00 s/$/that exists/ :) 2010-07-21T15:33:06 s/yes/yes there's a better solution/ 2010-07-21T15:33:09 heh 2010-07-21T15:33:19 definitely less invasive 2010-07-21T15:33:50 miker_: I see...well I'll update folks if we find out what happened or if it happens again. Hope to find something to monitor memory and cpu usage by each process/service and log when they spike. 2010-07-21T15:34:34 dbs: Yea I've seen cpu spikes which were no problem, this was a available system memory that was kaput 2010-07-21T15:34:35 moodaepo: nagios+snmp or mmrd+rrdtool+mrtg 2010-07-21T15:35:58 miker_: Our systems guy has nagios setup but that does only total memory not the more which process/service was the culprit information...or maybe there is a plugin we don't know about? 2010-07-21T15:37:16 well, you can certainly write a total memory plugin that reports the worst offenders when you go warning or crit 2010-07-21T15:37:30 nagios plugins are dead-simple to write 2010-07-21T15:39:11 Might have to give that a go sometime. 2010-07-21T15:51:15 hah! 2010-07-21T15:52:17 okay, have to confirm, but i think the problem here is that if you force re-targeting via "Find another target" on a suspended hold and there is a "best copy", and you then check in that copy, it'll be captured -- even though the hold is suspended. :) 2010-07-21T15:52:23 will confirm and hopefully patch. 2010-07-21T15:52:37 good news is that this circumstance is somewhat uncommon. 2010-07-21T15:52:51 more common depending on workflow. 2010-07-21T15:56:47 *** alxp_ has quit IRC 2010-07-21T15:58:58 *** Meliss has quit IRC 2010-07-21T16:00:12 *** dbs has quit IRC 2010-07-21T16:00:12 *** youdonotexist has quit IRC 2010-07-21T16:00:13 *** atz has quit IRC 2010-07-21T16:00:13 *** leed- has quit IRC 2010-07-21T16:00:13 *** phasefx_ has quit IRC 2010-07-21T16:00:59 *** atz has joined #evergreen 2010-07-21T16:04:00 *** sfortin has quit IRC 2010-07-21T16:04:23 *** dbs has joined #evergreen 2010-07-21T16:06:08 *** leed has joined #evergreen 2010-07-21T16:12:21 *** phasefx_ has joined #evergreen 2010-07-21T16:21:01 *** bshum has quit IRC 2010-07-21T16:27:39 *** laura_ has quit IRC 2010-07-21T16:31:45 *** natschil has joined #evergreen 2010-07-21T16:35:22 *** afterl has joined #evergreen 2010-07-21T16:35:37 quit 2010-07-21T16:35:41 *** shopkins has quit IRC 2010-07-21T16:47:42 <_dkyle_> miker_: it seems the asset.merge_record_assets function drops the indicator fields on merged 856 tags 2010-07-21T17:03:03 *** natschil has quit IRC 2010-07-21T17:03:50 *** dbs has quit IRC 2010-07-21T17:09:37 *** natschil has joined #evergreen 2010-07-21T17:14:42 *** natschil has quit IRC 2010-07-21T17:37:13 *** jenny has left #evergreen 2010-07-21T17:58:44 *** _bott_ has quit IRC 2010-07-21T17:59:01 *** _bott_ has joined #evergreen 2010-07-21T18:38:33 *** pmplett has joined #evergreen 2010-07-21T18:57:05 _dkyle_: will look tonight 2010-07-21T19:01:50 *** jeffgreenca has quit IRC 2010-07-21T19:07:42 *** afterl has quit IRC 2010-07-21T19:11:34 Anyone around who knows if you have to have a hard or soft boundary defined for hold requests to be valid (code seems like you have to have one or the other). Don't know how to set them up... :-( 2010-07-21T19:56:56 agJohn: they are ou settings. in our system, where we have holds stop at the system boundary (as opposed to branch or consortium), we have ours set to 1. i think there was somequestion the last time i looked as if it was a depth or some other value. 2010-07-21T19:57:32 agJohn: someone else present may have more details there. i won't have a chance until later to verify myself. 2010-07-21T20:13:49 they're depth values 2010-07-21T20:14:27 hard says "never look beyond selection_ou at hard-boundary depth" 2010-07-21T20:15:42 well, that's the wrong way to put it 2010-07-21T20:16:01 it sets selection depth to the value of the hard ou setting 2010-07-21T20:17:05 soft sets the selection ou to pickup_lib /at depth/ {soft boundary} (an anscestor) 2010-07-21T20:17:57 so, hard should always be smaller than (closer to 0) or equal to soft 2010-07-21T20:20:49 put another way, soft allows you to always search, say, an entire system for a copy without looking at /just/ the pickup lib first. hard allows you to never look beyond, say, the system in which the pickup lib (selection ou) lives for a potenial copy 2010-07-21T20:27:01 WHOA!!!!! HOLY CRAP I LOVE GOOG CHROME! 2010-07-21T20:28:33 typed in a trunk server hostname, little suggest box below the url bar has an entry with a little magnifying glass and "Search CONS:" ... arrow to that and start typing, hit enter ... I GET THE OPENSEARCH SLIMPAC SEARCH RESULTS! 2010-07-21T20:29:09 just because of the opensearch description in the front page of the opac 2010-07-21T20:29:20 that, my friends, is rocksome 2010-07-21T20:29:22 that is all 2010-07-21T20:38:40 _dkyle_: first: indeed, it was dropping indicators. second: fix being committed soon 2010-07-21T20:39:34 oh, and re AWESOME opensearch stuff in chrome, confirmed it works in 1.4 and beyond 2010-07-21T21:49:16 *** pmplett has quit IRC 2010-07-21T22:05:30 *** pmplett has joined #evergreen 2010-07-21T22:16:45 chrome is pretty badass. firebug-like dev tools built in... w/ sexier graphs 2010-07-21T22:51:47 *** alxp has quit IRC 2010-07-21T23:26:37 *** Callender has quit IRC 2010-07-21T23:26:37 *** kbeswick has quit IRC 2010-07-21T23:28:12 *** Callender has joined #evergreen 2010-07-21T23:31:51 *** kbeswick has joined #evergreen