Knowlegebase

SUMMARY

ILLiad-L is a listserv for users of ILLiad, and for others interested in automating ILL and document delivery functions in a paper-free environment.

ILLiad is now being used in libraries from coast-to-coast. This listserv provides a forum for discussing ILLiad procedures and optimizing services. ILLiad-L's purpose is to help to improve automated ILL services and refine management methods in a paper-free interlibrary loan/document delivery environment.

ILLiad-L is an open, un-moderated, listserv discussion group provided as a service of the Interlibrary Loan Department in the University Libraries at Virginia Tech (VPI).

SUBSCRIBING TO ILLIAD-L

(All commands and text are case insensitive. Upper case is used below only for clarity.)

You can subscribe to ILLiad-L by sending e-mail to

LISTSERV@LISTSERV.VT.EDU

Leave the subject line blank.

In the body of the message enter the following text

SUBSCRIBE ILLIAD-L YourFirstName YourLastName

Listserv will send you a message asking that you confirm your subscription request.

Once you confirm your request, listserv will send you a message acknowledging your successful subscription, and a message summarizing some basic listserv commands and functions. In addition, ILLiad-L will send you a welcome message that includes basic listserv commands.

ILLIAD-L ARCHIVE

(All commands and text are case insensitive. Upper case is used below only for clarity.)

The ILLiad-L archive is available for reading and searching on the web at http://listserv.vt.edu/archives/illiad-l.html.

The archive can also be searched by standard listserv search commands sent by e-mail to listserv@listserv.vt.edu. Some of the most useful commands are outlined below:

To see a list of all the archive files, send the following command:

INDEX ILLiad-L

To see a list of all messages containing particular keywords, send the following command:

SEARCH ILLiad_L keyword1 keyword2

To see a list of all listserv commands, send the following command:

INFO refcard

Admin Tools

SYMPTOMS

• When selecting to delete Document Delivery requests, Lending requests are deleted erroneously.

CAUSE

This is a known issue in the version 6.5 Database Manager.

RESOLUTION

A newer version of the Database Manager will be released to correct the problem.

Authentication

SUMMARY

In some cases, libraries may want to import users to the ILLiad database rather than have customers register and create accounts themselves. In order to do this, however, you will need to choose usernames and passwords for your users. The username can be any string under 20 characters. The password can be any length, but is stored in the ILLiad database using MD5 one-way encryption. To create those passwords ahead of time for users, you will need to convert the password from plain text to an encrypted value.

Using the text "ill" as an example, the ILLiad version of that password would first be converted using standard MD5 encryption to the hexadecimal value:

2F9C691594932556EF427450338A74B7

The hexadecimal value would then be converted to a decimal value, two characters at a time:

47156105211481473786239661168051138116183

where 2F converts to 47, 9C converts to 156, 69 converts to 105, etc. You may use any tools you choose to create these passwords on your own and load them pre-encrypted. If you do not have that option, however, you can use the following tool to convert the password after loading it to the Users (or UsersALL for Shared Server installations) table.

WARNINGS

The following tool is for advanced users who have an understanding of how to load data to a SQL database. This program can be run on a schedule or manually but will affect every user in the Users table regardless of NVTGC. Please test this thoroughly before using in production.

Note: See the SQL Help files on DTS Import/Export Wizards or Creating a DTS Package for further information on how to import data.

USING THE MD5USERPASS.EXE TOOL

To run the MD5 ILLiad User Password Tool, you must run it on a machine that has a BDE Administrator and SQL connectivity to the SQL Server. This may be your web server or your SQL Server if they are separate. It would most likely be scheduled to run immediately after the import of users from an outside source to the database. The MD5 ILLiad User Password Tool does the following:

• Queries the ILLiad database's Users table for any records where Special = 'PTP' (for plain text password).
• Updates those user records so that the password is the MD5, numeric version of the original text.
• Changes the Special field from 'PTP' to NULL (the default blank value).

This means when you load the user information that has a plain text password, you would also need to set the Special field to 'PTP' for the tool to find it and convert the password.

COMMAND LINE PARAMETERS

You can run the executable from any folder on the machine and it can be scheduled via Windows Scheduled Tasks. There are two command line parameters that can be added to the program when it runs:

AUTO
This allows the program to run with no user input. It will run, convert the passwords and close on its own. (i.e. c:\illiad\admin\MD5UserPass.exe AUTO)

HIDEGUI
This can be added as well so that when the program runs automatically, it will run minimized. (i.e. c:\illiad\admin\MD5UserPass.exe AUTO HIDEGUI)

DOWNLOAD

The following link is a zipped file of the MD5UserPass.exe.

MD5 ILLiad User Password Tool

SUMMARY

In order to authenticate using PatronAPI, there are several keys that need to be set in the Customization Manager under Web Interface .. Innopac. The keys are described below.

EXAMPLES

InnopacPatronAPIAddress: This the the location of the PatronAPI server. Normally, the key also has a port after it of 4500. An example value would be http://123.123.123.123:4500 - where 123.123.123.123 is the PatronAPI server at your site. Also, the ILLiad server needs to have access to query the PatronAPI server. Most PatronAPI servers restrict access by ip address.

InnopacPatronAPIExclusive: This key should be set to Noif customers not in the PatronAPI server should still be allowed to register and Yes to only allow customers who pass the PatronAPI authentication to register with ILLiad.

InnopacPatronAPIExpireDate: Set this key to Yes to have ILLiad check if a customer is expired before allowing registration.

InnopacPatronAPIField: This is the field that ILLiad sends to the PatronAPI server for authentication. Currently the only two values allowed for this field are SSN or Number.

InnopacPatronAPIFineBlock: Set this key to Yes to have ILLiad check if a customer has exceeded his or her fine limit beforing allowing registration. If this is set to Yes, there needs to be a key for every Patron Code allowed to use ILLiad. There are some examples in a default installation of 0, 1, 2, etc. But for each code, there needs to be the value for number of dollars before customers can no longer register or use ILLiad.

InnopacPatronAPISupport: Set this key to Yes to turn on PatronAPI authentication.

TESTING CONNECTIVITY WITH YOUR PATRONAPI SERVER

To test connectivity with your PatronAPI server using an internet browser, open the browser and go to the following URL:

http://<YourPatronAPIServer>:<YourPatronAPIPort>/PATRONAPI/<UserNumberBeingUsedForVerification>/dump

An example would look something like this:

http://123.123.123.123:4500/PATRONAPI/123456789/dump

This will tell you if the necessary connectivity exists.

If you receive a message like the following, you do not have access from the machine from which you tried to connect.

403 Forbidden
No access permitted from 123.123.123.123

If you receive a message like the following, you have the appropriate level of access.

REC INFO[p!]=p
EXP DATE[p43]= - -
PCODE1[p44]=
PCODE2[p45]=
PCODE3[p46]=0
P TYPE[p47]=3
TOT CHKOUT[p48]=102
TOT RENWAL[p49]=103
CUR CHKOUT[p50]=2
HOME LIBR[p53]=none
PMESSAGE[p54]=
MBLOCK[p56]=-
REC TYPE[p80]=p
RECORD #[p81]=1062432
REC LENG[p82]=335
CREATED[p83]=06-17-94
UPDATED[p84]=08-20-04
REVISIONS[p85]=242
AGENCY[p86]=1
CL RTRND[p95]=0
MONEY OWED[p96]=$0.00
BLK UNTIL[p101]= - -
CUR ITEMA[p102]=0
CUR ITEMB[p103]=0
PIUSE[p104]=0
OD PENALTY[p105]=0
CIRCACTIVE[p163]=08-20-04
PATRN NAME[pn]=LASTNAME, FIRSTNAME MI
ADDRESS[pa]=LIBRARY ASSOCIATE$Library Admin$Library$
ADDRESS2[ph]=123 Library Rd$Librarytown VA 12345
TELEPHONE[pt]=1234567
TELEPHONE2[pp]=1234567
UNIV ID/SS#[pu]=123456789
P BARCODE[pb]=12345678912345
EMAIL ADDR[pz]=emailaddress@atlas-sys.com
PTYPE2[pd]=STAFF
LINK REC[p^]=i

SUMMARY

There are 5 different types of authentication available to ILLiad users with a default install:

Basic ILLiad Authentication is the default option. This version allows the user to select a username and password and register with the system. They are placed in a queue for the staff user to review, who can then allow access, or disavow the user, automatically cancelling all of their requests.

LDAP Authentication is another type of authentication available to ILLiad users. If you have an LDAP server with an authoritative database of users, you can point ILLiad to it for authenticating users as they log in. This is a live link and is used at each logon.

Importing an Authentication Database is another available option. From an OPAC or similar system, you can download patron information into a file format that is compatible with SQL Server, then import those entries into the ImportValidation table in ILLiad. Users are checked against this list when they register (using the model in the Basic ILLiad Authentication above) and if they are in the list, skip the staff review queue. If they are not in the list, they are still allowed to register, but then must be reviewed. You can import block information as well.

Implementing a User Gateway using an Authentication Database is another option. This way works similarily to the Importing an Authentication Database, but will not allow access to patrons not in the Authentication Database.

III's PatronAPI is an option for Innopac sites who have purchased this module from III. A user will register with ILLiad, giving the system in one of the registration fields their "patron number". This matches to a number within the Innopac system and is used for validating the registration as well as for subsequent logons to the system. This can be set to be exclusive (allow only people within this database access) or non-exclusive. Fines, blocks, and expirations are all carried over to ILLiad as well.

MORE INFORMATION

For more information on each of the authentication options, choose a related article from the panel on the right.

SUMMARY

