Consequences of a Large Number of Patron ID Types (Z308)

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
I have a question about having a large number of types of IDs. The system where we get our patron information requires only that the patron's tech id be unique to the campus, so there is no way to ensure that a patron's tech id is unique in our multi-adm Aleph system.

Currently we preface the tech id with the 3 letter ADM code to ensure that the tech id is unique in the Aleph system. Up until now, this tech id (z308 type '02') has been mostly used as a match point for updating patrons during the nightly plif load, so this set up has worked fine.

With the trend toward distance education, there are a large number of patrons that do not arrive on campus to obtain their barcodes, which are unique system wide. These patrons need to logon to Aleph to create ILL requests and also Aleph is being used as an authentication source to logon to proxy servers for access to databases. While the distance learners do know their tech id, it is problematic to instruct them to preface the tech id with the correct 3 letter ADM code. I have an idea for a solution and was wondering what implications it would have on the system.

My idea for a new solution would be to create multiple types of ids instead of prefacing the tech id with the 3 letter code. So instead of a tech id type 3 of ACC00000000 I would have type 10 be the ACC tech ids and the id would be 00000000, type 11 would be the ADC tech ids, type 12 would be the AHT tech ids, etc. We would end up with about 50 types of ids that we would allow to logon to the system. We would also run multiple sip2 servers so that the patrons can be authenticated via their tech ids for the proxy servers we support.

My question, how would this set up effect the system? Would all of these types of ids that can logon to the system through the web OPAC cause any undesirable side effects?

Also, can I run sql queries to modify the type 3 ids and make them the new types? Since the ids are only used for plif loads, is there any problem with changing the z308_rec_key using sql queries?

Resolution:
The ./alephm/source/copy/TAB_BOR_ID file can have 1,000 lines:

02 TAB-BOR-ID-LINE OCCURS 1000.

(Of course, there are only 99 possibilities for the 2-digit TAB-BOR-ID-TYPE.)

In any case, I think that 50 different ID types should not be a problem. I do not believe that they would cause any undesirable side effects.

Changing the z308 ID type with SQL should not be a problem. (If the "tech id" were a z308 type 01, you would also need to consider the z353 "Patron index" (z353 "BC" entries), but since it involves only type 02-up, this is not an issue in this case.)

Note: Though it initially seemed that having just a single tab_sip2.conf, with just a single match_id_type value, would be a problem, the solution to that was found in KB 8192-5399.

[Postscript: This site was not actually able to implement this solution because they found that certain students were assigned the same ID at some campuses -- and Aleph requires that the ID be unique across the different z308 types.]

Article last edited: 10/8/2013