Data Migration Questionnaire for Dynix Sites

Transcription

1 Data Migration Questionnaire for Dynix Sites Note: You should fill out this questionnaire only if your institution is migrating data from the Dynix automated library system release 143 or later. This questionnaire describes the functionality of our Dynix data extraction and Voyager load programs. It details the standard options available to you for migrating your data from Dynix to Voyager, and allows you to describe the practices you have followed in your Dynix system. When you have completed this form, please return it to your Project Manager. Please provide the following information: Institution: Contact Person: Telephone Number: Fax Number: Date Returned: Pacific Lutheran University Layne Nordgren cell: April 26, 2001 Endeavor Information Systems, Inc E. Devon Ave., Suite 382 Des Plaines, IL (847) FAX (847) Date Received: For Endeavor Use Only: By: Page 1 of 26

2 I. SUMMARY The standard Dynix migration package can extract the following types of data from your Dynix system: 1. Bibliographic (from the BIB and MARC.BIB files) 2. Authority (from the MARC.AUTH.SUBJECT, MARC.AUTH.SERIES, and MARC.AUTH.AUTHOR files) 3. Copy record (from the MARC.HOLD and PROCESS files) 4. Item (from the HOLDINGS file) 5. Patron (from the PATRON and PURF files) 6. Charge transaction (from the CIRC.OUT file) 7. Current patron fines and fees (from the PURF file) 8. Course reserve instructors (from the INSTRUCTOR.AUTHORITY file) 9. Vendor (from the VENDOR and VEND.ADDR files) 10. Open orders (from the ORDERS file) 1 This questionnaire will describe each of these extractions in more detail as well as the standard options that are available. Please answer the questions as fully and accurately as possible. If you are unclear about anything discussed in this document, please do not hesitate to ask your project manager about it. If you should have any special requirements not within the range of options listed in this questionnaire, you may wish to order custom programming to alter the extraction software. However, please note that custom programming is billable. Requests for custom programming should be discussed with your project manager. 1 Note that there is an extra charge to perform an open orders migration. Consult with your project manager for more information about the open orders load. Page 2 of 26

3 II. TABLE OF CONTENTS This questionnaire is divided into the following sections: I. SUMMARY...2 II. TABLE OF CONTENTS...3 III. General Questions and Request for Access...4 IV. Multiple Libraries...7 V. Bibliographic Records...8 VI. Item Records...9 VII. Serial Copy Records...14 VIII. Authority Records...17 IX. Patron Records...18 X. Charge Transactions...20 XI. Fine/Fee...21 XII. Vendor Records...22 XIII. Open Orders (Extra cost)...23 XIV. Fund Mapping for Open Orders (Extra Cost) 22 XV. Serials Patterns 23 XVI> Holds/Recalls 24 Page 3 of 26

4 III. General Questions and Request for Access Platform What version of Dynix are you currently running? 180 What version of UniVerse or PICK is Dynix running on? 9.4 What is the underlying operating system of your Dynix system (e.g., AIX, HPUX, etc.)? Compaq True 64 Unix v. 4.0D Please describe the hardware platform that Dynix is running on. It would be helpful if you attached the output of lscfg v (for AIX systems) or an equivalent command that displays the hardware of your Dynix server. see system diagram and devices pages FAXed on How much free disk space is available on your Dynix server? Please attach a copy of the output of DUR (Disk Usage Report), which is a utility found in the Dynix EXEC module. If possible, we would prefer that your data be sent to your Voyager server via FTP, which means that the extracted data reside on your Dynix server temporarily. Also, if you are planning to use an NFS-mounted file system to store the extracted data, please note that fact below. DISK USAGE REPORT for Robert A. L. Mortvedt Library. 24 APR 01 Filesystem 512-blocks Used Available Capacity Mounted on /dev/rz1a % / /dev/rz1g % /usr /dev/rz1h % /temp /proc % /proc /dev/rz2d % /uv /dev/rz2e % /dnx /dev/rz3g % /dnx1 /dev/rz0g % /dnx2 /dev/rz2a % /oldroot /dev/rz0f % /oldusr /dev/rz6c % /cdrom Server Connection Information and Accounts We would prefer that Endeavor staff be granted access to your Dynix system so that we can install and run the extraction programs. However, it is also possible for you to install and run the extraction software with the assistance of Endeavor staff. If you decide to let Endeavor do the extraction for you, please complete the following: Please specify how we may connect to your Dynix server: X Telnet Page 4 of 26