ILLiad has a built-in authentication system that will allow you to clear customers as they register with the system. Here is a scenario using this authentication scheme:

For the User

• A first time user would get to the ILLiad logon screen and click the First Time Users link.
• User will fill out the New User Registration form (NewUserRegistration.html) and submit it.
• User can then start immediately submitting requests.
  

For the Staff

• Several times a day, the staff user would select the Clear New Customers option from the Pre Processing menu in ILLiad. This will show a list of all newly registered users.
• After reviewing each one, they can click the Clear, Disavow, or Merge buttons. Each will send the user a note regarding their current ILLiad status. Disavow cancels all of their requests. Merge will allow you to merge two accounts together.

This is how ILLiad is configured to work upon completion of the installation. No changes are needed to the system to configure it for Basic ILLiad Authentication. All User information is stored in the ILLiad system.

MORE INFORMATION

For a discussion of the available authentication types ILLiad supports, review the related articles in the panel on the right.

SUMMARY

The ExpirationDate field in the Users table can record a date X number of days after the initial date a customer registers with ILLiad (if registering through web pages). That date can be set using the UserExpiration keys found under Borrowing .. Customer Clearance in the Customization Manager. The keys can be set for each Status in the Users table (if your status is not in the table you can add it to the Customization table under System .. General).

The expiration date does not restrict customers from logging into ILLiad or access the web. It only serves as a date to run custom queries against (using Access or some other table link) to find users who have registered within a certain time period. Any blocking or restricting of access would have to be done manually through the ILLiad Client.

SUMMARY

LDAP Authentication can be used in place of the Basic ILLiad Authentication. Here is a
scenario using LDAP for authentication.

For the User

• A first time user would get to the ILLiad logon screen and put in their LDAP UID for the ILLiad username and LDAP Password in place of the ILLiad password.
• ILLiad checks the LDAP server, using the supplied information. If it can successfully bind using the userid and password, then it goes to the next step. If not, it immediately returns a message to the user stating "Bad Username or Password".
• When the username and password are good, next ILLiad looks in its local Users table to see if they have registered before. If yes, then they are automatically routed to the Main Menu. If not, then they are taken to the New User Registration page where they can fill out the registration information. All of their information is stored in the ILLiad Users table. The LDAP server is used for authentication purposes only.
  

For the Staff

• Since the LDAP server is used for authentication purposes, the staff do not need to review any customers as they register.
  

Setup

Setting up LDAP authentication involves updating several keys in the customization table. Here is a list of the keys and what their purpose is.

LDAPSupport - Yes or No to turn LDAP on or off.
LDAPServerName - LDAP Server name or IP address.
LDAPPortNo - port for your LDAP server (389 is default regular LDAP and 636 is default for SSL)
LDAPSearchPrefix,LDAPSearchSuffix - strings around which the ILLiad username is placed in order to bind with the LDAP server.

MORE INFORMATION

For a discussion of the available authentication types ILLiad supports, review the related articles in the panel on the right.

Billing

SUMMARY

Institutions sometimes wish to charge their Borrowing customers only whatever fees that the Borrowing library was charged by the Lending Library. In such cases, the normal practice of setting specific charges in the billing tables does not typically work, as the charges in question will very from transaction to transaction depending on the Lending institution's billing policies.

To allow the possibility of Reciprocal Charging, set up the following Billing Addition:

• Open the Customization Manager and navigate to System Billing - Setup - BillingAdditions.
• Create an option in the BillingAdditions table. Set the AdditionName to Reciprocal Charges (or something more descriptive if you prefer) and give it a Category of Default.
• Set the Base Fee to $0 and the per page fees as desired. (Probably $0 as well)

In the course of processing an incoming Borrowing Item for the customer, you will check the item in from the lending institution as normal.

• The Add Billing Charges form will appear with all relevant charge information in it.
• Select the Additional charge that you have set up for this purpose. Ex: Reciprocal Charges.
• The Additional Charge of $0 will appear on the form.
• In the Base Fee column of the form, next to the chosen Additional Charge, set the amount to the desired total (whatever charge the Borrowing institution incurred from the Lender).
• Click the Refresh button (the clock icon). This will adjust the totals on the form.
• Click the Charge button to apply the charges.

SUMMARY

ILLiad allows libraries who participate in Docline's EFTS to bill within the client automatically and generate EFTS files for each month.

First, EFTSActive must be set to Yes. This key is in the Customization Manager under Lending .. Billing. Also, the EFTS participants must be marked as such in the Address Maintenance form. To set the library as an EFTS participant, search for that library and check the checkbox for EFTS. Save changes for the Address.

When billing for EFTS items, the billing form appears the same as for other billing. The total at the bottom will say EFTS Total instead of Total or IFM Total.

To generate EFTS files for each month, open the Invoice form from the main menu by choosing Billing .. Search/Generate Invoices. Choose a date range of the previous month ( i.e. 7/1/2002 - 8/1/2002) and click the button to generate the EFTS file. Give a file name when prompted. Once the file is generated you can find it in the location you specified.

SUMMARY

When an item becomes lost or damaged by one of your customers, you can set ILLiad up to send them an email with charge information in it. You can add this new email template through the Customization Manager and through additional email text files.

EXAMPLE

Open the Customization Manager and look under System|EMail for the EMailRouting table. Add a new entry for the Lost/Damaged item for the Borrowing process by adding the following fields:

Once you have added the record to the EMailRouting table, you need to create the loan and article templates. Take a template you are already using for emails and edit it to include the information about the item being lost or damaged. A good one to start from would be ILLLoan.txt and ILLArt.txt. These will be on your server in the default email directory, or another location depending on your setup. Your system administrator should know where these files are located. Once they have been edited, put them in the default email directory.

Once you close and reopen the client, a new entry (Lost or Damaged Item) will appear on the EMail menu from the request forms.

MORE INFORMATION

More information about EMailRouting setup can be found in the Implementation Guide.

SUMMARY

If you have a large list of items to update when setting up ILLiad, or a large list of items to change because a billing category has changed, you can use a SQL Query and the Microsoft SQL Server Query Analyzer to make the change in the ILLiad database. Remember that any billing categories that you add this way must exist in the BillingDefaults table as well.

EXAMPLES

If you wanted to set all libraries in the database to be exempt:

use ILLData
go
update LenderAddresses set BillingCategory = 'Exempt'

Be careful with this type of query - this will change ALL BillingCategories, regardless of what they are set to now.

If you wanted to set all Virginia libraries in the database to be "VirginiaBilling":

use ILLData
go
update LenderAddresses set BillingCategory = 'VirginiaBilling'
where ((Address1 like '%VA%') or (Address2 like '%VA%') or (Address3 like '%VA%'))

This query uses the "like" operator and the wildcard operator "%". This will select any address that has the letters VA anywhere in Address1, Address2 or Address3 and change the BillingCategory to 'VirginiaBilling'.

If you wanted to set libraries with these symbols (ABC, BCD, CDE, DEF, EFG) in the database to be "SpecialLibraries"

use ILLData
go
update LenderAddresses set BillingCategory = 'SpecialLibraries'
where LenderString = 'ABC' or
LenderString = 'BCD' or
LenderString = 'CDE' or
LenderString = 'DEF' or
LenderString = 'EFG'

Using this method, you could take a long list of symbols, and insert the "Lenderstring = '" part and the "' or " part programmatically in order to change a large number of symbols at the same time, without having to edit each one by hand in the client.

MORE INFORMATION

More information on how the SQL Query language works in Microsoft SQL Server can be found in the Online Books under the Transact-SQL reference.

SUMMARY

In a standard installation of the Billing Manager, the reports are stored within the ILLiad share in the \billing\reports subfolder. If for some reason you need to replace the reports with the standard files from installation, you can download them from here.

RAV REPORT FILE DOWNLOADS

Reports folder zip file (latest versions of all report files)

Customer Balance Summary report zip file (omitted from initial upgrade files)

SUMMARY

When billing by date ranges in ILLiad, there are a few steps necessary to print invoices for any date range. For example, to generate and print invoices for the month of July in lending, do the following steps:

• Under Billing on the Main Menu, choose Search/Generate Invoices.
• On the right side of the billing form, put in a date range of 7/1/2002 - 8/1/2002 and click Generate Invoices.
• After the invoices are generated, enter the same date range in the search criteria on the left side of the billing form and click Search Invoices.
• Once the resulting list appears in the grid at the bottom of the form, click the button to Print Selected Invoices. This will print invoices to the dbf file for the invoices appearing below.
• Open the Microsoft Word template for the Lending Monthly Invoices and merge the template to print the invoices.

SYMPTOMS

When billing in Borrowing, an error is displayed of: Billing Amount Not Found for Document Type X, where X is a valid ILLiad document type.

ERROR MESSAGES

Billing Amount Not Found for Document Type... X.

CAUSE

This is generally caused by either a missing billing account for the user, or a missing document type in the BillingDefaults table.

RESOLUTION

First, check the user to make sure that they have a valid account type assigned, and that that account exists in the BillingDefaults table.

If that is the case, then also check to make sure that the BillingDefaults table has an entry for document type X.

SUMMARY

Institutions sometimes wish to charge their Borrowing customers only whatever fees that the Borrowing library was charged by the Lending Library. In such cases, the normal practice of setting specific charges in the billing tables does not typically work, as the charges in question will very from transaction to transaction depending on the Lending institution's billing policies.

To allow the possibility of Reciprocal Charging, set up the following Billing Addition:

• Open the Customization Manager and navigate to System Billing - Setup - BillingAdditions.
• Create an option in the BillingAdditions table. Set the AdditionName to Reciprocal Charges (or something more descriptive if you prefer) and give it a Category of Default.
• Set the Base Fee to $0 and the per page fees as desired. (Probably $0 as well)

In the course of processing an incoming Borrowing Item for the customer, you will check the item in from the lending institution as normal.

• The Add Billing Charges form will appear with all relevant charge information in it.
• Select the Additional charge that you have set up for this purpose. Ex: Reciprocal Charges.
• The Additional Charge of $0 will appear on the form.
• In the Base Fee column of the form, next to the chosen Additional Charge, set the amount to the desired total (whatever charge the Borrowing institution incurred from the Lender).
• Click the Refresh button (the clock icon). This will adjust the totals on the form.
• Click the Charge button to apply the charges.

Copyright

SUMMARY

The copyright.txt file is an optional file that exists to allow ILLiad sites increased flexibility in terms of how their ILLiad Client deals with copyright.

The default copyright query (built into the ILLiad Client) displays an alphabetical list of journal titles for items that have been requested five or more times from the last five years of the displayed journal titles. The query used for this is:

select distinct PhotoJournalTitle from Transactions
where (transactionstatus != 'Cancelled by ILL Staff'
and transactionstatus != 'Cancelled by Customer'
and transactionstatus != 'Awaiting Copyright Clearance'
and CopyrightAlreadyPaid != 'Yes')
and datepart(year, TransactionDate) = datepart(year, getdate())
and PhotoJournalYear > convert(varchar(4),(datepart(year, getdate()) - 5))
and ProcessType = 'Borrowing'
group by PhotoJournalTitle
having count(PhotoJournalTitle) > 4

If this query is sufficient to your institution's needs, and to your institution's interpretations of the rules governing copyright practices, there is no need for the additional copyright.txt file. If however you need to modify this query for some reason, the copyright.txt file gives you the ability to do so.

Some sites have noticed that the Electronic Delivery Cleanup program will affect their Copyright list as it moves articles from Delivered to Web to Request Finished at the beginning of the new year. If you would like to avoid seeing those articles, you can change your query to only show items that were routed to Awaiting Copyright Clearance this current calendar year. The ILLiad Client will eventually be changed to have this copyright query be its default, but for now you can change your query as needed.

To update the default query to reference the date the item went to copyright processing and not when it was last touched, the query should read:

select distinct t.PhotoJournalTitle from Transactions t, Tracking k
where t.TransactionNumber = k.TransactionNumber
and (t.transactionstatus != 'Cancelled by ILL Staff'
and t.transactionstatus != 'Cancelled by Customer'
and t.transactionstatus != 'Awaiting Copyright Clearance'
and t.CopyrightAlreadyPaid != 'Yes')
and k.DateTime = (select min(dateTime) from Tracking
where changedto = 'Awaiting Copyright Clearance' and transactionNumber = t.TransactionNumber)
and (k.ChangedTo = 'Awaiting Copyright Clearance')
and datepart(year, k.DateTime) = datepart(year, getdate())
and t.PhotoJournalYear > convert(varchar(4),(datepart(year, getdate()) - 5))
and t.ProcessType = 'Borrowing'
group by t.PhotoJournalTitle
having count(t.PhotoJournalTitle) > 4

You can also make other changes to the copyright query. For example, some institutions interpret copyright law as requiring that the last six years of requested journal titles be considered, rather than just five. If this is the case, the modified query would read as follows:

select distinct t.PhotoJournalTitle from Transactions t, Tracking k
where t.TransactionNumber = k.TransactionNumber
and (t.transactionstatus != 'Cancelled by ILL Staff'
and t.transactionstatus != 'Cancelled by Customer'
and t.transactionstatus != 'Awaiting Copyright Clearance'
and t.CopyrightAlreadyPaid != 'Yes')
and k.DateTime = (select min(dateTime) from Tracking
where changedto = 'Awaiting Copyright Clearance' and transactionNumber = t.TransactionNumber)
and (k.ChangedTo = 'Awaiting Copyright Clearance')
and datepart(year, k.DateTime) = datepart(year, getdate())
and t.PhotoJournalYear > convert(varchar(4),(datepart(year, getdate()) - 6))
and t.ProcessType = 'Borrowing'
group by t.PhotoJournalTitle
having count(t.PhotoJournalTitle) > 4

Another common modification to the copyright query is a change to differentiate between sites in a Shared Server ILLiad system so that each site tracks their own number of requests for "fair use" etc. This is done by referencing the Users Table as in the following query:

select distinct t.PhotoJournalTitle from Transactions t, Tracking k, Users u
where t.TransactionNumber = k.TransactionNumber
and t.username = u.username
and (t.transactionstatus != 'Cancelled by ILL Staff'
and t.transactionstatus != 'Cancelled by Customer'
and t.transactionstatus != 'Awaiting Copyright Clearance'
and t.CopyrightAlreadyPaid != 'Yes')
and k.DateTime = (select min(dateTime) from Tracking
where changedto = 'Awaiting Copyright Clearance' and transactionNumber = t.TransactionNumber)
and (k.ChangedTo = 'Awaiting Copyright Clearance')
and datepart(year, k.DateTime) = datepart(year, getdate())
and t.PhotoJournalYear > convert(varchar(4),(datepart(year, getdate()) - 5))
and t.ProcessType = 'Borrowing'
group by t.PhotoJournalTitle
having count(t.PhotoJournalTitle) > 4

Using these examples you can mix and match to choose the best list for your copyright tracking needs. Remember that this list is showing journal titles of items that might need to be paid for copyright and that some article may get cancelled later in the process. The copyright report you run and submit is the actual list of items that need to be paid.

ADDING AND ENABLING COPYRIGHT.TXT

To add a copyright.txt file do the following:

1. Create a file named copyright.txt, containing the query you wish to use for copyright purposes, and save it on the ILLiad Server. This is usually placed in the ILLiad Share, in the same location as the ILLiadClient.exe.
2. Open the Customization Manager and look under Borrowing - Copyright.
3. Set the CopyrightQuery key to File.
4. Set the CopyrightFile key to either copyright.txt orX:\filepath\copyright.txt . (If the copyright.txt file is located in the same place as the ILLiadClient.exe, copyright.txt will work. If the copyright.txt is located elsewhere on the ILLiad Server or ILLiad Clients, use X:\filepath\copyright.txt, where X:\filepath\ is the drive letter and path to the copyright.txt file.)

Docline

SUMMARY

Docline 2.0 is scheduled for release on Monday, December 8th, 2003. The service will be down starting Friday, December 5th at 5pm EST and is expected to be back up by 7am EST on Monday.

Once Docline 2.0 is in place there is only one change necessary for the ILLiad Borrowing module to send out requests on Docline.

EDITING FILLARTICLE.TXT

Each ILLiad client machine that uses Docline should have a c:\illiad\docline\FillArticle.txt text file.

You will need to open that file in Notepad and add one more tab to the end of the text file before the final enter command. So the text of the file would be:

{tab}{tab}{tab}{tab}{tab}<#User>{tab}oo{tab}{tab}{tab}<#Lastname>, <#FirstName> - <#TransactionNumber>{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{tab}{enter}

The change from the previous version is that there are 28 tabs after the TransactionNumber tag instead of 27.

You can also download an updated text file from this link to FillArticle.txt (right click on the link and choose save as ...) and replace it in your c:\illiad\docline folder.

As a note, if you do not want the macro to automatically forward to the shipping address screen in Docline, remove the final {enter} from the text file.

SUMMARY

You can customize the macros that ILLiad uses to fill the Docline requests.  The macros are the FillArticle.txt and FillLoan.txt files.  These files reside in C:\illiad\docline on each ILLiad client machine.  The files store TAB commands and merge fields that ILLiad accesses to know how to fill the Docline Web pages.  

The merge fields are the same as those used by ILLiad in the e-mail templates.  The merge fields allow you to use any field in the ILLiad request, user's record, or your office contact information (LocalInfo) to automatically fill a field in the Docline workform.  

The {TAB} commands instruct ILLiad to tab through the fields on the Docline workform.  

the {Enter} command mimics the pressing of the Enter key.  It can be used when a button needs to be activated in the Docline workform. 

EXAMPLES

Here is an example of the FillArticle.txt macro file:  

{tab}{tab}{tab}{tab}{tab}<#User>{tab}oo{tab}a{tab}a{tab}<#Lastname>, <#FirstName> - <#TransactionNumber>{tab}{Enter}

Note:  The existence of merge fields together without a {tab} means that the information will appear in one field in the Docline workform (i.e. the patron information all showing in one field). 

MORE INFORMATION

See Customizing E-Mail Files

SYMPTOMS

When on the Borrowing Request Form, clicking Docline .. Search does not switch to Docline to perform the search. There are no error messages, but the program just does not respond.

CAUSE

There are several possible causes for this problem. First, Docline may not be opened on the client machine. Also, the web browser used for Docline may not have the standard title in the toolbar.

RESOLUTION

First, verify that Docline is opened on the client machine with the latest version of Microsoft Internet Explorer and the Search UI form is displayed. Also, be sure that the cursor is in the UI Number edit box on the web page.

Next, verify that the Docline Window Title key matches the titlebar of the Docline system in the web browser. Note that Docline searching only works with Microsoft Internet Explorer. The value will most likely be " - Microsoft Internet Explorer" (note the space at the beginning). Basically, the value should be whatever follows after Docline ® on the web form after logging into Docline. In some cases your title may say something like "Docline ® - Microsoft Internet Explorer provided by ABC Library". In that instance you would want the DoclineWindowTitle customization key to be " - Microsoft Internet Explorer provided by ABC Library".

