Enter Sierra

So, we’re moving to Innovative Interfaces Sierra, hosted at the III server farm in Syracuse, New York.

I will be updating this as we go. [also updated 2017.1.23]


We were notified that our aging III “turnkey” server, a Sun V240 running Solaris 9 (which hit the upgrade wall at version 2009B and no more upgrades to Millennium or other software were possible), needed an upgrade to our security, or it would jeopardize the campus being able to use credit cards.

I.T. is required to patch or update any servers with a rating of 4 or 5, that are accessible through the internet. The libcat.uafs.edu is one of those servers that needs to be patched or updated. According to the report, our OpenSSL is rated as a #4 and needs to be updated. In addition, “SSLv2 and SSLv3 protocols need to be turned off and the server needs to only use the TLS protocol.” (Is that clear to everyone? Then I don’t need to explain it, good.) There are other minor vulnerabilities at this time.

The catch is that we cannot upgrade due to the age of our software, and we cannot upgrade the software because of our outdated hardware — III is not maintaining a newer version of their software on this platform (Sun V240) on a newer version of Solaris.  This is our second server model since 1999.

So, we have to move on.  We don’t have the programmer(s) to handle an open source system, so we’ve been looking at OCLC or III’s Sierra for a changeover or upgrade for a while now.

Using III’s hosting was not cost-effective for a single server system, as we calculated — we could pay for a server and still get by for less, as long as III handled the service contract.  By moving to Sierra, however, which needs two servers, it then becomes cost-effective for us to have III host our catalog rather than trying to do it ourselves.  We’re not that large a campus, and our I.T. staff is working hard already, so let’s make it easier on them.

III offers the option to either stay with our present name libcat.uafs.edu, which means we would need to keep buying (and often updating) our SSL certificate, or changing to [something].iii.com and letting them deal with the certificate updating.  They are hosting larger campuses already, so they should be doing any needed updates for their more extensive databases already.

Warning: the decision to change to the iii.com domain did not work out – the SSL certificate does not cover us adequately. We are changing back to libcat.uafs.edu in spring 2017 and adding the WAM replace function along with an SSL certificate.

We’re also going to avoid the hassles of backup for the server (on little tape cartridges all these years) and let III start to do all of that.  Again, something else our I.T. staff won’t have to deal with anymore.  They didn’t have people to do backups on weekends and holidays anyway.

Fortunately, most of the computer workstations were updated when we moved into the expanded building, so the processors are fast enough with sufficient memory and such.

Our newest professional staff member has worked with Sierra before and is happy we’re moving to it, so we have an insider already who’s been through the conversion before.

Sierra is the future for III, and will be where they are concentrating their updating, so this was pretty much inevitable if we stayed with III.  At this time, we’re not ready to change to OCLC (as they presently exist) or another system.

First Teleconference

June 16: We had a teleconference with the III people handling things at their end, plus librarians and an I.T. representative at our end.

I asked them about going with the iii.com URL which, it turned out, they had already set.  Since we’re going to have to change all the I.P. addresses anyway, we want to update the name to uafs.iii.com .  They got a little ahead of us and created warkc.iii.com (based on our old name, since we started with them as Westark College).  We’ve asked to change to uafs to make it less confusing; we’ll see if they can manage that.

We did get the new I.P. address for our application server.  We go through that to a database server.

The sequence for us will be:

  1. Move to the hosted servers in Syracuse, N.Y. with our existing 2009B version of Millennium.  We’ll change the Millennium software on staff PCs to the new I.P. (me and maybe I.T.), and the links on the library web pages and databases (another librarian handles that) will go through the new hosted system.  I’ll need to change all the 856 links using libcat.uafs.edu to our new URL (whichever it ends up being).  This is set for July 7.
  2. Upgrade to version 2011, which is the closest version of Millennium that can convert to Sierra (no use upgrading more than that since we’re moving to Sierra at the end of it, anyway).  Do a quick bit of testing on that.  This is set for July 9.
  3. Sierra will be “seeded” and then we’ll be able to access the Preview version of that.  It should be ready by July 14.
  4. While on Preview, we’ll get the permissions and such set up for the staff along with installing the SDA (Sierra Desktop Application).  We’ll then have both Millennium and Sierra software for a bit.  Actual access will be read-only while any real work is still done in Millennium.
  5. We’ll go live on Sierra full time and use only that.  That will be July 28.

Since we’re relatively small, our down times for the changes should be only a couple of hours.  This will be during Summer II, which is a really thin semester, so it shouldn’t be a huge problem.

