Beth’s Blog

We downloaded a new iBorrow build on Wednesday, February 21.  We got some good bug fixes, some nice enhancements, and a few new bugs.  So far, these seem to be kind of gnat sized bugs, rather than the giant cockroaches we’ve gotten a few times in the past.  Here, for your amusement and edification, is what they are and what we know about them.
Lender cannot decline requests
If the borrowing library has no Lender of Last Resort in the library profile that Matt and I originally set up for them, and if there is no lender on the far side of you in the ROTA, you will not be able to decline their requests when they show up at your library.  SirsiDynix has found the cause of this problem, and it will be fixed in the next build.  Meanwhile, there are two workarounds. 
Workaround Number One is to just leave the requests you would normally decline alone.  They should “age” out of your Fill Loan or Mediate Loan work space in a few days.  Exactly how many days depends on what you asked us for when we initially set you up.  Remember what your Mom told you—“Ignore them and they’ll go away.”
Workaround Number Two is to give these libraries a Lender of Last Resort for a while.  Usually we use OCLC for that, and the affected libraries may want to try that approach anyway.  But we can put anything in there, and you’ll be able to decline again.  But the ones you decline will go to that lender.  Ken Adams and I are still working on the details, but I think we could set up one of the libraries who is not yet using iBorrow (Sanibel, maybe?) as their LOLR, and set the aging threshold at one day.  So, anything you declined would bounce to there for a day, then reappear at the next participant in the ROTA.  We may have that set up by the time you read this.
‘Ear’ File Problem
If you had a file that lived on your OPAC server and spent all its time listening for NCIP messages to come from URSA/iBorrow, what would you call it?  How about an ‘Ear’ file?  That’s the common name at SirsiDynix for the “NCIP Responder File” that we have on our local servers.  We should probably call it an “Ear and Brain File”, because it has to interpret what URSA tells it after it hears it.  And our current Ear file has a brain cloud. 
So, many of you are having trouble filling requests in Fill Loan, because the Ear file keeps saying, “Huh?  What was that middle part again?” whenever URSA sends it an instruction.  I’ll tell you why in a minute, but the good news here is that we don’t need to wait for a new build to fix this.  We can load a new Ear file as soon as SirsiDynix can whip one up.  The catch is that every affected system has to load the Ear file separately.  Loading the Ear file at Sunline will not help Hillsborough.
The cause behind this problem is that all Horizon systems use a computer language called SQL (Structured Query Language).  There are three dialects of SQL:  Solaris, MS, and Sybase.  Our current Ear file has trouble with the Sybase dialect.  And Sunline uses Sybase SQL.  So, we think, does Palm Harbor.  And maybe Hillsborough and Polk.  We’re still checking.

Up until yesterday, the messages in the My Account section of the iBorrow portal were prhased in “ILL-speak”.  They made sense to ILL staff, but not to patrons.  The new messages are less confusing.  I’ve listed them below with the status on the left and the matching message on the right.

STATUS                                 MESSAGE

Requested                              Processing request

Pending at Borrower                Processing Request

Pending at Lender                    Processing Request

Filled                                       Shipping Requested Item

Received                                 Processing Requested Item

If you have ideas for even better wording, send them to me, and I’ll pass them on to SirsiDynix.

The latest and greatest iBorrow build is now available on a computer near you. Here are a few of its improvements.  (I’m quoting from the SirsiDynix ‘Delta Document’.  I have not yet had a chance to verify every one of these.)

1. URSA/iBorrow will no longer send the same request to OCLC multiple times, even if OCLC is slow to respond. I’m not sure what this will mean for your request, if it’s OCLC that drops the ball. I hope you expert OCLC users will keep me up to date on that.

2. In Receive Loan in the URSA client, “Local Barcode” has become the default window. (You can tell by the blue ‘radio button’) This has always been the right window to use, but it was not the default, so you had to remember to select it every single time. And, in case we’ve never mentioned this, “Local Barcode” doesn’t mean one of “your” barcodes. It means the barcode you want your local server to associate with the item you are receiving. Almost always it will be the barcode that is on the item.

3. In Fill Loan, if the item whose barcode you scan has a different ISBN than URSA/iBorrow is expecting, it will still let you use that item to complete the Fill Loan. This gets a little tricky, so take a big gulp of coffee and stay with me here. First off, URSA loves ISBN’s. To URSA, the requested title is the ISBN. Keeping track of a requested title that does not have an ISBN brings a sheen of sweat to its silicon forehead. Unfortunately for URSA, many libraries put multiple ISBN’s into the same bibliographic record. For example, the paperback and the hardcover editions will both be attached to the same bib record, and there will be two ISBN fields in it. URSA hates that. But now, when you scan a barcode in Fill Loan and URSA does its barcode lookup on your local server, it will bring back ALL of the ISBN’s in the Bib record and see if ANY of them match the ISBN of the request. If any one does, URSA will be happy and give you the Success message.

