Beth’s Blog

Now, here’s the long version, mostly for ILL staff:  The URSA/iBorrow server lives in Utah and communicates with our local library servers through NCIP: the NISO Circulation Interchange Protocol.  Every major step in an iBorrow request has an NCIP message. Sometimes two of them. URSA has the easy job. It tells the local library server to “do this”, and the local server has to get it done. The local server does not get to give URSA any instructions. The most it can ever say is “Yes, sir!” or “Sorry. I can’t do that!”

When the item that your patron requested in the Portal shows up at your library in the orange Delivery bag, you do Receive Loan in the URSA client.  That generates the NCIP Accept Item message—the one that creates a brief bib, an item, and a hold for the patron.  That works in Polaris, too.

Now, before we get too excited, I should say that it has worked in Polaris so far. And Polaris staff will have to set up a particular template in your account, once you come up on Polaris.  We may be able to arrange to have that template in place on the day you come up. I guess the bottom line is that this can work and has worked. And we may have to fumble around a little at first to make it work in your particular library.

When “Request Item” works, the local server places a Title level hold for one of the URSA dummy patrons.  If the local server says, “Yes, sir! I did that!”, URSA puts the request in the Fill Loan workspace, and you work with it there.  If it fails, the request goes into your Incoming Loan workspace. You can fill it the same way you would, if the request came from OCLC. You find it on the shelf and lug it back to ILL.

Sidebar: The NCIP Request Item message is also the one URSA uses when it turns a Portal request into a local hold. That is another reason that it is at the top of our list.

“Lookup Item” uses the barcode you scan to find the title this barcode belongs to in your bibliographic database. Then it brings back the ISBN from that title and uses that ISBN to find the matching request in the URSA database. If it finds it, it uses “Checkout Item” to tell your server to check out the item to the dummy patron, while you sent the real item to the requesting library. These two NCIP messages do not yet work in Polaris, so you will need to do the kind of checkout you normally do with an OCLC request. Then you just change the request’s status to Filled in the URSA client.

Don’t tell anyone, but that message does not work in Sunline. It never has. So, you have to check returned item in yourself.   This NCIP message may or may not work in Polaris. We haven’t gotten there yet. But, it can’t be worse than Sunline, so you won’t be going backwards. 

Are you still awake? Are you still with me?

The two borrowing messages work in Polaris now.

The three lending messages are being beaten into submission as you read this.

Your patrons will probably need to re-register in the Portal once. And their open requests won’t follow them to their new identity.

Aside from that, they can request just as they do now.  So, turn ‘em loose, and let them do it.

You’ll have to do more manual work while lending than you do now, but not for long.

Got questions? Got concerns? Got tickets to the next Rays game?

Call me.

–Al Carlson

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.

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

You may want to take notes.  There is a lot happening right now.

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

TECO experienced a power outage on Saturday, September 8, at about 11 a.m. that took out several office complexes in the vicinity of Falkenburg and Windhorst.  TBLC was one of the complexes that was hit.  Our APC UPS carried our servers for almost an hour, but then it had to shut down.  At that point, Sunline, SunCat, RPA, SIP, Help Desk, and any other service that depends on a TBLC server was down for the count.

TECO took responsibility for the problem but was unable to give us any prediction on when the power would be restored.  It turned out to be about 4:30 p.m.

I have restarted all the servers that did not restart automatically.  So far as I can tell, everything is working as it should.  But I may have overlooked something.  So, if you run into problems on Sunday, September 9, call the Sunline weekend number (813-476-1725).

–Al Carlson

The title of this post makes it sound as though we’re going to get the Sunline server ready for the Antiques Road Show.  But, as you know, we will be reloading the Operating System to remove all traces of the hackers who invaded it and who may have left secret entrances that we haven’t found.

The proposed date for this is still Thursday, July 12.
The process will take all day.  (If you work the evening shift, you may have access.  We can’t predict that with any certainty.)