The time frames were expressed as normally being longer than we really need.  Since all this is being done on the hosted servers, I think it’s actually simpler and faster than having to deal with us remotely on local servers.  (On the other hand, people in California are dealing with servers in New York, if you consider that “local” for them.)  So our dates are somewhat compacted, which will get us in shape well before Fall classes begin on August 17.


III is using Basecamp for project management software.  We’ve gotten invitations (June 18) and I’ve logged in.  The interface looks nice.

I had already read the Sierra preparation information and created our circulation Statistical groups, so that’s done.  The other thing to do seems to be at III’s end: opening ports on the Sierra server.  I’d sent info on that to our I.T. people in an earlier email so they can see it’s not their problem at our end (III just gave a manual reference).

uafs or uasf?

Well, after a slight glitch, III switched us to uafs.iii.com.  I didn’t think about the fact that it also meant that their help software, CS-Direct, needed to change our login from the old warkc to uafs but apparently that is synced to make it easier to keep track.  Which happens to be the reason we wanted it changed to match our current acronym rather than the old one for Westark College (which we haven’t been since 2002).

So, I got an email that our new login would be uasf.  That’s right — the last two letters transposed.  And it wasn’t just a typo in the email; that was the actual login.  So I gently asked if that was intentional (maybe “uafs” was taken already by somebody?).  No, it was a typo in the setup and would be corrected  (and was, promptly).

I told the coordinator that I was glad, as I hadn’t been looking forward to telling the Chancellor we had to change the campus to “University of Arkansas – San Francisco”. >;-)

So we are now going to be (correctly) using uafs.iii.com for our URL.  Progress!

Our webmaster/database librarian is getting the word out to vendors on our new I.P. address, which many of them may just add as another option to our access.

The next big milestone at our end is probably going to be the migration to the hosted servers on July 7.  While that’s going on (about 2 hours, they figure), we’ll need to go around to all the staff workstations and append the IP address to the properties in the Millennium icon to redirect it.  Then we restart by connecting to the hosted server in Syracuse, and we should be back in business, still on release 2009B.  On the 9th, we upgrade to the 2011 release.


I mentioned that our campus I.T. people wanted us to upgrade somehow due to security.  It turns out that they’ve had a security outfit called Qualys scanning campus systems as part of this.

And we’ve been getting “all ports in use” ever more frequently.  This has been going on for months, but it seems to be stepping up this year.

Finally III managed to track down a group of I.P. addresses that seem to come from this company, which I then asked I.T. about.  Oh yeah, we have them scanning you for the security, I was told.  We just didn’t tell you before.

Well, that might explain at least some of the resources being tied up.  Since our system is not going to change before we finally leave it, I asked if we could get off the scan, as it seemed to be overloading us often.  That’s been done.  So far, no more “all ports in use” messages.

Once we can confidently say we’re on the hosted server and tested okay, we can shut down the old local libcat.uafs.edu server and take it and its outdated security off the campus network.  That solves I.T.s security standards problem.

Preparations for web pages

We have a campus home web page and related pages, on a campus server.  This links to our III server.  Those pages will need to be updated immediately after we migrate to the hosted server.  Our webmaster will be busy with those for a bit.

I’ve gone through the other web pages which are still on the old server.  Updating these is a little easier, as instead of libcat.uafs.edu/screens/whatever.html, I can reduce the link to /screens/whatever.html and the server will search for the page on itself, whether local or hosted.

So, making that change to most of the links leaves only a few pages to fix after the migration.  I have those marked on my printout so I can head straight for them ASAP.

Migration Day, July 7

So, it’s the big day to switch to the server in Syracuse.  I’m told it will take 2 to 3 hours, perhaps more.  We’ll end up with the same thing we have now, only running on a different server.

There’s a notice on the library home page that access to databases and the catalog will be down for several hours.  It’s the start of the Summer II semester, which is about as slow as it is likely to get during an actual semester.

While this is ongoing, I’ll be going around and changing the command line in everyone’s Millennium:

C:\Millennium\iiirunner.exe ip=our new IP address

By adding the IP address to the command line in Properties, we connect there without having to remove and reinstall Millennium everywhere.

That’s not all — we have to change the Export option in OCLC Connexion to the new IP address as well, for everyone that has that, which is a smaller group.

Once we’re back up, I have the last few web pages to update.

Following migration, July 8

Well, that could have gone a little smoother, frankly.  But we have Millennium up again.  However…

