20000418: McIDAS-X, -XCD Addendum for ETA HR+60 storage and more... (cont.)

>Eirh-Yu Hsie <address@hidden>
>Organization: University of Virginia
>Keywords: 200004072010.OAA01470 McIDAS-XCD IDD ETA ADDE XCD DMGRID DSSERVE 
>RTMODELS.CFG GRIBDEC.PRO

Hsie,

>Do I need to remove the old HRS.SPL file???  I still only get 16 MB HRS.SPL 
>file.

You do need to remove the old spool file.  This is done by the steps
outlined in the addendum:

http://www.unidata.ucar.edu/packages/mcidas/mcx/addenda_000417.html

  < while in the ~mcidas/workdata directory>

  rm GRIBDEC.CFG
  rm HRS.CFG
  rm gbtbpds001.av1
  lwu.k DEL HRS.SPL
  lwu.k DEL GRIBDEC.PRO

If you are doing this as the user 'mcidas', then your McIDAS
environment variables MCDATA, MCPATH, etc. should be properly defined
already at login.  The lwu.k invocations from the workdata directory
will then delete the copies of HRS.SPL and GRIBDEC.PRO that is used by
XCD.  The new copy of HRS.CFG, which should now be linked into the
~mcidas/workdata directory, will have the information to make HRS.SPL 32
MB.  This is the line SPOOLENG=32.  As soon as you update the files and
restart the LDM, the spool file should be recreated as a 32 MB file.

>>5) modifications to ADDE data set definitions to account for the change
>>   in ETA GRID file numbers (DSSERVE.BAT)
>
>DO I need to do anything here?

If you are serving others through ADDE, then yes.  The change in the GRID
file numbers makes the ADDE definitions for RTGRIDS/ALL and RTGRIDS/ETA
stored in RESOLV.SRV invalid.  These can be fixed either by redefining
all ADDE datasets by running the local copy of DSSERVE.BAT, LSSERVE.BAT,
or they can be individually redefined by:

cd ~mcidas/workdata
dsserve.k ADD RTGRIDS/ALL GRID 5000 5620 RT=YES "ALL Real-Time ETA Grids
dsserve.k ADD RTGRIDS/ETA GRID 5501 5620 RT=YES "Real-Time ETA Grids

>From address@hidden  Tue Apr 18 15:35:14 2000

>>On another topic, ...

>My original ADDE server (stratus) is a Sun Sparc Ultra1 143 MHz
>machine.  It is running out of CPU power and disk space.

OK, I understand these kinds of problems :-(

>I am running
>ADDE server on another machine right now.  It is my file and
>application server.  I would limit outside access to this new server.

This sounds reasonable.

>Can I still run ADDE server on stratus and point the data to the file
>system on the new ADDE server???

Yes, absolutely.

>I can relax outside access on startus.

Wonderful!  I would really appreciate that.  If outside ADDE access
to stratus becomes a problem (I don't anticipate that it will, by
the way), then you could start limiting machines that you would allow
access to by modifying your hosts.allow/hosts.deny file entries.
This would tell the TCP wrappers which request to reject immediately.

Thanks for the quick update.

Tom