Koha: Because the migration will occur between semesters, there will be a clean break for the Academics. We will set fixed and final due dates, as we do every year.

New Port Richey: We don’t know yet how we will handle this, as we do not yet know which vendor New Port Richey will migrate to.

Subscription Database Access

Subscription databases identify valid users in two main ways. They look at the IP address of the computer that is trying to connect, or they can check a validation server. As each library moves to its new system, its IP address will change. We—TBLC staff and library staff—will need to compile a list of the subscription database vendors and provide each of them with the new IP addresses and the date they will become active. Presumably, then, they will accept searches from computers with the new and different IP address. RPA is an intermediary. When a patron at home wants to search a subscription database, he comes to the RPA server first and is asked for his barcode. RPA looks that barcode up in the main library database and, if it is good, passes it on to the subscription data base with an “OK” stamp. RPA will need to be told the new IP addresses, so that at the appropriate time it can go to the correct server to validate remote borrowers. In most cases your new vendor will provide you with or help you find a substitute for TBLC-managed RPA.

Like RPA, SIP is a process that uses an intermediate server (housed here at TBLC) to validate a patron for a specific purpose. It may be for self checkout or to reserve a public access PC or for some other purpose. The patron’s barcode is keyed in or scanned at the library and is sent to the SIP server. The SIP server does a barcode lookup in the patron database and sends a response back to the device at the library. Like RPA, SIP has to know where the patron database is, so we will have to give it the IP address of the new server at the time of the transition. Again, SIP services will probably be a part of your new vendor’s package.

Four Sunline libraries currently use Debtcollect and Unique Management. Three of them are migrating to Polaris. Unique tells us that they can work with Polaris as easily as they can with Horizon, and that nothing special needs to be done for the transition. The fourth user is New Port Richey, and we do not yet know how their migration will affect their use of Unique Management.

There are a large number of iBorrow issues that come out of the migration.

1. Duplicate barcodes. The problem of duplicate item barcodes has come up with PALS in the past, but it should not come up in relation to iBorrow. This problem would occur if a library that migrated into the PALS database brought with it an item that had been borrowed (e.g through OCLC) from an existing PALS library. The copy attached to the brief record for the borrowed item would have the same barcode as the original item in the PALS database. Since iBorrow has not so far been able to communicate with Polaris, the PALS Polaris libraries are not part of the iBorrow network. So, no PALS items will have come into our Sunline system through iBorrow. Items borrowed through traditional ILL mechanisms and entered into the Sunline database with their original barcodes could cause this problem. But not iBorrow.

2. Use by patrons prior to the closed period. Patron searches in iBorrow and ILL staff work in the URSA client are both done on a server in Utah that is unaffected by the migration. When a Sunline library fills a request for another library system through iBorrow, that item is checked out to a dummy patron in the Sunline database, while it is on loan to the ‘foreign’ borrower. To Sunline, this is a normal checkout, and it will carry over intact into Polaris. Fixed and final due dates for the libraries going to Koha will prevent any issues there. Generally speaking, there is no technological reason to restrict patrons’ use of iBorrow prior to the closed period.

3. Use by patrons during the closed period. Sunline patrons who use iBorrow are, by definition, getting materials from other libraries, and these libraries are not affected by the Sunline migration. I see no reason to restrict the Polaris libraries ability to initiate requests in iBorrow during the closed period. The Koha libraries will probably cease to use iBorrow after they migrate, because Koha does not have an NCIP responder iBorrow can talk to. We can’t yet address how this will be handled with New Port Richey.

4. Use by patrons after re-opening. Like SIP and RPA, iBorrow stores an IP address for a library and communicates with it at that address. We will have to change the IP addresses for the Polaris libraries in iBorrow. This will take about 2 minutes per library. The bigger post-migration issue is that–as of mid-May–Polaris can handle only one of the eight NCIP messages that iBorrow uses. Fortunately, it is the most critical of those messages: the one that enables patrons to validate and request. We are making progress with Polaris and may have many or all of the working by the time of final migration.  At present, Koha and iBorrow to communicate at all, so we’re not optimistic about the academics being able to continue to participate.

There are two migration-related issues with Overdrive: titles available and patron validation.

We need to make sure that any titles to which Polaris patrons have legal access are copied into the new database, if they are not there already.

Overdrive also uses RPA to validate borrowers. Our RPA server will not move nor change its address, so the change of home server should not matter to Overdrive, so long as they can find our RPA server and our RPA server can find the new Polaris server.  Again, new RPA or RPA-like services provided by your new vendors may eliminate any need for RPA in relation to Overdrive.

http://ipac.tblc.org will see everyone’s material, because this is the ‘all libraries’ interface.This is the first ‘draft’ of this message. I expect that there will be additions and corrections.   If you have any, contact me at TBLC by phone or email.

But don’t delay! Ms. Has-it-all-but-wants-more keeps calling us back to ask why she hasn’t gotten hers yet.  And she can’t even spell iBorrow.

 –Al Carlson

