McIDAS-OS2 IDD Leaf Node Implementation Plan

Tom Yoksas
June 1994

Introduction

In spite of continual encouragement by the UPC for movement to Unix, a substantial number of sites (~30) continue to participate in Unidata with McIDAS-OS/2 platforms. The reasons that sites may wish to continue to use OS/2 platforms generally fall into two categories: a) platform cost; and b) ease of configuration and system management. Unidata, through direction of its User and Policy Committees, has accepted the need to continue to support these sites for the near to indeterminant future.

This paper outlines strategies considered by Unidata for continuing to support these typically-small sites as Unidata moves to the Internet Data Distribution (IDD) method of disseminating weather data.

Support Options

The options recognized by Unidata for continued support of OS/2 McIDAS systems are: The strengths and weaknesses of each of these approaches are presented.

Continued Satellite Broadcast of the Unidata-Wisconsin data channel

Unidata has considered moving the broadcast of the current Unidata-Wisconsin channel from C band to KU band after the December 1, 1994 sunset of C band transmissions by Alden. This move would cost $5300/mo as compared to the current $3750 being paid for C band transmissions. Since the cost of this service is considerably higher than it is currently, and since Unidata's goal is to provide data to its community through the IDD, we do not consider this a viable long term option although it may be useful during the period when sites not yet on the Internet get connected. As presented elsewhere in this meeting packet, the Unidata cost to continue C band broadcast of any data stream would be on the order of $20K per month, a cost that Unidata can not afford.

Use of 'mctingest' to feed OS/2 leaf nodes

'mctingest', an LDM McIDAS ingester developed by Steve Emmerson of the UPC, is built upon the freely-available FSU's Pthreads package for SunOS 4.1.x, DECThreads for OSF/1 and Ultrix, and the builtin threads package that comes with SunOS 5.x (Solaris). This ingester, which has been in use at Unidata since September, 1993, functions in a similar manner to the new "product queue" version of the ldm that is under development: products are assembled from a feed and then sent to a list of clients by independent threads. The independence of the feed threads insures that machines that suffer from a "slow link" problem do not affect others. Unidata has successfully used mctingest to feed up to 7 McIDAS-OS2 and McIDAS-X machines simultaneously here at the UPC and around the US. The experience gained from mctingest convinced us that producing a highly reliable, data distribution system was feasible. Like other ldm ingesters/decoders written by Unidata, mctingest can operate from a variety of inputs: files, devices, and standard input. The ability to use standard input allows mctingest to be used as an LDM decoder that gets its input from an LDM PIPE action. This means that we already have a reliable method of feeding McIDAS-OS2 workstations (AND McIDAS-X workstations not using the LDM) that are connected to the Internet). The drawback of using mctingest with the IDD is that the configuration mechanism for mctingest is completely different than that for the LDM. This would make it harder for a relay site manager to maintain and upgrade IDD configurations at his/her site. It also, on SunOS 4.1.x machines, requires that users maintain current distributions of a non-Unidata package, FSU's Pthreads.

Development of an LDM client for OS/2

Even though we currently are able to feed McIDAS-OS2 workstations with mctingest (described above), we feel that effort should be devoted to developing an OS/2-based LDM client that would allow IDD relay sites to send the Unidata-Wisconsin channel products directly to McIDAS workstations. This effort, which is estimated to be about two programmer weeks work to get the code functioning reliably, would allow for a consistent configuration method for IDD relay sites. Documentation and release engineering will take at least as long as the code development so the total effort is on the order of a month's work. We believe that simple and consistent configuration and management of relay nodes will be key to successful operation of the IDD. The limiting aspect of this approach is the McIDAS-only orientation of the solution. It is likely that most sites will eventually want to take advantage of the variety of data offered on the full IDD.

Full port of the LDM to OS/2

A longterm option for expanded support of McIDAS-OS2 platforms is the port of the entire LDM to OS/2. Review of the facilities provided by the two Unidata-recommended OS/2 network packages (PC/TCP for OS/2 from FTP Software, Inc., and TCP/IP for OS/2 from IBM) indicates that a port of the LDM to OS/2 would most likely be possible. What is not known, however, is the extent of the effort that this port would take. We also question the advisability of a move like this based on the slow acceptance of OS/2 in the PC computing community as a whole. Given that we are already shorthanded for the forthcoming IDD deployment effort, we do not believe that this option is viable at this time.

IDD in-a-box

The last option that we have been considering is the creation/deployment of a single-purpose, inexpensive, Unix-based machine that would be used for IDD reception (and possible relay) of data at sites lacking other Unix machines. The idea is to put together a machine (e.g. a 486-based PC class machine or a low end Unix box) with a standard configuration (e.g. Solaris for 486 or for a Sun Classic) that would only be used for IDD tasks. This machine would necessarily support NFS so that other machines at a site could access locally ingested/decoded data. This machine would NOT run the X Window system nor be used for other research or educational activities. In this way, we would be assured that system overloading would not affect IDD data movement activities. We also feel that by limiting the facilities used we can minimize the Unix experise needed to run the machine for IDD purposes only. We are confident that a machine that would serve this purpose could be assembled for a cost of less than $3000.