p_manage_17 questions

• Article Type: General
• Product: Aleph
• Product Version: 16.02

Description:
I have several questions relating to p_manage_17. For starters, is it correct that manage_17 can be run post-STP while the system is up, public is searching, and staff is cataloging new records at the same time?

Resolution:
1. Is it correct that manage_17 can be run post-STP while the system is up, public is searching, and staff is cataloging new records at the same time? << Yes
2. You talk about possible collisions with manage_17 and ue_01, and mention stopping ue_01. I think that a post-STP run of manage_17 will take a week and a half. (They have 2.9 million bibs. Do you think this is a reasonable estimate?) << If it's run with multiple processes, I think it should be faster than that.
3. This will almost certainly be unacceptable - having no access to new record for this long. Do you think stopping ue_01 is really necessary? How likely is a collision, and what do you think the results will be? << Collision is unlikely. Results would be the ue_01 process stopping or error on that one record. Not so severe.
4. I understand that manage_17 does some re-organizing of headings which are very long and may be out of order towards the end. Does this reordering take place real time, or does it all get done at once at the end of the run. << Real time.
5. I assume you can't stop and restart the job. If you do have to stop it for some reason, can you just restart it from scratch?
6. The site is primarily concerned about the impact of manage_17 on performance post-STP. Have you seen any problems with this? They have an 8 processor machine. Would you recommend that manage_17 be run with only one process, or could it be more without impact? << If it's a time of relatively low OPAC use, I would think that it could be run with more processes without any problem.
7. What is the actual mechanism for running manage_17 with the system available. Do you just submit it normally and then unlock the library? << Yes.