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.
Hi Trung, re: what is output of 'DMAP AREA09' > [~] $ dmap.k AREA0* > PERM SIZE LAST CHANGED FILENAME DIRECTORY > ---- --------- ------------ -------- --------- > 0 bytes in 0 files > > So I can see the images AREA0* did not get created. This is what I suspected. > What caused the IMGCOPY to fail? Good question. I can't comment since I am not able to look at the permissions on the directory into which the copied images were to be written, etc. > Another strange thing when I tried on the below message: > > Beginning Image Data transfer, bytes= 2003568 > Transferring AREA data outbound, bytes= 2003648 > IMGCOPY: LOC/POS.115 copied to LOC/PAVOLMUL.67 > imgcopy.k: done > DONE: INVOKE. > > I could display the image when I ran the command > > IMGDISP LOC/PAVOLMUL.67 > > but I couldn't with IMGDISP LOC/POS.115 Wow! This is extremely weird. Please send the output of: DATALOC LIST LOC > Looked like the source image at LOC/POS got erased after the copy?? I don't think so. There is nothing in IMGCOPY that would/could erase a source image after a copy. 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: QNX-338397 Department: Support McIDAS Priority: Normal Status: Closed