5 Host name or IP address (e.g., library.university.edu): library.plu.edu ( ) prefer secure shell connection (ssh) x Modem Connection Phone Number: (off unless needed) Baud Rate: 9600 Parity: N Data bits: 8 Stop bits: 1 Other connection (please give full details): A special Dynix account will need to be created for the extraction. The account should have access to the following: Level 6 access to these modules: Cataloging for all agencies to be migrated Circulation for all agencies to be migrated Reserve for all agencies whose course instructor lists are to be extracted Access to the RECALL/TCL prompt Access to the Unix shell Working FTP client on the server The account should not have access to the following: Access to any modules other than those listed above Root privileges. Note that the exec account has root privileges. If Endeavor will be performing the extraction, please supply the following about the account: Unix login account name: Unix login account password: Please call for this info; account will be unlocked and locked as needed Dynix account user id: Dynix account password: Please, provide complete step-by-step guide how to get into the Dynix system if after entering Unix account name/password system does not bring user to it automatically. For example, from Unix shell user might type the following command to get into Dynix system: $> /user/local/bin/dynix account will log into Dynix shell Please use ssh level 1 for all connections. You may have to specify the path as /usr/bin Data Transmission We would prefer use FTP to transfer data from your Dynix server to Endeavor and to your Voyager server. If necessary, we can accept tapes. Page 5 of 26

6 X Use FTP to transmit the data. Use tapes to transfer the data. If you selected this option, please specify the type and format that you will use. Number of records Please give an estimate of the number of each type of record you will be extracting from your Dynix system. If you are also migrating records from a source other than Dynix (e.g., records from an authority control vendor or a retrospective conversion project), please attach a list of the sources and the approximate record counts. Bibliographic: 248, 461 (all figures as of ) Authority: Name: 311,207; Subject 249,400; Series: 27,907 Item (i.e., Dynix HOLDINGS records): 380,299 Serials copy records: Patron: 2,565 18,124 Charge transactions (i.e., number of items checked out): 6,625 Vendor: Open Orders: 833 1,630 (standing) Scheduling Do you have any restrictions on file sizes? no Do you have any restrictions on when batch jobs should be run? no If so, please describe: When is your Dynix system backed up? Weekdays 4:00am to 7:00 am PDT Page 6 of 26

7 IV. Multiple Libraries One Dynix catalog can store the information for multiple libraries and/or branches. In general, these libraries and branches can be migrated into one Voyager database or into separate databases. 1. Yes Are you migrating a single Dynix catalog to a single Voyager database? If you answer yes to this question, please skip the rest of this section and continue on with the next. Please note that the owning library feature of Voyager allows two or more catalogs to reside in a single Voyager database while still preserving access control boundaries between their records. 2. Are you splitting a single Dynix catalog into two or more Voyager databases? 3. Are you combining multiple Dynix catalogs into a smaller number of Voyager databases? Splitting and Combining 4. Please list the names of the Voyager databases that you will have after the splitting and/or combining take place (e.g., Main Library, Law Library, Branch Campus, etc.) PLU Library For each of the resulting databases, please indicate how to determine which bibliographic, copy, and item records from your Dynix catalog should be chosen to go into that database. The criterion could be in the form of a list of collection codes for that database, an agency codes, or a RECALL statement. The criteria you provide for each database must meet the following requirements: The criteria must select all of the records to go into that database. The criteria must select only the records to go into that database. The criteria must ultimately be expressed in the form of a RECALL statement or statement(s) that select records from the BIB, MARC.HOLD, HOLDINGS, and PATRON files. Endeavor staff can assist you with the construction of these RECALL statements. For each database, please duplicate the following sections of this questionnaire and fill them out. Please make sure to clearly indicate the database name on each copy of the questionnaire. Note: We may charge you for custom programming depending on the complexity of the splitting or merging that you wish to do. The PLU Library database will include records from: All Dynix BIB records with the exception of media equipment extracted to the Media Scheduling module PLU Index (Community Resource Newspaper Index) PLU Photo Index (Access Database) Archives EAD XML records We have already sent samples of these records Page 7 of 26