Java 1.6 compliance:  Yes.  No problems at all.

Faster “Edit Request” response:  Well, maybe.  A little faster, I think.  It’s not yet what you would call ’speedy’, but if you can set up a three way race with MS Vista and a glacier as the other two competitors, you can bet on URSA.

Proxy Request Improvements:  The patron’s barcode is now readable as you type it in.  Yayyy!

Incoming Loan to Fill Loan:  This one is lovely.  It is still true that URSA can’t place a hold on your local system, if it can’t give your server a single unique bib record to request.  That is why ISBN’s are so important.  But there are several other things that can drop a request into your Incoming Loan box, even if it has an ISBN.  Most of these are transient.  So, if you could try again, the hold would take.  The new build lets you do that.  If you go to your Incoming Loan space and find requests there with ISBN’s, you can right click on each request, choose Process Request, and watch it go to Fill Loan.  That’s not the important part, though.  The important part takes place in your server, where a Hold gets placed, and a copy will show up on someone’s pick list tomorrow morning.

More Detail in History:  I’ll send this out to you as Email and attach a spreadsheet Holly gave us.  When you edit an item now and look at its History, you (and SirsiDynix Support) will see a lot more information.

Availability Rules and LOLR Issues:  These weren’t really testable over one weekend.  Time will tell us how much closer to ‘perfect’ iBorrow/URSA is at following the Availability Rules and properly routing requests that run into LOLR issues.

As we learn more, we’ll share it with you.  And I trust you to tell me when you find something that doesn’t work.

–Al Carlson

The neatest trick is being able to go into the Incoming Loan work space in the client, find a request there with an ISBN, right click and ‘process’ it, and have it show up in Fill Loan.  With a hold placed in the local system.

I used this a lot on Friday evening, because both Hillsborough County and Sunline have been ‘resistant’ to iBorrow requests for the past week.  Both issues were resolved Friday afternoon, just before the new build was loaded, so there were LOTS of requests hanging around, eager for a chance to create a real Hold.

It also runs nicely with Java 1.6.

We’ll keep testing and keep you informed.

–Al Carlson

If you are a Southeastern University borrower, any hold you place in Sunline from now on can be filled only by an SEU item.

If you are a New Port Richey borrower, any hold you place in Sunline from now on can be filled only by a New Port Richey item.

(Pause for dramatic effect)

If you are a borrower at Dunedin, Largo, Oldsmar, Safety Harbor, or Tarpon Springs, any Sunline hold you place from now on can be filled only by an item owned by any of the libraries migrating to Polaris. In other words, holds can still be filled among those five libraries just as they always could among the larger group. Those holds will behave as though New Port Richey and the Academics (Wouldn’t that be a great name for a rock band?) had vanished in the night, leaving only the Pinellas Publics behind. I can do this, because (Polaris tells me) those holds queues will be preserved and reassembled in the new system.

Got all that?   Want to read it again?  Good.  Let’s go on.

“Caveat” is Latin for “Gotcha!”  And there are some caveats to tell you about.

(1) This is one complex set of rules. I may have formulated them perfectly on the first try. And I may be the long lost heir to the throne of Pottsylvania. But I will not be surprised if errors crop up. Or someone else winds up on the throne. If you or your borrowers encounter weird stuff while placing holds, tell me.

(2) If things go as we hope they will with Polaris, the New Port Richey borrowers and the Clearwater Christian College borrowers will be part of the migration and will wind up in the PALS database as reciprocal borrowers. They will also be on their own new systems, of course. So, in theory, I could have tweaked the rules to allow those groups to be part of the Polaris Public group for requesting purposes, although their parent libraries would still be off limits to the borrowers in the Polaris Publics group. At present, I have decided not to attempt that level of rule complexity. If the rule set I put in place today works perfectly, and if we get hard data on what will happen to those borrowers during and after the migration, I can revisit this. But not right now.

(3) Keep in mind that Holds are placed at the Title level and filled at the Copy level. You don’t place a hold on the Dunedin copy of Dracula in Suncat. You place a hold on Dracula, and you get the first available copy. Which may or may not be Dunedin’s. So, depending on how many copies of a title there are in Sunline and who owns those copies, my new rules may stop a hold from being placed at all or they may not. If you are a CCC patron and try to place a hold on Dracula, you may see lots of copies and be unable to place a hold, because CCC owns none of them. If CCC owns one copy, you can place a hold. If that copy is out, and all the other libraries have copies on the shelf, you may be surprised by how long it takes your hold to be filled. Because none of those on-the-shelf copies at Oldsmar and Safety Harbor and so on can fill your request. Only the CCC copy can.

Got a headache, yet?  I do.   So, I’ll stop here and we’ll see what happens with Holds over the weekend and coming week.  I’d like to say, “If you run into problems, call Matt”, but that wouldn’t be fair.  Call me.

–Al Carlson

Let’s start with the good stuff.  Citrus County is now an active iBorrow participant, and Collier County will join us on Monday morning, May 5.  Did I hear an “Ooooo!” or perhaps an “Ahhhh!”?  Well, I should hope so.

