View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide

Shared Systems Recommendation - for comment

Table of Contents - please post comments under each section

1. OBJECTIVE 4
CCLA:
these sites want an easy way to replicate tasks/tables to many libraries

VCCS:
Yes The main point is that it is the updates and changes from things like the patches that are the big problem. The on-going changes to reflect local practices are a pain, but.. Most of the time when a change comes in we move the default condition into the individual ADM's and then edit things as (and if) needed.

USMAI: (jean)
We would like to have EL specifically address Service Pack applications. Sounds like currently you need to move local changes to each environment manually. Do they have a suggest for automating this work where appropriate?

2. BACKGROUND 4

CCLA:
2.1
The move after v15.5 from a single alephe resulted in more limited options in some ways

2.2
An important element of ILL is statistics. “External” borrowing must be tracked by most libraries. Will this be available with DCB?
ILL if ISO-compliant allows libs to use one resource system for all their resource-sharing needs. PDQ forces them to use a second interface for non-shared system requessts.


PALS (BB and MB):
2.2: This may be the case for some shared systems. In our consortium, the distinction between ‘ILL requests’ and ‘hold requests’ is defined by who manages the request, how delivery occurs, and who takes financial responsibility for the item(s). When the borrowing library manages the requests on behalf of the patrons, the process used is ILL and the item is delivered to the requesting library. When a patron initiates a hold request for material owned by another library (assuming he has the privileges to do so), the library expects the patron to travel to the library to check it out. In MnPALS, the external ILL partners include MINITEX (MII), which is on the University of Minnesota server, ODIN, and potentially SDLN, OCLC, and the MnLINK Gateway. Currently, most rotas that the libraries set up for ILL have MII listed as the library of last resort, so when material isn’t available from a MnPALS library, the request is automatically forwarded to MII.
b. We will analyze the workflow of PDQ to determine if and how it could be integrated. We have identified some questions that may or may not have been addressed in the design. They are:
1. When a hold is filled, is the item immediately checked out to the patron? Is delivery time (both to and from) calculated into the due date?
2. How does the software know whether to place a hold request or an ILL request? Are both choices displayed and the patron needs to select one?
3. If an item is not available within the consortium, will the software use the hold request information to automatically create an ILL request? Or does the patron need to re-enter information in another form?
4. How can delivery of the item be tracked in the hold request scenario?
5. Libraries want detailed information concerning borrowing and loaning for ILL statistics. How does PDQ track holds from patrons registered at another library? Are there counts by library (patron A borrowed from library C, for example) added to the circulation logger?
vi. What impact would there be to set up and tables? Particularly, pc_server_defaults, www_server.conf, tab_hold_request, tab_hold_request_form, tab100, tab15.eng, tab31and any others that might apply?

VCCS:
I don’t know enough about PDQ yet, but it looks like it has the potential to meet our needs. Basically, we want to expand the current hold functions so that it will work across the whole system We would, for example, like, in support of our DL students, let the patron place the hold anywhere and we would ship the item off to them directly. The patron’s “owning” library would still be on hook for the item if it gets lost.

6. How is patron privacy maintained when using PDQ?

SUNY (Andy Perry)

SDLN (Sean Crooks)
How does PDQ handle periodicals and copyrights? One reason for us choosing ExL was that our users do not want the type of ILL system they are proposing in this document. We want the seperate ILL system that is currently in place an not the global hold system. Also, what about ILL from places outside our consortia? Currently it uses the Z39.50 protocol, does DCB have the capability of doing that and what will the interface be?

FCLA: We plan to continue with our separate Aleph instances therefore we are assuming that we would need to use pure ILL rather than DCB/PDQ if we were to implement any form of resource sharing.

USMAI: We have a number of questions related to how intra-consortial borrowing will work in this environment. Our questions are actually very different from those above. We want to move items within our consortium, for communication outside the consortium we are currently using Illiad. Also our process is now seamless, with no extra steps whether the patron or item belongs to the circing campus or not.
We'd like to understand how this will work in multi-adm, here are some scenarios:

1. If a patron from campus A walks up to a campus B circ desk and wants to charge out an item from campus B, what is happening? Does the circ person need to log into campus A circ to perform any of the tasks or see any of the information about the patron? Will the borrower status in the global record be used?
2. What if they are renewing a book from campus C? Same question about what the circ person needs to do to make this happen.
3. What if they are renewing a stack of books from various campuses, some that they have local records for and some not?
4. What if there is a hold on an item from a patron on campus D? Will the circ person be alerted to this?

