ALEPH

New Functionality in Cataloging

New Fix Routines -fix_doc_new_aut_7 -- request via email to the FLVC Help Desk at help@flvc.org This new fix_doc program is used by MARC 21 libraries to create an authority record from the current bibliographic record (using the derive new record function). The new authority record is created based on 1xx, 6xx, and 7xx (same as fix_doc_new_aut_5 routine). fix_doc_new_aut_7 also works for subject fields cataloged in 69x fields (Hebrew subjects). With this new program, the authority record created will contain the text from the 69x field in the 159 field. FCLA NOTE: 159 is not a valid MARC21 authority tag. -fix_doc_track The new fix_doc_track fix routine is used to store the change history of bibliographic records in the new Z00T Oracle table.

New Functionality in Authorities

Enhancement of the Correct Heading Functionality
An enhancement has been made in all Aleph modules, under the Search > Browse option. It is now possible to correct headings of bibliographic records that have an associated authority record. Until now, the system did not allow the correction of headings that were associated with a bibliographic record as well as authority record. Only headings that were associated with a bibliographic record and not an authority record could be corrected. Now, the system shows the Correct Heading button as active and allows headings to be corrected even if they have an associated authority record.

AUT Record Link from Reference List

How do I run a global change using a restricted character (e.g., a question mark or comma)?

Answer: 