ISO ILL

SUMMARY

If going live with the entire ILLiad System, there is a script in the Implementation Manual. However, once live with one module, a different script must be run to go live with Borrowing/Doc Del or Lending separately.

BORROWING EXAMPLES

Going Live with Borrowing Only (single server)

use ILLData
go
delete from Users where Username <> 'Lending' and Username <> 'Unmatched' and Username not in
(select Symbol from DeliveryLocations)
go
delete from ESPUpdate where ProcessType <> 'Lending'
go
update Transactions set SpecIns = Username, Username = 'BeforeLiveTest', ProcessType =
'TestBorrow' where ProcessType = 'Borrowing'
go
delete from UserAccounts
go
delete from UserAccountsLink
go
delete from UserNotes
go

Going Live with Borrowing Only (shared server) - replace XYZ with your site code

use ILLData
go
update Transactions
set ProcessType = 'TestXYZ', SpecIns = UserName, Username = 'BeforeLiveTest', TransactionStatus =
'Cancelled by ILL Staff'
where ProcessType = 'Borrowing'
and Username in (select username from UsersALL where NVTGC = 'XYZ')
go

LENDING EXAMPLES

Going Live with Lending Only (single server)

use ILLData
go
delete from ESPUpdate where TransactionNumber in
(select TransactionNumber from Transactions where ProcessType = 'Lending')
go
update Transactions set SpecIns = Username, Username = 'BeforeLiveTest', ProcessType = 'TestLend'
where ProcessType = 'Lending'
go

Going Live with Lending Only (shared server) - replace XYZ with your site code

use ILLData
go
delete from ESPUpdate where TransactionNumber in
(select TransactionNumber from Transactions where ProcessType = 'Lending' and Username = 'XYZ')
go
update Transactions set SpecIns = Username, Username = 'BeforeLiveTest', ProcessType =
'TestLendXYZ' where ProcessType = 'Lending' and Username = 'XYZ'
go

SUMMARY

The following instructions detail how to install and setup ISO ILL on an ILLiad server.

INSTALLING THE JAVA RUNTIME

The OpenURL Service requires Sun Microsystems Java Runtime Environment (JRE) 1.3.1 or 1.4.0 (recommended).

First, check to see if this file is available for installation in your Admin folder of the ILLiad share on the server. For example, the default 1.4 version is named: j2re-1_4_0_01-windows-i586-i.exe. If the file exists, you can install it by double-clicking on it, accepting the defaults as it installs.

If the file does not exist in the Admin folder, you can download the latest JRE version from http://java.sun.com/j2se/1.4/download.html– Download the version appropriate for you, for example “Windows (U.S. English only).” Once again, you can install the file by saving it to a location on the hard drive (the Admin folder of the ILLiad share is recommended) and double-clicking on it, accepting the defaults as it installs.

UNPACKING THE DISTRIBUTION

If this is the first time you've installed ISO on this ILLiad server, create an ISO folder in the ILLiad share (for example: c:\illiad\iso\).

Next, check to see if there is an updated version of ISO in your update folders. These are located in the ILLiad share's Setup folder, under Setup\ISOUpdates\#.#.#.#, where # is the latest version number. If there are any folders with ISO updates on your machine, copy the ILLiadISOService.jar from the latest version folder into the illiad\iso folder.

If your machine doesn't have any updates folders (because it is a new installation) then you can find the ILLiadISOService.jar file in the Admin folder of your ILLiad share.

ILLiadISOService.jar is a self-extracting archive, so you can expand it by double-clicking on it. If ILLiadISOService.jar does not expand into several files, check your installation of the Java Runtime.

INSTALLING THE ISO SERVICE FOR SINGLE ILLIAD SERVER INSTALLATIONS

You can follow the Single Server ILLiad Server Installation instructions if the follow is all true:

• You are installing the ILLiad ISO Server on the same machine that runs the ILLiad SQL Server
• You installed ILLiad using the default ILLiad database name of ILLData.
• You are using the standard SQL port of 1433.
• You haven't changed the ILLiad user's SQL password.

If all of the preceding is true, then you can use the default installation. When you extracted the files into the ILLiad ISO directory, a file was created called InstallService.bat which is tailored for a default installation. To install the ILLiad service, you must have Administrator-level permissions. Run it by double clicking, or calling it from the command line. You will be prompted to add information to the registry - respond yes. When it tells you the information was successfully added, click OK. This will install the ILLiad ISO Service as a Windows NT/2000 service, which you may access through the Services list in the Computer Management Console. The service is set to start automatically, but will not be running at this point.

INSTALLING THE ISO SERVICE FOR MULTIPLE ILLIAD SERVER INSTALLATIONS

If you need to make changes to any of the following configuration settings, then you need to perform this installation routine:

• Changing the database server that the ISO service points to.
• Changing the database name that the ISO service points to.
• Changing the database port that the ISO service talks to.
• Changing the ILLiad user's SQL password.

To do this, you need to edit the isocontrol.properties file that can be extracted using the InstallService.bat installation file.

Open a command prompt, and navigate to the ILLiad ISO directory that you created earlier in the installation. You must be in the ISO directory when running this command.

Next, extract the isocontrol.properties file by typing this:

installservice.bat -config

This will extract the file and open it in Notepad for you to edit. Once you have finished editing it, you will save it using Notepad, then close it and the batch file will re-integrate it into the service.

To change the database server, database name, or port, find this section in the isocontrol.properties file:

#--- Database Connection Section ---
# connection parameters for connecting to database
db.databaseUrl=jdbc:microsoft:sqlserver://127.0.0.1:1433;DatabaseName=ILLData

• The text in red is the database server address. This can be either the name of the server or the IP Address.
• The text in green is the database server port. This can be changed from the default of 1433 if necessary.
• The text in blue is the database name. This can be changed to the new database name.

To change the default ILLiad password, find this section in the isocontrol.properties file:

#--- Database User Section ---
# modify as necessary
#db.userName=illiad
#db.password=your_illiad_password

• If you replace the text in red with your new password, then that will be used instead of the default ILLiad password.

Once you have made the changes, save the changes in Notepad, then exit. The file will be written back into the installation files, and will be used when you run the installation.

To install the ILLiad service, you must have Administrator-level permissions. Run it by double clicking, or calling it from the command line. You will be prompted to add information to the registry - respond yes. When it tells you the information was successfully added, click OK. This will install the ILLiad ISO Service as a Windows NT/2000 service, which you may access through the Services list in the Computer Management Console. The service is set to start automatically, but will not be running at this point.

INSTALLATING THE ILLIAD GATEWAY

The ILLiad Gateway service is used both for ISO functionality and Odyssey functionality. If you have already installed Odyssey and have the latest Gateway installed, you can skip this step. If not, then you'll need to make sure you have the latest Gateway installed.

Check to see if there is an updated version of the Gateway in your update folders. These are located in the ILLiad share's Setup folder, under Setup\GatewayUpdates\#.#.#.#, where # is the latest version number. If there are any folders with Gateway updates on your machine, copy the ILLiadGateway.exe from the latest version folder into the illiad\iso folder. If the system won't let you replace the ILLiadGateway.exe file in the ISO folder, then you'll need to stop the ILLiad Gateway service using the Services option under Windows NT/2000.

STARTING THE ISO SERVICE

Go to the Services module (under Control Panel or Control Panel .. Administrative Tools). There are two new services - ILLiad Gateway and ILLiad ISO Service. Start both of these services (they should be set to automatically start the next time you boot).

CUSTOMIZING VALUES FOR ISO ILL

The last step is to open the Customization Manager (usually in an Admin folder in the ILLiad share) and set the following keys under System .. ISOILLDefaults:

ISOEnabled=Yes
ISOIFMBorrowing & ISOIFMLending=Yes if you support IFM
ISOInstitutionName=<Your Institution>
ISOReturnIPAddress=<Yoursqlserveripaddress>:1611
ISOSystemID=<Your symbol when sending to other ISO libraries - usually your OCLC Symbol or similar>

The main key is ISOEnabled, which turns on ISO ILL for ILLiad.

You *must* also setup the LocalInfo table with valid

SUMMARY

When sending requests using ISO ILL, it will take the last ISO note from your notes table and send it as the note that is associated with the request. Since sometimes you'd like to send a note with a request that was entered as a non-ISO note (and vice versa), you can now change the Note Type associated with a note.

Right-click on the note you want to change and select Change Note Type to... and select the note type you'd like to have for the note.

SUMMARY

There is a field - ISOPaymentMethod - that was added with the ISO Version 6.2.1.0 update. If you are not using ISO ILL and update to version 6.3.2.0 of the Client, you may find this field missing (the update scripts for both releases have since been updated so that any current updates will not give an error). To add this field after the fact, connect to your SQL Query Analyzer as the system administrator and run the script below.

EXAMPLE

USE ILLData
GO

IF NOT((select min(table_schema) from Information_schema.columns
where Table_Name = 'LenderAddresses' and Column_Name = 'ISOPaymentMethod') IS NOT NULL)
BEGIN
IF (Select min(Value) from Customization where CustKey = 'SSSLenderAddressesALL') = 'Yes'
BEGIN
EXEC ('alter table LenderAddressesALL add ISOPaymentMethod [varchar] (6)')
END
ELSE
BEGIN
EXEC ('alter table LenderAddresses add ISOPaymentMethod [varchar] (6)')
END
END
GO

SUMMARY

