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.
>From: Erick Lorenz (address@hidden) <address@hidden> >Organization: UC Davis >Keywords: 199910272007.OAA03748 McIDAS XCD Erick, >I have been trying to get the LDM to run correctly on ATM12, a SGI Origin >200 running Irix 6.5. > >Up till the most recent modification it was collecting DDPLUS|IDS|HRS >correctly but I was writing to a disk on another machine which I was >advised was not a good idea. Right. >I cleaned off a 4Gb disk on ATM12 called /kapok and created >a directory called /kapok/data/mcidas. > >I then added MCIDAS to the request line of ldmd.conf > > request (MCIDAS|DDPLUS|IDS|HRS) ".*" typhoon.atmos.ucla.edu > >and the following to pqact.conf > >MCIDAS ^(LWTOA3 .*) > PIPE > -close lwtoa3 -d /kapok/data/mcidas -l /usr/local/ldm/logs/mcidas.log > -xv > >which is similar to the entry on ATM23 which has been collecting AREA >files correctly. Only the -d entry is different to conform to the >path I want to use on ATM12. Does this work? >I still do not understand how the McIDAS-XCD processes know where to >write their products McIDAS locates products through file REDIRECTions and MCPATH directories. XCD, being McIDAS, does the same thing. There is a set of things that you should do when setting up XCD for the first time. Given that you are going to write to a brand new disk, you are essentially setting things up for the first time. >but I knew that they were writing to > > /home/data/mcidas or /home/data/xcd > >which were mount points to a disk on ATM23 so I just dismounted those >points, deleted them from fstab and created symbolic links in /home/data > >lrwxr-xr-x 1 root sys 18 Oct 26 17:56 mcidas -> /kapok/data/mcidas >lrwxr-xr-x 1 root sys 18 Oct 26 17:56 xcd -> /kapok/data/mcidas > >This strategy worked fine for the XCD stream. Those files are updating >nicely. OK. >However the AREA files are not being updated. They still have the >dates for when I copied them over from ATM23 eg: > >-rw-r--r-- 1 ldm unidata 308528 Oct 26 16:16 AREA0199 >-rw-r--r-- 1 ldm unidata 225088 Oct 26 16:16 AREA0200 >-rw-r--r-- 1 ldm unidata 225088 Oct 26 16:16 AREA0201 > >Also the ldmd.log file is not being written to but the following >entries can be found in /var/adm/SYSLOG: > >Oct 27 19:31:11 3Q:atm12 pqact[9231]: pipe_prodput: trying again >Oct 27 19:31:11 3Q:atm12 pqact[9231]: pbuf_flush (6) write: Broken pipe >Oct 27 19:31:11 3Q:atm12 pqact[9231]: pipe_dbufput: -closelwtoa3-d/kapok/ >data/mcidas-l/usr/local/ldm/logs/mcidas.log-xv write error > >and I am seeing the following on the system console. Sounds like there is a write premission problem on /kapok/data/mcidas. >Oct 27 18:10:51 pqact[8655]: pipe: execvp: lwtoa3: No such file or directory I don't understand this one. >I am also puzzled by the fact that the times shown in the SYSLOG, the >console and the "ldmadmin watch" display are 7 hours ahead of the >current time as shown by the date command. The times are in UTC, not local time. >The difference is about >right for GMT so I could understand it in the ldm messages but not >in the system messages. This would depend on how you have the system setup for time. >The pwd for... I logged onto atm12 and noticed that you were playing with the LDM. I verified that logging to ldmd.log was not working, so I can't see the error messages. I decided to change the directory permissions for /kapok/data to 775, and then I noticed that you restarted the LDM. A quick look at images in the directory shows that they are now being updated: cd /kapok/data/mcidas ls -lt AREA* | more -rw-rw-rw- 1 ldm unidata 607856 Oct 27 15:32 AREA0218 -rw-rw-rw- 1 ldm unidata 225088 Oct 27 15:32 AREA0117 -rw-rw-rw- 1 ldm unidata 225088 Oct 27 15:32 AREA0116 -rw-rw-rw- 1 ldm unidata 2422256 Oct 27 15:32 AREA0158 -rw-rw-rw- 1 ldm unidata 607776 Oct 27 15:29 AREA0069 -rw-rw-rw- 1 ldm unidata 607776 Oct 27 15:27 AREA0168 -rw-rw-rw- 1 ldm unidata 225088 Oct 27 15:25 AREA0101 -rw-rw-rw- 1 ldm unidata 225088 Oct 27 15:25 AREA0100 ... date Wed Oct 27 15:33:18 PDT 1999 So, either changing the directory permissions or something that you were fiddling with got the image decoding going. As far as the logging into ~ldm/logs/ldmd.log, I would suggest killing and restarting syslogd to see if that gets things moving. >Thank you Whatever happened to the McIDAS build on the DEC OSF/1 machine? Tom