p_ret_adm_01 and p_ret_adm_02 sort problem

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

Article Type: General
Product: Aleph
Product Version: 20

Description:
When we run the General Retrieval File-02 (p_ret_adm_02) and select sort by title, the file that is opened in the Task Manager is sorted by doc. number. The file on the server is in title order. On the production server, see the file lmn in ABC50 $data_print. When I grep the file for z30-doc-number I can see that it is not in doc number order (for example, these 3 lines from the file:
289664:<z30-doc-number>1467615</z30-doc-number>
289783:<z30-doc-number>943273</z30-doc-number>
289902:<z30-doc-number>1315872</z30-doc-number>

But when I pull the file up in the Task Manager it is in doc number order.

The same can be seen in ABCs $data_print file dol_grf00_test. Why are these not sorting by title?

Resolution:
I observe that the last one hundred entries in lmn-test-4 are in title order (beginning with "ABRAZOS ROTOS" but the first 500+ are not.

./abc50/scratch/ret_adm_01_1.sorted is the work file used to produce lmn-test-4. This file shows the title info as *blank* for the first 500 entries and begins with title info only with these:

0000011TH HOUR 001500146000010
0000061 COOPERATIVE LEARNING ACTIVITIES FOR COMPUT 001448331000030
0000100 001386512000010
0001776 001074948000010
ABRAZOS ROTOS 001687364000010
ANNIE HALL 000085106000010
...
...

The following grep

grep '<z13-title-code>245' lmn-test-4

shows that these last 100 entries have z13-title-code's like

<z13-title-code>245 0</z13-title-code>
<z13-title-code>24510</z13-title-code>
<z13-title-code>24500</z13-title-code>

while the first 500+ have z13-title-code's like these:

<z13-title-code>245</z13-title-code>
<z13-title-code>2451</z13-title-code>

That is, they have zero or one indicator value rather than two.

It seems that these are mostly (or entirely) abc30 items.

The abc30 z13 000001214 has the following values:

02 z13_title_code .......2451
02 z13_title ............Win-win discipline

This comes from this value in the abc30 doc# 1214:

2451 L $$aWin-win discipline

abc01@ALEPH20> select count(*) from z13 where substr (z13_title_code,5,1) = ' ';
shows that there are 4,316 cases (out of 1,874,954) of blank second indicator in abc01 (0.2%).

abc30@ALEPH20> select count(*) from z13 where substr (z13_title_code,5,1) = ' ';
shows that there are 1,222 cases (out of 3,832) of blank second indicator in abc30 (31%).

abc30@ALEPH20> select count(*) from z13 where substr (z13_title_code,4,2) = ' ';
shows that there are 745 cases (out of 3,822) of blank first/second indicator in abc30 (19%).

Checking 245 at http://www.loc.gov/marc/bibliographic/bd245.html, I find that blank is *not* a legitimate value for either the 245 first or second indicator; the two legitimate values are 0 and 1.

I believe that the cases of blank should be "0" and that this can be done using p_manage_21 in abc30:

In the "Line in Record" section, you would put:

Tag 245
First indicator 1
Second indicator - (the "-" indicates that no indicator is present)

In the "Change Field" section (near the bottom), you would put:

Tag 245
First indicator 1
Second indicator 0

Similarly, in a separate, second run.

In the "Line in Record" section, you would put:

Tag 245
First indicator -
Second indicator - (the "-" indicates that no indicator is present)

In the "Change Field" section (near the bottom), you would put:

Tag 245
First indicator 0
Second indicator 0

Article last edited: 10/8/2013