[an error occurred while processing this directive] [an error occurred while processing this directive]

HOLLIS Newsletter

Volume 7, Number 2 (February 1992)

Subscription Info | OIS Contacts

  • Agenda for Liaisons Meeting
  • Notes from January's Meeting
  • Meet Linda, again
  • Bib record security change approved
  • Operator profiles fixed
  • FAXON training
  • Progress on security changes
  • Vendor file column to end
  • Format code displays
  • New search engine: NOTIS Search
  • Notes and Reminders
  • HOLLIS Statistical reports
  • Obsolete bibliographic fields
  • Fund fiche details
  • Major microform sets due
  • What the MERG command does not do
  • Keyword "near" fixed
  • Houghton drawings database
  • Response times
  • Network Notes
  • Should you replace old terminals?
  • More printers available

    Agenda for HOLLIS Liaisons Meeting #73
    February 12, 1992
    Lamont Forum Room, 2:30 - 4:00 p.m.

    1. Announcements: H. Reid
    2. Update on current Development Division projects: P. Caplan

    | Table of Contents | OIS Contacts |

    Notes from the January Meeting
    One more bow for Linda. Heather took the opportunity to re-introduce Linda Marean, OSPR's new Manager of Operations and Network Support, to liaisons who may have missed the December liaisons meeting. In this newly created position, Linda will oversee the daily operations activities of Kate Mullen and Lauren Caulton, and the network activities of Steve Thornton.

    Liaisons approve bibliographic record security change. Liaisons approved a recent proposal by the Bibliographic Standards Subcommittee regarding changes to security after the provisional tag set is removed from HOLLIS. This proposal stipulated that when assigning operator security, there would no longer be a distinction between different levels of bibliographic records. Under this proposal, operators would have full editing capability for bibliographic records at any encoding level or be restricted only to adding and editing LOCs (and the non-bibliographic records attached to LOCs). OSPR will move ahead and implement these changes this spring. If you have questions about this security issue, consult the related article in the January HOLLIS Newsletter or contact Robin Wendler in OSPR.

    Profile preservation fix -- one last time. Yes -- it's fixed! Operators will now receive the appropriate operator profile defaults for the database in which they are working. It is no longer necessary to perform a transaction in LTHU immediately after you signon in order to have your HU-specific defaults available while in the HU database. Further, any SET TAP or SET SCL defaults in effect when you switch databases will not be lost. However, LOC and SCR values that have been established by means of the SET command will be erased when you switch databases. Any location or screen type defaults that are part of your signon profile are preserved. If you observe anything strange (related to profile preservation, that is), please contact Heather Reid at OSPR.

    Faxon training at Harvard. Several representatives of the Faxon Company will be in Cambridge on January 14th and 15th to train Harvard library staff in the use of the Faxon DataLinx system. [In fact, the Faxon training went well, with over a dozen staff in attendance. Debbie Jensen and Debbie Bingham were pleased with the outcome and may consider scheduling this as an annual event. Thanks to all who participated. The Editor].

    Update on operator security changes for the BF database. OSPR is making progress in fulfilling the security change requests made by operators as a result of the availability of standard cataloging records in the BF database. Kate Mullen reports that nearly 90 percent of requests have been fulfilled and the rest should be completed shortly. If you have a question, please contact Kate Mullen in OSPR.

    Say goodbye to vendor changes in the newsletter. Liaisons agreed with OSPR's proposal to remove the "Vendor File Changes" section from the monthly HOLLIS Newsletter. Current vendor changes (new, inactive vendors, etc.) will continue to be posted on the EMS common messages bulletin board.

    Proposal for display of format codes in other databases. The article records in the AI, LR, and PA databases contain bibliographic data in HOLLIS format Y (article citation format). When these records display in the public catalog, there is no indication of their format, unlike scores or sound recordings, for instance, which have three-letter codes both in the indexes and single record displays (see example below).

    The Standing Subcommittee on User Services in HOLLIS (SSHUSH) has recommended that the code 'art' represent article format materials in record displays and indexes. A displaying article format code would have immediate impact on the PA database (PAIS International), allowing users to distinguish between article citations and book format records. One drawback noted by the subcommittee is that future HOLLIS databases may describe materials using the article citation format that are not truly journal articles. In such cases, the 'art' format code would be misleading. However, SSHUSH could not come up with a more satisfactory code.

    In addition, SSHUSH considered whether the format code for books, 'bks', should also appear in record displays and indexes. Currently, the 'bks' code is suppressed from display but is a valid format qualifier. Although SSHUSH endorsed the idea, not all liaisons were in favor. They consider the absence of 'bks' in record displays and indexes to be just as meaningful and for some staff members, it actually presents a less cluttered display. Those who favor the display are concerned that 'bks' may not be the best code -- why not 'bk' or 'b' instead?

    Heather pointed out that the issues in this discussion needed further examination. She urged liaisons to talk with other library staff about the display of 'art' and 'bks' and OSPR will revisit the issue this spring. If you have any questions or comments, please contact Kate Ellis at OSPR.

    NOTIS Search to be installed soon. Due to contractual agreements with NOTIS Systems Inc., Harvard is about to install new keyword search software -- called NOTIS Search -- to replace the BRS keyword search engine currently in use. The portion of the new software that affects online performance will be installed on Sunday, 12 January. NOTIS Search will have little effect on online keyword performance, although there are a few small changes that staff should know about. The portion of the new software that generates the keyword indexes will not be installed until after 1 March -- giving OSPR time to insure that online keyword performance runs smoothly under NOTIS Search.

    What changes will the user see?

    OSPR tests of the new software indicate keyword search response time is slightly slower and computer resource usage is somewhat higher than our current software. For most keyword searches, the difference will be imperceptible to users. However, users will now be required to use a minimum of three characters when truncating keyword searches -- since deeply truncated searches are guaranteed to cause extremely poor response time under NOTIS Search. HOLLIS will display an error message if a search contains less than three letters followed by the question mark truncation symbol (e.g., find kw tr?).

    The WS operator (within sentence) has been changed to WF (within field). WF functions the same as WS, that is, you use it to search for keywords occurring in the same field. However, WF is able to find words in the same field that are separated by a period -- something that WS could not do. And don't worry, if you type WS by mistake, HOLLIS will assume WS is a synonym for WF. We will not see this improvement in WF performance until all keyword indexes are regenerated in March, but WF will be available starting 12 January.

    What NOTIS Search did not provide.

    OSPR had hoped that the NOTIS Search engine would bring some improvements to HOLLIS keyword searching, but aside from the few changes mentioned above, NOTIS Search is very similar to the original BRS search engine. NOTIS Search in its original form does allow qualification of keyword searches, but in our system this caused absolutely miserable response time (20 minutes or more) and we therefore abandoned this feature. Heather noted that not only was response time degraded, but all other HOLLIS searches would queue up behind the qualified keyword search, waiting for it to finish. Poor response time is the reason why OSPR also abandoned increasing the maximum number of keyword search hits from 250 to some higher number . And lastly, HOLLIS keyword indexes will continue to be arranged by publication year and HOLLIS record number rather than by publication year and title, since SSHUSH preferred the present arrangement where the most recent items appear at the top of the index.

    Heather reminded liaisons that OSPR never envisioned this project as the long hoped for keyword search enhancement, but merely the replacement of one search engine by another similar engine due to contractual agreements. As NOTIS makes improvements to this search engine, OSPR will revisit possible enhancements at a later time. Rest assured that OSPR will closely monitor developments in this area.

    Since 12 January the new and not so improved keyword search engine seems to be working smoothly. The only wrinkle (so far) -- not being able to use the word "near" as a keyword -- has been fixed. However, staff should report anything unusual to OSPR. When March arrives, OSPR will notify staff when keyword index regeneration (using the new search engine) commences.

    | Table of Contents | OIS Contacts |

    Notes and Reminders
    HOLLIS Statistical Report lives once again. Starved for statistics? Dying for data? Rejoice --the HOLLIS Statistical Report has returned after a year's hiatus. This Report contains summary and detailed data describing HOLLIS system growth, performance, and activity. OSPR plans to publish this statistical data regularly (probably quarterly) and distribute copies to library managers and HOLLIS primary liaisons. The first issue covers HOLLIS system activity from October to December 1991. (Note that HULPR system activity is not part of these reports.) OSPR also plans to produce reports covering the other three quarters of calendar year 1991. These retrospective reports will be available upon request from Eric Young in OSPR. OSPR will announce in EMS common messages when the retrospective reports become available.

    Since printing of the October-December 1991 issue coincided with the appearance of the February HOLLIS Newsletter, liaisons will receive their copy of the Statistical Report with the newsletter shipment. Managers will receive their copies in a separate mailing. Liaisons should insure that this report is circulated to all interested staff in their units. If you have a question about this report or its distribution, please contact Eric Young in OSPR.

    Change to bibliographic fixed field. The fixed field elements MEB (main entry in body of entry designator), TP (title page availability; serials), INDX (index availability; serials), and CUMUX (cumulative index availability; serials) are now obsolete in the USMARC format for bibliographic data. OSPR also plans on invalidating these elements in the HOLLIS MARC format during the week of 27 January. Invalidation means that these elements will no longer display in HOLLIS technical services mode records. Specifically, OSPR will eliminate MEB in both HU and BF records; TP, INDX, and CUMUX will be removed from all serial format records in HU.

    Until they become obsolete, these elements still require valid values on HOLLIS bibliographic records. In particular, staff who derive, migrate, or merge BF records into the HU database will need to add a fill character to the MEB element in HU in order to successfully file the record. After these elements become obsolete, this step will not be necessary. Staff who use keyboard macros to input fixed field data on bibliographic records should examine these macros to make sure they function properly once OSPR changes the fixed field display. OSPR will announce the removal of these elements on the EMS common messages bulletin board. If you have questions, please contact Robin Wendler in OSPR.

    'Payments by fund' fiche. On 9 January OSPR distributed (to those units with subscriptions) the year-to-date fiche of:

    Jul 1 - Dec 31, 1991

    Please notice that the format of this report has been changed slightly; the information provided, though, is basically the same. We regret that, because of software and hardware changes, we were unable to provide this fiche in recent months. This new style report will again be distributed, free of charge, every month.

    Please review your subscription requirements for this product. If you rarely need this information, you might wish to consider relying on the kindness of one of the larger units to provide it for you when necessary. If you would like to reduce or cancel you subscription, please contact Kate Mullen in OSPR.

    CRL and LAW major microform records in HU. Over the last few weeks OSPR has been loading large numbers of records into the HU database. As of 13 January we have completed loading 39,352 records cataloged by the Center for Research Libraries (CRL) in OCLC last year (both monographs and serials), as well as 3,150 records for the Law School's International Law Microfilm (ILM) set. Loading of approximately 19,000 records for the American Theological Library Association on behalf of the Andover-Harvard Theological Library is ongoing.

    What the new MERG command will not do. OSPR designed the MERG command to merge a BF record with an HU book format record. MERG, as in the following example--

    • LTHU MERG [HU target record/check digit] [BF source record/check digit]
    • LTHU merg abc1234/7 aac8765/3

    assumes that the second number represents a BF record so that the operator does not need to indicate the source database in the command. This works fine for staff who are supposed to be MERGing records from BF into HU.

    MERG is not designed to combine bibliographic records for any other purpose. The problem is, a staff member authorized to use MERG who mistakenly tries to MERG an OW record with an HU record will not receive an error message -- HOLLIS assumes the second number represents a BF record instead of an OW record, and if BF contains such a number, the merge will proceed. If the staff member does not check his/her work and files the record, "poof" there goes a BF record. Luckily, we can avoid this ugly scenario by giving MERG authorization only to those staff members trained to work with BF records. Staff members who need to combine two records in HU for some other reason (migrating from OW or duplicate resolution, for example) should use the MLOX (move locations), MRGL (merge locations), and (perhaps) the ENHB (enhance bib) commands. All three commands are described in the HOLLIS Reference Manual. If you have any questions about MERG or any other HOLLIS command, please contact Julie Wetherill at OSPR.

    Keyword search for "near". The problem with issuing a keyword search that involves the word "near" has been corrected. It is, once again, possible to search by keyword for the word "near", it is no longer necessary to truncate near to zero characters (i.e., find kw near?0). If you encounter anything unusual with keyword searching (now that there is a new keyword search engine in place) please call Kate Mullen in OSPR.

    Houghton drawings database in HULPR. Staff in Houghton's Department of Printing and Graphic Arts are in the midst of creating a database of drawings -- called the VS database -- which is available in HULPR technical services mode. Using the transaction identifier LTVS, library staff can perform author (FIND AU), title (FIND TI), subject (FIND SU), or call number (FIND CO) searches to find both collection-level and item-level records. The project is scheduled for completion in approximately two years and at some point VS may become available to the public.

    For a very fine article that describes this project in detail, please consult page two of the January 9 Harvard University Library Notes (issue no. 1041).

    Response time tests. Response time tests are scheduled for the first Tuesday of each month. Upcoming tests are scheduled for: 3 March, 7 April, and 5 May. Volunteers should mark their calendars appropriately.

    The response times reported in the test given on January 7th were higher than in recent months, but not severely so. There was a marked increase in the number of long searches: searches of four seconds or longer were up from 0.8 percent of all searches last month to 6.9 percent this month; searches of two seconds or longer were up from 12.5 percent in December to 23.1 percent in January.

    These figures are (barely) the worst results in the last two years for these tests. This is not really a cause for alarm, but it bears watching. If February's results show a continued deterioration in performance, further investigation may be warranted.

    | Table of Contents | OIS Contacts |

    Network Notes--by Steve Thornton
    Thinking of Replacing Your Old Terminals? In the course of answering questions about terminal and communications costs for the recent round of budgeting, I have heard several administrators ask if it is time to begin replacing their old HOLLIS terminals with new models. They have heard a rumor that you should replace your PCs and terminals after about three years, or when they start showing signs of needing frequent repair. Fortunately for Harvard libraries' finances, this rumor is in most cases completely erroneous. The oldest terminals in the HOLLIS system are the last remaining Telex 476L terminals in the Countway Library of Medicine, which are almost seven years old. The oldest IBM 3151/3163s are approaching their fifth birthday, and most of them are more than three and still going strong.

    In addition, Harvard has negotiated excellent maintenance contracts with IBM for our terminals. While the Telexes cost more than $300 a year to cover, and that only covers repairs, not replacements, and most PC service contracts cost a similar amount, the IBM contracts cost about $50 per year, and provide for replacement of any failing component. This means that if your terminal's monitor or keyboard blows up, IBM will bring you a new one, usually in a day or two. While this maintenance charge has been going up a little over the years (from $20 to $50 since 1987), it is always going to be a lot less than the $600 + for a new machine.

    Naturally, machines not covered by IBM maintenance contracts are a different story. If your library has Telex terminals or PCs in use as terminals, you may indeed want to consider replacing them as they get old. You should also keep in mind the future of the HOLLIS network. This is somewhat difficult to do, since we don't know what that future is, or when it is coming. However, you can safely make some assumptions: the future is likely to be based around desktop workstations (what used to be called "PCs"), and it is likely to make use of wider networking technologies, such as the HSDN. This doesn't mean that you should run out and buy a raft of monster PCs to replace all your dumb terminals today. It does mean that you might want to start doing that gradually in several years' time, which is another reason for not investing large sums now in dumb terminals that may be no more useful in the future than the ones you have now.

    As always, I will be more than happy to answer your budget questions. I hesitate to simply publish the costs here in the newsletter, because the situation in each library is different, and the cost for a single terminal can vary dramatically depending on whether you have any mux ports available, for example. So just call.

    Printer Availability Update. I have received from our vendor the welcome news that there are more than 175 Canon BJ-80 printers in Canon's New York warehouse. He's not sure how they got there, since six months ago they only had 75, and they've stopped making them, but Canon works in mysterious ways. Since academic libraries are pretty much the only customers for this exact model, this means that we undoubtedly have enough printers available to us to satisfy our needs for the next year at least. So any fears I may have raised last month about running out of printers can be put to rest for now.

    | Table of Contents | OIS Contacts |

  • [an error occurred while processing this directive]