NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Paul, re: > Thanks for your response concerning the NEX* files. No worries. re: > we have been trying to do upgrades and I have a few more questions. > > I think our problem was that we were appending to a log file and that file > was so large it caused high latencies in I/O. I have remedied the problem > by writing stnrd/erro out to /dev/null for the loggin of our mcidas kickoff > scripts. We have also seen that failing to rotate logs can lead to extremely large log files, and this can impact system performance even on very fast machines. re: > Here are the two questions at this time. > > First, I saw that McIDAS-V has support for SVG files. Will McIDAS-X do > that? No, McIDAS-X does not support the SVG (Scalable Vector Graphics) format. The types of save formats in McIDAS-X are listed in the HELP for the FRMSAVE command: HELP FRMSAVE FRMSAVE -- Saves a McIDAS frame to a GIF, PPM, BMP, JPEG or PostScript file FRMSAVE frame name <keywords> FRMSAVE window name TYPE=COMBINE <keywords> Parameters: frame | image frame number to save (def=current) window | combined window number (created with COMBINE command); the range is 0-9; you must also specify TYPE=COMBINE with this option name | name of the file in which to save the frame; if you don't specify an extension, .GIF is appended if FORM=GIF, .PPM is appended if FORM=PPM, .BMP is appended if FORM=BMP, .JPG is appended if FORM=JPG, .PS is appended if FORM=PS, and .CPS is appended if FORM=CPS Keywords: GRA= | graphics frame to save with the image; valid only for TYPE=FRAME; see the Remarks (def=number specified in 'frame' if session does not have independent graphics; def=last- associated graphics frame if session has independent graphics) FORm= | format of saved file; valid entries are GIF, PPM, BMP, JPG, PS, and CPS for graphics interchange, portable pixmap, bitmap, JPEG, PostScript, and color PostScript formats, respectively (def=GIF for TYPE=FRAME; def=JPG for TYPE=COMBINE) re: > we want to save frames using SVG formats rather than gifs and hope > that will be possible soon. Unfortunately, it is not possible at this time, and, quite frankly, I have never heard any comments from the SSEC folks that they are contemplating adding SVG as a viable save format. re: > Second, I am running the command dsinfo.k NEX1/IMAGE (where NEX1 is aliased > as NEXRCOMP/1KN0R-NAT) > The output finds AMRC, BLIZZARD and, CIMSS with info but then the process > hangs and it does not return any more. What would cause that? The syntax for DSINFO invocations is: DSINFO -- Lists ADDE datasets on local and remote servers DSINFO type group The default for the 2nd positional parameter to be specified, 'group', is ALL: HELP DSINFO DSINFO -- Lists ADDE datasets on local and remote servers DSINFO type group Parameters: type | data type; valid types are GRID, IMAGE, NAV, POINT, TEXT, or ALL (def=ALL) group | group name (def=all groups) What is happening is that DSINFO only checks the first character of the 1st positional parameter to see what type of dataset (e.g., GRID, IMAGE, NAV, POINT, TEXT, or ALL) to list information for. In your case, it is picking up the 'N' in NEX1/IMAGE and assuming that you are asking for information on NAV type datasets. Also since you are not specifying a specific group name, it is trying to list out information on all ADDE datasets it finds in your McIDAS-X client routing table (the table that DATALOC creates and maintains). In effect, your DSINFO invocation is being interpreted as: DSINFO NAV ALL Why this hangs is a mystery to me; it is likely an indication of a bug in DSINFO. You can demonstrate the importance of the first character of the first positional parameter by running: DSINFO IMAGE NEXRCOMP DSINFO I NEXRCOMP DSINFO IWXY NEXRCOMP Each invocation should give you the exact same output. re: > Hope all is well Tom! Wish I could have a beer with you sometime! I'm doing OK. I was in China working with folks from two Chinese Met Agency offices for two weeks, and it was very interesting. I'm back in the office now trying to catch-up on a variety of things, but mainly doing support for sites that are spinning back up their data ingest (LDM), decoding (GEMPAK and McIDAS) and use after being off for the summer. Getting together for a beer (or three ;-) whenever you are in town sounds great! Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: WLU-125107 Department: Support McIDAS Priority: Normal Status: Closed =================== 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.