8 V. Bibliographic Records Modifications to Bibliographic Records Please note that the following changes will be made to the USMARC bibliographic records during extraction and migration. For more information, see section 3.3 of the Dynix Data Extraction Manual. The existing contents of the 001 field will be moved to a new 035$a. A new 001 field with the Voyager bib ID will be added. The 003 field will be stripped from all records. The 005 field will be stripped from all records. A new 035$9 will be created containing the Dynix bib number. The 035$9 can be searched in Voyager. Since the holdings and item information associated with each bib record will be stored in 949 fields during migration, any 949s that existed before migration will be stripped. Options 5. No Have or will you send your bibliographic records out for authority control processing. If so, please attach a copy of the processing specifications to this questionnaire and include a completion date. 6. No Have or will you order smart barcodes for your collection? If yes, please include a completion date. 7. Which of your bibliographic records do you want to extract from Dynix? Please check only one of the four options. Extract all bibliographic records Extract the bibliographic records that are on a list of bib keys. This list, called an include file, must be an ASCII file with one bib key per line. The include file can be in the form of a RECALL select list. X Extract the bibliographic records that are not on a list of bib keys. This list, called an exclude file, must be an ASCII file with one bib key per line. The exclude file can be in the form of a RECALL select list. Use a RECALL statement (such as a SELECT or a GET.LIST) to choose the bibliographic records to extract. If you choose this option, please provide the RECALL statement: 8. Yes Brief bib records (i.e., short bibs and fastadds) can be upgraded to USMARC format and extracted. Do you wish to extract brief bib records and their holdings? Yes 9. No If you have chosen to extract brief bib records, do you want them to be suppressed from OPAC display after migration to Voyager? Page 8 of 26

9 VI. Item Records The transfer of holdings and item information from Dynix to Voyager is perhaps the most complicated part of the entire migration. In this section we will explain how this information is loaded into Voyager, describe the location mapping file, and describe the options available to you for migrating item information and serial copy records. Loading Process for Monographic Titles A typical monograph will be represented in Dynix by a bib record and one or more Dynix HOLDINGS records. For the same title, Voyager will use a three-level representation with a bib record, one or more MFHDs, and one or more item records. During migration, the holdings-level information in the Dynix HOLDINGS record will be migrated to a MFHD, and the item-level information will be migrated to an item Dynix Voyager Bib record Bib record MFHD Holdings record Holdings record Item record Item record record. The migration process will create one Voyager item record for each Dynix HOLDINGS record. For a given bib record, a MFHD will be created for each distinct combination of collection code, call number, and copy number present in the attached Dynix HOLDINGS records. An item record will then be attached to the MFHD with a matching collection code, call number, and copy number. During a normal extraction from Dynix, a 949 field will be added to the bib record for each Dynix HOLDINGS record attached to it. These 949 fields will contain such information as the call number, item barcode, collection code, copy number, etc. Note that any 949 fields that were present before the extraction will be removed. When we receive the file of bib records with 949 fields, we run a program called bibconvert that creates the MFHDs and transfers the item-level information to 949 fields in the MFHDs. The bib records, now stripped of their 949 fields, are then loaded into the Voyager database. Then, the MFHDs are loaded, and an item record is created for each 949 field in the MFHD file. The 949 fields are then stripped from BIB record BIB load BIB record BIB record 949 c c c c.2 Bibconvert MFHD 949 c c c.1 MFHD 949 c.2 MFHD load MFHD Item Item MFHD Item Item the MFHDs. Page 9 of 26

10 Location/Item Type Mapping File During the loading process, Dynix collection codes will become Voyager permanent location codes, and Dynix item type codes will become Voyager item type codes. The location/item type mapping file is used to map from the Dynix collection code and item type to the Voyager permanent location and item type. The mapping file has four columns: Dynix collection code, Dynix item type, Voyager item type, and Voyager location code. Here is an example of some entries from a typical location mapping file. The file you create for your institution should be given to your project manager as an Excel spreadsheet. Note that the Voyager item type and location codes cannot exceed ten characters in length. Dynix collection code Dynix item type Voyager item type Voyager permanent location MAIN BOOK MONO CIRC PER P PER PER PERMF MF PER MICROFORM Classification Scheme, Call Number Hierarchy, and Smart Barcodes The mapping file should include an entry for each Dynix collection code and item type present in your database. Besides providing the Voyager item type and permanent location that the collection code and Dynix item type should be mapped to, you should also specify the classification scheme and call number hierarchy. The classification scheme of the call number from the HOLDINGS record needs to be specified for the database load. The values in the following table should be used to identify the correct scheme. Code Classification Scheme 0 LC 1 Dewey 2 NLM 3 SUDOC 8 Other If a call number is not stored in the HOLDINGS record call number field, it can be taken from the bibliographic record using the call number hierarchy. The basic pattern for this hierarchy is [xxx] or [yyy] or [zzz] where xxx, yyy, and zzz are call number fields in the bib record. For example, if your call number hierarchy is as follows: 099, 090, 050; the display hierarchy is: If the 099 field is found with data, it is indexed and displayed as the call number. The 099 field is repeatable. In the situation where there are multiple 099 fields, the database loader program will use the last occurrence. If the 099 field is not found or is empty and the 090 field is found with data, then the 090 field is indexed and displayed as the call number. If neither the 099 field or 090 field are found or both are empty, and field 050 is found with data, then the 050 field is indexed and displayed as the call number. If neither 099 field, or 090, or 050 are found (or all three are empty), then no call number is indexed or displayed for that record. Note that there may be one or several choices in this indexing and display hierarchy. However, only one call number field will be indexed and displayed regardless of the number of entries in the hierarchy. You should specify HFO (holdings field only) if the call number should be taken from the HOLDINGS record for that collection and item type. Complete the smart barcodes column only if you have contracted with Endeavor for smart barcode labels. For each location/item type combination you have the option of specifying smart label production. If you do not want smart labels for a particular combination (for example, a microform collection), place an N in this column. Place a Y in each column for which you would like smart labels produced. Here is an example of the table specifying classification scheme, call number hierarchy, and smart barcodes. Page 10 of 26

