>From: Mark Tucker <address@hidden> >Organization: Lyndon State >Keywords: 199812081808.LAA17744 McIDAS-X 7.4 Mark, re: set of REDIRECTions in LWPATH.NAM >After editing the LWPATH.NAM many of the problems I was having have gone. re: problems with the MAN.BAT PP BATCH: >The problem with MAN.BAT running as a PP BATCH is that it is being >launched without any values for the arguments (ie. %1, %2, %3, %4 all have >null values). This is very odd indeed. The code that invokes a PostProcess BATCH file is regularized. It always provides the same set of parameters on the BATCH invocation command line: BATCH pcode cylinder/name date time ccode "PP batch file to run ^ ^ ^ ^ ^ ^ ^__ McIDAS BATCH file to run | | | | | |_______ decoding condition code | | | | |_____________ time of product | | | |__________________ date of product YYDDD | | | |__________________ date of product YYDDD | |______|_______________________ cylinder (non-TEXT)/name (TEXT) |_____________________________________ product code If these arguments are not there, I suspect one of two things has happened: o the contents of the Bourne shell script, batch.k, has been altered o you are attempting to invoke the McIDAS executable, ~mcidas/bin/batch.k, directly The latter of these is what I have seen happen on your system a couple of times. This occurs when the PATH for the user running the LDM gets changed so that the McIDAS bin directory is included (bad!) and is before the directory in which the Bourne shell script, batch.k, exists. I suspect that this is what is happening as I have seen it on your system more than once (I noted and warned about this in at least two previous emails). >The batch file assumes that the second argument %2 has a >value The second passed parameter (%2) would be the file cylinder number for non-textual products (e.g. AREA, GRID, or MDXX). >and then compares and updates the syskey table, #SYS(2011), Right, SYS(2011) is the storage location for the MD file number for the MDXX mandatory level upper air product. >with >that value. Since it is not a valid value the rest of the batch file does >not function properly. I haven't yet figured out why the arguments are >not being correctly passed to the batch when it is launched. I suspect option two above. >We also have a program that is used in several of the PP batch files that >was written by Bill Fingerhut, ygdchk.k, which works when run from a >mcidas-X session (or from the unix commandline) but does not work when >called from a batch file. From any BATCH file, or from ones run as ROUTE PP BATCH invocations? >I'm at a total loss as to why this is not >functioning. The program checks for the existence of a grid and the >return value is used for a condition for different processes. I'm trying >to find the source code to this but if you have any ideas why it would >behave this way I'd appreciate it. I don't know enough about how it is failing to even guess why it is failing. >Another question I have is that it appears that the uppperair data that is >processed by MAN.BAT comes in at 02:00 and 13:00 EST (07:00 and 18:00 UTC) >which seems like quite a bit of lag for 0Z and 12Z data. Is this normal? No, this is not normal. This is, in fact, VERY late. I would expect to see these data files arrive in the Unidata-Wisconsin datastream about one to two hours after the ordinal time (i.e. either 1-2Z or 13-14Z). re: questions on WXP >Who should I direct WXP related questions to? WXP has been a community supported package for quite some time now. You will need to rely on your Unidata "neighbors" for help on WXP issues. If you are not already subscribed to it, you should join the WXP and/or WXP email lists that we maintain and send your questions to them. >BTW, we have changed the passwords on our servers. I will call with the >new passwords. OK. I will be heading to the AMS meeting in Dallas on Tuesday morning, and I won't be returning to work until Monday, January 18. I will try to look in on support email from time-to-time, but this relying on this is iffy. >Thanks. Later... 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.