We took longer to get it done (we didn’t get the original time frame from an engineer, for one thing).  Also, the fact that we had a reference database (originally called a community information database) may have been overlooked by the other project people.  That was extra work for III.

The problem now is that the Web Access Manager is still not functioning.  If we delete the “0-” and “libcat.uafs.edu” from the URLs, we can reach databases on campus.  However, substituting “uafs.iii.com” in there still doesn’t work… yet.  That’s a project for the engineer to fix today, and then we’ll be beck.  (Sorry – “back” — my Terminator accent kicked in.)

This is apparently due to changing the domain completely to uafs.iii.com which actually means more work at this point, even though it leaves us less vulnerable to problems later.  Apparently most places just alias their old address to redirect over to the new one, whereas we wanted to go directly to it from everywhere.  That sames a micro-second on connecting and having to go through other computers to disguise the new address with a redirect, so technically it was the better way to handle it.  It’s more effort up front for the engineer, however.

While that means that changes elsewhere (say on campus servers) in the future won’t “forget” to include that alias kludge and have to be fixed if/when they occur, right now III is trying to get all the old libcat references changed over, and something connected to the proxy server (WAM) is not correct yet.

The engineer was working late last night and planned to come in early this morning (California time), so we’re hoping his dedication will pay off shortly.

We still have a software upgrade to 2011 Millennium scheduled for Thursday morning, so I’m hoping we get this all straightened out today.

Thursday July 9

The upgrade to version 2011 has been postponed to Friday.  III’s decision.

The engineer was scheduled to work on another library yesterday, so couldn’t clear everything up from the migration, but we did have the databases up again for the most part.  The new address needed to propagate through all the DNS servers for the various vendors, apparently.  Our serials librarian will be checking all that.  So, good for that.

Also, we had some odd glitches with the CSS, but that has been tracked down and resolved for the most part, so things display more or less properly now.

We still get a “server not responding” error when we try to log into our reference database.  That’s going to take a bit of tweaking by III, I suspect.

Yesterday I began the 856 URL change for ebooks, etc., in the catalog.  The WAM needs the libcat.uafs.edu changed to uafs.iii.com in all those links that have it go through the proxy server, so I’m doing those in 10,000 record chunks at a time.  I don’t bother to select or sort — I just look for that in the 856 and pull up another batch of records.  If somebody needs a specific one I haven’t done yet, I can nip in and fix it individually, but it’s pretty quiet right now, so I’m just plowing along.  I probably can’t do them all right away; the transactions file would fill up.  But I can do a good number of them daily.

We also have to go through our LibGuides and update any catalog links.  I got mine done pretty quickly.

We are having email problems with overdues, and courtesy notices — they don’t seem to be going out.  III is working on it.

July 10, Friday

III is still working on the overdues/courtesy notices email problem.  The hosted server cannot print directly to the printer that used to handle server stuff, but works fine when we select “local printer” and designate it.  (No, most of us don’t have attached printers, it’s a cost-effectiveness thing for campus I.T.) So we have that working, but all the notices print because they can’t send them via email.  Fixing that is now a priority.

We don’t have Web reports, either, but that’s a Java thing.  And thereby hangs another tale…

We have SCT Banner for the campus management system.  We must use Banner.  The catch is, SCT is behind on updating Banner for use with the latest version of Java.  Therefore everyone gets “outdated” notices on Java, and has to be blocked from updating themselves to a newer version of Java that won’t run Banner.  Follow so far?

Millennium also runs on Java, and we have to deal with I.T. on letting us run a separate Java for that regardless of the other Java on each workstation.  That’s a long-standing conflict here.  I’m not too concerned about that until we move to the 2011 Millennium, frankly, as I’d rather not deal with that all over again for a newer version.  It might resolve with the upgrade.

I’m waiting to find out if we have the 2011 upgrade delayed on account of the email issue or not.  Oh, it seems not.  III hopes the email problem may be resolved by the upgrade, so we’re going ahead, and a half-hour early at that, at 9:30 instead of 10.

Well the upgrade was quick.  But the email problem was not fixed, and we still cannot get to our reference database through Millennium.

I notice that Chrome does not load the Java for Web Management Reports but IE does.  Go figure.  As long as we can get to it somehow, I’ll settle for now.

Monday July 13

III kept working Friday after we went home here (thanks to time zone differences) and solved the email problem.  So hurrah for that.  The engineer is still working on the reference database, but that’s not quite as urgent.