ISO ILL requests in ILLiad use the NotWantedAfter date field when sending the requests to determine the "drop dead" date for that request for the lending site. Once this date is reached, the request is automatically returned to the sending library via ISO with an APDU type of Expired, and the status will go to Awaiting Expired Request Processing.

If items are going to Expired status before you expect them, check the NotWantedAfter date when sending the request. In the ILLRequest APDU, it is called expire-date and it is sequence number 1.12.3.

SUMMARY

ISO ILL requests can be forwarded (or referred) to another ISO ILL LIbrary on the same server within ILLiad using the standard ILLiad route menu.

When a Lending request is received for a site, if that site needs to send the request to a different site on the same ILLiad server, they can choose Route from the menu at the top of the request and choose the site to receive the forwarded request.

This takes the request and marks it as Cancelled by ILL Staff, with a Reason of Cancellation of Referred via ISO ILL. The request is returned via ISO ILL to the Borrower/Requester, and automatically forwarded back to the new ILLiad site (if the Requester is using OCLC ILLiad, RLG ILL Manager, or any system that supports the RLG Requester service).

This differs from non-ISL ILL requests. Non ISO ILL requests in ILLiad are moved from one site to the other. ISO ILL requests are cancelled at the original receiving library and a new request is received at the referred library.

SUMMARY

In a shared server configuration, it is possible for each site to define their identity for ISO requests independantly of the other sites. This requires some additional records in the Customization and ISOCustomization tables. These two tables allow you to use your own site codes within ILLiad that translate to your ISO values when sending and receiving ISO ILL requests between other servers.

Customization Table key - ISOSystemID

For each site in a shared server configuration, there can be a separate and unique ISOSystemID. For example site LEAFS may identify itself as NHL:TORONTO for it's ISOSystemID, while the site DUCKS may identify itself at NHL:ANAHEIM. Any site not specifically listed in the Customization table will be assigned the first value in the table. So it is a good idea to fill out values for all of your NVTGC fields for this key. Here's an example of the values in your table.

As a note, ISO symbols are generally designed to have the external system as the prefix and then the symbol after it. So for those sites using RLG symbols, your codes would be RLG:NYCX. This means that when you send to other RLG institutions as well, you would need to add addresses for those libraries to your database with the symbol RLG:NYCX etc. where before you were only using NYCX.

ISOCustomization Table key - ResponderId

For incoming messages, you ILLiad's ISO service must match the ResponderId on the incoming request to a site on the shared server (NVTGC). So that if another institution sends an ISO request to NHL:TORONTO, ILLiad on that server knows that that ResponderId maps to the NVTGC site of LEAFS. If you have one site who handles all incoming requests, you only need one value in the table, and the ISOValue would be Default, but most sites will work independent of each other in a shared server environment. An example of the values in your ISOCustomization table would be:

You can not view this table currently in the Customization Manager (this table will be added in a future Customization Manager release), so you would need to add these values through a SQL Script. To add these values to your table, open a SQL Query Analyzer and connect as sa or Windows authentication. In the open script window paste a script similar to the one below. Note the script below is only a sample and you will need to make changes to customize it to your site.

Use ILLData
go
insert into ISOCustomization (ISOType, ISOValue, ISOName, ILLiadName)
values
('RequesterId','NHL:PHILLY','NVTGC','FLYERS')
go

SUMMARY

When using ISO ILL and interacting with non-ILLiad ISO systems, it is possible for you to receive the article or loan from the lender before they've updated their system to Shipped. (Because of workflow in ILLiad, this is not a common problem between ILLiad sites.) In order to allow your ILLiad workflow to continue, ILLiad automatically holds the Received APDU until it receives the Shipped APDU from the Lender. Once the Shipped APDU is received, the Received APDU is sent automatically by ILLiad.

The graphical display of the ISO ILL Tracking in ILLiad will show a different icon for Received APDUs that haven't actually been sent yet - and there will be a note beside it saying that it is waiting on a Shipped APDU from the lender.

PORTS

ILLiad ISO ILL uses port 1611 to send and receive ISO ILL APDUs. This port must be open for incoming and outgoing traffic on your firewall for your ISO partners.

RETRIES

ILLiad ISO ILL automatically tries to send a request 4 times before failing, over a period of an hour. If ILLiad can not successfully send the request, the reason is added to the Notes field for the request and the status is changed to ISO Sending Failed. After fixing the problem, you can resend the request by right-clicking on the APDU that was not sent on the General Update form and choose Resend Selected APDU.

SUMMARY

When using ISO ILL, ILLiad restricts the sending of ILL ISO APDUs based on the ISO ILL state tables, as defined in the ISO standard. This prevents ILLiad from sending "illegal" APDUs (for example, an ILLAnswer - Unfilled *after* an Expired has already been sent). If an action in ILLiad generates an illegal state transition, the ILLiad status will change to ISO Attention for that request and a note that describes the illegal transition will be displayed in the Notes field.

The graphical display of the ISO ILL Tracking in ILLiad will show a red X for items that were not sent because of illegal state transitions.

Resolving state transition problems generally takes communication with the requester or responder in order to fix whatever problem exists in the request.

SUMMARY

These codes are used by OCLC as well as by the ISO ILL Protocols to indicate the reason for saying No to a request to Loan or Photocopy something.

When filling out your Lending Reasons for No, for OCLC, use these OCLC codes.

SUMMARY

ISO ILL requests in OCLC ILLiad are sent via the TCP/IP method of ISO ILL on port 1611. If something goes wrong during this process, ILLiad will move the request to ISO Sending Failed and place a note in the notes field as to the cause. The most common cause of this is that the ISO Address of the site you are sending the request to doesn't exist in ILLiad.

To resend a request, check the note in the request, and if it says that the address does not exist, fix that via the Address Maintenance Form. Once that is done, you can open the request on the General Update Form, find the problem in the ISO Tracking display (any failed APDUs will be marked with a red X), right-click on the one what you want to resend, and choose Resend Selected APDU.

You can watch the status update on the ISO Tracking screen by right-clicking on the ISO Tracking view and choosing Refresh ISO Tracking.

SUMMARY

Title is a required field when sending an ILL Request to RLG ILL Manager sites. If you don't include a title, the request will be rejected. This behavior is by design.

ILLiad does not require a title when sending requests between ILLiad ISO systems.

SUMMARY

When searching RLG's Eureka database using the Z39.50 functionality within ILLiad, ILLiad will automatically create lending strings based on the available lenders for a request and the priorities you've assigned for each lender. These priorities are used only when the system generates a lending string using the Z39.50 Search form in ILLiad, and only when connected to RLG's Eureka database.

ASSIGNING LENDER PRIORITIES

From the Address Maintenance Form, open a site that is an RLG ISO ILL site. If ISO is enabled for that site, you will see 2 edit boxes labelled ISO Article Priority and ISO Loan Priority. These will contain a number if you have never set them equal to the default in the LenderPriorityDefaultValue key (which defaults to 10).

Changing priorities is as simple as changing the numbers in the 2 boxes and hitting Save Changes. You can have as many different priority levels as you want.

NOTES ON PRIORITIES AND AUTOMATIC LENDER STRINGS

When ILLiad generates the lender string from the available sites, it orders them by priority first, then randomly within similar priorities, with a maximum of 5 lenders automatically generated. For example, if you have 5 available sites: A, B, C, D, and E, ranked this way with Article Priorities:

An example lender string would be:

B, C, A, E, D

B would always be first and D would always be last, with A, C, and E, since they all share a priority of 2, being randomized in order each time.

Each time you click the record, the lending string is generated from scratch, overwriting any changes you have made to the lending string.

SUMMARY

On startup, ILLiad ISO may print some diagnostic messages to the standard error stream. When running as a Windows NT service, the standard in/out/error streams do not exist - therefore the messages have nowhere to go. When ILLiad ISO is run as a service on Windows NT 4, the diagnostic messages cause the service to abort. Windows 2000 in effect redirects the streams to nul, so those messages are never seen, and cause no undesirable effects. You can make these changes to get the ILLiad ISO Service to start on the server.

To redirect stdout and stderr on Windows NT:

1. Open the registry editor on the server by going to Start .. Run and typing regedt32. Find the service entry for the ILLiad ISO Service under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ILLiad ISO Service

2. Under the Parameters subkey, add the following values by clicking on the Edit menu and choosing Add Value.

Value Name: System.err File
Data Type: REG_SZ
String: {isodir}\stderr.log

Value Name: System.out File
Data Type: REG_SZ
String: {isodir}\stdout.log

where {isodir} is the name of the directory where ILLiad ISO was installed (it will be the value stored in the 'Current Directory' registry key). After adding these values, close the Registry Editor. Changes are saved automatically.

3. Stop and restart the ILLiad ISO Service from the Services module in the Control Panel.

MORE INFORMATION

The ISOInstall program (build 6.2.1.1 and greater) has been modified to add these entries automatically. Additionally, non-essential messages have been eliminated.

SUMMARY

ISO ILL Messages can be sent and received between 2 ISO sites. These messages can contain any text, ranging from a request for a status update to a question about a citation.

SENDING ISO MESSAGES

ISO ILL Messages can be sent between 2 ISO sites. Open the request from the General Update Form, choose the Process menu, then ISO ILL, then ISO ILL Message. This will prompt you to type in the message you want to send to the other site regarding this request. When you finish typing and hit OK, the message is sent to the other site and is stored in the Notes field.

RECEIVING ISO MESSAGES

When an ISO ILL Message is received, it changes the current status of the request in ILLiad to ISO Attention. Open the request on the General Update Form and review the message by reading the notes field. If it requires a reply, you can send a reply message via the Process menu, then ISO ILL, then ISO ILL Message.

