[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ldm-5.0.8 pqact regular expression substitution problem (fwd)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: ldm-5.0.8 pqact regular expression substitution problem (fwd)
  • Date: Wed, 12 May 1999 09:35:24 -0600 (MDT)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Tue, 11 May 1999 10:54:58 -0500
From: Pete Pokrandt <address@hidden>
To: Robb Kambic <address@hidden>
Subject: Re: ldm-5.0.8 pqact regular expression substitution problem (fwd) 

In a previous message to me, you wrote: 

 >
 >Pete,
 >
 >Your ldm version of 5.0.8 doesn't have the palt.c patch included.  With
 >all the activities going on here, I only updated version 5.0.8 today.  You
 >might want to use the included patch or get the latest version 5.0.8
 >Hope this helps.
 >
 >
 >
 >Robb...
 >

Robb,

Yep, that patch solved the pqact problem.  I'm running 5.0.8 now, I'll
let you know of any further problems.

As for the large queue/swapping problem, I'm running kernel version
2.0.35 on a dual pII machine, with the rest of the operating system
being RedHat 5.1. I'm looking around to see if there are any kernel
changes in the more recent 2.0 or 2.2 series that address large memory
mapped files, or memory management in general. 

I believe that memory management in general is better in the 2.2
kernels, and there are also optimizations for newer processors (i.e.
Ppro, PII, etc) that take advantage of the newer architecture and speed
things up alot too, so I may try upgrading that machine to RH 5.2 or 6.0
and the 2.2 series of kernel.

If I find anything out, or have any successes or failures in all of
this, I'll forward the info along to you.

On the SGI IRIX 6.5 front, my queue has grown from the 120 Mb I set it
to (up to about 140 and leveled off). I'm not filtering the NOAAPort
stream at all, so that probably accounts for the large queue necessity.
It hasn't crashed since yesterday though (fingers crossed) so it looks
like the large queue size is the fix for that.

Thanks again for all your help!  Sorry to hit you with all these
questions/problems all at once, but now the semester is pretty much
over, and I've got a little time to look into these little nagging
problems.

Pete

--
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
^ Pete Pokrandt                    V 1515  AOSS Bldg  1225 W Dayton St^
^ Systems Programmer               V Madison,         WI     53706    ^
^                                  V      address@hidden       ^
^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (W)  222-0919 (H) ^
^ University of Wisconsin-Madison  V       262-0166 (Fax)262-3086 (VM)^
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+