Common Issues That Are Encountered In Circulation And Ways To Respond,
Address and Resolve Them --- Ping Fu, Systems Librarian, ILTS, 6/4/2008
1. How is a book’s loan period determined?
The system takes the patron and item information and applies the
appropriate Circulation Matrix to determine the loan information in
SYSADMIN.
Item information includes Item Shelving Location and Item Type.
Item Shelving Location is where materials are stored in the library,
such as stacks, reference, off-site storage, rare books room, and so
forth. There are permanent shelving location and temporary shelving
location.
An item is a piece of library material that may be borrowed or used by
a patron. Each item must have an item type. Item types define the kinds
of materials owned by a library. For example, an item type could be a
CD-ROM, book, or map.
For example, the loan period is 181 days defined for the Patron Group
“staff” and Item Type “circ” applied for the Circulation Policy Group
“SML Circ Group” in Circulation Matrix. No matter where the book is
being charged – courtesy charge or not – that it is the items shelving
location that starts the circ process.
A patron’s ability to charge and request items depends on the patron
group to which the patron belongs and the type of item the patron wants
to charge or request. Rules are set up in a Circulation Policy Group
and an associated Circulation Policy Matrix to govern circulation
transactions. A Circulation Policy Group is a set of locations and
circulation policies. These locations include both the circulation
desks (happening locations) and the shelving locations. The policies
defined in a Circulation Policy Group are in effect for all patrons who
are members of the patron groups within that Circulation Policy Group
regardless of the item involved in the circulation transaction. Many of
these policies involve the block points for patrons, such as the
maximum number of items a patron can borrow.
Additionally, each Circulation Policy Group has a Circulation Policy
Matrix. A Circulation Policy Matrix connects a patron group-item type
combination to a set of policies. The policies in the Circulation
Policy Matrix provide the rules for circulation transactions between
specific patron groups and specific item types, such as the length of
the loan period for a CD-ROM charged to a staff member.
An item has two important characteristics that relate to circulation,
its location and its item type. The location, where the item is shelved,
connects the item to its Circulation Policy Group through the locations
that are defined as part of that group.
The following screen shot shows how these shelving locations sml* are
assigned to one Circ Policy Definition Sterling Circ Group.
The following screen shot shows how these patron groups are selected to
one Circ Policy Definition Sterling Circ Group.
The following screen shot shows how these patron groups – item types
combinations are connected in Sterling Circ Group Matrix.
The following screen shot shows how Voyager defines loan period
according to the patron group (Staff) – item type (circ) combinations
in Sterling Circ Group Matrix.
That is, an item belongs to a Circulation Policy Group if it is shelved
in one of the locations included in the Circulation Policy Group. The
item type, such as a book or CD-ROM, is one part of a Circulation
Policy Matrix that is associated with a Circulation Policy Group. The
Circulation Policy Matrix contains specific patron group-item type
combinations and provides the rules which govern transactions. The key
to circulation in Voyager is to bear in mind that the item location
essentially governs the transaction.
Additionally, each Circulation Desk also belongs to a Circulation
Policy Group. It is possible for the item used in a circulation
transaction to belong to a different Circulation Policy Group than the
Circulation Desk where the transaction is taking place. In this case
the transaction is an 'exception' transaction and will require an
operator override that that is treated as courtesy Charge. The policies
for this transaction will still come from the Circulation Policy Group
to which the item belongs. There are any bookings made for that item.
A
•
•
•
•
Circulation Calendar defines the following.
A circulation desk’s regular open and closed hours.
A circulation desk’s exceptions to the regular schedule.
Fixed due dates and times (YUL does not use).
End of term date and lead days (YUL does not use).
Loan periods and policies vary among libraries and item types (of
materials), so it is important to check due dates.
2. How is recall date calculated?
Minimum Loan Period of Recalled Items: The minimum length of time that
the patron may keep an item that has been recalled. This period is used
when recalculating the due date for a recalled item. If Loan Period is
in days, this period defaults to days. If Loan Period is in hours or
minutes, this period defaults to hours or minutes. If Loan Period is
indef or term, this period defaults to days.
If 0, the system assumes the recalled item is due back immediately and
the due date is based on the recall return interval.
In our case, Minimum Loan Period of Recalled Items is 4 days.
Recall Return Interval: The number of days, hours, or minutes added to
the Minimum Loan Period for Recalled Items, in order to give the
institution time to print and send the appropriate notices, as well as
give the patron sufficient time to return the recalled item before it
is considered overdue. This defaults to the same value (days, hours,
minutes) as the minimum loan period for recalled items.
In our case, Recall Return Interval is 10 days.
How is the recall period calculated in Voyager? Voyager now adds the
Min Loan Period for Recall Items (in our case 4 days) with the Recall
Return Interval (10 days) to calculate the due date for a recalled item
(14 days), which means books that have already been out for more than 4
days are given a recall due date 10 days from the date the recall was
placed; books that have been out less than 4 days are given a recall
due date 14 days from the day of check-out.
3. What does Patron Loader do?
The Patron Load is a process which creates three patron .sif files for
subsequent load into Voyager through Voyager's patron load program. It
consists of a Visual Basic application called PatronLoadv32.exe, an MSAccess database called PatronLoadVoyager.mdb and an initialization file.
The application consists of a series of subprocesses to connect to the
DataWarehouse for primarily employee data, Banner for primarily student
data, download and manipulate this data, and create the output sif
files.
The Access database consists of a number of ODBC-links pointing to
views in the DataWarehouse and Banner, queries to extract the data from
these views, and local tables to hold this extracted data.
When a semester starts, we will run the patron update, we first need to
update the patronload.ini file to change term codes and such. Before
the fall semester starts, we also need to run Global Patron Expiration,
and this will require getting the last spring patron .sifs somebody
would have run in mid May of this year.
Example of PatronLoad.ini for Academic yr 2007-08, Spring term:
Patron Load Ini File
Staff Expiration Date:07/01/2011
Staff Purge Date:01/01/2012
Faculty Expiration Date:07/01/2011
Faculty Purge Date:01/01/2012
Grad Expiration Date:01/01/2011
Grad Purge Date:07/01/2011
UGSenior Expiration Date:05/30/2008
UGSenior Purge Date:07/01/2011
UG Expiration Date:01/01/2010
UG Purge Date:07/01/2011
Bursar Patron Group Code:BURSAR
Address Start Date:07/01/2003
Address End Date:01/01/2010
Effective Term Code:200801
PatronLoad.ini:
If creating Student SIF: Watch term dates in PatronLoad.ini!
Spring = 200801;
Summer = 200802;
Fall = 200803.
As of Aug 19, 2008 scheduled extract/load, change PatronLoad.ini stanza
for “Effective Term Code:” to Fall term (200803) This will activate
students registered for Fall 2008 term and beyond. Follow the schedule
below for changing term codes:
Aug 19, 2008 = 200803
Jan 06, 2009 = 200901 (may want to do this in Dec before Xmas
recess rather than wait until Jan)
May xx, 2009 = 200902
etc.
There is no firm schedule for updating Expiration dates, Purge Dates
and Address dates. Please consult with Cindy Greenspun before defining
such a schedule. Generally the Expiration, Purge and Address dates
should remain consistent throughout the academic year. However, they
can be modified as requested.
We run patron load every two weeks. For example, when a patron status
changes and the ID center issues a new card for the patron, due to the
two-week time gap, the updated patron information has not been loaded into
the voyager database yet when the patron wants to loan a book with his/her
new card. Last year, we did receive a few problem reports from our circ
desks that the barcodes on card for some patrons are different from those
in voyager.
4. The Voyager.ini file
The voyager.ini file is an initialization file that contains important
connection information, which enables your Voyager clients to access
the server.
During the installation process, this file is placed in the directory
into which the clients are installed (typically the c:\Voyager
directory).
Since the voyager.ini file is overwritten each time the
VoyagerInstall.exe is executed, it must be edited to include the
appropriate connection information and stanzas needed for the specific
computer.
The voyager.ini file contains the following stanzas: [GlobalLog],
[Email], [SearchURI], [MARC POSTing] and a stanza for each client
module.
An example of a voyager.ini file shows as below:
[Cataloging]
Server=prodorbis.library.yale.edu
Port=7010
Timeout=2000
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[Acquisitions]
Server=prodorbis.library.yale.edu
Port=7020
Timeout=2000
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[Circulation]
Server=prodorbis.library.yale.edu
Port=7030
Timeout=2000
ChargeTimeout=
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[SysAdmin]
Server=prodorbis.library.yale.edu
Port=7050
Timeout=2000
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[CallSlip]
Server=prodorbis.library.yale.edu
Port=7080
Timeout=2000
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[MediaScheduling]
Server=prodorbis.library.yale.edu
Port=7085
Timeout=2000
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
[MARC Posting]
Orbis OPAC="http://orbstaff.library.yale.edu/cgi-bin/Pbibredirect.cgi"
[GlobalLog]
SingleLogin=N
Encrypt=Y
ServerSortList=Y
ASCIISortList=Y
ASCIISortColumn=Y
The module stanzas set up the client/server connections for each module.
For [Circulation] module stanza,
[Circulation]
Server=prodorbis.library.yale.edu
Port=7030
Timeout=2000
ChargeTimeout=
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
Server=value
This parameter contains the IP address of the Voyager server. In our
case, we use the domain name of the production server
prodorbis.library.yale.edu in stead of the IP address. If you want to
change the server from the Production to the Test (TOrbis), replace the
domain name of the production server prodorbis.library.yale.edu with
the domain name of the test server Torbis.library.yale.edu
Port=value
This parameter corresponds to each module's designated port, as defined
by the /etc/services file on the Voyager server. In our case, port
number is defined as in each module stanzas. In our case, the port
number is 7030.
Timeout=value
This parameter specifies the number of seconds that are allowed to
elapse while attempting to connect the client to the Voyager server. In
our case, the default is 2000 seconds.
ChargeTimeout= value
The parameter defines the charge timeout value for the [Circulation]
stanza only. The default is 60 seconds. In our case, we use the default
value.
NewVersion= value
This parameter specifies the URL that allows you to link to a download
site for Voyager clients. In our case,
NewVersion=http://www.library.yale.edu/wsg/docs/voyager/alternatelocati
on.html
5. Circulation Charge Timeout
When charging items in Voyager’s Circulation module, the system is
configured such that the Charge workspace closes automatically. This
occurs if, after entering the charging patron’s information, a set
amount of time passes with no activity occurring in the Charge
workspace. This set amount of time is the charge time-out value.
The ChargeTimeout= key is in the [Circulation] stanza of the
voyager.ini file. The default charge time-out value is 60 seconds.
6. Other Time out problem
PST has received the question about a time-out problem with the Voyager
clients, specifically Circulation and Cataloging seeming to time-out
from inactivity. The Cause of the problem is undetermined. Maybe the
problem is intermittent. If you experience the problem constantly,
please let PST know.
There are currently three production regions, or copies of the directory
structure, in use: orbis, orbstaff, and orbexpress. The main difference
between the three (as far as the public is concerned) is the timeout
value. The fourth backup production region, orb24hour, is only used when
the other production regions are down.
orbis (yaledb) - 20 minute time out
orbstaff (orbstaffdb) - 1 hour time out orbexpress (expressdb) - 2
minute time out orb24hour (24hourdb) - used when production Orbis is
down for backup
7. Run time errors
Some staff have been experiencing an extraordinarily high number of
‘Run-time Automation Error: 440/65099’ issues during normal Circulation
tasks-- e.g., scanning barcodes during charge and discharge activities.
An example scenario when scanning a patron's barcode into the Circ
module: ‘Run Time Error 440 Automation Error’ you are forced to click
‘OK’. After clicking ‘OK’ the next error message appears: ‘-Run Time
error 91 Object variable or with Block variable not set-‘ and after
clicking ‘OK’ the Circulation module quits.
The cause of the problem is undetermined. One explanation from
Voyager-L list is that this is a problem with the Voyager Circ module
in how it interacts with your firewall. It's not the server, it's a
software setting in your firewall appliance. The firewall monitors
connections between the circ client and the Voyager server. If the
client sits idle for a while the firewall drops the connection,
resulting in the 65099 runtime error.
However, the firewall usually functions correctly. The Voyager circ
client does not send out a periodic "keep alive" signal to the server
saying that it is still a valid connection.
It's not just the circ client that does this, the Acq and cataloging
clients are subject to this timeout error as well. This is a well known
problem that Endeavor had acknowledged but Endeavor/Ex Libris has
declined to fix.
Run-time errors are notoriously hard to troubleshoot, as we often have
little to no info on what could have triggered the error.
A best practice when dealing with a run-time error is to first re-start
Voyager. If the problem persists, restart your machine. If the problem
still persists, contact PST again and we will look into it further.
Other Run-time error
Problem description:
Run-time error '6': Overflow
I clicked out of voyager 3 times and signed back in to try checking out
the following book: Topology 39002082222101. I am not able to check out
the book. Also, I tried at our Circulation desk and received the same
message.
Solution: When I canceled the HOLD on this book, 39002082222101, I was
able to check out the book.
8. Call Slip Issues
There are 4 types of problems occurred in Orbis in terms of call slip
issues.
Type 1 problem is not a real problem.
Here is a sample problem description: Mudd circulation gets call slips
for non-circulating items in the Government Documents collection. I am
curious why those call slips even come through when the item status is
non-circ. I would think Voyager would somehow block them - but no?
When we check the Circ Policy matrix in Voyager we will find Voyager
does allow Mudd circ group patron to charge, recall, hold, and call
slip for nocirc item. The possible reason is we get things sent to
other library such as KSL for use there and perhaps that is part of why
this is available to the Mudd circ group, and perhaps this also allows
for some tech services types of exchanges.
Type 2 problem is caused by human errors and/or barcode readers.
Here is a sample problem description: last week that 26 out of 106
titles on the Missing in Transit report (titles routed from Kline to a
variety of locations) have bad barcodes. Upon further investigation I
discovered that for the first few of the records I checked each had two
item records attached to the same MFHD. Of these two item records one
had a migration creation date and the other had a more recent create
date within the past few months. The more recent item record's barcode
was the "bad" barcode. Bad barcodes in this instance are short digits,
some are missing the initial 3, some are missing other random digits
within the barcode and some are just partial barcodes (i.e. the last
four digits of the actual barcode). In all cases the barcode number on
the second item record is obviously based on the "real" barcode number.
Further investigation leads me to believe that these item records with
bad barcodes are somehow being created, either by user error or by a
bug, in the Callslip Daemon. I wish that the item table actually
recorded in which module the item was created instead of just the
location in which it was created. Despite that I am 100% certain that
these items are NOT being created in the Cataloging or Acquisitions
modules, nor is it likely that they are being created in the Circ
module.
I believe that the problem is a multifaceted problem with the Callslip
Daemon. It seems that rather often the barcode is not completely
scanned in the Callslip Daemon
I theorize that the problem may involve the barcode being incompletely
scanned in the Callslip Daemon and then a pop-up asks if the incomplete
barcode should be used to create a new item record. The staff say that
they do not choose to create a new item from this point in the Callslip
Daemon, however it appears that this is sometimes happening.
Type 3 problem relates to running time gap of the circ reports.
A sample problem describes as below: I am trying to delete the second
barcodes that were created by the call slip daemon/barcode scanner
problem. On at least two of these I was unable to delete the barcode
that was created in error. I got the following message:
"Item has exception logged run the exception report to clear this
condition"
The bib record numbers are: 7472396 w/error barcode: 3900201293782
7473183 w/error barcode: 9002012168986
There are exception reports run every day via Reporter and posted to
the Library Upload and Review site. You have to be patient to wait
until the exception reports running finished.
This circulation batch job clears the exceptions table of patron and
item links and removes blocks on deletion of patrons and items.
This circulation batch job produces three reports: item related
exceptions, patron related exceptions, and transaction related
exceptions.
The item related exceptions report includes the location, exception
description (lost item discharged or in process item charged are
examples of descriptions), title, item ID, exception date, and operator
ID.
The patron related exceptions report includes the location, exception
description (fine limit override or lost limit override are examples of
descriptions), patron name, patron barcode, exception date, and
operator ID.
The transaction related exceptions report includes the location,
exception description (circulation review is an example of a
description), patron name, patron barcode, title, item ID, exception
date, and operator ID.
Type 4 problem is regarding Call Slip Daemon installation.
A sample problem description: two staff members who use this
workstation do not have this problem. Others who use it do. The
problem is: When trying to print a call slip a window pops up with a
save as screen. It lists folders "my ebooks, my music, my pictures"
give a file name to save as "Voyager Call Slip Daemon.mdi" When this
screen is cancelled, staff are thrown out of the call slip daemon and
get a run time error 482, printer error. Voyager also did not ask staff
to sign in to a happening location either, and should because there is
not other active Voyager module open that is signed in to, i.e. staff
log in to call slip module first rather than circ.
Runtime error 482 is printer error. This problem occurs if the
workstation does not have a printer defined (or set up). When either a
network or local printer is defined, the problem does not occur.
Try one of the following to solve the problem:
* If possible, define a printer for the workstation
* If a printer is not available or you do not want the workstation
to have access to a printer, add a printer. Use the Generic/Generic
Text Printer option and decline the test page option. You may have to
insert a Windows CD to update driver files. This must be done at each
affected workstation.
It also explains why you don't get an opportunity to select a happening
location when you first sign on to call slip.
When you launch Voyager Call Slip Dæmon, a log-in window displays. Use
the following to log into Voyager Call Slip Dæmon.
1.
Enter your Operator ID and Password
2.
Click OK.
3.
(Optional) Select the Call Slip Group, and click OK.
Result: The first time staff log in to Voyager Call Slip Dæmon the Call
Slip Group needs to be selected. This selection is then permanently
stored in the callslip.ini file in the LocationCode field under the
[General] stanza thus eliminating the need to repeat this step. The
location information is stored the callslip.ini file in the
LocationCode field under the [General] stanza.
for example,
[General]
LocationCode=SML
NewItem=<Create New Item
AddBarcode=<Add Barcode to Item
[Preferences]
Upon installation, the Voyager Call Slip Dæmon initialization file is
located in the .../Voyager/misc directory. Your library may have
customized the name of the main directory under which Voyager resides.
•[General]
•[Preferences]
•[Print Options]
•[Routing Slip Print Template]
•[Call Slip Print Template]
•[Email Options]
•[Email Template Filled]
•[Email Template UnFilled]
•[Email Template UB Filled]
•[Email Template UB UnFilled]
9. Pseudo patron
A Sample problem description:
A(ny) circulating book in Math Circ gets charged to the Math opac
message pseudo patron DPT0001129 at the Math desk, for binding. System
responds that item is non circulating and requests override and date.
That same circulating book gets charged to a "live" patron, and it
treats it as a circulating item giving a two month loan, no overriding.
Solution: this is caused by that the pseudo patron DPT0001129 belonging
to the OPAC Message Flag patron group is not “checked” in the Math
matrix. That means, the OPAC Message Flag patron group is not
associated with the Math Circ Group. In order to solve th eproblem, PST
should copy the circ item types and settings of SML circ group to Math
Library. Three item types: circ, jourcirc, and lsfc will be added to
this patron group OPAC Message Flag in Math Circ Group matrix. The
settings and intervals were copied from the same patron group from SML
Circ Group matrix. The reconfiguration in SYSADMIN should solve the
problem.
10. Workstation and network errors vs. Orbis client/server errors
When Voyager appears to be down, there are two possibilities.
One possibility is Voyager is not technically down. We are just
having network problems. This may make it difficult to connect to
and navigate in Voyager. Data Network Operations (central ITS)
will be working to resolve this issue.
When Staff didn't shut machine down in the evening, she would
encounter the run time error of 65099 'Connection lost,
application will be aborted'. When trying to close that window,
another run time error occured: runtime error '-2147418105
(80010007)' application defined or object defined error. That’s
because the production server does in fact shut down every night,
briefly, in order to restart and refresh. This is what that
"Connection lost" message she got means. The problem will be
solved after shuting down the machine and re-starting it.
The other possibility is Voyager is technically down. ITS
monitors and ITS’ attempts to connect can confirm that there is a
problem with Voyager servers. It could be a power drop (or
perhaps surge) or other unexpected eroors which will cause
interruptions to Voyager production servers, sometime, both
Magyar and Columbus. When Columbus is also affected, ITS will be
not able to put the 24-hour OPAC in place during the Orbis
outage.