When you need to include a restricted character in the text for a global change (manage_21),
enter \% followed by the 2-character UTF-8 value for the character instead of the character.
for ? (question mark) -- enter \%3F
for { (left curly bracket) -- enter \%7B
for ' (apostrophe) -- enter \%27
for ` (spacing grave/grave accent) -- enter \%60 (that's a zero)
for ^ (circumflex) -- enter \%5E
for > (greater than) -- enter \%3E
for , (comma) -- enter \%2C

This covers all the characters that appear in the manage_21 error
message. If you run across more, refer to the Latin I Character Set
document at LC's site and use the value in the UTF-8 column:
http://lcweb2.loc.gov/diglib/codetables/42.html

New Functionality in AlephILL

FIXED - "Weird" due dates Bulk Receiving in Borrowing now carries the Expected Return Date forward, and the correct patron due date is calculated from that. • Expiry Date Calculation Borrowing library queries the supplier for a set number of days before the request expires. This table allows you to exclude non‐working days from the number of days

New Functionality in Circ

Changing Date on Multiple Loans Enables you to change the date on several loan items simultaneously • Item Status Filter (cir‐04, 06, 16, 50, 51, 52) and Recall Filter (cir-50/51/52) on Services Forms Patron Navigation Tab ILL Requests node has been enhanced to display information on the total yearly quota for ILL requests, as well
as how many requests have been used from the current yearly quota Rush Cataloging - *request via email to the FLVC Help Desk at help@flvc.org Patrons request expediting cataloging of an item in order to make it available for borrowing

What is the project to load e-doc records centrally?

Answer: 

In recent years, the Public Services Planning Committee (PSPC) and SUL government documents librarians have expressed interest in making federal documents that are freely available online accessible in all the library catalogs. The Technical Services Planning Committee (TSPC) currently is working with FCLA to make it a reality.

Here are some FAQs about the project:

What is meant by central loading of e-doc records?
What are these e-doc records?
Which records will be loaded?
How many e-doc records would be loaded per month?
Can just the e-doc records that match a library's GPO item profile show in its local Mango?
If there are two records for a title, one for the electronic version and another for the print or other tangible format, will the e-doc record still be loaded centrally?
Will the records be loaded into each library’s Aleph?
Can a library’s OCLC holdings be updated in WorldCat for the centrally loaded e-doc records in order to increase accessibility?
Will there be a retrospective load of e-doc records?
Can a library change its mind about whether to have these records display in its Mango?
What happens if a library continues to load into Aleph the e-doc records that match its profile?
Will the centrally loaded records appear in a library’s non-Mango discovery tool such as Summon? (updated 8/22/11)
How will routine maintenance be done to correct typos, update urls and subjects, and so on? (new 8/22/11)
Will authority maintenance be done on the records? (updated 8/22/11)
Will libraries be able to get collection statistics for the centrally loaded e-docs? (new 8/22/11)

What is meant by central loading of e-doc records?
Each month Marcive provides a single file of GPO records for the whole SUL. The records may be for documents newly available through GPO’s Federal Depository Library Program (FDLP) or updates to records previously issued. Each record contains one or more 049 fields, one for each library that is profiled to receive that particular category of federal documents. Each record could contain one to eleven 049 fields.

Currently staff at each library pick up the file from Marcive’s server. Using a GenLoad utility or other tool that reads the 049 fields, library staff identify their library’s subset of records for loading into the library’s Aleph. Most libraries use GenLoad to load the records; USF uses an Aleph loader. FCLA’s only role is to notify library staff when a file is available.

The proposed project is for FCLA to extract the subset of records for documents available online (e-docs) and load them centrally each month. The purpose as FCLA understands it is to expand access to these publicly available federal e-docs. This would be a new dataload service from FCLA.

What are these e-doc records?
These are records for federal documents distributed through the (FDLP) that are available online. Because UF is a full depository, the monthly Marcive GPO file includes records for all e-docs available through the FDLP. As of January 2011, Marcive’s license agreement permits sharing UF records among all the SULs (http://home.marcive.com/index.php?option=com_content&view=article&id=97&...).

Which records will be loaded?
FCLA will attempt to identify the records that describe only the online version of documents and load those. The records that describe multiple formats (e.g., print and online) will not be loaded. GPO now catalogs different formats on separate records so there shouldn’t be many, if any, records for multiple formats in the monthly GPO file.

How many e-doc records would be loaded per month?
An average of 1257 e-doc records were included in each monthly Marcive GPO file for January 2010-May 2011. This volume of records could possibly overwhelm the other catalog holdings of smaller institutions. Smaller institutions may want to consider this when deciding whether to include the e-doc records in their local Mango.

Can just the e-doc records that match a library's GPO item profile show in its local Mango?
This functionality does not currently exist in Mango. This would be a large development project that would need to be prioritized by CSUL.

If there are two records for a title, one for the electronic version and another for the print or other tangible format, will the e-doc record still be loaded centrally?
Yes, the e-doc record will still be loaded. FCLA will not attempt to restrict the e-doc load to “internet only” titles, as Marcive offers in its Documents Without Shelves product. As long as a particular record describes an e-doc and only an e-doc, it will be loaded centrally.

Will the records be loaded into each library’s Aleph?
No, the records will be loaded only once. FCLA will be looking at different load options. Loading the records into some shared Aleph bib library (along the lines of DLU01) is a possibility. This would support monthly loads of new and changed records and URL maintenance.

Can a library’s OCLC holdings be updated in WorldCat for the centrally loaded e-doc records in order to increase accessibility?
FCLA should be able to provide a file of OCLC numbers for each load, which library staff can use to update their library’s holdings in WorldCat.

Will there be a retrospective load of e-doc records?
No. The central loading would begin with the current month and continue from there.

Can a library change its mind about whether to have these records display in its Mango?
Yes, being able to turn the display on or off should be possible. It may be as simple as a parameter change.

What happens if a library continues to load into Aleph the e-doc records that match its profile?
The current plan calls for merging the e-doc records with the libraries’ Aleph records for Mango. This should avoid the display of duplicate records.

Will the centrally loaded records appear in a library’s non-Mango discovery tool such as Summon?
Yes. First it should be verified the mega-index itself does not include the e-docs. The e-doc records would be an additional record export. The details would be worked out with each library's vendor. (updated 8/22/11)

How will routine maintenance be done to correct typos, update urls and subjects, and so on?
If we follow the model used for another shared bib library, DLU01 for digital library records, certain staff at each SUL will be designated to help maintain the shared e-doc records. Another model is to designate a more limited group of library staff to maintain the shared records for everyone. A third model is for FCLA staff to maintain the shared records for everyone. However, because of organizational changes coming in 2012, FCLA is not prepared to commit to this. If central maintenance of the records is desirable, the libraries should suggest this as a service that the future organization provides. (updated 8/22/11)

Will authority maintenance be done on the records?
Authority maintenance on the shared e-doc records is an evolving issue. It does look like FCLA will need to support ARROW authority reports for the bib library where the e-doc records reside. (updated 8/22/11)

Will libraries be able to get collection statistics for the centrally loaded e-docs?
Yes, collection statistics for the centrally loaded e-docs can be included in reports for libraries who opt to display the records Mango. If call numbers are needed for the stats, this requirement should be included in the discussion about the environment for the centrally loaded records. (updated 8/22/11)

UBorrow Privileges

Each user processing UBorrow requests must be assigned an "ILL Unit" on the "User Password Information" window. This is the window that is opened when selecting a user in the user names list and then clicking on the "Modify User" button to the right.

Users must also be assigned specific permissions (Access Rights) under the XXX40 (ILL) and XXX50 (ADM) libraries.  This can be individually or through a "proxy".

Workstation Identifier

How to setup a Workstation Identifier

Loan and Return functions in Aleph are controlled by the Workstation IP address
or special Aleph Station Identifier, or Workstation Identifier.

Workstation Identifiers are useful when:
o Static IP address are not available/cannot be used
o Users want loan/return access at different workstations, ie., desktops &
laptops, inventory systems, etc.
To set up a workstation identifier, do the following:

1. In the Circ Client, right click on the Profile Key , located in the lower right hand side of the client.

2. Select “Set Workstation Identifier”, and enter a New Station ID. The ID can be any combination of characters (alphanumerics), up to 20 characters in length.

What to do if you encounter a problem with ret-adm-01 file too large error.

Answer: 

Contact FCLA and explain that your ret-adm-01 did not complete but generated a "file too large" error. Ask that the xxx50/scratch/ret_adm_01_2 file be deleted. The file will be very large and deleting it will allow ret-adm-01 to complete successfully once again.

How do I delete the locally saved copy (NEWXXX.MRC) of the BIB record that I edit in Aleph?

Answer: 

In Aleph, every time a BIB record is opened in the Cataloging module, a local copy is created on the PC. These locally copied records will accumulate on the PC until they are deleted. You may delete "all" of these records at once by using the Cataloging client menu option:

"Cataloging/Delete New* Records".

They may be viewed or deleted individually using the following menu option:

"Cataloging/Open Record on Local Drive"