[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20050810: 20050810: Endlless loop of log files
- Subject: 20050810: 20050810: Endlless loop of log files
- Date: Wed, 10 Aug 2005 12:58:30 -0600
Nancy,
The LDM does not know anything about GEMPAK decoders, and its
installation cannot populate the decoders directory with dc* programs.
I don't know the source of your dc* programs in the decoders directory, but
they are not the same as the executables under the $GEMEXE directory as
you noted whenyou said that in the $NAWIPS directory you could run the
dcmetr -h and get the online help, but not from the ~ldm/decoders/dcmetr.
You should copy your $GEMEXE/dc* programs to the ~ldm/decoders directory
again and see if that is in fact the problem.
Steve Chiswell
>From: Nancy Selover <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200508101744.j7AHi4jo012137
>Steve,
> Correction, the old LDM computer has the nested logs. I was in
>the wrong window, as I am still working with the old LDM as it's
>archiving data for us. It is linked forever, but when I deleted all the
>old files, I only needed to deleted them once. I have to break the
>link. The files were all old, back when we stopped the pqbinstats from
>running in February.
>
> With regard to the new LDM, the new installation of LDM created
>the decoders folder and populated it with all the decoders, except the
>ones I copied in yesterday from $GEMEXE which were: dccraft_move,
>dcrotatelog.csh, and dcgunzip The permissions of all the decoders are
>-rwxrwxr-x EXCEPT dccraft_move and dcrotatelog.csh which are
>-rwxr-xr-x
>
>Nancy
>
>-----Original Message-----
>From: Unidata Support [mailto:address@hidden]
>Sent: Wednesday, August 10, 2005 9:58 AM
>To: Nancy Selover
>Cc: Unidata Support; address@hidden
>Subject: 20050810: Endlless loop of log files
>
>
>Nancy,
>
>The *.stats files would have been created by the use of an old program
>called pqbinstats, that is no longer used as part of the LDM.
>This is a new LDM installation correct? Verify that you don't have an
>"exec pqbinstats" line in your ldmd.conf.
>
>Are these all old files? Or have them been created recently. You can
>remove the .stats files. The depth of ./logs/logs/logs is strange
>though.
>This would be a directory found in the syslog.conf file for ldmd.log.
>You may need to check any symbolic links you have in your LDM tree to
>make sure you haven't gone off somewhere unexpectedly.
>
>Also check your crontab for obsolete entries of "ldmadmin dostats".
>
>Back to the dc*. You said the programs were able to be executed when you
>were in the $NAWIPS directory, but when you specifically tried to launch
>the dcmetr in $LDMHOME/decoders, you got a error in trying to execute
>binary file. That sort of sounds like the files in ~ldm/decoders are not
>the correct operating system decoders that you have in your $GEMEXE
>directory. Could they have been copied from another old (OSF/1?) system?
>
>The ldm-mcidas log files are created from the pnga2area and pngg2gini
>decoders from the ldm-mcidas distribution. It sounds like they are being
>routated to keep the last 8.
>
>Steve Chiswell
>
>
>
>>From: Nancy Selover <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200508101645.j7AGjSjo005409
>
>>Steve,
>> I have X permission across the board for the decoders. However,
>I
>>have a problem with an endless loop of log files. I have
>>~/data/ldm/logs/logs/logs/..... And in each one is a bunch of
>>YYYY02HHMM.stats files, plus ldm-mdcidas.logs.1 etc through log.7.
>>
>>Where is this being written from??
>>Nancy
>>
>>-----Original Message-----
>>From: Unidata Support [mailto:address@hidden]
>>Sent: Wednesday, August 10, 2005 7:19 AM
>>To: Nancy Selover
>>Cc: Unidata Support
>>Subject: 20050809: 20050808: LDM write errors from decoders
>>
>>
>>Nancy,
>>
>>It sounds like the decoders you copied over to $LDMHOME/decoders do not
>
>>have execute permission.
>>Do an "ls -l" in that directory and see if all users have executs "x"
>>permission.
>>If not, you can run "chmod a+x dc*" to add the execute permission.
>>
>>Steve Chiswell
>>Unidata User SUpport
>>
>>
>>
>>>From: Nancy Selover <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200508100111.j7A1BUjo021372
>>
>>>Steve,
>>> I have the decoders all in a directory $LDMHOME/decoders and
>>when I
>>>use the command: dcmetr -h I get the error message:
>>>
>>>/huser/ldm/decoders/dcmetr: /huser/ldm/decoders/dcmetr: cannot execute
>
>>>binary file
>>>
>>>When I am in $NAWIPS and enter the command, I get a big help file.
>>>Since no data are being written, I don't know how to invoke dcmetr for
>
>>>a file in the queue.
>>>
>>>Nancy
>>>
>>>-----Original Message-----
>>>From: Unidata Support [mailto:address@hidden]
>>>Sent: Tuesday, August 09, 2005 2:45 PM
>>>To: Nancy Selover
>>>Cc: Unidata Support
>>>Subject: 20050809: 20050808: LDM write errors from decoders
>>>
>>>>From: Nancy Selover <address@hidden>
>>>>Organization: UCAR/Unidata
>>>>Keywords: 200508092108.j79L8wjo024617
>>>
>>>>Steve,
>>>>
>>>>Adding the "/" in Gemenviron helped NWX, as now I can see most of the
>
>>>>messages and products. I still get the error message, which has the
>>>>leading "/", but it only happens to certain products, perhaps those
>>>>are
>>>
>>>>products I commented out in the pqact.gempak_nwx file.
>>>
>>>Nancy,
>>>
>>>Not every product in NWX is available all the time. A few will only be
>
>>>broadcast 1x per month (like the 30 day outlook). Some are only
>>>broadcast when a particular event occurs, such as a hurricane local
>>>statement.
>>>
>>>It sounds like things are normal, unless you have a common product
>>>like
>>
>>>a Zone forecast, MOS, etc which do not appear after at least one day.
>>>
>>>
>>>>
>>>>The bigger problem is I am still not getting the surface or upper air
>
>>>>obs or models or satellite images to write to directories. The
>>>>connection is they are all decoded files. I have checked the
>>>>pqact.gempak_decoders file, and there is no leading "/" for any of
>>>>entries in that file. They all say, for example:
>>>>
>>>>HDS ^[YZ].[A]... KWBH
>>>> PIPE decoders/dcgrib2 -d data/gempak/logs/dcgrib2_MRF.log
>>>> -e GEMTBL=/huser/gempak/GEMPAK5.8.2a/gempak/tables
>>>>
>>>>But, there is NO log directory under /var/data/gempak so I can't see
>>>>the logs.
>>>
>>>The LDM uses relative (to $LDMHOME which was set when LDM was built).
>>>You should copy of link your $GEMEXE/dc* programs to an ~ldm/decoders
>>>directory (which you have to create). You will also want to copy or
>>>link
>>>
>>>the shell script $NAWIPS/bin/scripts/dcgunzip to ~ldm/decoders.
>>>
>>>If you are receiving the CRAFT feed you will want to copy or link
>>>$NAWIPS/bin/scripts/dccraft_move to an ~ldm/util directory.
>>>
>>>
>>>The decoders will create their directories, but if they are failing
>>>earlier than that point, you can create the ~ldm/data/gempak/logs
>>>directory by hand. You can always try launching a decoder from the
>>>command line, such as "dcmetr -h". It should print out some help
>>>information. If it fails, then something more basic is wrong.
>>>
>>>
>>>>
>>>>Also, the other type of entry without the leading "/" is like this:
>>>>
>>>>WMO ^S[AP]
>>>> PIPE decoders/dcmetr -a 500 -m 72 -s sfmetar_sa.tbl
>>>> -d data/gempak/logs/dcmetr.log
>>>> -e GEMTBL=/huser/gempak/GEMPAK5.8.2a/tables
>>>> data/gempak/surface/YYYYMMDD_sao.gem
>>>>
>>>>I did not edit these, except to update the version to 5.8.2a
>>>>
>>>>I am also not getting the satellite imagery and I have set up the
>>>>nsat_links script in the crontab and checked the path.
>>>
>>>nsat_links shouldn't be needed, unless you aren't going to use gempak
>>>naming for the pnga2area actions- but rather file to AREAxxxx McIDAS
>>>style names.
>>>I haven't used nsat_links for about 4 years. Tom now supports the
>>>GEMPAK style file name in the McIDAS distribution.
>>>
>>>
>>>>
>>>>The radar are coming in, but Garp can't see the directory structure.
>>>
>>>Your Level III data should be found under $RAD/NIDS/ where $RAD should
>
>>>be set in Gemenviron to $GEMDATA/nexrad.
>>>
>>>Steve Chiswell
>>>Unidata User Support
>>>
>>>
>>>>
>>>>Nancy
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Unidata Support [mailto:address@hidden]
>>>>Sent: Tuesday, August 09, 2005 9:54 AM
>>>>To: Nancy Selover
>>>>Cc: Unidata Support
>>>>Subject: 20050808: LDM write errors from decoders
>>>>
>>>>
>>>>Nancy,
>>>>
>>>>I can help you with GEMPAK decoders and program access to the data.
>>>>
>>>>For the NWX access problems, check your GEMDATA environmantal
>>>>variable
>>
>>>>as configured in your $NAWIPS/Gemenviron file. That should point to
>>>your
>>>>/var/data/ldm/gempak directory. In looking at the error message you
>>>show
>>>>below, you are missing the leading "/" in the directory name, and I
>>>need
>>>>to know if that was a typo, or the root of the problem.
>>>>
>>>>The environmental variable $TEXT_DATA will be set to $GEMDATA/nwx in
>>>>Gemenviron, so this also relieas on the GEMDATA variable being
>>correct.
>>>>
>>>>Steve Chiswell
>>>>Unidata User Support
>>>>
>>>>
>>>>>From: Nancy Selover <address@hidden>
>>>>>Organization: UCAR/Unidata
>>>>>Keywords: 200508090157.j791vPjo029601
>>>>
>>>>>This is a multi-part message in MIME format.
>>>>>
>>>>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)
>>>>>Content-type: multipart/alternative;
>>>>>boundary="Boundary_(ID_ithdHyIr2omZeORHgiZROw)"
>>>>>
>>>>>
>>>>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)
>>>>>Content-type: text/plain; charset="us-ascii"
>>>>>Content-transfer-encoding: quoted-printable
>>>>>
>>>>>
>>>>>Gempak can't find the LDM files. We finally got LDM running after
>>>>>commenting out the network IP address, and it's busy writing the NWX
>
>>>>>and Radar data. However, Gempak cannot read any of it. Garp can't
>>>>>find the directory structure, although the NIDS files are exactly
>>>where
>>>>
>>>>>they should be. The NWX files are all there and show up in the NWX
>>>>>program, but when I click on any of the files, I get:
>>>>>NWX: Error scanning directory
>'var/data/ldm/gempak/nwx/pub_prod/SFT'
>>>>>or which ever product I selected. =20
>>>>>
>>>>>When I looked at the directory structure, data is linked to
>>>>>/var/data/ldm and /var/data is owned by root, while /var/data/ldm
>>>is
>>>>
>>>>>owned by ldm and the ldm and gempak users all have permissions. =20
>>>=20
>>>>
>>>>>I can't find this on the e-mail archives. I have tried checking all
>
>>>>>the configuration files to make sure they are sending the data to
>>>>>the
>>
>>>>>right place, but I can't find anything wrong. Attached is a piece
>>>>>of
>>
>>>>>the log file from the ldmd.log, showing that there are write errors
>>>>>from the decoders, as well as from the Mcidas satellite imagery
>>>script.
>>>>
>>>>>I haven't got NSAT_LINKS set yet, so I'm not particularly worried
>>>about
>>>>
>>>>>that yet. But I should be able to get the surface and upper air
>obs.
>>>
>>>>>I am using the configuration files from mothra (LDM 6.10.0) on the
>>>>>new
>>>
>>>>>version, but I changed the version number for GEMPAK from 5.7.4 to
>>>>>5.8.2a throughout. It was easier than trying to find the changes in
>
>>>>>products from the old file to the new file. =20
>>>>>
>>>>>Sorry to be such a pest, but this is our first time setting the
>>>>>programs up from scratch on a new machine (FC3).
>>>>>
>>>>> <<writeerrors.txt>>=20
>>>>>
>>>>>Our older machine crashed that was running Gempak, so I really need
>>>>>to
>>>
>>>>>get this running. If it's something really simple and stupid I did,
>
>>>>>that's great, just let me know. If there's an e-mail archive that
>>>>>covers this, send me the link or the exact subject line. If you
>>>>>need
>>
>>>>>to poke around in the machine, let me know that, and I'll call you
>>>with
>>>>
>>>>>the password.
>>>>>
>>>>>Thank you,
>>>>>Nancy
>>>>>
>>>>>Nancy J. Selover=20
>>>>>Asst. State Climatologist=20
>>>>>Office of Climatology tel: 480-965-0580=20 Arizona State University
>>>>>fax: 480-965-1473=20 Tempe, AZ 85287-1508 e-mail: address@hidden=20
>>>>>
>>>>>
>>>>>
>>>>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)
>>>>>Content-type: text/html; charset="us-ascii"
>>>>>Content-transfer-encoding: quoted-printable
>>>>>
>>>>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD>
>>>>><META
>>
>>>>>HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>>>>>charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange
>
>>>>>Server version = 6.5.7226.0"> <TITLE>LDM write errors from
>>>>>decoders</TITLE> </HEAD> <BODY>
>>>>><!-- Converted from text/rtf format --> <BR>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial">Gempak can't find the LDM
>>>files.
>>>>
>>>>>= We finally got LDM running after commenting out the network IP
>>>>>address, = and it's busy writing the NWX and Radar data.
>>>However,
>>>>
>>>>>Gempak = cannot read any of it. Garp can't find the directory
>>>>>structure, = although the NIDS files are exactly where they should
>>>>>be. The NWX = files are all there and show up in the NWX
>>>program,
>>>>
>>>>>but when I click on = any of the files, I get:</FONT></P>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial">NWX: Error scanning directory
>
>>>>>=
>>>
>>>>>'var/data/ldm/gempak/nwx/pub_prod/SFT' or which ever product I
>
>>>>>=
>>>
>>>>>selected. </FONT> </P>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial">When I looked at the directory =
>>>>>structure, data is linked to /var/data/ldm
>>>>>and
>>>
>>>>>= /var/data is owned by root, while /var/data/ldm is
>>>>>owned
>>>
>>>>>by = ldm and the ldm and gempak users all have permissions.
>>>>></FONT></P>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial"> </FONT>
>>>>>
>>>>><BR><FONT SIZE=3D2 FACE=3D"Arial">I can't find this on the e-mail =
>>>>>archives. I have tried checking all the configuration files to
>
>>>>>=
>>>
>>>>>make sure they are sending the data to the right place, but I can't
>>>>>find = anything wrong. Attached is a piece of the log file
>>>>>from
>>
>>>>>the = ldmd.log, showing that there are write errors from the
>>>>>decoders,
>>>
>>>>>as well = as from the Mcidas satellite imagery script. I
>>>>>haven’t got = NSAT_LINKS set yet, so I'm not particularly
>>>worried
>>>>
>>>>>about that = yet. But I should be able to get the surface and
>>>>>upper air = obs. I am using the configuration files from
>>>>>mothra
>>
>>>>>(LDM 6.10.0) = on the new version, but I changed the version number
>>>for
>>>>
>>>>>GEMPAK from =
>>>>>5.7.4 to 5.8.2a throughout. It was easier than trying to find
>>>the
>>>>
>>>>>= changes in products from the old file to the new file.
>>>>></FONT></P>
>>>>>
>>>><P><FONT SIZE=3D2 FACE=3D"Arial">Sorry to be such a pest, but this is
>>>=
>>>>
>>>>>our first time setting the programs up from scratch on a new machine
>
>>>>>=
>>>
>>>>>(FC3).</FONT> </P>
>>>>>
>>>>><P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
>>>>><<writeerrors.txt>> </FONT> </P>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial">Our older machine crashed that was
>>>>>=
>>
>>>>>running Gempak, so I really need to get this running. If it's
>>>>>=
>>
>>>>>something really simple and stupid I did, that's great, just let me
>>>>>=
>>
>>>>>know. If there's an e-mail archive that covers this, send me
>>>>>the
>>>
>>>>>= link or the exact subject line. If you need to poke around
>>>>>in
>>
>>>>>the = machine, let me know that, and I'll call you with the =
>>>>>password.</FONT></P>
>>>>>
>>>>><P><FONT SIZE=3D2 FACE=3D"Arial">Thank you,</FONT>
>>>>>
>>>>><BR><FONT SIZE=3D2 FACE=3D"Arial">Nancy</FONT> </P>
>>>>>
>>>>><P><B><I><FONT SIZE=3D2 FACE=3D"Arial">Nancy J. =
>>>>>Selover</FONT></I></B><I></I><FONT FACE=3D"Times New Roman"><BR>
>>>>></FONT><I></I><I><FONT SIZE=3D2 FACE=3D"Arial">Asst. State =
>>>>>Climatologist</FONT></I><FONT FACE=3D"Times New Roman"><BR>
>>>>></FONT><FONT SIZE=3D2 FACE=3D"Arial">Office of Climatology tel: =
>>>>>480-965-0580</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>>>>SIZE=3D2 FACE=3D"Arial">Arizona State University fax: =
>>>>>480-965-1473</FONT><FONT FACE=3D"Times New Roman"><BR> </FONT><FONT
>>>>>SIZE=3D2 FACE=3D"Arial">Tempe, AZ 85287-1508 e-mail: =
>>>>>address@hidden</FONT><FONT FACE=3D"Times New Roman"> </FONT> </P>
>>><BR>
>>>>>
>>>>></BODY>
>>>>></HTML>=
>>>>>
>>>>>--Boundary_(ID_ithdHyIr2omZeORHgiZROw)--
>>>>>
>>>>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)
>>>>>Content-type: text/plain; name="writeerrors.txt"
>>>>>Content-transfer-encoding: base64
>>>>>Content-disposition: attachment; filename="writeerrors.txt"
>>>>>Content-description: writeerrors.txt
>>>>>
>>>>>QXVnIDA5IDAwOjEyOjU2IGdvZHppbGxhIGNpcnBbNDY1MV06IERlc2lyZWQgcHJvZHVj
>>>>>d
>>>>>C
>>>B
>>>>>jbGFz
>>>>>czogMjAwNTA4MDgyMzEyNTYuNDY2IFRTX0VORFQge3tFWFAsICAiLioifX0gDQpBdWcg
>>>>>M
>>>>>D
>>>k
>>>>>gMDA6
>>>>>MTI6NTYgZ29kemlsbGEgY2lycFs0NjUxXTogQ29ubmVjdGVkIHRvIHVwc3RyZWFtIExE
>>>>>T
>>>>>S
>>0
>>>>>2IA0K
>>>>>QXVnIDA5IDAwOjEyOjU2IGdvZHppbGxhIGNpcnBbNDY1MV06IEVSUk9SOiByZXF1ZXN0
>>>>>Z
>>>>>X
>>>I
>>>>>2LmM6
>>>>>Mjc4OiBVcHN0cmVhbSBMRE0gZGlkbid0IHJlcGx5IHRvIEZFRURNRSByZXF1ZXN0OyBy
>>>>>Z
>>>>>X
>>>F
>>>>>1ZXN0
>>>>>ZXI2LmM6Mjc4OiBSUEM6IEF1dGhlbnRpY2F0aW9uIGVycm9yOyB3aHkgPSAoYXV0aGVu
>>>>>d
>>>>>G
>>>l
>>>>>jYXRp
>>>>>b24gZXJyb3IgNSkgDQpBdWcgMDkgMDA6MTI6NTkgZ29kemlsbGEgcHFhY3RbNDY0NF06
>>>>>I
>>>>>G
>>>N
>>>>>oaWxk
>>>>>IDUxNTcgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAwOSAwMDoxMzowMiBnb2R6
>>>>>a
>>>>>W
>>>x
>>>>>sYSBw
>>>>>cWFjdFs0NjQ0XTogY2hpbGQgNTE2MiBleGl0ZWQgd2l0aCBzdGF0dXMgMTI2IA0KQXVn
>>>>>I
>>>>>D
>>>A
>>>>>5IDAw
>>>>>OjEzOjA1IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBjaGlsZCA1MTY3IGV4aXRlZCB3aXRo
>>>>>I
>>>>>H
>>>N
>>>>>0YXR1
>>>>>cyAxMjYgDQpBdWcgMDkgMDA6MTM6MDggZ29kemlsbGEgcHFhY3RbNDY0NF06IGNoaWxk
>>>>>I
>>>>>D
>>>U
>>>>>xNzIg
>>>>>ZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAwOSAwMDoxMzoxNCBnb2R6aWxsYSBw
>>>>>c
>>>>>W
>>>F
>>>>>jdFs0
>>>>>NjQ0XTogY2hpbGQgNTE3NyBleGl0ZWQgd2l0aCBzdGF0dXMgMTI2IA0KQXVnIDA5IDAw
>>>>>O
>>>>>j
>>>E
>>>>>zOjE1
>>>>>IGdvZHppbGxhIHBxYWN0WzQ2NDddOiBwYnVmX2ZsdXNoICgzKSB3cml0ZTogQnJva2Vu
>>>>>I
>>>>>H
>>>B
>>>>>pcGUg
>>>>>DQpBdWcgMDkgMDA6MTM6MTUgZ29kemlsbGEgcHFhY3RbNDY0N106IHBpcGVfcHV0OiAt
>>>>>Y
>>>>>2
>>>x
>>>>>vc2Vk
>>>>>ZWNvZGVycy9wbmdhMmFyZWEtdmwvdXNyL2xvY2FsL2xkbS9sb2dzL2xkbS1tY2lkYXMu
>>>>>b
>>>>>G
>>>9
>>>>>nLWFl
>>>>>dGMvU0FUQU5OT1QtYmV0Yy9TQVRCQU5EL3Zhci9kYXRhL2xkbS9nZW1wYWsvaW1hZ2Vz
>>>>>L
>>>>>3
>>>N
>>>>>hdC9H
>>>>>T0VTLTEwLzhrbS9XVi9XVl8yMDA1MDgwOV8wMDAwIHdyaXRlIGVycm9yIA0KQXVnIDA5
>>>>>I
>>>>>D
>>>A
>>>>>wOjEz
>>>>>OjE1IGdvZHppbGxhIHBxYWN0WzQ2NDddOiBwaXBlX3Byb2RwdXQ6IHRyeWluZyBhZ2Fp
>>>>>b
>>>>>i
>>>A
>>>>>NCkF1
>>>>>ZyAwOSAwMDoxMzoxNiBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogcGJ1Zl9mbHVzaCAoMykg
>>>>>d
>>>>>3
>>>J
>>>>>pdGU6
>>>>>IEJyb2tlbiBwaXBlIA0KQXVnIDA5IDAwOjEzOjE2IGdvZHppbGxhIHBxYWN0WzQ2NDdd
>>>>>O
>>>>>i
>>>B
>>>>>waXBl
>>>>>X3B1dDogLWNsb3NlZGVjb2RlcnMvcG5nYTJhcmVhLXZsL3Vzci9sb2NhbC9sZG0vbG9n
>>>>>c
>>>>>y
>>>9
>>>>>sZG0t
>>>>>bWNpZGFzLmxvZy1hZXRjL1NBVEFOTk9ULWJldGMvU0FUQkFORC92YXIvZGF0YS9sZG0v
>>>>>Z
>>>>>2
>>>V
>>>>tcGFr
>>>>>L2ltYWdlcy9zYXQvR09FUy0xMC84a20vV1YvV1ZfMjAwNTA4MDlfMDAwMCB3cml0ZSBl
>>>>>c
>>>>>n
>>>J
>>>>>vciAN
>>>>>CkF1ZyAwOSAwMDoxMzoxNiBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogY2hpbGQgNTE4MiBl
>>>>>e
>>>>>G
>>>l
>>>>>0ZWQg
>>>>>d2l0aCBzdGF0dXMgMTI2IA0KQXVnIDA5IDAwOjEzOjE2IGdvZHppbGxhIHBxYWN0WzQ2
>>>>>N
>>>>>D
>>>d
>>>>>dOiBj
>>>>>aGlsZCA1MTg3IGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MTcg
>>>>>Z
>>>>>2
>>>9
>>>>>kemls
>>>>>bGEgcHFhY3RbNDY0NF06IGNoaWxkIDUxOTUgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiAN
>>>>>C
>>>>>k
>>>F
>>>>>1ZyAw
>>>>>OSAwMDoxMzoxNyBnb2R6aWxsYSBwcWFjdFs0NjQ0XTogY2hpbGQgNTE5MiBleGl0ZWQg
>>>>>d
>>>>>2
>>>l
>>>>>0aCBz
>>>>>dGF0dXMgMTI2IA0KQXVnIDA5IDAwOjEzOjE3IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBj
>>>>>a
>>>>>G
>>>l
>>>>>sZCA1
>>>>>MTk4IGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MTcgZ29kemls
>>>>>b
>>>>>G
>>>E
>>>>>gcHFh
>>>>>Y3RbNDY0NF06IGNoaWxkIDUyMDcgZXhpdGVkIHdpdGggc3RhdHVzIDEyNiANCkF1ZyAw
>>>>>O
>>>>>S
>>>A
>>>>>wMDox
>>>>>MzoxNyBnb2R6aWxsYSBwcWFjdFs0NjQ0XTogY2hpbGQgNTIxMCBleGl0ZWQgd2l0aCBz
>>>>>d
>>>>>G
>>>F
>>>>>0dXMg
>>>>>MTI2IA0KQXVnIDA5IDAwOjEzOjE4IGdvZHppbGxhIHBxYWN0WzQ2NDRdOiBjaGlsZCA1
>>>>>M
>>>>>j
>>>E
>>>>>zIGV4
>>>>>aXRlZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MjEgZ29kemlsbGEgcHFh
>>>>>Y
>>>>>3
>>>R
>>>>>bNDY0
>>>>>N106IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlwZSANCkF1ZyAwOSAwMDox
>>>>>M
>>>>>z
>>>o
>>>>>yMSBn
>>>>>b2R6aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9zZWRlY29kZXJzL3BuZ2Ey
>>>>>Y
>>>>>X
>>>J
>>>>>lYS12
>>>>>bC91c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ctYWV0Yy9TQVRBTk5PVC1i
>>>>>Z
>>>>>X
>>>R
>>>>>jL1NB
>>>>>VEJBTkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0L0dPRVMtMTAvNGttL1ZJ
>>>>>U
>>>>>y
>>>9
>>>>>WSVNf
>>>>>MjAwNTA4MDlfMDAwMCB3cml0ZSBlcnJvciANCkF1ZyAwOSAwMDoxMzoyMSBnb2R6aWxs
>>>>>Y
>>>>>S
>>>B
>>>>>wcWFj
>>>>>dFs0NjQ3XTogcGlwZV9wcm9kcHV0OiB0cnlpbmcgYWdhaW4gDQpBdWcgMDkgMDA6MTM6
>>>>>M
>>>>>j
>>>E
>>>>>gZ29k
>>>>>emlsbGEgcHFhY3RbNDY0N106IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlw
>>>>>Z
>>>>>S
>>>A
>>>>>NCkF1
>>>>>ZyAwOSAwMDoxMzoyMSBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9z
>>>>>Z
>>>>>W
>>>R
>>>>>lY29k
>>>>>ZXJzL3BuZ2EyYXJlYS12bC91c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ct
>>>>>Y
>>>>>W
>>>V
>>>>>0Yy9T
>>>>>QVRBTk5PVC1iZXRjL1NBVEJBTkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0
>>>>>L
>>>>>0
>>>d
>>>>>PRVMt
>>>>>MTAvNGttL1ZJUy9WSVNfMjAwNTA4MDlfMDAwMCB3cml0ZSBlcnJvciANCkF1ZyAwOSAw
>>>>>M
>>>>>D
>>>o
>>>>>xMzoy
>>>>>MSBnb2R6aWxsYSBwcWFjdFs0NjQ3XTogY2hpbGQgNTIyMiBleGl0ZWQgd2l0aCBzdGF0
>>>>>d
>>>>>X
>>>M
>>>>>gMTI2
>>>>>IA0KQXVnIDA5IDAwOjEzOjIxIGdvZHppbGxhIHBxYWN0WzQ2NDddOiBjaGlsZCA1MjI3
>>>>>I
>>>>>G
>>>V
>>>>>4aXRl
>>>>>ZCB3aXRoIHN0YXR1cyAxMjYgDQpBdWcgMDkgMDA6MTM6MjIgZ29kemlsbGEgcHFhY3Rb
>>>>>N
>>>>>D
>>>Y
>>>>>0N106
>>>>>IHBidWZfZmx1c2ggKDMpIHdyaXRlOiBCcm9rZW4gcGlwZSANCkF1ZyAwOSAwMDoxMzoy
>>>>>M
>>>>>i
>>>B
>>>>>nb2R6
>>>>>aWxsYSBwcWFjdFs0NjQ3XTogcGlwZV9wdXQ6IC1jbG9zZWRlY29kZXJzL3BuZ2EyYXJl
>>>>>Y
>>>>>S
>>>1
>>>>>2bC91
>>>>>c3IvbG9jYWwvbGRtL2xvZ3MvbGRtLW1jaWRhcy5sb2ctYWV0Yy9TQVRBTk5PVC1iZXRj
>>>>>L
>>>>>1
>>>N
>>>>>BVEJB
>>>>>TkQvdmFyL2RhdGEvbGRtL2dlbXBhay9pbWFnZXMvc2F0L0dPRVMtMTAvNGttL0lSL0lS
>>>>>X
>>>>>z
>>>I
>>>>>wMDUw
>>>>>ODA5XzAwMDAgd3JpdGUgZXJyb3IgDQpBdWcgMDkgMDA6MTM6MjIgZ29kemlsbGEgcHFh
>>>>>Y
>>>>>3
>>>R
>>>>>bNDY0
>>>>>N106IHBpcGVfcHJvZHB1dDogdHJ5aW5nIGFnYWluIA0KQXVnIDA5IDAwOjEzOjIyIGdv
>>>>>Z
>>>>>H
>>>p
>>>>>pbGxh
>>>>>IHBxYWN0WzQ2NDddOiBwYnVmX2ZsdXNoICgzKSB3cml0ZTogQnJva2VuIHBpcGUgDQpB
>>>>>d
>>>>>W
>>>c
>>>>>gMDkg
>>>>>MDA6MTM6MjIgZ29kemlsbGEgcHFhY3RbNDY0N106IHBpcGVfcHV0OiAtY2xvc2VkZWNv
>>>>>Z
>>>>>G
>>>V
>>>>>ycy9w
>>>>>bmdhMmFyZWEtdmwvdXNyL2xvY2FsL2xkbS9sb2dzL2xkbS1tY2lkYXMubG9nLWFldGMv
>>>>>U
>>>>>0
>>>F
>>>>>UQU5O
>>>>>T1QtYmV0Yy9TQVRCQU5EL3Zhci9kYXRhL2xkbS9nZW1wYWsvaW1hZ2VzL3NhdC9HT0VT
>>>>>L
>>>>>T
>>>E
>>>>>wLzRr
>>>>>bS9JUi9JUl8yMDA1MDgwOV8wMDAwIHdyaXRlIGVycm9yIA0KQXVnIDA5IDAwOjEzOjIy
>>>>>I
>>>>>G
>>>d
>>>>>vZHpp
>>>>>bGxhIHBxYWN0WzQ2NDddOiBjaGlsZCA1MjMyIGV4aXRlZCB3aXRoIHN0YXR1cyAxMjYg
>>>>>D
>>>>>Q
>>>o
>>>>>=
>>>>>
>>>>>--Boundary_(ID_mRLemyhH004n7qDStD3mNQ)--
>>>>>
>>>>--
>>>>*********************************************************************
>>>>*
>>>>*
>>>*
>>>>Unidata User Support UCAR Unidata
>>>>(303)497-8643 P.O.
>>Box
>>>>address@hidden Boulder,
>CO
>>>>---------------------------------------------------------------------
>>>>-
>>>>-
>>>-
>>>>Unidata WWW Service
>>>>---------------------------------------------------------------------
>>>>-
>>>>-
>>>-
>>>>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.
>>>>
>>>--
>>>**********************************************************************
>>>*
>>>*
>>>Unidata User Support UCAR Unidata
>>>(303)497-8643 P.O.
>Box
>>>address@hidden Boulder, CO
>>>----------------------------------------------------------------------
>>>-
>>>-
>>>Unidata WWW Service
>>>----------------------------------------------------------------------
>>>-
>>>-
>>>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.
>>>
>>--
>>***********************************************************************
>>*
>>Unidata User Support UCAR Unidata
>>(303)497-8643 P.O. Box
>>address@hidden Boulder, CO
>>-----------------------------------------------------------------------
>>-
>>Unidata WWW Service
>>-----------------------------------------------------------------------
>>-
>>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.
>>
>--
>************************************************************************
>Unidata User Support UCAR Unidata
>(303)497-8643 P.O. Box
>address@hidden Boulder, CO
>------------------------------------------------------------------------
>Unidata WWW Service
>------------------------------------------------------------------------
>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.