While Sunline is down, you can use PC Reliance to do Checkouts. 
Matt will be calling you early next week (The week of July 9) to make sure you are comfortable with it or have some alternate plan.

While Sunline is down, we will “try” to keep RPA working. 
It usually talks to the borrower file on Sunline, and that will be unavailable.  But Sandy Schlueter from SirsiDynix has a plan that should let us export that file as a ‘flat file’ to the RPA server itself, then tell RPA to talk to that file instead of the one on Sunline. 

One small caveat here.  Once the borrower file is copied over to that flat file, any new borrowers who register between then and Thursday morning will not show up in an RPA check.

And while Sunline is down SunCat and SIP will not be able to function. 
SunCat is essentially an index to–and a display device for–the Bib and Holdings records on Sunline.  No Sunline, no SunCat.

SIP, like RPA, accepts a query from a remote PC (e.g the Largo SAM system or the New Port Richey 3M Self Check) and ‘talks to’ the Sunline borrower file in order to respond to that query.  Unlike RPA, SIP can’t work with an exported flat file.  So any devices or services at your library that depend on SIP will not work on July 12.

Are you beginning to see why I think “lethal injection” would be a good concept to put into a convicted hacker’s punishment?

Expect to see more updates between now and the 12th.  If you have questions about this admittedly unpleasant and stressful process, please contact Beth Farmer, Ben Ostrowsky, or Matt Smith.

–Al Carlson

See the post just below this one?  Well, it’s still true except that our target date is now Thursday, July 12.

–Al Carlson

We have to scrape some hackers off the bottom of our shoes.  Well, actually we have to scrape them off the Sunline server.  But the idea is the same.  And we want to do a very thorough job, before we walk on the carpet.  Or restart Sunline. 

Yes.  We’ll have to bring the Sunline server down to do this right.  The traces we’ve seen suggest that the hackers are amateurs who have used tools that someone else designed in order to break into our system.  But those tools may have given them the ability to build secret back doors into our server that we have not found.  So, we need to treat them as a serious threat. 

That means bringing the Sunline server down and reloading its Operating System (OS) from a CD, then rebuilding all of the file structure that allows Sunline to work.It will be an all day job.  And it will affect your use of SIP, HIP, and RPA as well. 

Our first target date is this Thursday (July 5), with a fallback date of next Thursday (July 12).  (The Sunline Directors were clear that Thursday was the best day of the week to do this.) 

We’re between the rock and hard place of wanting to do this as soon as possible and needing to have a complete set of resources to do it.  Plus a guy at SirsiDynix to do the really hard stuff. 

I apologize for the short notice (if we do this on July 5), and I regret having to do this at all.  I’m beginning to think that the penalty for hacking ought to include the words “lethal injection”.

–Al Carlson

Suncat searches began producing weird results Monday afternoon, so we got SirsiDynix on the line and had them take a look.  They said, “Corrupted index.  Rebuild it.”  So, we fired up the Horizon Information Portal (HIP) Mass Indexer and put it to work.

It has–as I write this at 4:40 Monday afternoon–re-indexed about 100,000 records.  It has been knocking them off at the rate of 25 per second, and we  have a little under 700,000 records in our database for it to take care of.  You do the math.

If things aren’t hunky dory Tuesday morning, we’ll attack the problem again.

–Al Carlson

(This post is for those of you on Horizon system.  If you are on Dynix, we don’t think it is an issue.)  Believe it or not, some patrons lose the material we check out to them.  When they do, a LOST block pops up when they try to check out more stuff.  Except for iBorrow items.  Those blocks have gone straight to History. 

But no longer!  With help from several people, we’ve figured out how to put a default price of $25 on all iBorrow items.  So, if one of your borrowers gets a book from another system and loses it, the block will say he owes $25.  If he borrows a BMW through iBorrow and loses it, the block will also say he owes $25.  So, don’t trust it on the dollar amount.  The point was to get it to show up as an active block, and that took associating a dollar figure with the item.

We still don’t want patrons to lose iBorrow stuff.  But, if they do, we’ll know about it at Check-Out.