Once you have replied to the message and want to put it back to its prior status in ILLiad, simply choose the Process menu, ISO ILL, then Return Request to Prior Status option. This will look at the tracking in the request and put it back at whatever status it was at before the ISO ILL Message was received.

SUMMARY

Sending overdues for ISO ILL request in ILLiad is the exact same process as sending all other lending overdues. From the Lending Overdues screen, hitting the Send Overdues button will start the overdues process. Items that are marked as ISO ILL will not print, but will generate ISO ILL overdue messages to be sent to the library via ISO ILL.

Notifications

SYMPTOMS

Email Copies are not available for all email functions.

CAUSE

Email Copies are not available for newer email functions.

RESOLUTION

Email Copies are no longer supported. All emails are held inside ILLiad, so outside copies are no longer necessary.

SUMMARY

In Borrowing and Doc Del you may choose not to send an email notification. This may be accomplished by changing the EMailFileName key value(s) to be "None" instead of the text file denoting the name of the EMail template (example illartdel.txt).

The most common example of this woud be in the case of Articles to be delivered via mail. Many sites will choose to skip notification for this.

EXAMPLES

Relevant Keys - Borrowing:

ILLArticleDeliveryNotifyEMailFileName
ILLArticleNotifyEMailFileName
ILLLoanDeliveryNotifyEMailFileName
ILLLoanNotifyEMailFileName

Relevant Keys - Doc Del:

ILLDDArticleDeliveryNotifyEMailFileName
ILLDDArticleNotifyEMailFileName
ILLDDLoanNotifyEMailFileName
ILLDDLoanDeliveryNotifyEMailFileName

To bypass sending EMails in Borrowing for Articles Delivered, perform the following actions:

1. Open the Customization Manager
2. Go to Borrowing - Email - ILLArticleDeliveryNotifyEMailFileName
3. Change the Key Value to "None"
4. Click on the Update Key Value button.

Note: For Shared Server situations, the ILLArticleDeliveryNotifyEMailFileName may be named differently. It will appear as XYZArticleDeliveryNotifyEMailFileName, where XYZ is the symbol for your site on the Shared Server system.

SUMMARY

There is a checkbox on the borrowing cancellation form that will allow you to send the cancellations to a print queue instead of (or in addition to) sending the normal email. If this checkbox is selected, all notifications will also be written to the BCancel.dbf file, which would be referenced by the BorrowingCancellation.doc Word template.

Note: The BorrowingCancellation.doc Word template is not a part of the standard print documents package provided with your ILLiad installation. Print notification for cancellations is so rarely used that those installations that wish to do so should create their own document template for this.

PROCESS

• Make sure the checkbox is checked on the borrowing cancellation form for the items you wish to print. You can select this on a request by request basis, or you can change the default of whether this is checked or not by changing the BorrowingPrintDefault key in the Customization Manager under Borrowing|Cancellations.
• After you have completed your cancellations and wish to print out the accumulated templates, open the Borrowing Cancellations print document by going to a shortcut or to Start -> Programs -> ILLiad -> Borrowing -> Borrowing Cancellations.
• Choose the mail merge option in Word and print out the cancellations.
• Once you are finished, switch back to the ILLiad Client and choose "Empty Cancellations Print Queue" from the Process menu. This will empty out the DBF file and let you start writing fresh cancellations.

SUMMARY

For an undetermined amount of time, the default documents for the three Lending Overdue Letters were available for download from our server without an assigned data file from which to get the mail merge information needed for them to work properly. If you have these documents, and they do not function because of this, you have two options to fix them.

Option 1: Add the data source to the document through the mail merge helper in Word. The data files should be matched to the documents as follows:

• LendingOverdueLetter1.doc should point to LendingOverdues1.dbf
• LendingOverdueLetter2.doc should point to LendingOverdues2.dbf
• LendingOverdueLetter3.doc should point to LendingOverdues3.dbf

Option 2: Download new versions of the documents, complete with designated data sources, from here. Then replace your existing LendingOverdueLetter documents with the new ones.

SUMMARY

If anything should happen to your ILLiad Email Templates, you can download a zip file of the latest Email Templates supplied. These documents would replace those in the email folder either on your local machine or on the file server in the ILLiad share.

SUMMARY

To setup overdues in ILLiad, there are several keys that apply. All of the overdue days only apply to which template is used when sending overdues. Overdues are only sent when a staff member goes to the client and clicks the button to send the emails (for Borrowing) or print the files (for Lending). The following keys need to be set for Borrowing:

OverdueGraceDays: This key should be set to the number of days after the due date before overdues should start being sent. For example, to have the first overdue notice apply after the book is 2 days overdue, the OverdueGraceDays should be set to 2. NOTE: OverdueGraceDays cannot be set to a negative number in order to create a reminder notice. The is being considered as a possible future enhancement.

OverdueNoticeOneDays: This key is the number of days after the due date when the second overdue should be active. For example, if the second overdue should be sent after 9 days, then the OverdueNoticeOneDays would be set to 9.

OverdueNoticeTwoDays: This key is the number of days after the due date when the third overdue should be active. For example, if the third overdue should be sent after 16 days, then the OverdueNoticeOneDays would be set to 16.

BlockOnThirdOverdue: This is a Yes/No key to give the option of not blocking borrowing customers when their items are in the third category of overdues. By default, this key is set to Yes.

For the previous examples, overdues would be in three categories. Items that were 2-9 days overdue would be in the first overdue category. Items that were 9-16 days overdue would be in the second overdue category. And items that were over16 days overdue would be in the third overdue category. Overdues would still only be sent whenever the overdue button is clicked.

SYMPTOMS

When viewing items on the Awaiting Customer Contact form, double-clicking to mark a notification as sent or clicking the Start Automatic E-Mail leaves items in the queue to be notified still. Those requests remain "stuck" in Awaiting Customer Contact and cannot be notified by phone or email.

CAUSE

The DeliveryMethod or LoanDeliveryMethod for the customers is not set to a value of "Hold for Pickup" or "Mail to Address". Note that those values are case-sensitive, so the values must match exactly. If the values are anything other than those, ILLiad does not understand what type of email to send to the customer (delivery versus pickup notice).

RESOLUTION

Edit the web pages to only allow values of Hold for Pickup or Mail to Address. Also update the customer's information so that their delivery methods are correct.

MORE INFORMATION

See INFO: Valid Delivery Methods for Loans and Articles in ILLiad

SYMPTOMS

When attempting to send an email for a customer, you receive an email error and the email is not sent.

ERROR MESSAGES

Email not sent! Error: 503 Need RCPT (Recipient) (0)

CAUSE

This is generally caused by either the email address being incorrect for the user, or the NVTGC field being blank for the user.

While we have not experienced this ourselves, we have had several reports from various ILLiad users that there may also be an issue with McAfee VirusScan 8 software in conjuction with ILLiad. When version 8 is installed, it prevents access to port 25 which is needed for email notification from ILLiad. For campuses using ePO an administrator will need to change a setting under 'access protection policies' for VirusScan 8. The rule 'Prevent mass mailing worms from sending mail' blocks port 25 which is what is causing the problem. Unchecking this rule seems to solve the problem. For campuses not using ePO, an administrator will have to make that exception on all library staff machines.'

RESOLUTION

If the email address is incorrect, change the email address to be valid and resend the email.

To check the NVTGC field, look up the customer from the Edit Customer screen and check the NVTGC field at the bottom. If it is blank, it should be changed to match a valid site. If you are a single ILLiad site, this is usually ILL. If you are a shared ILLiad site, then you should change it to a valid SSS NVTGC code.

SYMPTOMS

On the main menu of ILLiad, there are items listed as Awaiting Customer Contact, but when you look at the Customer Contact screen, nothing shows up.

CAUSE

This is caused by a blank NVTGC field on the user's record.

RESOLUTION

Edit the user using the Edit Customer form and replace the NVTGC field with a valid code. For single ILLiad sites, this is ILL. For shared ILLiad servers, use a valid code.

OCLC

SYMPTOMS

When clicking either the OCLC button on the search form, or the OCLC Live Link menu option from the General Update form, ILLiad stops responding and you have to use the task manager to kill the session.

CAUSE

This is caused by an incorrect OCLC Authorization or Password entered in the Customization Manager.

RESOLUTION

Verify the Authorization and Password for your site entered in the Customization Manager.

SUMMARY

You may notice the following error on your ILLiad server in the Windows System Event Log each night between midnight and 3am:

The ILLiad Connection Manager service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 0 milliseconds: Restart the service.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This is normal as the service resets itself. The ILLiad Connection Manager Service is set to restart automatically after stopping. As long as you use the ILLiad Auto Updater or the InstallConnectionManager.bat file provided with it to install the service, it will be set to restart automatically.

SUMMARY

You will need to make several changes to your constant data settings within OCLC in order for your Connection Manager to function properly. You can edit these through the OCLC .. Resource Sharing Settings option within the ILLiad Client. These changes are necessary for any constant data used by a site for updating within the Connection Manager. In shared server installations, each site can designate a constant data to use for sending and receiving requests from within the Customization Manager under System .. OCLC.

Please note that a DEFAULT Constant Data set is required by the ILLiad Connection Manager unless your OCLCILLConnectorCDBorrowing and/or OCLCILLConnectorCDLending keys are set to some other Constant Data set.

Check the following values in your constant data. These are the ones needed for ILLiad. Others may be recommended or necessary for OCLC sending to function but are not specific to ILLiad.

Required Changes

Shipped - The value should be "-0" so that when responding Yes to requests, the status changes to Will Ship instead of Will Supply. ILLiad does not use Will Supply for updating filled requests.