The description of PDQ (in the documentation and in a presentation by Carmit) in terms of patrons being able to place holds on titles across the consortium and have the item delivered from any library seems to meet our needs. We will begin testing this in a one ADM model first when we begin work on the upgrade to Aleph 18 in January.

2.3:
PALS:
I think that the word ‘autonomy’ might better describe what institutions need for the acquisitions functions instead of privacy. Nearly everything that is purchased by the library is seen in the catalog and is reported on various reports eventually. Each institution, though, does need to manage its budgets without fear that another institution could spend from its budgets. A more important issue is patron privacy.

CCLA:
Patron privacy is also an issue in some environments.
PP is an issue in increasing numbers of situations as people become more aware


2.4:
PALS:
It would be useful for the documentation to identify which Web OPAC pages relate to local branding. How much difference can there be without affecting the functionality of the Web OPAC?

CCLA:
Co-branding is often desired: the institution and the system.

VCCS:
Amen to CCLA's comment.
Plus -- the "base" function does need some fine tuning, there still seem to be too many cases where the system drops out of the current base (forgets which base it is suppose to be in) to the default, which in our case is the “all colleges.” This does tend to confuse the users.

ODIN:
Branding for both the institutions and the system is important. And possible to do in a reasonable manner.

USMAI:
Currently we do not have individual campus interface design. Its possible that our sites might want to reconsider this given the opportunity.

3. PROPOSED STRUCTURE 6

SUNY (Andy Perry)
--single application of service packs
--single oracle instance
--single aleph instance
--union catalog is byproduct of combined bib file and not a separate system


SUNY (Natalie Sturr)
Editing system files, such as pc_server_defaults and www_server.conf – by campuses

Indexing

Tab_type_config --How will all the campus-specific files be treated?; These are very specific to each campus and should be retained

USMAI: one question about reserves libraries, will it be possible to have more than one per institution? We will have a single institution with multiple reserve sites.

USMAI: not sure where to put this, but we currently have a problem with limits in tab_library_relations, its actually the opposite problem of having a limit to the number of bibs "related" to one ADM. Is there a limit to the number of ADMs "related" to one bib library?

USMAI: can we assume that the serial subscription file is included in the Acq box on the diagram?

USMAI: currently we keep our collection codes in tab_40 in synch between our HOL and ADM libraries. Will that no longer be necessary?

4. BIBLIOGRAPHIC DATABASE 7
CCLA:
This is different from what CCLA has traditionally done. No one in LINCC ‘owns’ the bib. record. What impact would this have on us?

FCLA: since we intend to keep our separate Aleph instances each with their own BIB01 (which for some universities does include multiple bib records), this isn't an issue for us. However, were we to ever decide to merge into a single Aleph instance with a single BIB01, we would want to consider reducing to a single shared bibliographic record in order to reduce the total size of the database and to realize true shared maintenance of the cataloging data.

USMAI: at this point we want to retain the single shared bib. record.
We would like to see Union View improved to include all available items displays. Currently it is limited to 2 types. (We have other uses for Union View).

5. HOLDINGS RECORDS 9

PALS (Becky and Mike):
We need OWN control on holding records. How is the OWN forced on new holding record creation? Check_doc? Other?

SUNY (Maggie Horn)
p. 9 -- for our purposes, the item and serial subscription records MUST be linked to holdings records.

FCLA: we would want OWN control separate holdings records linked to a single, shared bibliographic record.


USMAI: Will anything change with our "superholdings", i.e. HOL records with bib. only information? Also we were wondering if there would be a mechanism for one institution to view another's HOL record to see the publication patterns?

6. AUTHORITY CONTROL 9

SUNY (Maggie Horn)
Some folks may be distressed about a single authority file -- question? What happens to purely local records? [they go in, but is there a way to tie them to a specific record? -- we might have to come up with our own set of indicators for linkages]. Also, a single authority file probably means more commitment to upkeep on the OLIS side ... I doubt we'd expect the individual libraries to be doing authority control ...

FCLA: We currently share the resource authority files (LCS01 and MSH12) while having separate, individual local authority files, e.g., UFU10. The linking defaults to the local first and then to the shared files. Would it not be possible to have a similar situation in this model?