11 Dynix collection Dynix item type Classification Call number Smart barcodes scheme hierarchy MAIN BK 0 HFO Y GOVDOC DOC N PER PER 1 082, 092 N Options Mandatory item record data elements The following fields in the Dynix HOLDINGS record are always migrated to corresponding fields in the Voyager item record: Collection code (to Voyager permanent location) Call number Optional item record data elements Several data elements from the Dynix HOLDINGS record may be migrated to corresponding fields in the Voyager item record. Please specify which of the optional fields you want migrated. 10. Yes Migrate item barcode? 11. Yes Migrate historical charges (checkouts) count? 12. Yes Migrate item type? 13. Yes Migrate general and checkin notes fields? 14. Yes Migrate item price? Enumeration, Chronology, and Copy Number During extraction, you can have various enumeration tags such as v., vol., no., and pt. normalized. This means that if these tags occur in the HOLDINGS record copy field in upper or mixed case (e.g., V., VOL., or even vol. ), they will be converted to lowercase during extraction. Note that normalization can take place whether or not the copy field is parsed. 15. _Yes Do you want to normalize the numeration? You can choose to have the HOLDINGS record copy field parsed into enumeration, chronology, and copy number. For example, if the copy field contains v c.3, the extraction program can recognize that the enumeration is v.2, the chronology is 1998, and the copy number is c.3. If you choose to parse the copy field, you can then choose to migrate the enumeration, chronology, and copy number to the corresponding fields in the Voyager item record. Parsing may also affect how item records are linked to Dynix copy records. 16. Yes Do you wish to parse the HOLDINGS record copy field into enumeration, chronology, and copy number? If you have chosen to parse the copy field, please answer the following three questions: 17. Yes Do you wish to migrate the parsed enumeration to the Voyager item record enumeration field? 18. Yes Do you wish to migrate the parsed chronology to the Voyager item record chronology field? 19. Yes Do you wish to migrate the parsed copy number to the Voyager item record copy number field? If you have chosen not to parse the copy field, please answer the following question: 20. N/A Do you wish to migrate the copy field to the Voyager item record freetext enumeration/chronology field? Need to parse call number into two fields for those with collection code prefixes as discussed in Orientation session. The collection code would go into subfield k. See attached list of possible call number prefixes. Page 11 of 26

12 Call Number Prefixes and Iterations ARCH PHONO CDROM COMPDK CURRREF curr.ref. currref. CURR curr. curr DVD ELCA FILM JUV juv. juv REF ref. ref SLIDES slides. slides SPEC spec. spec VIDEO video. video VIDISK vidisk. vidisk Item statuses You can choose to migrate the Dynix item status to an equivalent Voyager item status. Since Dynix allows you to create item statuses but Voyager does not, you may have Dynix item statuses that do not have Voyager equivalents. You can also choose to migrate these statuses to Voyager temporary locations. 21. _Yes Do you wish to migrate item statuses? If you have answered Yes to the last question, you must create an item status map that maps from the Dynix item status to a Voyager item status and/or a Voyager temporary location. For each Dynix item status that you wish to map, you must provide a valid Voyager item status code and/or a temporary location code. Here is the list of valid Voyager item status codes: Voyager Item Status Meaning Code BIND At bindery CAT Cataloging Review CIRC Circulation Review CLMR Claims Returned DAMA Item Damaged LOSL Item lost library applied LOSS Item lost system applied LOST Item lost library applied MISS Item missing WITH Item withdrawn And here is a sample item status mapping. Note that the temporary location code must be ten characters or less in length. Page 12 of 26

