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.
> I gave up on the IRIX machine this morning and have moved on to > the Linux machine this afternoon. The attempts at building a 6,5,4 g > queue were on Linux i386. The error below is on a Linux Athlon. I am > able to get beyond the 2^31 restriction, but not too far beyond. Doh! Sorry, I wasn't following this too closely until the bug report, and didn't look at the subject of your message, which clearly said it was on Linux. > I did not think that my Origin 2000 had enough horse power to > handle the big queue, since rpc.ldmd was taking a long time to start. It takes a long time to create a big queue, but I'd be surprised if it takes rpc.ldmd any longer to start up on an already-created big queue than on a small queue. At least I don't see any such difference on a Sun/Solaris. I'll look into that also. > I am happy to help you out in any way. The 3g queue is not quite > as big as I want, since the CONDUIT data is soo large... > > Also, I can not build a 3 g queue from the ldmadmin script, I have > to do it manually by specifying the "-s 3g" to pqcreate... So you might be able to get larger than 3G but smaller than 4G (which you said fails), by using something like pqcreate ... -s 3999m Also, if you have plenty of disk space for both the queue and any products you will put in the same partition, you can make pqcreate run much faster by using the "-f" option. This makes the queue allocate space as needed, and the only danger is rpc.ldmd would exit if at some point their was insufficient space on the disk partition for the whole queue, perhaps because a bunch of products had gobbled up the space ... --Russ