For the libraries that choose to use separate bib records with OWN codes, could the OWN codes be linked to local authority files, e.g., UFU10, SFU10, etc...

USMAI: This fits into our current plans to have one LC and one Mesh authority file.

7. INSTITUTION LIBRARY ENVIRONMENT (ADM) 9

SUNY (Andy Perry)


8. STAFF AUTHORIZATIONS 10

FCLA: does this presume that all users have to be unique within the single pw_library? Is there anything that imposes this uniqueness such as an institution or ADM prefix to the IDs?

9. ACQUISITION ORDERS AND BUDGETS 10
USMAI: this would be a great improvement for our institutions.

10. VENDORS 10

11. CURRENCIES 10

PALS (Becky and Mike)
We concur that these tables should be systemwide.

CCLA:
My guess is that there is minimal use of currencies by shared systems, and therefore overeas shared systems should be consulted. However, it seems that a single system-wide exchange rate should be sufficient.

ODIN:
It makes sense for currency and exhange rates to be in shared tables.

SDLN
If this is system wide, it will be another setting that requires us to monitor on a regular basis (weekly?) While not a big deal we would like to see it controlled on a library to library basis.

USMAI:
We have a system wide table now, but we don't think anyone is using it. We'll have to check into this. Being shared doesn't seem to be a problem.

12. PATRONS 11

PALS (Becky and Mike so far):
Paragraph 7: Is the intent for the patron to choose on an item by item basis which library will be used to manage their borrowing request? What would the ILL Library field in the patron global record be used for if the patron can choose a library to handle borrowing requests? What is the benefit of this? It’s possible that in MnPALS, the patron would want to choose an ILL unit that resides on a different system (OCLC PICA, formerly FDI). Would this feature work across servers?
Paragraph 8: How would this happen? Will there be an additional address type in the patron record for other libraries or ILL libraries? How would the from/to dates in addresses work in this environment?
12.1: In MnPALS, patron id’s are unique as long as we have prefixes that can be associated with one ADM.
Are the xxx50/z52 sequences still used for new patron record id assignment?
12.5: MnPALS has some libraries that create new records with new barcodes. The problem is cash transactions (fines/bills). Most libraries in our consortia pass financial data on to an institutional financial system. Fines/Bills to external patrons are not defined in the local financial system.


CCLA:
If we cannot use DCB, would a special Z305 record still be needed/created?

Non-shared users must be able to participate in ILL.

I think that most libraries in shared systems have selected “shared” patrons, but do not actually share. In other words, when a patron has privileges in multiple libraries, duplicate patron records exist with ids made unique.

As long as the ILL Units list is small (i.e., not all 28/72) that shouldn’t be a problem?

The patron ¬does¬ need to be able to select the ILL unit.

Options such as this may make it easier to use truly shared patron records.

Unless this (and the previous one) impact response time, I don’t see an issue.

ODIN:
Echo PALS comment that "It’s possible that in MnPALS, the patron would want to choose an ILL unit that resides on a different system..." It is higly likely that PALS and ODIN users would want to select a library in the other system.

SDLN
In the second paragraph it mentions that each institution determines whether patrons are shared or non-shared. We had an institution that started off as shared but then wanted to change to non-shared. The setting was changed in Tab100 and all the patrons that were added under shared were no longer visible. This issue needs to be addressed.

We currently have one ADM that has 4 sub-libraries that do not have shared patrons. They need to be able to participate in ILL still but under PDQ, that will not be possible.

In regards to the 6th paragraph, we have shared patrons right now that have more than 1 global record. What is the impact of that going to be?

USMAI:
We will not be using Aleph ILL at this time, so the problem of assigning a default ILL Unit is not a problem for us. We don't currently have multiple addresses for our shared patrons. This proposed enhancement seems very complicated and hard to implement.

12.1

CCLA:
Several shared systems have patrons who are registered at multiple institutions. They load duplicate records and solve the need for unique ids by making the patrons non-shared – or by applying an institution prefix to the id forcing uniqueness.

Allowing non-unique patron ID’s (other than 00) and retrieving a “list” similar to the patron name list, for selection, might make it possible for us to have shared patrons