Return To - This should be the full return address for your institution. If this value is missing and ILLiad attempts to update Yes for a Loan, you may get an error about the request missing a required field. You can not update Loans to Yes without supplying a Return To field in OCLC.

Optional Changes

Patron fields - These should be blank. ILLiad will fill out the Patron field with the customer's name by default and append it to whatever is in the field already. You can edit what is put in that OCLC field by editing the WorkFormMapping table.

Due Date - This value should be blank. If you put in a default value such as +30, the date created will be overwritten by the due date from ILLiad or N/A for articles.

Lending Charges - This value should be blank. ILLiad will enter any charges and add IFM tags for those items billed via IFM.

All other borrowing fields for the OCLC workform will be filled out using the WorkFormMapping table or the Connection Manager when performing the updates.

SUMMARY

The following OCLC fields are recognized by the ILLiad WorkFormMapping table as potential OCLCFieldName values. These fields can be used to map ILLiad field values to the specified OCLC fields in the OCLC work form upon creation of the work form during processing. These fields are not case-sensitive.

affiliation
article
author
billto
billingnotes
borrowingnotes
callnumber
copyrightcompliance
dissertation
edition
email
fax
imprint
insurance
isbn
issn
issuedate
issuenumber
locations
maxcostamount
maxcosttype
needbeforedate
pages
patron
patronaddress
patrondepartment
patronemail
patronfax
patronid
patronnotes
patronphone
patronpickuplocation
patronstatus
series
shipto
shipvia
title
uniformtitle
verified
volume

MORE INFORMATION

Please note that the former OCLC MaxCost field has been split into two distinct fields in the new OCLC system. These are MaxCostAmount and MaxCostType.MaxCostAmount should contain only a dollar amount, such as $15. No additional text will be accepted in this field. MaxCostType should contain only text. Recognized values for this field are IFM or Other. Any other text which may have populated your MaxCost field in the past should be moved elsewhere, such as to the borrowingnotes field.

SUMMARY

The process for borrowing renewal requests has changed slightly in order to accomodate the ILLiad Connector.

If customers request renewals automatically, those items go to Renewed by Customer to XX/XX/XXXX. Those requests can be sent to the Connector from the Main Menu under Process .. Write Renewal File/Send to OCLC. This will move the items back to Checked Out to Customer and send the requests for the next Connector update.

If customers request a renewal that goes to Renewal Requested or if a staff member wants to place a renewal request for a customer, the staff can place the renewal request from the General Update form. First change the due date to the new one desired. Then under Process choose Renew Request. The request will be sent to OCLC with the next Connector update. Be sure to change the status back to Checked Out to Customer after requesting the renewal.

SUMMARY

The ILLiad Connector automatically downloads and updates requests and statuses in OCLC. Here is a list of statuses updated and downloaded by the ILLiad Connector.

BORROWING

* Connector Version 6.3.0.0 and higher.

LENDING

SUMMARY

There are two keys, OCLCILLConnectorCDBorrowing and OCLCILLConnectorCDLending, that set the constant data when the ILLiad Connector runs to perform updates and downloads. These keys are located in the Customization Manager under System - OCLC.

These keys are used ONLY by Shared Server institutions when multiple libraries that are otherwise separate entities share an OCLC symbol. They specify which set of constant data the ILLiad Connector should use for sites that share OCLC symbols. This information is used for updating Lending (for Return To fields etc.) and for sending out on Borrowing (Ship To fields etc.).

There is no need to set these keys for Single Server ILLiad institutions. Nor is there any need to set these keys for Shared Server ILLiad institutions that do not share OCLC symbols, as in most cases there is no constant data choice to be made.

SYMPTOMS

When exporting items to the OCLC MicroEnhancer from ILLiad, an error will appear. The error varies depending on the problem.

ERROR MESSAGES

Permission denied.

File not found.

CAUSE

Permission denied: If the ILLiad share is set to read only, and there is no MEDatPath key directing ILLiad to another folder location for the files it needs, ILLiad can not gain the necessary access to send the updates to the MicroEnhancer.

File not found: The four dat files necessary for updating are not in the ILLiad share or the path that MEDatPath points to if that key exists.

RESOLUTION

The four dat files - EvenReceived.dat, EvenReturned.dat, OddReceived.dat and OddReturned.dat - need to be copied to the local machines in the c:\illiad folder.

Next set your MEDatPath to point to c:\illiad\ (be sure to include the last \ in the path). The key should be under Borrowing .. OCLC Microenhancer. If the key does not exist, you can either add it by entering it in the Customization table (under System .. General in the Customization Manager) with these values or by running the script below that on the ILLData database:

CustKey: MEDatPath
Value: c:\illiad\
NVTGC: ILL
Description: Directory location for the four dat files for Borrowing updating OCLC
AdminCat: Borrowing
AdminKey: OCLC Microenhancer
AdminType: StringValue

<begin script>

