>From: Xu Li <address@hidden> >Organization: Meteorology Department of UMD >Keywords: 200010201907.e9KJ7G415693 McIDAS-X SCHE LSCHE DCxxxx Xu, >My name is Xu Li and am working with Professor Rachel Pinker at >University of Maryland at College Park. > >I just joined here and involve in the use of McIDAS. >Steve Williams provides GOES data to our project. He said that you are >the best person to ask the question on McIDAS. I will certainly try :-) >Now, I have a question: >When I register a schema, e..g, CTYP, by sche.k CTYP, the feedback >information is following: > >CTYP will be treated as a text file Apparently the file your schema is in is named CTYP and it is an ASCII text file. Is this true? The historical method from SSEC was to store schema definitions in files whose names begin with 'DC'. This is not a necessity, however. >"CTYP (JSP) 0001 SCHEMA -- Cloud Screening SCHEMA >" NAME VSN DATE ID "TEXTID >" ---- --- ----- -- ------- > SCHEMA CTYP 8 96183 0 "SNOW and CLOUD MAP >*--SCHEMA * CTYP *, VERSION * 8 * ADDED TO SCHEMA FILE * KEYS=7 > > --END OF SCHEMA REGISTRATION PROGRAM > >This looks the registration was OK. Yes, this does seem to suggest that the schema got added to the schema registry file, SCHEMA. Some McIDAS routines, however, may fail to properly report errors. This is changing as McIDAS evolves, but it may be what we are seeing here. >But when I checked it by lsche.k CTYP, it shows: > >lsche.k: DONE The fact that lsche.k does not show that the schema is registered makes me wonder if SCHEMA is writable by the user (you?) attempting to register it. Make sure that the user (you?) has write permission for SCHEMA. It is likely that if it is you that is registering the schema and SCHEMA is located in ~mcidas/data that you do not have write permission. >I think this means schema CTYP was not registered successfully. Right, this is what it means. >Could you help me to solve this problem? Given that the steps you took look correct, I have to suspect that SCHEMA is not allowing write by you. If this is the case, then I would rerun your sche.k invocation as the user that actually owns SCHEMA. If write permission is not your problem, please let me know. >Thanks! You are welcome. >Xu Tom -- +-----------------------------------------------------------------------------+ * Tom Yoksas UCAR Unidata Program * * (303) 497-8642 (last resort) P.O. Box 3000 * * address@hidden Boulder, CO 80307 * * Unidata WWW Service http://www.unidata.ucar.edu/* +-----------------------------------------------------------------------------+
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.