III still shows Sierra Preview scheduled for tomorrow.  Whoa!  They did it early.

Next post will be “Sierra Preview“.



Followup on the new website

More on the website revision, in part to remind myself what I did and why, and perhaps something here will be of use to others.

So, I’ve been converting our Innovative Interfaces catalog pages on our libcat server to a format as close to the new library.uafortsmith.edu server pages as possible.

I’ve wanted all along to make the transition as seamless as possible — ideally (IMHO) most users won’t realize they’re moving back and forth from one server to another.

Due to the wiki template set up on the campus website (and therefore the old library pages), however, we elected not to do that and allowed variation on the catalog pages.  Now, with the new server, I’m striving for identical looks.

Little things crop up in the process, of course.

Date Script

JavaScript for date in the header is one I borrowed some years back for use in the catalog.  We are finally able to use it on the regular home page now that we are on a server that allows it.  I like it because it specifically states what today is (day of the week and date) and the hours today only.  There is also now a link to all our hours on a separate page.

When we’re closed, it says so for that day, but I wanted the ‘closed’ message to remind people that online services are still available: “Closed Today (Online Services Still Available)”.  The catch was, I had that message on one line replacing the ‘hours’ text for that day, and it’s a much longer piece of text.  It threw everything off in the header — kicked everything right off that over and some of it wrapped onto additional lines, which looked terrible.  So, I broke the text display for the ‘closed’ message into two lines and it works neatly now: “Closed Today<br />Online Services Still Available”.

III uses “tokens” which are shortcuts to scripts in their system that handle certain tasks.  These work somewhat like SSI (Server Side Includes).

For example, for much of the top header in catalog pages, I can use “toplogo” which calls up a separate HTML partial file to fill in a stock header.  Same for “botlogo” which fills in a stock footer section.  Very handy.

So, I linked the toplogo section in the catalog to run the same JavaScript for the date/hours info from the library server, so I only have to change it one place to update it (changes in hours, holidays, etc.).  Very handy.

Advanced Searching

The catch to the above is, the header in ‘toplogo’ included the same catalog search box that is on all the pages.  The Advanced Searching page in the catalog, however, is one page that uses not an HTML form, but a token which calls up a form, since it’s more complex (combines terms, searches several indexes, etc.).

That called form assumes it’s the only one on the page, which conflicts with the one in the stock header.  Normally, you avoid this by giving specific names to the forms and referring to those, but when using the token to call up the form, I didn’t have the option to change the token-called script.

Trying to use Advanced Search in the proper box resulted in the form trying to get information from the box in the header search box instead (since that was the first form encountered on the page), and then telling me I needed to enter something there.

Answer: I entered the toplogo completely in normal HTML on this one Advanced Search page, instead of calling it with the ‘toplogo’ token.  That way, I could comment out the search box in the header so only this page is without that search box in the header.  Now the only working search was the one called by the Advanced Search token script.  Conflict eliminated.

If I change the header, I’ll have to remember to change this page as well.  However, the date script still works as usual, so no extra concerns on that.


CSS (Cascading Style Sheets) are multiplying in the catalog.  III includes one of their own (untouchable since it operates some of their specialized functions), and we can override aspects of that and augment it with another, which we do. Now I added the one for the new style pages.

That meant that I had to make sure that adding the style sheet Joni created wouldn’t conflict with any names in the other style sheets.  Then I added that to the list of style sheets to check when a browser creates a page on the screen.

Then there was minor tweaking to get the CSS to work within our catalog server.  This included some little spacing things to allow for (as usual) Internet Explorer not working to the same standards as other browsers, but that worked out.

I commented a lot in the catalog version of the CSS file as to what I did to make it different from the version in the home version.  I may need to know all that some day.

Testing Browsers

I’m testing with Firefox 3.5 and Internet Explorer 7 and 8 (although 8 is not approved on our campus at this time as it won’t work properly with our version of some instructional software elsewhere on campus), as well as the current Windows version of Safari (since I don’t have a Mac to test) and current Google Chrome.

Progress is being made!

Zebra TLP2844 printer manual is up

The manual for our new Zebra TLP2844 thermal transfer printer is up.

We needed a one-up label printer for our serials, that could also print the routing list as part of the process.

The TLP2844 is a thermal transfer printer, which means that instead of using thermally -sensitive labels (which fade over a short time, we’ve found to our dismay), the TLP2844 uses a thermal process to tranfer ink from a ribbon to the plain label. This should last for years.

