Tuesday, July 14, 2009

Aleph 19 Upgrade: The Final Week

On Tuesday, July 21 FCLA will upgrade our Aleph Library System from version 18 to version 19. Our system will be down from approximately 5:45AM to 10:00AM. The library OPAC will work but the patron empowerment features, like holds and renewals, will not. Here is how the upgrade process should proceed.

Some of you have been asked to to assist with the testing in preparation for this conversion and department heads of affected areas have been given a checklist to verify functionality using the test client. If you were given a checklist, please review the operations and let me know if you have any questions or concerns. I will be coming by this week to install the Aleph 19 Production client on your machines. It will not work until the new system is brought online Tuesday.

On Monday, July 20 I will install the new offline circulation module on to the circ desk. In the highly unlikely event that Aleph goes down Monday evening, circulation events should be recorded manually. Please insure that all student workers understand this or library transactions will be lost.

On Tuesday, July 21 all circulation should be handled through the Al500 Offline client until we are given the go ahead to switch over to production. Once that happens, I will share through a lib-all email. At that point I will be at the circ desk ensuring that the morning’s data is loaded properly. If you have any issues with the new client, please email me and I will do my best to find a solution as soon as possible. I am setting the circ desk and the OPAC as my first priorities.

I do not expect this process to be difficult or painful. FCLA has put a great deal of effort into preparing for this and we have been testing for quite some time as well.

Again, if you have any questions or concerns, please let me know as soon as possible.

Aleph 19 Offline Circ Client

In testing for the Aleph 19 upgrade, we made a couple of discoveries. First, the version 19 offline client is different and must be installed. I was hoping to use the v18 client but FCLA says no. Second, the path to the dat file created by the client is slightly different. Instead of going to T:\AL500\OFFCIRC\FILES\NFU50\OFFCIRC.DAT we need to go to T:\AL500\OFFCIRC\FILES\USM50\OFFCIRC.DAT Not much of a change but certainly enough to throw people off if they are not comfortable with the process.

Monday, July 13, 2009

Aleph to Banner Data Transmission

This week we met with UNF ITS and Finance to go over the progress of our Aleph to Banner export project. The news was very good. FCLA sent over the data from Aleph and ITS successfully imported it into our Banner Financial System. The process appears to match what I envisioned from the outset. When the data is imported into Banner, all of the fields will be filled an our business office will simply need to approve the transaction without entering much, if any, data.

Our next steps will require ITS to automate the ingestion of our index number. This number is the same 99% of the time so that will be part of the approval process for our business office. We will also have an "accuracy report" produced, again by ITS, to tell us what was entered into banner and what was left out. Finally, we decided to ask ITS to script the import process to run nightly which is, of course, much faster than our current manual process which is only done once a week.

We are going to retest the rejection process of PCARD transactions. The initial thought was to automatically reject any invoice without the proper n-number and ingest any invoice with an n-number but we must also reject invoices that contain the text PCARD even if it has a legitimate n-number. We will perform one more export to validate the process and then go live. Hopefully this will all be wrapped up before Fall.

Browser Functionality

Recently a couple of links were sent my way that my browser wouldn't render properly. This is particularly irritating to me. I believe a browser should work properly, quickly, and conveniently in that order. Unfortunately my browser of choice at the time (Flock) was not up to the challenge. Sure, it has a ton of cool features that I love but it is not particularly quick and seemed to be falling flat on the proper aspect as well. I decided to have a look by running it through the acid test or acid3test to be more precise.

The Acid tests are part of the Web Standards Project developed to discern a browser's support of html standards, particularly DOM and Javascript. By going to http://acid3.acidtests.org/ you can see how your browser rates. I did this with the Mac version of Flock and scored a 70. I didn't know how good or bad that was but I wasn't terribly encouraged so I ran a couple of others through the mill. Firefox, unsurprisingly did little better with a 72. I say unsurprisingly because Flock is built from Firefox. Next I tried Opera 9. It did much better with an 85. Finally I tried Safari and scored a perfect 100. Safari is very fast and apparently supports html standards very well. It does fall short on a few of the features that I have grown accustomed to, though so I decided to see if I could fix that. I found keywurl which restores my keyword search functionality I grew to love in Flock and Firefox. Other plug-ins allowed me to try to replicate Firefox's "Awesome Bar". Oddly, the next time I hit the acid3 site, my score had dropped to 99. After uninstalling the other plug-ins (keywurl did not have an impact), I made it back to 100. This might explain the disparity between Flock and Firefox given that Flock uses the same engine but is a very heavily "plugged-in" version of Firefox.

So I guess the lesson here is that you can't have it all. Speed, compatibility, and functionality are truly warring with each other and it looks like you are going to have to take your pick. Oh and in case you were wondering. Internet Explorer 7 on Windows scored a 5 on the Acid3 Test. No, not 50 but FIVE! IE8 reportedly is much better with a score of 20. That is particularly disappointing considering all of the things Internet Explorer can't do and it isn't even very fast.

Wednesday, July 1, 2009

Aleph Version 19 and Receipt Printers

On July 21, 2009 UNF is scheduled to undergo the upgrade from Aleph 18 to Aleph 19. As part of our preparation for that event, we are looking at how v19 handles receipt printing. UNF already has receipt printing configured and if your school doesn't I highly recommend it. Contact Ellen Bishop at FCLA for help with this one. She and Robb Waltner (then Head of Access Services) put together the templates which are now part of our client package and carry over from version to version.
What does not carry over are the settings which I would like to share in case anyone else needs to do this. I must say in advance that I had intended to do this myself this week but Robb (now Head of Acquisitions) beat me to it). Once you have v.19 Test installed and your receipt printer set as your default printer you must implement the following steps:
1. Set the receipt printer to be the default system printer.
2. Edit the circ\TAB\print.ini to P for loan and return receipt.
3. Run htmlprint.exe (in alephcom\bin) and set the margins to 3,2,3,2. Note: This is different from v18.
4. Edit alephcom\TAB\alephcom.ini to NewPrintType=Y
5. In the Circ client under Aleph - Options - set up loan options select "all loans in one receipt".
6. In the Circ client under Aleph - Options - set up return options select "print return receipt"
7. Edit alephcom\TAB\alephcom.ini to defaultPrintConfig=0 in order to bypass the print preview.

That should get the receipt printers humming. Again thanks to Robb for doing the labor on this one.