>From: Bill Fingerhut <address@hidden> >Organization: Lyndon State >Keywords: 200011031415.eA3EFH422672 McIDAS-X 7.6 SFCPLOT SFCPLT XCD Bill, >Mark passed along last nights response. He isn't around >just now, but I tried what you suggested. Cirrus is the >adde server, we are pointing at it, the schema is the same >for all sfchourly dates available. And, the SFCPLOT command >worked for me. OK, perhaps the failure was some sort of a transient occurrance? >We thought the answer might be a corrupt MD file and tried >an experiment to test the idea. All MD files between 1 and >9 were renamed, except for yesterdays (7). This did not fix >the problem yesterday. We must have made a mistake. Your renaming experiment was an excellent idea! This would eliminate the possibility of a bad file IF the 'mcadde' account was only able to see MD files in the SFCHOURLY range (1-10) in the directory where MD files are being decoded. Since 'mcadde' shares 'mcidas's' home directory, this would mean that the user McIDAS on the ADDE remote server machine would have to have either a REDIRECTion pointing to a file with a different schema, or such a file could have existed in the MCPATH of the user 'mcidas' (as defined in ~mcidas/.mcenv). This is the only thing I could imagine that could cause the weirdness that you saw. >Unfortunately, I have another question 'related' to this >command. If we change the command to SFCPLT and keep the >parameters and keywords the same, it fails. The response is > >--MDX-- INVALID PARAMETER GUS > >Any thoughts? Since SFCPLT is an MDX macro command, I would try a couple of things right after seeing an error like this: o rerun the SFCPLT invocation adding the DEV=GCC keyword sequence so we get more debug output o run MDL file_number, where file_number is the MD file from which you are attempting to read data (e.g., MDL 7) The debug output from SFCPLT could help us target what is amiss. Since SFCPLT uses SYSKEY.TAB values for the LATEST data, it could be that the copy of SYSKEY.TAB that your REDIRECTion pointed to had a value for the current ISFC MD file number that was incorrect. The debug output will help us trace this. >On another subject: > >* When you pointed at cirrus, you changed case to lower case. >Can this make a difference? No. The case used to specify the machine name in a DATALOC command has no effect. >* Did you decide what to do about the 'assignment of cylinders >to UKMET model data' problem I reported Sept. 15? Not yet. I finished my McIDAS-X workshop duties last night at 8 pm. I can now focus my attention on problems like this one. BTW, thanks for reminding me of this; it has been a long three weeks! 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.