ODIN:
There are systems where there are patrons with multiple institutions and one ID. A number of Students, faculty and staff at higher education institutions have associations with multiple institutions. In a Human Resources (HR)system shared by multiple institutions there is only one ID number for such an individual. These individuals can have only one 'home' library in the current design. The conflict is that the HR system number for the person can only be put in one record. The HR system number that the PLIF loader uses to update the patron's record. However, libraries have operationaly had to create additional records for patrons like described. (It has not been practical for some libraries to try keep to a shared record.) These additional patron records cannot be updated via the PLIF for obvious reasons.

USMAI: We currently add a prefix to local ids to make them unique. This will probably not change.

12.3
CCLA:
Selecting the option for “local patrons only” is used to limit the view to local patrons.

VCCS:
We find that making everyone searching the global records is important if we want to avoid dulication.

SDLN
We agree with CCLA's comment, under this setup, will we retain the ability to display local patrons only?

USMAI:
We will want all of our sites to see all of the patron records. So this seems to work for us.

12.4

ODIN:
In the patton with a multiple institution and one ID senario one of the libraries will be the home library (when each library might feel that they are the home library or the paton might believe that a library other than the one that has become the home library is the correct one.

USMAI:
Does this mean you can view all patrons, but not update them? Can you add a local record for another institution (we have patrons who come in with i.d.s for other institutions and are not yet in the system). To do so does the circ staff member have to be logged into that ADM?

12.5

VCCS:
If there were someway to reduce the processing when running PLIF it would be nice. Right now I have to run 23 batches every time I load students. Since the job runs “within the ADM’ environment each batch has to be ADM specific. In the global environment, however, it would seem that the global record should drive things with the “local” record(s) going off to the correct ADM as required.

12.5
SUNY (Maggie Horn)
I'm somehwat concerned about the alerts in the patron loader section ... "Care must be taken not to inadvertently open a new record for the same person in a shared patron setup" -- we know our current folks don't always take "care" What is meant by this? Would we have that?

SUNY (Andy Perry)

SUNY (Natalie Sturr)
plif files – will likely need to be sure all fields are completely and accurately filled out, such as HOME-LIBRARY. This will be especially true if there are shared patron records.

FCLA: Given the number of sources of PLIF data, the variation in frequency of loads and the complexity in which we currently work with our separate Aleph instances, I am very concerned about the viability of trying to load records into a shared patron file. It boggles my mind.

USMAI: we currently load many campus files into our one ADM. To make this work we have written a complicated set of pre-processing programs that review what is in the file and make decisions based on expiration date and borrower status. We are guessing that this will still be necessary under a multi-adm/shared patron scenario.

13. BATCH PROCESSES 13

PALS (Becky and Mike):
Scheduler: Does the scheduler take the place of the job list? Will the scheduling options include daily, weekly, monthly, quarterly, annually? Will the scheduling options include specific days of the week, with the ability to choose Tuesday and Thursday but not the other days?
Log Analyzer: In a shared system, the log files can become extraordinarily large, and get to the point where they are not useful because they can’t be easily searched or read. Our suggestion is to add a parameter that will narrow down the log files by only clearly reporting errors and by indicating successful processing at site determined intervals, i.e., every 10,000 records.
Improvements: Does this mean that the log files for each job will be available to the ADM’s in addition to the report or notices generated?
Batch processing: The serial batch queue is a problem for shared systems. Is there some way that a multi-threaded batch queue could be created so that job two doesn’t have to wait for job one to complete?
Batch processing: Our system can never use Catalog Print print-04 because of the size of the database. Even for small sets of records, the entire Z01 table is read. This can take days for us, and in the meantime the batch queue waits. We also cannot use Print Catalog Records with “Non-preferred” headings print_05 for the same reason.
Batch processing: In many of the services forms, there is an option to Print to ADM. Is this option available in all services forms? And does it work reliably?
Batch processing: Many of the services create files in alephe/scratch which are used as input to subsequent services. Presently, the file name can be whatever the creator assigns. With a shared aleph/scratch has consideration been given to automatically add the ADM symbol to the file name? If there is no way, it’s quite possible that any filename could be used by more than one ADM, which would result in overwriting another ADM’s file.

VCCS:

I generally agree with the other comments. How to make the logging function more efficent would be a significant value, particularly the number of logs that end up in the alephe scratch directory.

SUNY (Maggie Horn)
p. 13 -- Batch processes "This task is a heavy burden on the central office resources." I believe that sentence says it all -- means we need folks who would be working on this [i.e. a single shared database won't necessarily cut down on our work -- it might actually increase it on a daily basis]

SUNY (Andy Perry)

ODIN:
Job List need serious improvement or replacement if that is what the "scheduler" is. Options such as daily, weekly, monthly, quarterly, annually as mentioned by PALS. As it is we have to swap out job lists for montly jobs, ...

13.1
CCLA:
The options below are useful, but if I understand this correctly, the number of batch jobs are not reduced with these enhancements?

I’m not sure that reducing the # of batch jobs is the answer. That might just amplify the problem when a job fails…..now what failed? And how do we correct it?

Also make it easier to clear the TM using the filters to select files for delete

SUNY (Natalie Sturr)
Improvements in Task Manager and Alerts (p. 14) – these will be wonderful to have!


14. CONFIGURATION 14

PALS (Becky and Mike):
Print forms: When ILL is implemented in the client, will the ILL forms be included in the form_eng or will they continue to be in separate directories?
Configuration tables: We suggest adding www_exp_field_eng.ill and tab_type_text to the list of the local/global overlay.

All our users customize forms. Upgrade express generally doesn’t upgrade any form that has local customization. With 63 ADM’s this makes for a monumental manual effort to analyze and fix forms in version upgrades. We need some automated process that at least attempts forms upgrades and reports on all failed results.

CCLA:
again. Centrally controlled sites don’t necessarily want it more “simple” we want a want to “simply” replicate across many ADM’s We can then edit if a few lines are different.

VCCS: Yes to CCLA point -- see my comment on section 1.

yes, and there are many (tables). Welcome to the whole TCO issue

(tab15 and tab16) these are often updated, but tend to have unique (non-replicable) parameters

ODIN:
Agree with PALS comments: Staff who are responsible for staff priveleges in their own ADM ahould not be able to set higher priledges than the level at which they are set up.

SUNY (Maggie Horn)
p. 14 -- "update of GUI client files problem has been reported by a LaSSSI member; this should be further investigated" -- this statement scares me (my guess it is related to version check and the inability to do it properly in a shared environment)

USMAI:
Yikes! This area is where we stand to loose the most in terms of efficiencies and gain the most in terms of users maintaining their own tables. We currently don't have the problem of multiple configuration files. We just have one set. Not sure how to get into the details of identifying relevant tables for global + local treatment. Does the global + local treatment sound doable to others?

APPENDIX A - FUNCTIONALITY CURRENTLY IN PLACE
1. STAFF AUTHORIZATIONS 16

PALS (Becky and Mike):
In our shared system, each ADM is responsible for their own staff privileges. We need a method that will disallow each ADM from assigning privileges over and above what the original privilege record allows. For example, in order to use the Cataloging services menu as it’s delivered, we need a way to set the ADM system librarian privilege records so that person can’t allow a cataloger in the ADM to start indexing jobs. In other words, we need a way to inherit the deny settings in the privilege records created by an ADM system librarian who has master authorization for the ADM. We suggest adding the port number to the privilege record to ensure that the staff person logons to the proper pc-server.

SUNY (Andy Perry)

USMAI:
We'd like to understand how this change would fit into the work being done with the ELUNA Permissions Task Group.

1.1
SUNY (Maggie Horn)
p. 16 -- looks like we (OLIS/ITEC) would absolutely have to have separate username/passwords in order to work across ADMs -- right now we can cheat with "OLIS" -- could we still cheat that way (by having the OLIS name everywhere?)

SUNY (Natalie Sturr)
Staff authorizations

1.2 and 1.3
SUNY (Natalie Sturr)
OWN fields (page 16-17)


1.4
USMAI:
Same question as elsewhere: how does this affect circ staff being able to see patrons/holdshelf items/intransits/loans for the patron standing in front of them no matter what their affiliation?

2. CONTROL IN BATCH SERVICES 17

SUNY (Maggie Horn)
Control in batch services -- I don't see any mention of "p-ret" functions or some of the indexing functions for batch jobs -- would it be possible for someone else to retrieve records which AREN'T theirs? (they can't change 'em, but I wouldn't think they'd want them in their retrieval in the first place!) .... the only place where I see a retrieval limited by OWN field is on p. 18 -- and that's talking about p_auth_03.

2.1.1
SUNY (Natalie Sturr)
Job_list (page 17)



3. WEB OPAC 18

PALS (Becky and Mike):
Paragraph 7: Tab100 is not necessarily ‘naturally controlled’ by each ADM. In our implementation, we have suppressed tab100 from the ADM’s due to the patron settings. When an ADM wants to change a setting that doesn’t involve patron settings, the central site makes the change for them. In fact, any setting that could affect the way the system works for the whole consortium is generally set the same for each ADM.

3.1
CCLA:
we have log_bases defined at the sub-library level

One topic that needs to be expanded upon is the ability to configure multiple pc_servers, oclc_servers and sip2_servers on different ports (z39_gates and www_servers are mentioned). CCLA used the same approach for the aleph_start.private file as the www_server.conf, but instead of using a port number as a file extension, we used the 3 character ADM code. By defining specific ports and other variables in separate aleph_start.private files, we can run pc_servers, oclc_servers, sip2_servers, z39_gates and www_servers on different ports for each college. It appears that you could also have multiple pc_server_default files that can do some of the same things. Mankato and Palni are both running multiple servers on different ports in version 17. I'm not sure how Palni is accomplishing it, but Mankato is doing it similar to the way we are.

SUNY (Laura Murray)
The Web OPAC is discussed on pp.18-19 of "Proposed Large Shared Systems Model." In this model each library has its own www_server.conf table, based on the assigned port. This will allow much flexibility for campuses to control setting such as the SFX URL, the amount of items that can display and the default search type. Campuses will share most of the HTML files, but it will be possible for campuses to have their own unique HTML files if functionally necessary. If I read this correctly, it will be possible to lock down some web OPAC files and make others available to campuses for editing. I like this model and have no concerns with it as proposed.

SUNY (Andy Perry)

USMAI:
Does this mean we would have to run a pool of www servers for each adm? Right now we have one large pool for all our campuses.

4. GUI 19

PALS (Becky and Mike):
There can be separate pc-servers for each ADM. We can also setup separate service menu’s for each. Once a user has a system privilege record though, there is no way to restrict that user to a specific pc-server. We have a separate pc-server set up for our consortial office with a different set of services (like indexing is visible). There is no way though that we can keep a user with a valid privilege record from signing on to this pc-server port, and getting access to the restricted services. Since we can’t keep the user from assigning himself indexing privileges and can’t restrict him from a restricted pc-server, the system has a significant security hole.

USMAI:
Sounds like we can run on one pc server configuration if we choose to, correct?

4.1
CCLA:
we have multiple ports per ADM

4.3 Fast Cataloging
USMAI: this would be an improvement for our campuses.

5. SUBLIBRARY ADDRESSES 21

PALS (Becky and Mike):
Why don’t you treat this as tab16 or tab17? In other words, why don’t you place the tab_sub_library_address in the XXX50 only? I cannot imagine one tab_sub_library_address table that includes all the addresses for all 63 ADM’s. How would the system be able to tell which address to use on forms?

CCLA:
How can the entire table be in each ADM, when data for all ADMs is in the table?

6. TAB_BASE. 21

7. Z39.50 GATE 21

7.2
CCLA:
"each ADM library sets its own access password for the target." Are there shared systems needing this?


8. SFX 22

PALS (Becky and Mike):
A rep_change in version 17 has moved the SFX server address from the www_server.conf file to the system startup file. This then requires a single SFX server system wide?

USMAI:
We have recently done some work to try and guess which sfx to link to from Aleph, when we brought up sfx in the catalog. This looks like we may not need to bring all that work forward into this environment.

OTHER Comments not considered in the document

PALS (Becky and Mike):
ARC – Placing the entire shared patron file in each ADM is a problem. It opens up many data privacy issues, uses up too many system resources and in general makes patron reporting difficult. Only patrons associated to an ADM by the home library, a local z305 or cash/loans/holds for items of the ADM should be extracted as part of the ADM patron file.

SUNY (Maggie Horn)
Overall, I guess it is doable -- I'm concerned about redundancy (i.e. if the server goes down everything goes)....also indexing times, batch processing times, response times, etc. It would probably make for easier upgrade and "easier" table maintenance, but on an ongoing, daily basis, is it better? Dunno.

SUNY (ITEC staff)
See attachments for comments and questions regarding Oracle and Hardware considerations

SUNY ITEC Oracle Hardware 1.pdf
SUNY ITEC Oracle Hardware 2.doc

Link to this Page