Both systems are easing in rather than jumping in, so here are the complications.  Citrus will begin by lending only.  That’s right.  Citrus County has been added to your list of lenders, and you should find yourself getting loans from them any day now.

For a while, they will request only out of Tech Svcs HQ.  These will mostly be staff tests, but for real items.  No more sandbox testing for them!  When they get used to that and work out any bugs, they will open it up to Reference Desk staff as a tool Reference can use when the patron’s needs suggest it as the best option.  When that is going smoothly, they’ll open it up to their borrowers for direct access.

Collier County will be doing pretty much the same thing.  They will begin lending right away on May 5.  But they will ease into borrowing a little at a time.  So, for a while, you may have to put up with both Citrus County and Collier County lending you more than they borrow from you.  Try to be brave about that.

 Now, let’s do the not-so-good-at-the-moment stuff.

East Lake, Palm Harbor, and Pinellas Park have all completed their migration to Polaris.  That’s good for the citizens of Pinellas County, but it moves them to a library system that URSA/iBorrow cannot—at the moment—talk to.  So, as I write this, they cannot fill any new requests for you.  (They can still fill requests they got before the migration, and they will return your stuff.  They promised.)

 But we are working with Rob Gray at Polaris on getting it and URSA to talk to one another.  Earlier this week we were able to get past a major hurdle on their test server.  We were able to go to the iBorrow Portal as a Polaris patron (which the Palm Harbor, East Lake, and Pinellas Park patrons now are), create an iBorrow user, and request a title.  If we can get that same thing set up on the ‘real’ Polaris server, East Lake, Pinellas Park, and Palm Harbor borrowers can start requesting again.  I think there is also a way they can fill iBorrow requests, but we haven’t had a chance to really test that yet.  Remember all the glitches and strange errors that you went through when you were first coming up on iBorrow?  Well, it’s now Polaris’ turn for all that.

Check in here from time to time for updates.  I’ll also put them out as Email.

–Al Carlson

But as of Monday, April 21, that changed!  Now, Hernando patrons who can’t find what they want in the Library’s online catalog can click on—are you ready?—”Can’t Find It?”   That takes them to a page with a couple choices, and one of those takes them to an iBorrow link.

This is sort of a soft launch for now. They plan to do some classes in May and bring in the brass band from River City in June.

As you may have heard, the Statewide Delivery Service is getting an upgrade.  On Monday, January 14, we’ll begin Beta Testing barcodes on orange Delivery bags using print-on-demand labels. (The TBLC and Ft. Myers hubs will be the participants in the Beta Test.)   Several of you have contacted TBLC to ask how you should integrate these new high tech labels with your existing procedures for AlleyCat and iBorrow materials, when you become part of the action.  Here’s the plan. 

If you currently use AlleyCat labels, use the new barcoded labels, but whack them with the iBorrow rubber stamp before you put the label into the orange bag pocket.  This will alert anyone with 20-80 vision or better that these are AlleyCat/iBorrow items and should be handled accordingly.  If you don’t have an iBorrow stamp, contact Vickie Frost at frostv@tblc.org, and she will send you one.  If you don’t currently use AlleyCat labels, you may ignore this message. 

And if your palms are feeling sweaty, because this is the first time you’ve even heard of the whole idea of barcoding Delivery bags, visit www.tblc.org/delivery.  All your questions will be answered.

Whew!

For a partial list of new features, see the article below called “Early Christmas Gift”.

–Al Carlson

That’s because it was the old build.  Our weekend testing revealed a deal breaker, so we had SirsiDynix restore the old build Sunday evening.

We’d hoped that our testing would be just a formality, and that we’d sign off on the new version by Saturday noon and go back to Christmas shopping.  But we ran into a problem Friday night that the SirsiDynix engineers were not able to diagnose and fix.  Not that they didn’t try.  We caught Holly at the SirsiDynix Christmas party Friday evening, and she had Keith Poole in on the problems before the first round of canapés was gone.  We all continued testing the next day, but by Saturday afternoon, it was clear that this was not a trivial coding issue.  Peter Fripp restored the build we’ve been using late on Sunday afternoon.

The problem we ran into was a variation on one we’ve seen before:  declining requests.  About a third of the time, we would get a rude and cryptic error message, when we tried to decline a request.  We hoped to find the pattern behind the problem.  Maybe something like, “When the requesting library is their own Lender Of Last Resort and they are set to unmediated, declining will fail.”  Nahh!  Nothing that easy.  I had three requests from the same library lined up in Fill Loan in the iBorrow Training database.  The first declined fine.  The second failed.  The third worked.  Go figure.

So, Holly, Keith, Peter, and Aaron will put the new build up on the rack (Think mechanic, not inquisition) this morning, tear it apart, and see if they can find the cause of this nasty bug.  You will keep using the build you know and have grown to love.  And we’ll let you know when we’re ready to try again.

–Al Carlson