>From: Unidata Support <address@hidden> >Organization: UCAR/Unidata >>Keywords: 200501201933.j0KJXOv2020815 McIDAS-XCD ADDE Hi Again Jim, OK, the McIDAS-X/-XCD rebuild finished and I reinstalled the full distribution. While on accas I found that XCDDATA had been defined to be 'pileus.geo.msu.edu'. I changed this and then reran the XCD BATCH setup scripts. I also deleted the ADDE dataset definition file, ~mcidas/workdata/RESOLV.SRV and recreated the datasets. After all of this I expected things to start working again, but they are not, or, at least, they didn't appear to be any different than they were prior to my rebuild. So, I started watching data being ingested through your LDM and found that you are requesting IDS|DDPLUS, HDS, UNIWISC, and FSL data from U. Wisconsin's f5.aos.wisc.edu. I tried changing that to a Unidata machine, but nothing improved. I then started to think about the fact that you are inserting data from a NOAAPORT receiver into your LDM queue using pqing, AND you are calling this data 'WMO'. I believe that what is going on is the following: - textual products from the 'WMO' stream are the same as ones you are requesting from UW. - the LDM MD5 checksum assigned to products is compared to products already in the LDM queue and the product is only inserted if a product with the same MD5 checksum is not already in the queue. The MD5 test does _not_ include any notion of the datastream this product belongs to! - the products being sent from UW are, therefore, being rejected since they have already been put into the LDM queue in your 'WMO' datastream - the XCD action in ~ldm/etc/pqact.conf says to send all textual products from the IDS|DDPLUS IDD stream to 'xcd_run DDS'. Since the products in 'WMO' from your NOAAPORT ingest machine get put into your LDM product queue before you receive the same ones from UW, you are essentially not receiving any data that should get processed by XCD decoders. This is why your McIDAS MDXX files are not being updated as they should. The solution to this dilemma is insert products from your NOAAPORT system into the LDM queue using datastream names that correspond to those used in the IDD. Note that if you attempt to send binary (i.e., HDS and NNEXRAD) products from your WMO stream into the McIDAS XCD text processing action ('xcd_run DDS'), the decoding should fail in unexpected ways. An alternative solution would be if you could figure out a regular expression for the products in your 'WMO' stream that selected just the textul products, then use that regular expression in a redone pqact.conf action that is something like: WMO <your regular expression for text products> PIPE xcd_run DDS WMO <your regular expression for grib message products> PIPE xcd_run HDS The final solution would be to stop your pqing process so that you would get IDS|DDPLUS products from UW. This was a tough one to understand! Cheers, Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.