>From: Owen Cooper <address@hidden>
>Organization: UVa
>Keywords: 199902011446.HAA01860 McIDAS ROUTE PP BATCH
Owen,
>We have had SFC.BAT running well for the past few months, kicking off
>batch jobs that create images for our web page. All of a sudden, since
>approx 7 UTC Jan 30 SFC.BAT has been failing because it can't find
>QTIME that is used in the following command:
>
>RUN "PTABLE MID$("%4",1,2),"QTIME"
This single line McBASI script (RUN is McBASI) sets QTIME. If the invocation
fails, then it typically means that writing to the McIDAS string
table (STRTABLE) has failed.
>I tried typing #QTIME at the mcidas prompt to see if it would return a number
>as happens when you type #Y, but it just says STRING NOT FOUND
If you look further in SFC.BAT (at least the copy we send in the distribution)
you will see that it is deleted at the end of the script:
:TIME
RUN "PTABLE MID$("%4",1,2),"QTIME"
IF "#QTIME"=="#SYS(2002)" GOTO DAY
SYSVAL CHANGE 2002 #QTIME
:DAY
IF "%3"=="#SYS(2003)" GOTO MD
SYSVAL CHANGE 2003 %3
:MD
IF "%2"=="#SYS(2001)" GOTO CLEAN
SYSVAL CHANGE 2001 %2
REM Clean up string used
:CLEAN
TD QTIME
REM Done!
:EXIT
> The UNIDATA email archives shows this problem has appeared before but
>i wasn't able to get a solution out of that particualr e-mail.
>
>Any idea why mcidas suddenly can't find QTIME.
The problem is that the setting of qtime is failing.
>And what is QTIME anyway?
In SFC.BAT, QTIME is the first two digits of the 4th parameter passed
in. From the documentation block in SFC.BAT, you can see that the 4th
parameter passed in is the time in HHMMSS. The McBASI MID$ function
extracts a substring from a string. MID$(("%4",1,2) extracts two
characters from the string "%4" (the time) starting at position 1.
QTIME is, therefore, the time as HH.
>I can't find it in any of the on-line manuals.
It is in the header help section of SFC.BAT.
>>From address@hidden Mon Feb 1 09:53:50 1999
>I'm still fairly new to the ldm, but I've got a problem that I'm fairly sure
>I have no control over.
>Today we have received sig. and man. raob data for Feb. 2, which is tomorrow.
>How can this be, when the data haven't even been recorded yet??
This looks like a decoding problem in XCD which must be tracable back to
an error in McIDAS code. I will send this along to SSEC for review.
>These data come from the HRS data stream, not the Wisconsin data stream.
>
>here is the MDU listing
>
>MD# CREATED SCHM PROJ NR NC ID DESCRIPTION
> ----- ------- ---- ---- ---- ---- ------- -----------
> 11 99030 IRAB 0 8 1300 99031 Mand. Level RAOB for 31 JAN 1999
> 12 99031 IRAB 0 8 1300 99032 Mand. Level RAOB for 01 FEB 1999
> 13 99032 IRAB 0 8 1300 99033 Mand. Level RAOB for 02 FEB 1999
> 20 99029 IRAB 0 8 1300 99030 Mand. Level RAOB for 30 JAN 1999
> 21 99030 IRSG 0 16 6000 99031 Sig. Level RAOB for 31 JAN 1999
> 22 99031 IRSG 0 16 6000 99032 Sig. Level RAOB for 01 FEB 1999
> 23 99032 IRSG 0 16 6000 99033 Sig. Level RAOB for 02 FEB 1999
> 30 99029 IRSG 0 16 6000 99030 Sig. Level RAOB for 30 JAN 1999
>
>I did an MDL on MDXX0023 and it listed the data as having julian date 99033,
>which is tomorrow.
Wow, McIDAS can see into the future :^O.
>Over the past 24 hours we haven't been receiving MRF or ETA data from the
>HRS data stream. We haven't received any e-mails from other ldm
>users saying that they have had similar problems. So I'm not sure if
>we're having problems at our end with the ingestors
Unfortunately, our LDM machine crashed last night and has still not been
fully restored, so I can't tell you if we saw the same problems. I did
respond to a request from Jennie to act as a backup with ADDE access,
but, since our machine is down, we can not. I suggested to her that
you contact Robert Mullenax of the National Scientific Balloon Facility
(NSBF) to see if you can access his remote ADDE server. Robert has
already agreed in principle to this, but it is a good idea to ask.
>Any idea what might be going on?
Not as far as the XCD decoding goes, sorry.
Tom Yoksas
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.