p_manage_32 hangs in p_manage_32_u.sql step

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

Description:
We're doing full indexing in our single bib test environment (XBtest). The last job we need to run in the BIB library (SBU01) is p_manage_32. It hangs while in the p_manage_32_u.sql step. The last entry in the alephe/scratch/SBU01_p_manage_32.log file shows a successful Oracle connection. There are no Oracle errors. In $data_scratch, the cycles file is fully set up and there's an empty p_manage_32_u.seq file. The job runs for about 10 seconds. Then the following is logged to the screen:

[1] + Suspended (tty output) csh -f /exlibris/aleph/a19_2/aleph/proc/p_manage_32 SBU01,1,ALL,14 >& ...

Here's the output from "ps -ef | grep p_manage_32":
aleph 24972 21303 0 12:39 pts/9 00:00:00 csh -f /exlibris/aleph/a19_2/aleph/proc/p_manage_32 SBU01,1,ALL,14
aleph 25081 24972 0 12:39 pts/9 00:00:00 /usr/local/bin/rlwrap /exlibris/app/oracle/product/102/bin/sqlplus <user>/<password> @/exlibris/aleph/a19_2/aleph/proc/p_manage_32_u.sql SBU01
aleph 25082 25081 0 12:39 pts/4 00:00:00 /exlibris/app/oracle/product/102/bin/sqlplus @/exlibris/aleph/a19_2/aleph/proc/p_manage_32_u.sql SBU01
aleph 25088 21303 0 12:40 pts/9 00:00:00 grep p_manage_32

SBU01 does not have any logical bases but p_manage_32 also loads the tab_base.eng files for FSU50, SFU50, and UFU50 and they do have some logical bases. The cycles file lists a cycle for those XXU50 logical bases. Is this causing p_manage_32 to hang?

Note: The reason we kept institution tab_base.eng files in the xxu50/tab directories (among other things) is related to an Aleph document we were following, "Proposed Large Shared System Model" (see attached). After we were well into setting up single bib (6-9 months) and after a couple of SIs about set up, we were informed to disregard the information in that document. But, we've gotten this far and things are working (until p_manage_32) the way the document said they would, at least the way "Appendix A: Functionality Currently in Place" said they would.

Mostly, our tab_base.eng set up is to enable having the single bib OPAC (sb.latest.fcla.edu) that has a drop down list containing itself and the individual institution) yet still have individual institution OPACs with their customizations (uf.sbtest.fcla.edu, fs.sbtest.fcla.edu, and sf.sbtest.fcal.edu).

Resolution:
I didn't realize the background to this, so I have tried to get p_manage_32 running in your current environment. The following SQL showed that there are *zero* sbu01 z01's with Z01_REF_TYPE = 'U':

SQL> SELECT count(*) FROM sbu01.Z01 WHERE Z01_REF_TYPE = 'U';

COUNT(*)
----------
0

Therefore, the following step in $aleph_proc/p_manage_32 is unnecessary:

sqlplus $ALEPH_ADMIN @$aleph_proc/p_manage_32_u.sql $p_active_library

So I commented it out. [Note: It's unclear that this change fixed the problem. It may be that a rerun would have worked even without p_manage_32_u.sql commented out....]

I ran p_manage_32 with the same parameters as you. The job seemed to be running normally, but ran out of space because there were so many large bases.

I suggest that you reduce the number of bases with tab_base, col. 8, set to "Y". As described in KB 8192-6888, we in U.S. Support feel that 10% is a better number.

[From site:]
I made the changes to the tab_base.eng files and reran p_manage_32. With the call to $aleph_proc/p_manage_32_u.sql commented out, p_manage_32 completed without error. It ran in about 2.5 hours and there were no tablespace issues this time.

• Article last edited: 10/8/2013