13 Dynix Item Status Code Voyager Item Status Code Voyager Temporary Location Code B BIND NBA NewBooks FLOODED DAMA FloodBooks Note that you cannot use the item status mapping file to set the status of an item to Charged or Checked out. This can only be done via the charge transactions load. Item statistical categories You can migrate the Dynix item statistical code to the Voyager item statistical category. 22. _Yes Do you wish to migrate item statistical codes? If you have answered Yes to the last question, you must provide an item statistics map that maps from the Dynix item statistical code to the Voyager item statistical code. Only the item statistical classes you define in UIS can be migrated the call number table codes cannot. Note that the Voyager code may not be longer than three characters. Here is a sample item statistical code mapping: Dynix Item Statistics Code Voyager Item Statistical Category GERMAN GER BOOKS BK MATH MTH Page 13 of 26

14 VII. Serial Copy Records Note: The term holdings record does not mean the same thing for Voyager and Dynix. A Voyager holdings record, also known as a MFHD (MARC Format Holdings Display), is a record in MARC Holdings format that stores data elements such as the permanent location and call number. A Dynix HOLDINGS record stores both holdings- and item-level information, including permanent location (or collection code), call number, and item barcode. Information from a Dynix HOLDINGS record will be migrated to both a MFHD and a Voyager item record. To avoid confusion, in this questionnaire a Voyager holdings record will always be referred to as a MFHD, and a Dynix HOLDINGS record will be referred as a HOLDINGS record. Overview Dynix uses the copy record to store serials-related information such as summary holdings, publication patterns, subscription information, routing lists, and so on. A copy record is stored in two parts: a MARC.HOLD record in MARC Holdings format that contains the summary holdings and publication patterns, and a PROCESS record that stores serials processing information such as the subscription number, price, routing lists, etc. The copy records can be extracted, converted to full MARC Holdings format, and loaded as Voyager MFHDs (which we will call copy record MFHDs to distinguish them from the MFHDs created from the item information). If Dynix HOLDINGS records are also present for individual issues, under certain circumstances these can be migrated to item records attached to the copy record MFHDs. Options 23. Yes Do you wish to migrate Dynix copy records? Note that if you do not have the Dynix Serials module, you will not have any copy records to migrate. 24. No If you answered Yes to the previous question, do you want to suppress the copy records from display in the OPAC? This is only advised if you do not want to attempt to link item and copy records. If you have decided to migrate Dynix copy records, please fill out the rest of this section. Item/Copy record linking If you use Dynix to create HOLDINGS records during serials checkin, these HOLDINGS records are logically linked to the copy record containing the publication pattern under which the serial was checked in. You can choose to have Voyager retain the link when the copy record and HOLDINGS records are migrated to MFHD and item records, respectively. However, you should be aware that for various reasons, a HOLDINGS record can point to the wrong copy record. The extraction program will not attempt to migrate a link if the collection code of the copy record does not match the collection code of the HOLDINGS record. Since MFHDs will be automatically created during migration for unlinked HOLDINGS records, a potentially confusing situation could arise. For example, one MFHD (derived from a Dynix copy record) could list holdings for (say) vol.1-120, while a second MFHD (automatically generated from HOLDINGS records that for some reason could not be linked to the Dynix copy record) could list vol. 1, 15, and 119. This could give patrons the incorrect impression that you hold multiple copies of some items. Alternatively, you can elect to have the extraction program try figure out how to link the items and MFHDs for a serial by comparing the permanent location and call number of the item and copy records. For example, suppose that you hold Journal of Cell Biology in both loose issues and bound volumes. You might have two copy records attached to the bib record for the Journal, one in the Periodicals collection and one in the Bound Periodicals collection. If you barcode your loose issues and bound volumes, then a number of item records (i.e., Dynix HOLDINGS records) will be attached to the bib record. During extraction, those item records in the Periodicals collection whose call number matches that in the Periodicals copy record would be linked to the MFHD created from the copy record. Similarly, the item records in the Bound Periodicals collection whose call number matches that in the Bound Periodicals copy Page 14 of 26