For books, you can get spine/pocket label combinations, and those can be printed with a more durable resin ribbon.

For the serials, however, I went a little cheaper and got paper labels, and printed on them with a wax ribbon directly from the Innovative Interfaces Millennium Serials module. The setup info for all that is on the manual page. These will work for in-house circulation until we bind the serial.

Unfortunately, MilSer does not recognize the particular size of label (3×2) we use from the Zebra, so I have to tell it that we’re using 4×4 labels instead of 3×2, and the spacing is a bit wonky after the serials label prints if we have a routing list. If there is no routing list, the next label comes out blank. Still, it does the job, quickly and neatly.  We stick on the serial label, and staple the routing list labels (still on the backing) and pull them off later after routing is completed.

We had been using a standard dot matrix printer (remember those?) but had a continuing problem with the label feed. I insisted they “waste” the first label, leaving it blank, and feed it through into the guide bar so the remaining labels would go through properly. Often somebody decided to “save” that label (and avoid the extra task of detaching it) by not feeding it into the guide bar, so when the printed label came out, it jammed in the guide bar.  Then they took the guide bar off the printer to avoid that, and so the labels kept jamming because they didn’t feed properly through the ribbon guide without the guide bar holding them flat against the platen.  On top of that, they had to feed out the printed label, and doing that by using the platen knob on the side stripped the gears (because people forgot to disengage the gears first) and made it even harder for labels to go through properly.

They needed a “black box” kind of printer that didn’t need any adjustments (or have removable parts).  The standard dot matrix printers were designed for batches, not one-at-a-time labels, but that increased the chance of mismatching labels to issues.

I’m hoping that the new customizing of III’s labels in Release 2007 (due out RSN: Real Soon Now) will allow me to print a barcode on the labels. We use a barcode for counting circulation of a serial within the library, but right now, with no barcode on the issues, we have to go to a rolodex full of cards with the barcodes for each serial title.

While I created a barcoded label using our Wasp Barcode Labeler software, which pulled the right title and barcode for it from an Excel file, it’s an extra step and shifting back and forth between softwares, and it was decided not to do it.

Wasp will let me do book labels (I got a roll of spine/pocket labels and tested), and once I see how the new Release 2007 (or the next version) allows me to customize, we might see about getting another Zebra for Tech Services. I’m also looking at the option to print book bands for ILL.

Another day, another icon

We have a few titles in the catalog that are both online databases and available in paper:  Value Line, the Arkansas Code, for examples.

I had a request to come up with a new icon to show in the search results that indicated the materials available, rather than one or the other.

The problem is, we’ve maxed out on material types.  These are in BCode2 and ICode2 in the III system, and since we use ICode2 for inventory and I try to keep these the same as much as possible, I had to hunt for something I could salvage.

Fortunately, we’ve eliminated filmstrips, so I reused that code “p” and made it “Database & Books” instead.

That still left me without a little graphic for the icon to show on the right.  So, I reworked and re-named the same picture from ebooks and made it work for this.

A keyword search on “value line” will show the results.

tabs in the catalog

Working on the catalog display in Innovative (III) today and making these notes to myself.

I originally used the May 2007 set downloaded from III, with some modifications I picked up at IUG, for the version I brought out in August 2007.

The campus standard HAD been to accomodate 800×600 displays, and I didn’t want people using those to go from the campus pages to the library pages and find themselves suddenly running off the side of the screen with the catalog.

Since we are now no longer restricted to the 800×600 display (with the wide margins left and right), I’m reconfiguring the pages for 98% width (just a 1% margin on each side — I think it looks neater and less crowded than 100% across the page) of the screen in 1025×768 resolution.

That leaves a lot of stuff sort of weighing down the left side. All the tabs, for example, start on the left, and don’t go very far across in many cases.

So, I decided I needed to change the width of the tabs to spread them out a bit. The catch is, the tabs normally on mainmenu.html, for example, are using the div class “mainActiveTab” with “menuActiveTab” and InactiveTab, and those have only one size.

However, the div class “helpActiveTab” has “helpActiveTabMedium” and “Large” and seem to work just as well, so I’m replacing “main/menu” with “help” div classes. (It’s easier than adding to the CSS for “main/menu”.)

Then I changed the size to all medium tabs. Spreads further across and balances the look better, IMHO.

I’ve also taken the frame with the Quick Links and moved it over to the far right 20% of the page, and reset the percentages to 80% search and 20% Quick Links frame, now that I have the additional room. More balanced, again.

Tests okay.