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

Description:
Since last night our Course Reserves module is consistently unavailable. I have re-started the web server countless times today to try and keep it up, but to no avail. The OPAC is not affected but users consistently cannot log in to the course reserves module.

Either nothing happens at all when you try and get in or you get the error:

Not Found The requested URL /&server_staff/file/s-main-1 was not found on this server

or the error:

The requested file was not found on the server. Please contact the library administration and inform them about this problem.

I see the following error in the www_server.log but don't know what it means or if it's related to the course reserves going down:
WWW-F : FULL-SET-SET
Enviroment Table needs more than 1000 lines
Enviroment Table needs more than 1000 lines
Enviroment Table needs more than 1000 lines
Enviroment Table needs more than 1000 lines
Enviroment Table needs more than 1000 lines
<etc.>

Resolution:
<From Jerry:>

On Tuesday I added displays to the program which builds the "Enviroment table". A sample -- from the www_server__4991.log -- can be seen below.

As we can see, it is including &rsquo; &ldqou; &rdquo; and, especially &gt; --

TAB-ENV-NO-LINES= 000000166
ENV-NAME= rsquo;Eugenio
TAB-ENV-NO-LINES= 000000168
ENV-NAME= rsquo;histoire
TAB-ENV-NO-LINES= 000000170
ENV-NAME= rsquo;Hom?¨re
TAB-ENV-NO-LINES= 000000172
ENV-NAME= rsquo;abolition
TAB-ENV-NO-LINES= 000000174
ENV-NAME= rsquo;esclavage
TAB-ENV-NO-LINES= 000000176
ENV-NAME= rsquo;un
TAB-ENV-NO-LINES= 000000178
ENV-NAME= rsquo;d
...
TAB-ENV-NO-LINES= 000000152
ENV-NAME= gt;(OCoLC)ocm21670185
TAB-ENV-NO-LINES= 000000154
ENV-NAME= gt;AED9949
TAB-ENV-NO-LINES= 000000156
ENV-NAME= gt;(OCoLC)ocm07843282
TAB-ENV-NO-LINES= 000000158
ENV-NAME= gt;AEB6127
TAB-ENV-NO-LINES= 000000160
ENV-NAME= gt;(OCoLC)ocm02270773
TAB-ENV-NO-LINES= 000000162
ENV-NAME= gt;(OCoLC)ocm00419736
TAB-ENV-NO-LINES= 000000164
ENV-NAME= gt;(GRSN)00068004
TAB-ENV-NO-LINES= 000000166
ENV-NAME= gt;AAK1763
TAB-ENV-NO-LINES= 000000168
ENV-NAME= gt;(OCoLC)ocm00181264
TAB-ENV-NO-LINES= 000000170
ENV-NAME= gt;(GRSN)00070611
TAB-ENV-NO-LINES= 000000172
ENV-NAME= gt;AAK4148
...
ENV-NAME= ldquo;
TAB-ENV-NO-LINES= 000000038
ENV-NAME= rdquo;
...
TAB-ENV-NO-LINES= 000000930
ENV-NAME= gt;(OCoLC)ocm34727346
TAB-ENV-NO-LINES= 000000932
ENV-NAME= gt;AEW2757
TAB-ENV-NO-LINES= 000000934
ENV-NAME= gt;(OCoLC)ocm27308467
TAB-ENV-NO-LINES= 000000936
ENV-NAME= gt;AEZ5721
TAB-ENV-NO-LINES= 000000938
ENV-NAME= gt;O
TAB-ENV-NO-LINES= 000000940
ENV-NAME= gt;(OCoLC)ocm11076887
TAB-ENV-NO-LINES= 000000942
ENV-NAME= gt;(GRSN)00479943
TAB-ENV-NO-LINES= 000000944
ENV-NAME= gt;ACR3195
TAB-ENV-NO-LINES= 000000946
ENV-NAME= gt;8750-7137
TAB-ENV-NO-LINES= 000000948
ENV-NAME= gt;(OCoLC)ocm08075153
TAB-ENV-NO-LINES= 000000950
ENV-NAME= gt;AER9369
TAB-ENV-NO-LINES= 000000952
ENV-NAME= gt;1071-2984
TAB-ENV-NO-LINES= 000000954
ENV-NAME= gt;(OCoLC)ocm04037347
TAB-ENV-NO-LINES= 000000956
ENV-NAME= gt;AFK0495
...
TAB-ENV-NO-LINES= 000000988
ENV-NAME= gt;(OCoLC)ocm61262401
TAB-ENV-NO-LINES= 000000990
ENV-NAME= gt;(OCoLC)ocm40417776
TAB-ENV-NO-LINES= 000000992
ENV-NAME= gt;AFM9895
TAB-ENV-NO-LINES= 000000994
ENV-NAME= gt;YAJ9360
TAB-ENV-NO-LINES= 000000996
ENV-NAME= gt;(OCoLC)ocm34943170
TAB-ENV-NO-LINES= 000000998
ENV-NAME= gt;YAG0473
TAB-ENV-NO-LINES= 000001000
ENV-NAME= gt;(OCoLC)ocm20356444
Enviroment Table needs more than 1000 lines
Enviroment Table needs more than 1000 lines

The environment table is dynamic. But we see that it is hitting 1000 at your site while at other sites it isn't.

It seems to me that these "&gt's", etc., should not be in this table. (It should not be doing a "getenv" to see if they are defined as global variables in ALEPH.)

It's my belief that there is something about the ./www_f_eng/short-a-body-abser or /short-a-body-abc01. This is circumstantial, based on the fact that the update date on these files corresponded exactly to the time that this problem started happening (on Monday afternoon).

I suggested that, *as a test*, you temporarily replace short-a-body-abc01 with

Aug 20 14:39 short-a-body-abc01.20070807

and delete the short-a-body-abser . (And do util x/7 to clear the utf_files to make the older version take effect.)


<From site:>

I modified the code so that &gt; and &lt; HTML special characters no longer appear in the short-a-body tables. The problem was caused by the following modification to edit_field.eng:

1 # SFXLK D B ##
2 a A <AA> </AA>
2 b A <BB> </BB>

We created the SFXLK field as a virtual field concatenating the 035 and the ISSN fields.

We then used JavaScript in short-a-body to parse either the SFX ID, or, if the SFX ID does not exist, the ISSN.
The parsed field is then dynamically inserted into an OpenURL.

The <AA></AA> were simply placeholders to help parse the field. Aleph displays them as &lt;AA/&gt; in the source code.

As you discovered, the www_server was reading these HTML special characters as variables. We have used this technique elsewhere in our OPAC customizations, but the change I made last week - because of the sheer numbers of 035 and ISSN fields - caused the table to fill-up.

It seems to me that Aleph should not be checking to see if everything that has an ampersand before it is a variable - at least not for standard HTML characters...

• Article last edited: 10/8/2013