Now, let’s make it harder. Some libraries do NOT put all the editions of a title in the same bib record. But a good ILL person will often know that “The item I have in my hand is what the patron actually wants”, even if none of the ISBN’s in its bib record match the ISBN in the original request. URSA will now ask you whether you are sure you want to fill THIS request with THAT item. If you say, ‘yes’, it will proceed and give you a Success message. (It started doing this in the previous build, but I don’t think it was consistent about it.)

4. User friendly messages—which missed the bus on their way to the previous build—will now appear in the Portal in My Account. I haven’t seen these yet, so I don’t know how user friendly they actually are. If you spot one that is misleading (or rude), please tell me.

5. And speaking of My Account, here’s a nice addition. If you do a proxy request for a patron over the phone, the request you put in for him will hook up with the requests he has made on his own, and they will all show up in My Account in the portal. (This assumes he already has an URSA portal identity when you do the proxy. Doing a proxy request does not create an account for the patron. It just looks for an existing account and, if it finds one, adds the proxy to it.)

6. SirsiDynix also worked on the Availability Rules. Those are the rules that tell URSA/iBorrow which of your materials it can use to fill a loan from some other system and which it can’t. URSA’s grasp of Circulation Status has been a little weak up till now, and it has sometimes put requests in your Fill Loan work space, even when the only copy you own was really Out or Missing or in Mending. It should be much, much better at dealing with Circulation Status now, whether it is requesting one of your titles for some other system or turning an iBorrow request into a Local Hold. Gulp some more coffee here. Local Holds can be a little confusing. Here’s the short version.

If a patron is using your local online catalog, he can place a request on a title, even if all the copies are checked out. In fact, that is one the best reasons to place a request.

But URSA is not designed to patiently wait for a book to return. Its job is to find one—somewhere—right now. So, it is not allowed to place requests on local systems when all the copies are Out. (See Number 6 above) Now, you know that when a patron does a portal search in iBorrow and clicks on Request Item, URSA looks all over for available copies. If it finds an available copy on the same server that the patron is registered on (i.e. It is a Lee County patron and Lee County has an available copy), it will create a Local Hold. That is, it will hand the request off to the local server and let it fill the request. But—and this is big time—it will follow the same Availability Rules it follows when it is working for a ‘foreign’ borrower. If all of the copies are Out or otherwise unavailable, it will NOT place a local hold. It will try to find an available copy at one of the other participating libraries. So, there will be times when one of your patrons will get the item he wants faster through iBorrow than he would through your local system. (A murmur ran through the crowd.)

There’s more, but those are the highlights. And if I make you read any more, your lips will get tired.

Test these new features out. Tell me if any of them fail or if you find any new bugs. (There are bound to be some)

The latest iBorrow build on January 19 finally got it right.  It fixed some long standing problems and introduced some nice new features.  SirsiDynix is already working on and testing the next installment.  We’ll probably see it on Wednesday, February 21, so mark your calendars.  (In pencil)

If I can get a complete list of the new features prior to the download, I’ll put them out.  Here’s some initial information.

1.  The ‘patron friendly’ messages that missed the bus last time will appear in the My Account part of the portals.  We may still need to offer suggestions for improvement, but the idea is that the patron will actually be able to correctly interpret the statuses there.

2.  If a patron has an iBorrow identity, and if you do a proxy request for that patron, the request you do will link up with his record and show up in the My Account list of active requests.

3.  In Receive Loan, the default active ‘blank’ will be “Local Barcode”, which—as you ALL know—is the one you use whether you are using the barcode that came on the borrowed item or a barcode of your own.  (Give me a call, if this sounds like something that just came out of the Twilight Zone.)

4.  You will be able to use a ‘different ISBN’ when you fill loans.  I’m waiting for more detail on this one, but here’s how I think it will work.  Pay attention; this can be tricky. 

·       We and our patrons think of their active requests in terms of titles.  They want “The World Is Flat” or “Ice Age”.  But URSA/iBorrow thinks of them in terms of their ISBN’s.  When you said you wanted “The World Is Flat”, did you mean 0374292884, or did you mean 0374292795? 

·       If the patron originally clicked on Request Item next to the bib record with the first ISBN (Hardcover), and you try to fill it with the second ISBN (Paperback), iBorrow will get cranky and uncooperative, even though both ISBN’s are in the same Bib record.

·       With the new build, you will have a ‘graceful’ way to pat iBorrow on its little head and say, “It’s all right.  I know what I’m doing.”  And get on with filling the request.

5.  The new OCLC bugs will be fixed.

As I learn more, I’ll pass it along.