15 record would be linked to the MFHD created from that copy record. If there are any item records left over that do not match the collection and call number of one of the available copy records, they will be attached to MFHDs automatically created during the loading process. For a given bib record, the extraction program will not attempt to link items and copies if there exists two or more copy records in the same location. This is because the extraction program has no way of knowing to which copy record an item record in the collection should be linked. Also, an item record will not be linked to any copy record if the item record is part of a copy other than copy one. Third, the extraction program can link item and copy records if the location, call number, and copy number are the same in both records. Finally, you may choose not to attempt to link item and copy records. If you choose this option, you may want to consider suppressing the copy record MFHDs from the OPAC. To summarize, if you choose to migrate your copy records, you have four options with respect to linking item records: Do not attempt to link items and copy records. The item records will be linked to MFHDs automatically created during the loading process, while the MFHDs derived from your copy records will not have any items linked to them at all. This is the most conservative option because there is no chance of incorrect links being established between items and copy records. On the other hand, choosing this option may mean that you will have to manually relink your items and MFHDs for all of your serial titles. Link items and copy records by following links already present in Dynix. If you have used Dynix to check in all or almost all of your serial holdings (including those received before you came up with Dynix), this option may be best for you. However, if a large proportion of your serial items were not linked to copy records in Dynix, they will not be linked after migration. This may mean that you will have to do manual relinking after migration. Link items and copy records by matching on location (collection code) and call number. This has the potential to minimize the amount of manual cleanup you have to do after migration. However, if the matching criteria would produce a large number of incorrect linkages when applied to your data, this could also maximize the amount of manual work. Link items and copy records by matching on location, call number, and copy number. This is the essentially the same as option 3, except that the copy number (e.g., c.2 ) must be the same in both item and copy record for a link to be established. 25. If you are migrating copy records, please select the linking strategy you want to use. Choose only one. Do not attempt to link item and copy records. Yes Use the links established by SCKI in Dynix. Link by matching collection code and call number. Link by matching collection code, call number, and copy number. PROCESS record fields Several fields in the PROCESS record can be extracted and added as MARC fields in the copy record. Please select which fields you wish to extract from the PROCESS record. 26. No Do you wish to migrate the cost field (to the 876$c)? 27. Yes Do you wish to migrate the vendor name field (to the 876$e)? 28. Yes Do you wish to migrate the subscription reference number field (to the 876$x with prefix Sub. Ref. #: )? 29. Yes Do you wish to migrate the claim cycle field (to the 876$x with prefix Claim Cycle: )? 30. No Do you wish to migrate the cancel date field (to the 876$x with prefix Cancel Date: )? 31. Yes Do you wish to migrate the processing notes field (to a 583$x with the 583$a = Process; )? 32. Yes Do you wish to migrate the workslip notes field (to a 583$x with the 583$a = Workslip; )? Page 15 of 26

16 33. Yes Do you wish to migrate the routing notes field (to a 583$x with the 583$a = Route; )? 34. No Do you wish to migrate the destination field (to a 583$x with the 583$a = Destination; )? 35. Yes Do you wish to migrate the general notes field (to the 852$x)? Page 16 of 26

17 VIII. Authority Records Authority records are stored in Dynix in USMARC format, and can therefore be extracted as is. If you plan to load authority records extracted from Dynix, please answer the following three questions. 36. Yes Do you wish to extract name authority records? 37. Yes Do you wish to extract series authority records? 38. Yes Do you wish to extract subject authority records? If you plan to load authority records from an authority control vendor, please answer the following question 39. No Do you plan to load authority records from another source instead or in addition to authority records extracted from Dynix? Page 17 of 26

18 IX. Patron Records We can extract your patron records for migration to Voyager. Our standard patron extraction program comes with a number of options. However, if you Dynix patron record structure has been heavily customized or if you have requirements beyond the options listed on this questionnaire, you may either Write your own program to extract patron records from Dynix, Have Endeavor write a custom patron extraction program at standard billing rates, or Do the initial patron load using data from your registrar s computer system. Note that using Endeavor s patron extraction program will affect what decisions you make if your administrative computing staff is planning to write a program to extract records from your registrar s system for patron updates. 40. _Yes Do you want to extract patron records from your Dynix system? If yes, please provide Voyager version you are migrating to (default is 99.1) If you do not want to extract your entire patron database, please provide criteria or a RECALL statement to select just the ones you want to migrate: N/A 42. For a single patron extraction, either the Institution ID field or the SSN field in the patron SIF record may be set but not both, either in the same record or within the file. Please specify which you want set. Institution ID 43. The SSN or Institution ID (see the above question) may be taken from either the Dynix patron ID or some other field in the patron record. Please indicate which option you want. If you choose to use some other field in the patron record, please specify its field number. Note that during the extraction, if the other field is blank for a particular patron, the Dynix patron ID will be used. We would plan to insert the 8 digit institution ID into field 14 (Zip Code) for the extract. The zip code would be overlayed at the next patron load into the Dynix system. In order to migrate patrons, you must specify at least a permanent address segment. You may also migrate a temporary address and an address, but that is not required. For each address field in the following questions, please supply the field number of the PATRON record field that contains that data element. If you are having difficulty finding the field numbers, you can use the program eisi.patron_fields, which is included in the extraction package. This program creates a list of the PATRON record fields accessible to UPR along with their field numbers. 44. Permanent address street: Permanent address city/state: Permanent address zip code: Permanent address phone number: _ Temporary address street: Temporary address city/state: Temporary address zip code: Temporary address phone number: _ address: none 53. What should be the default address begin date? July 12, What should be the default address end date? Page 18 of 26

19 55. Yes Should the temporary address be used as the permanent address if the permanent address is missing? To be migrated into Voyager, a patron record must have a permanent address. If you answer Yes to this question, the patron record will be loaded unless both the permanent and temporary address are missing. If you answer No to this question, the patron record will not be loaded if the permanent address you ve designated is missing, even if the temporary address is present. 56. If a patron expiration date is not already present in the patron record, what should be the default expiration date? Leave this blank if you do not want a default expiration date. _July 12, 2001_ 57. What should be the default patron purge date? Leave this blank if you do not want a default patron purge date. 58. Many libraries will assign ILL patrons to a particular patron type or types. So that the extraction program can correctly assign a name type of institutional to those patrons, please indicate which patron types are used for institutional patrons. ILL 59. Please give the PATRON record field numbers of any fields that you want added to the patron notes field. These fields will be inserted without modification. 10, 11, Yes The extraction program can insert into the patron note field a message giving the patron s current total fine and fee balance. This note would take the form [Fine Balance = $23.84]. If the patron s balance is $0.00, the note will not be inserted. Do you want to migrate the fine/fee balance? 61. Yes Do you want to migrate the patron s historical charges (checkouts) count? Please provide a mapping table from Dynix patron types to Voyager Patron Group codes. This gives you an opportunity to change the patron type codes or merge groups of patrons. Note that a Voyager patron group code is limited to a length of ten (10) characters. Dynix Patron Type Code FAC UGRAD GRAD Voyager Patron Group Code Faculty Student Student Please provide a mapping table from Dynix patron statistical class codes to Voyager Patron Statistical Category codes. Note that a Voyager patron statistical category code may be at most three (3) characters long. Dynix Patron Statistical Class Code FAC UGRAD GRAD Voyager Patron Statistical Category Code FAC UGR GRD Page 19 of 26

20 X. Charge Transact ions Current circulation transactions can be extracted from your Dynix system for migration to Voyager. These circulation transactions are loaded into Voyager as active charge transactions ready for standard circulation activity, including fines, billings, overdue reminders, etc. The data migrated include: Patron barcode Item barcode 2 Charge date/time Renewal date/time, if applicable Number of renewals, if any Number of overdue reminders sent, if applicable Date last overdue notice was sent Note that the following types of circulation information cannot be migrated via the charge transactions load: Outstanding fines and fees (but these can be migrated using the fine/fee load) Patron blocks not involving money Holds and recalls Historical transactions 62. Yes Do you wish to migrate current charge transactions? 2 Note that if one or both of the patron barcode and item barcode for a transaction are missing, the transaction will not be loaded into Voyager. Page 20 of 26

21 XI. Fine/Fee Dynix patron record blocks that involve money (i.e., fines and fees) can be migrated to Voyager. The following elements from monetary PURF blocks will be migrated: Patron barcode Amount of the fine or fee Type code of the fine or fee Agency that assigned the block Item barcode Title Due date and time 63. Yes Do you wish to migrate current fine/fee blocks? GENERAL The fine/fee migration is a load that migrates fines and fee records to Voyager patron records. As part of the migration, the fine/fee are linked to Voyager patrons. Note that all fine/fee records must be mapped to one Voyager location. [Note: This mapping is implemented by the Project Manager prior to the load.] Specify Voyager location: FineFee Page 21 of 26

22 XII. Vendor Records Vendor records can be extracted and migrated to Voyager. 64. No Do you wish to migrate vendor records? 65. Voyager requires that a Vendor Type Code be assigned to all vendor records. See the Voyager System Administrator s Guide for more information. In the space below, please identify the Vendor Type Code you want assigned to all vendor records extracted from your Dynix system. Please note that this code may be up to two characters long. Vendor records in Dynix can be accessed by using a numeric vendor ID. This numeric key can be used as the Voyager vendor code. However, an alphanumeric vendor code based on the vendor name may be easier to remember. For example, using BT to locate the vendor record for Baker & Taylor may be easier than having to remember that vendor ID 163 is Baker & Taylor. You can provide us with a mapping from numeric Dynix vendor ID to alphanumeric Voyager vendor code. We can also provide you with a vendor ID mapping file that maps from vendor ID to the shortest unambiguous truncation of the vendor name. 66. No Are you going to create a vendor ID mapping file? 67. No Do you want the sample mapping file created by a program that generates a mnemonic vendor code from the name of the vendor? The vendor ID mapping table should be given to us in the form of an Excel spreadsheet. Note that the Voyager Vendor Code can be at most ten characters long. You do not have to provide a mapping for every vendor in your system, but those vendor IDs that are not mapped will be migrated as is. Here is a sample of the vendor ID mapping: Dynix Vendor ID Voyager Vendor Code 163 BT 15 BLKWLL Vendor Records If you desire, vendor records can be migrated to Voyager. All addresses are loaded. Voyager has separated address information for data elements such as city, state, and zip code. All vendor information will print in Voyager in its Voyager defined fields. Voyager requires that a Vendor Type Code be assigned to all vendor records. See the Voyager System Administrator s Guide for more information. In the space below, please identify the Vendor Type code you want assigned to all vendor records. Page 22 of 26

23 XIII. Open Orders (Extra cost) NOTE: Order record migration is an extra-cost option. If you want to migrate open orders, please discuss this with your project manager. Open orders in Dynix can be migrated to Voyager order records. As part of the migration, the order records are linked to Voyager vendor, holdings, and by extension, bibliographic records. Please note the following: Open orders are defined as those having a Dynix order status code of O. The vendor code in order record must match a vendor code already present in your Voyager system. Therefore, the open orders load must be done after the vendor load, and you must not change any vendor codes in Voyager until after the open orders loads is finished. The orders load will require the same vendor ID mapping file used during the vendor load. No invoice, payment, or claim data is migrated. No fund accounting information is migrated, except optionally as part of the notes field. 68. No Do you wish to migrate open orders? All open orders are migrated as pending orders and attached to a single default fund to enable the library to take advantage of differences in the Voyager and Dynix fund structures. At the time of the open load, you will have to specify the default ledger and fund to which you would like your orders linked. Several fund accounting fields and notes fields can be migrated from the Dynix order record to the line item notes field of the Voyager purchase order. If the line item notes field for an order record should exceed the current limit of 1900 characters, the order record will not be migrated and an error log message will be produced: 69. No Do you want to migrate the Dynix order record notes fields to the Voyager orders note field? 70. _No Do you want to migrate fund accounting information to the Voyager order note field? You should also create an order location mapping file, which should map from Dynix collection code to Voyager location code. This mapping file should also map from the agency codes of the agencies whose orders are to be migrated to acquisitions happening locations that you will define later. Here is an example: Collection Voyager Code/Agency location AGENCY MAINACQ BOOKS BOOKS PER PER For an open order to be loaded into Voyager, it is necessary that a PO number be present. Normally, the extraction program will use the PO number from the Dynix ORDERS record and will not extract the order if the PO number field is blank. However, you can elect to have the program use the ORDERS record key as the PO number if the PO number field is blank. 71. Do you want the ORDERS key to be used as the PO number if the PO number is otherwise not specified? 72. If you have answered Yes to the previous question, you can specify a character string (e.g., dynix, order, etc.) which will be prefixed to any ORDERS keys that are used as PO numbers. 73. Please specify a default collection code for any orders that do not have attached HOLDINGS records. This may be any collection code defined in Dynix: SPECIAL PROCESSING Page 23 of 26

24 All orders are migrated as pending orders and attached to a single default fund. Please specify the default ledger and fund to which you would like your orders linked: All order loads require a two column mapping file listing old system location and the new corresponding Voyager location. Fund Mapping into the Purchase Order records. GENERAL The fund mapping is an optional, extra cost extract that migrates fund information into Voyager purchase order records. As part of the migration, the purchase order line item fund is mapped to the Voyager ledger. The Voyager ledger must be created manually by the site prior to the order load. A table will be created prior to the load with the extracted fund information and the available Voyager ledger/fund id. Following the test order extract, the Project Manager will supply the existing fund information and the list of possible Voyager fund ids. The site will create an Excel map of the old system fund to the Voyager fund id. Original System Location Code Main Cbcirc Llevel Voyager Location code main cbcirc llevel Page 24 of 26

25 Serial Patterns Page 25 of 26

26 Hold/Recall Records. GENERAL The hold/recall migration is an optional, extra cost extract that migrates holds and recalls to Voyager patron records. As part of the migration, the hold/recalls are linked to Voyager patrons. The load map (used for order load mapping) can be used for this mapping also, unless a separate table is included and identified. [Note: This mapping is implemented by the Project Manager, and occurs prior to the load.] Data migrated includes: Patron barcode (used to link to the patron in Voyager) Request Type ( H for hold, R for Recall) Request Level ( T for Title Level Request, C for copy level request) Item Requested (If Request Level is T then this will be the NOTIS ID, If the Request Level is C this will be the item barcode of the copy requested.) Date Requested Time Requested Request Rank Expiration Date Pickup Location Original System Location Code Main Cbcirc Llevel Voyager Location code main cbcirc llevel Page 26 of 26