use ILLData
go
insert into Customization
(CustKey, Value, NVTGC, Description, AdminCat, AdminKey, AdminType)
values
('MEDatPath','c:\illiad\','ILL','Directory location for the four dat files for Borrowing updating OCLC', 'Borrowing','OCLC Microenhancer','StringValue')
go

<end script>

SYMPTOMS

The borrowing items that import to Awaiting Unfilled Request Processing (Unfilleds in OCLC) no longer show the history from the OCLC record that includes the "reasons for no" from each potential lender.

CAUSE

This feature was in version 6.0.0.3 - 6.0.0.8 of the Connector but was found to be causing problems at some sites (the imports would fail at this point occasionally).

RESOLUTION

This feature will be put back in the Connector an upcoming Connector release after verifying that it no longer causes imports to cease mid-stream.

SUMMARY

When processing both Borrowing and Lending OCLC requests, records that are in the queue for updating (either via the Connector or through MicroEnhancer or Passport) can be removed from that table so that a different update can be sent to OCLC.

The most common need for this is Lending requests that are mistakenly cancelled, conditionalized or marked as "yes" and that status needs to be changed later. ILLiad allows you to remove the old pending update from the table within the client so that staff can then update the request to the new status/process for updating on OCLC.

EXAMPLES

To change a Lending request that was originally answered as "yes" to a conditional, do the following steps:

1. From the Update Stacks Search form, click the Mark Item as Found button (this will most likely already have been done earlier, hence the need to change the update).
2. Search the request in ILLiad and go to the General Update Form.
3. If there are any pending updates to be sent to OCLC, a tab will appear on the right side of the form next to the Resubmission tab marked Pending Updates.
4. Click on the Pending Updates tab and right-click on the update you wish to remove.
5. Choose Remove Selected Pending Update from the pop up menu.
6. The selected update will be removed from the list and the update table. If the list is now empty, closing and reopening the General Update form will remove the Pending Updates tab. The Pending Updates tab only shows if there are updates in the table to be sent to OCLC.
7. Process the request again with the new status. In this example, you would conditionalize the request from the General Update form to send a Conditional message on OCLC at the next update.

Odyssey Electronic Delivery

SUMMARY

In order to set up electronic delivery on a client machine, a few keys must be set. Below are the keys found in the Customization Manager under Borrowing .. Electronic Delivery.

EXAMPLES

ArielPath: This is the location of the Ariel received files that ILLiad imports for delivery. The default location for version 3 of Ariel is: c:\Program Files\RLG\Ariel\In\ - be sure that there is a backslash at the end of the directory path.

CheckForPDFFileExists: This key is an internal setting used when sending the request to the server. It should be set to Yes.

DaysBeforeElectronicDeliveryCleanup: The number of days a request remains on the server before being removed by the ILLiadCleanup program.

EDTempPath: This key should be set to c:\illiad\elecdel\ - remember the backslash at the end. In order to activate electronic delivery on the client machine, the elecdel folder needs to be created in the c:\illiad folder.

ElecDelAllowRapidMatch: This key allows the client to match ILLNumbers with negative numbers. This is only necessary if your site receives requests that are processed by Rapid.

ElecDelCustomerDeleteDelay: The number of days after a customer "deletes" a request on the web, before the ILLiadCleanup removes the file from the server.

ElecDelDefaultZoom: The percentage of zoom for the incoming articles viewed in the electronic delivery screen. Normally a value of 40% or so is ideal.

ElecDelPath: The locaion on the server where the pdf files should be copied to. This key should be from the perspective of the client machine, however, so a share should be created for the pdf directory on the server. The staff using the client machine will need to have write access to that share on the server. An example value would be: \\illiadserver\elecdelshare\

ElecDelPrintAllCheckboxDefault: This key allows staff to have all requests in the Print box print and check in at once.

ElecDelShowPDFAfterConversion: This key originally was designed for testing electronic delivery and would have the PDF file open after each conversion. Once in production, this key should most likely be set to No.

ElectronicDeliveryEMailFileName: The name of the email template - normally elecdel.txt - that is used for sending notifications to customers. The template is located in the path set by EMailLocation.

ElectronicDeliveryEMailSubject: The subject of the email notification sent to customers when the request is moved to the server.

PDFPath: The location ILLiad creates the pdf files in after converting the tiff files. By default, this should be set to c:\illiad\elecdel\ (don't forget the backslash at the end).

RemotePDFStorage: A Yes/No value that determines if the pdf files are stored in a separate directory from the default c:\inetpub\wwwroot\illiad\pdf\ folder on the server. If the pdf files are stored in a separate folder, then that folder must be shared as a Web Share of pdf (right click on the folder on the server and go to Properties to set up the web share).

UseOldElecDelForm: This key should be set to No. The new electronic delivery form has PDF conversion built into the client. In order to use the new electronic delivery form, be sure that these three files are in the ILLiad share (or the same folder where ILLiadClient is running) - CRDE2001.dll, ISP2000.dll, and wPDF010A.dll.

WebPDFPath: The location of the pdf files on the server. Normally it is the pdf folder in the illiad web folder - i.e. c:\inetpub\wwroot\illiad\pdf\ but if RemotePDFStorage is set to yes, it can be any folder on the server. This should be the same location as ElecDelPath, except from the perspective of the server (a local path).

SUMMARY

Electronic Delivery was originally designed for processing on the same machine as the Ariel workstation. The ArielPath would be a local directory on the electronic delivery machine where the incoming Ariel files are stored. The staff could then process those Ariel files in the ILLiad Client on the same machine and send them to the server for customers to download as pdf files.

There are, however, other scenarios that can also work for electronic delivery processing. Electronic delivery can be processed on multiple machines in the same office and even connect to different Ariel machines for incoming requests. Below are several examples for setting up electronic delivery on separate client workstations.

EXAMPLES

To allow one or multiple ILLiad client workstations to import requests from a single separate Ariel workstation, do the following steps:

1. Share the Ariel received folder on the Ariel workstation as a Windows share. ILL staff will need read and write access to this share to copy and delete the files. The Ariel received directory is typically c:\Program Files\RLG\Ariel\In\ for version 3 and higher of Ariel. Share the folder as "ArielIn", for example.
2. Change the ArielPath key in the Customization Manager to be the share created on the Ariel workstation. For example, the path would be set to "\\ArielMachine\ArielIn\" (don't forget the \ at the end of the path).
3. Each electronic delivery processing machine would need to have a c:\illiad\elecdel folder created in order to access the electronic delivery form in ILLiad. Any of those clients could then push the Process Electronic Delivery Files to import the Ariel files to that local client machine. The files would at that point remain on the individual client machine until moved to the server or printed. Timing would be key to insure that no two electronic delivery client machines are trying to import Ariel files at the same time.

To allow multiple ILLiad client workstations to import requests from multiple Ariel workstations, do the following steps:

1. On each Ariel workstation, share the Ariel received folder as a Windows share. ILL staff will need read and write access to this share to copy and delete the files. The Ariel received directory is typically c:\Program Files\RLG\Ariel\In\ for version 3 and higher of Ariel. Share the folder as "ArielIn", for example. The share can be the same name on each workstation or separate names.
2. On each electronic delivery processing workstation, map a drive to its respective Ariel workstation. Each electronic delivery workstation can only import from on Ariel workstation. But in this scenario, electronic delivery machine A can import from Ariel machine A while electronic delivery machine B can import from Ariel machine B. Make sure that the mapped drive letter is the same on each machine even though they are connecting to different shares. For example, electronic delivery A would map a drive X to \\ArielMachA\ArielIn\ while electronic delivery B would map a drive X to \\ArielMachB\ArielIn\.
3. Change the ArielPath key in the Customization Manager to be the mapped drive. In the previous example, the path would be set to "X:\" (don't forget the \ at the end of the path).
4. Each electronic delivery processing machine would need to have a c:\illiad\elecdel folder created in order to access the electronic delivery form in ILLiad. Any of those clients could then push the Process Electronic Delivery Files to import the Ariel files to that local client machine from their own Ariel workstation. The files would at that point remain on the individual client machine until moved to the server or printed. No imports would overlap as each client would only be interacting with one other workstation and the server. Requests at the status In Electronic Delivery Processing could be physically at any of the electronic delivery processing workstations.

MORE INFORMATION

Setting Up Electronic Delivery

SUMMARY

By default, the Electronic Delivery documents are stored in the c:\inetpub\wwwroot\illiad\pdf folder (or if you change the web root, the pdf folder is located inside the folder designated by the WebPath customization key). If you want to store these files in a different location, you have to make several changes.

SETUP

To use this option:

• Set the RemotePDFStorage key in the Customization Manager to "Yes".
• Set the WebPDFPath key to the location where the PDF files are stored on the Server (i.e. D:\pdf\ ).
• The ElecDelPath key should be set to the \\servername\sharename that maps to the path defined in the WebPDFPath key above.

Since the PDF documents are stored in a folder outside of the path of the Default Web Site (\inetpub\wwwroot\) a virtual directory will need to be created to point the ILLiad web pages to the location where the PDF documents are stored when the patron is accessing them. Here are steps to create the virtual directory:

• Open Internet Information Services (IIS) and right click on the web site that contains the ILLiad web pages, select "Create Virtual Directory".
• Name the alias "PDF" and set the directory path to the same path that was set in WebPDFPath. Accept the default access permissions (should include Read Only).
  

SUMMARY

This update assumes that you are at the latest versions of all components before updating to version 6.

The latest version for each component before this release is:

Client - Version 6.1.5.0
Web DLL - Version 6.1.2.0
Web Reports - Version 6.1.0.0
Customization Manager - Version 6.0.0.0
User Manager - Version 5.0.0.0
Server Automatic Updater - 6.0.0.0
Electronic Delivery Cleanup - Version 4.0.0.0
Connector - Version 6.0.2.0

Macros are not updated in this release so their version number is ignored.

When you first open the AutoUpdater, you will get a message about three keys missing: VersionGateway, VersionISO and VersionOpenURL. Click OK past these as the new AutoUpdater will create these keys. The first step is to update to the latest AutoUpdater. It should be the first update in the list and is version 6.2.0.1. Only run this one update as you will need the latest Updater to retrieve the rest of the updates.

Be sure to get the latest updater from the x:\illiad\setup\AutoUpdaterUpdates\6.2.0.1\ folder and replace it where you run the ILLiad Updater (usually c:\illiad\admin). Manually replace that file and there is no reason to reboot.

Run the new Auto Updater. You may be prompted to enter your ILLiad ISO Directory if it does not exist. Enter the directory where you have installed ISO services (generally c:\illiad\ISO\). Leave this value as the default if you are not running ISO services. The same is true for your OpenURL directory and your Connector directory. Go ahead and make a directory to match the value if you do not have these installed. This will prevent further errors from appearing everytime you run the updater.

NOTE: If you were not prompted for your ISO directory, Connector directory or OpenURL directory and you still see errors about keys not found for VersionGateway, VersionISO and VersionOpenURL, STOP NOW AND VERIFY YOUR UPDATER VERSION. You are most likely still running the old ILLiadUpdate.exe and your updates will not work with this version.

Verify all of the directories listed on the left. Be sure to verify the new Connector directory, OpenURL directory and ISO directory.

• The Connector directory is wherever you run the illiadconnector.exe (generally c:\illiad\connector\).
• The OpenURL directory is where OpenURL was installed and contains the ILLiadOpenURL.exe file (generally c:\illiad\OpenURL or c:\OpenURL).
• The ISO directory is where the ISO services were installed and contain the ILLiadGateway.exe and ILLiadISO.exe files (generally c:\illiad\ISO\).

If you are not currently using OpenURL or ISO, you can ignore those folders but you will also want to skip over those updates in the list of available ILLiad updates. Otherwise, the Updater will attempt to download and replace files that don't exist and you will get errors.

Check the boxes for all available updates that apply to you. If you would like to use Odyssey, but have not installed ISO on your ILLiad server, you will need to follow the instructions within the Odyssey Overview Manual for setting up the Gateway first before downloading the latest Gateway. You can run the Gateway update after installing Java runtime and the Gateway service. This will automatically replace the ILLiadGateway and CRDE2001.dll files. If you check the box to download the Gateway before installing Java and the Gateway service, you will need to manually update the ILLiadGateway.exe and CRDE2001.dll files. Details on this procedure are in the Odyssey Overview Manual (Chapter 5) on setting up Odyssey.

If the Updater can not replace a file that was downloaded, an error message will appear explaining to which folder the file was downloaded and where it was trying to replace the existing file. The download will continue but you will need to manually replace that file and verify the directory for future updates.

After the files have been downloaded and the database changes made, you will be prompted to reboot the server. This will complete the replacement of all the updated files. Those files for which you received errors will not be replaced automatically during the reboot.

After rebooting, check each of the files updated to be sure they are the correct version. You should also have a file in the same directory that is ILLiadFileName.exe.20030424163000.replaced where the string of numbers is the date and time the file was replaced. This was the file that was renamed and then replaced with the current file.

Continue with the update for Odyssey by installing the Odyssey Gateway. Instructions for this are in chapter 5 of the Odyssey Overview Manual.

MORE INFORMATION

Changes in ILLiad Client 6.2.0.1
http://portal.knowledgebase.net/article.asp?article=58611&p=1901

Changes in ILLiad Customization Manager 6.2.0.1
http://portal.knowledgebase.net/article.asp?article=58614&p=1901

Changes in ILLiad Auto Updater 6.2.0.1
http://portal.knowledgebase.net/article.asp?article=58618&p=1901

Changes in ILLiad Gateway 6.2.0.1
http://portal.knowledgebase.net/article.asp?article=58620&p=1901

Changes in ILLiad Web DLL 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58613&p=1901

Changes in ILLiad User Manager 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58615&p=1901

Changes in ILLiad Electronic Delivery Cleanup 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58616&p=1901

Changes in ILLiad Connector 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58617&p=1901

Changes in ILLiad OpenURL 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58619&p=1901

Changes in ILLiad ISO ILL 6.2.0.0
http://portal.knowledgebase.net/article.asp?article=58621&p=1901

What Ports are Required to be Open for General ILLiad Use
http://portal.knowledgebase.net/article.asp?article=46967&p=1901