Skip to Content

Summer 1990

LTER Databits - Information Management Newsletter of the LTER Network - Summer 1990

Welcome to the summer 1990 issue of DATABITS!

This issue features the agenda of the upcoming data manager's meeting, a report on the most recent LTER Coordinating Committee meeting, reports from the sites and some hints on using Unix and MSDOS.

Featured Articles


Meet Mr. UNIX

I've passed along to John some barely rational ramblings from a fellow who tends to hang around my office.

I think he (they?) managed to pass a competency hearing not long ago ... but I'm not sure how. I found this first submission in my mailbox early one morning, along with an empty can of Jolt Cola and a Snickers wrapper. I've changed the name(s) of the author(s) to avoid embarrassing the administration here. I'd take these programming hints with a grain of salt (or, better, lithium chloride).

-- Tom Kirchner

LTER Data Managers Meeting Agenda

JULY 26 - 28, 1990

THURSDAY July 26, 1990
6 pm Social Mixer (Dinner?)
Place: TBA

7:00-9:00 pm GET ACQUAINTED/WHAT'S BEEN HAPPENING?
Site "happenings" All 17 sites report on Sci/Tech/MSI
Supplemental requests: What did they request?(45 min)
Reports: Fall LTER/CC mtg (Stafford)
Spring LTER/CC (Michener)
Connectivity (Brunt)
KBS workshop (Gorentz)
CISE RFP (Brunt, Kirchner)
Network Office update (Nottrott/Vande Castle)
NIN, KNZ, CPR, NWT, NET report on larger $150K requests (GPS, DBMS, UNIX workshop, GIS printer, Remote Images/Connectivity)
**Sites to bring copy of their Sci/Tech proposals**

FRIDAY July 27, 1990

8:00-8:30 Introduction (Data Managers Task Force)
Charge to the group: Overview of Plan for Workshop

  • What do we want to do in these 2 days?
  • What did we do last year? (Stafford))
  • Desirable Accomplishments: Group Consensus

Format: Working Groups with written reports

8:30-9:30 General Discussion:
New Directions/Leadership Role for LTER Data Managers
Overview of the national/international scene
"Network of Networks" concept
How will we be a leader?
What new projects will we choose to lead with?

9:30-11:00 Introduction of Working Group Topics:
New Directions
Research Facilitation activities
Establishing criteria for evaluating data management during Site reviews
Quality Assurance at LTER Sites
Global Change
Linking databases to GIS programs

10:00-10:20 Coffee available

11:00-12:00 Working Group Reports

12:00-1:15 Working Lunch: Finalization of Working Group Reports

1:15-2:00 Status and Update on Existing projects:
Core Dataset Catalog:
Michener: Report on project, prod. of hard copy.
Nottrott: On-line catalog, data access via catalog, future shape and directions for other catalogs, etc.
Bibliographic project- Status, What is needed?
Efforts to develop documentation standards for GIS layers and products

2:00-2:20 PROPRIETARY ISSUES Overview: rights, data sharing, legal
issues, how to share models and software [adaptation of
generic protocol (Conley and Kirchner) for data exchange
across sites (Michener, Kirchner, Stafford); Protocol for
data exchange

2:20-3:30 Proprietary Issues Working Groups

3:00-3:20 Coffee available

3:20-4:20 Proprietary Issues Working Group Reports

4:20-5:00 GENERAL TECHNOLOGY DISCUSSION:Sci/Tech/MSI supplemental requests (what do sites want next year?, what direction should we be giving NSF?, GIS implementation,etc?)
DEMONSTRATIONS (Andrew BB(?), others....)
REQUESTS from others to participate in LTER/DATAMGRs meetings, what is the consensus of the group?

7:00 Group Dinner

SATURDAY July 28, 1990

8:00-8:30 Review of Day 1
Introduction, Welcome to visitors, Comments by visitors

8:30-9:30 Guest Speaker on Scientific Databases: John Pfaltz, Institute for Parallel Computing, University of Virginia.

9:30-10:00 Questions and Discussion

10:00-10:20 Coffee

10:20-11:00 DATABASE MANAGEMENT SYSTEMS: LTER and DBMS Issues
(Porter, Brunt, Briggs, Nottrott & Vande Castle)

  • Different Databases : +'s and -'s
  • How to choose a common software DBMS? Integration of
  • Network Office Proposal for Common Database
  • Do we want to develop DBMS for catalogs?
  • LTER Directory, CoreDataset, All Site Bibliographies, Mail/White/Yellow Pages, Remote Images DB, site scientific DBs, etc.
  • NSF's BiolDataBasesInitiative (Stafford)

11:00-12:00 Working Groups on DBMS Issues
Databases Packages - SQL
Using networks in DM
Managing Meta-data (documentation etc)
Sharing models and software

12:00-1:15 Lunch - Finalization of Working Groups

1:15-3:00 Working Group Reports

3:00-3:20 Coffee

3:20-4:00 Finalize writing assignments

4:00-5:00 Wrap up, Agenda for 1991 mtg, contribution to LTER/CC proposal,planning for projects, Contribution to All Scientists Meeting (ASM).

5:00 Adjourn

Classification Society

Here's one for the Statistical Data Manager Types:

The "Classification Society of North America" (CSNA) is a nonprofit interdisciplinary organization dedicated to promoting the scientific study of classification and clustering, and disseminating scientific and educational information related to its fields of interest. The society attracts researchers from many fields including: psychology, statistics, biology and computer science.

CSNA's "Journal of Classification" publishes contributions to the theory and methodology of classification. Recent papers appearing in the journal included:

  • J.P. Barthelemy, "Thresholded Consensus for n-trees,"
  • F. Critchley and W. Heiser, "Hierarchical Trees Can be Perfectly Scaled in One Dimension,"
  • J. de Leeuw, "Convergence of the Majorization Method for Multi-dimensional Scaling,"
  • G.W. Furnas, "Metric Family Portraits,"
  • M.J. Greenacre, "Clustering the Rows and Columns of a Contingency Table,"
  • G. W. Milligan, "A Validation Study of a Variable Weighting Algorithm for Cluster Analysis."

The Journal publishes book reviews and software abstracts that highlight developments in theories, methodologies, procedures, and algorithms in cluster analysis and classification.

CSNA's has a classification literature automated search service which annually publishes a bibliography and indices of journal papers on classification. The volume for 1988 describes 889 papers from 474 journals.

Among these papers are those which cited contributions by Anderberg, Carroll, Duda, Greenacre, Johnson, Hartigan, Hennig, Kruskal, Sneath, Sokal, Tversky, Ward, and Wiley.

Glenn W. Milligan - CSNA Faculty of Management Sciences 301 Hagerty Hall The Ohio State University Columbus, OH 43210, USA, or Eva Whitmore - CSNA Technical Editor
Bitnet: EVA@MUN
Internet: eva@mun.bitnet

-- submitted by James Brunt, Sevilleta LTER

DM Meeting Agenda

The agenda for the upcoming LTER Data Managers' Meeting in Snowbird Utah is attached to this issue of DATABITS. The meeting features a wide range of topics from the general (selecting and using SQL-based relational databases) to the specific (reports on special data management projects, such as the data catalog).

There will be a small but important change in the format of the upcoming LTER Data Managers' Meeting. In recent months the network office and NSF have received several requests from individuals outside the LTER community to attend our meeting. Despite the obvious "public relations" advantages of allowing non-LTER individuals to attend, members of the task force expressed some reservations about whether the meetings were too LTER-specific to be of interest to the general public and whether changes in the size of the group would disrupt the meeting format. A compromise position was to have one day for LTER data managers only and have the second day be open to the general public. At the Coordinating Committee meeting it was announced that the second day of the meeting would, in fact, be open.

To allow full and frank discussion of LTER-specific issues among data mangers, the meeting has been structured into a day of LTER-specific topics and a day of general topics. The second day has more general topics where individuals outside the LTER program might be able to contribute to the discussion. To start off a second day, we will have a speaker. John Pfaltz, Associate Director of the Institute for Parallel Computation at the University of Virginia will be speaking on scientific databases and how they differ from databases used in other endevours such as business. There will be opportunities to discuss the value of general meetings and to evaluate the relative merits of open and closed meetings in the future.

News Bits


From the Sites

BNZ-- At BCEF field season has caught up with us, and our efforts are concentrated on data acquisition and storage at a fast and furious pace.

-- Phyllis Adams, Bonanza Creek LTER

HFR-- A busy field season has begun, with help from summer undergraduates: among other things, we're finishing the current forest inventory, mapping trees for the hurricane pull-down and overstory deadening experiments next fall, and resampling hurricane regeneration plots. Data is entered and analyzed on the computers at the end of each field day. Indoors we're setting up new computers, digitizing GIS overlays, continuing analysis of several GIS projects, and beginning the long task of keyboarding data from the past.  

-- Emery Boose, Harvard Forest LTER

NWT-- Recent construction of our climate database represents a level of accessibility previously unknown. Although these data (38-year record for Niwot Ridge) have been reduced and stored on magnetic tape or floppy disks for several years, difficulties associated with use of the data as stored on these media have discouraged all but the most persistent researchers from resorting to hard copies. The new climate database allows for the rapid creation of files, tailored by individual investigators to meet their parti- cular needs, that are easily loaded into a spreadsheet format. The user selects the time period(s), station(s), and climate variable(s) of interest and the database program returns summary statistics (mean, maximum, minimum, date of maximum, and date of minimum). Moreover, the program will graphic- ally display the data instantaneously on command. We anticipate that the database will be completely operational by the end of the summer and are planning to provide a demonstration for the University of Colorado community in the autumn.

For several months now we have been electronically interconnected with our field headquarters at the Mountain Research Station through PCs and modems. All CULTER investigators have had electronic mail addresses for some time.

All of the permanent plots and other study areas on the Saddle are being accurately located and digitized for inclusion into our GIS database. Once this task has been completed we will do the same for the Martinelli and Wetland areas, our other intensive study sites. -- Rick Ingersoll and Jim Halfpenny, Niwot Ridge LTER CWT-- Unfortunately, out connection to the campus broad band (and internet) will be delayed, since the ecology building is going to be remodeled, and we are not sure yet where we are going to be located. Nevertheless, the good news is that no matter where we end up, we are getting a bridge connected. (And that's a exciting news!!!)

I know we are probably talking about this in out our meeting, but how many sites are migrating to a Unix environment? And especially, what kind of dbms package are they using? I have been investigating and "relational technology" is offering a 80% educational discount for their "INGRESS" software package. It's a full-blown dbms tool, and quite frankly, I was very impressed: interactive sql, pc-to-host connection, aibased query optmizer, 4gl language, and much more. I will try to bring as much information as possible to the meeting, including price quotes.

-- GIL Calabria, Coweeta LTER

Notes From the CC Meeting

I will attempt to briefly fill you in on what happened at the LTER Coordinating Committee meeting in Puerto Rico. Particularly as it pertains to data management.

First, the meeting was largely structured to provide information about the LTER program for the benefit of Dr. Pat Werner (the new BSR division director). There was some initial concern about her support for LTER in general. It became readily apparent that she is actually quite supportive of LTER.

On Thursday the morning session was filled with introductions of all persons sitting around the table, LTER accomplishements in the 80's, a discussion of the Core Data Set Catalog, the global change report, highlights of strategic plans (I'm not sure that they were laid out, but everyone agreed that strategic plans were a good thing to have), possible expansion of the LTER to include an Antartic site, and probably some odds and ends that were of little consequence. The remainder of the morning and much of the afternoon session was devoted to discussion of the All Scientist's Meeting agenda. Additional afternoon topics included presentations on research being conducted at 4 LMER sites (Land Margin Eco. Research), reports on the LTER Network Office and what happened there. R. Nottrott presented a "Data Management" report which focussed on the sunshine report and email.

Caroline Bledsoe's report on what's happening internationally (MAB etc.), John Vande Castle's report on what his role is with respect to GIS and remote sensing, and additional tying up of loose ends related to the ASM.

Pat Werner expressed a great deal of interest in LTER. In addition, she explained how NSF fit into the US gov't particularly with respect to budgets and presented some ideas to PI's on how to increase LTER visibility in the community.

Now, specifically regarding data management:

  1. Pat Werner was quite pleased with the progress the dm group is making on the catalog. She felt that it would help justify LTER and perhaps increase our visibility with respect to the global funding arena.
  2. The data management group is on the agenda for at least 2 sessions. One session would simply be another 1+ hour(s) meeting to resolve issues left hanging fron UTAH, and to cover additional DM business. The second session will deal with a specific topic "proprietary rights to LTER data, data sharing issues, etc." The CC felt that some general policy applicable to LTER in general was necessary. (Please note that I did NOT suggest that we do this. In fact, I brought up several legal issues that might preclude having a policy set in stone.) I know many data managers can see positive and negative aspects associated with having a network wide policy. I suggest that we spend some time in UTAH discussing this topic among ourselves. Judy Meyer (Coweeta PI), Susan Stafford, and I were appointed to lead this discussion at the ASM. I am sure that other data managers are encouraged to participate in this process. The more people there are involved, the more difficult it is to zero in on any 1 target.
  3. Thursday night, several concerns were raised about the potential for the data catalog to swamp the data managers with database requests. Friday, I stole 10 minutes of time to discuss this with the CC. Specifically, I defined the potential problems associated with the catalog and how it could put a severe strain on all of us. I suggested that each site may wish to develop a site database usage log to keep track of the amount of requests we are getting and sites should consider developing a pricing policy to recover costs. Some of your PIs may come to you to discuss these matters. This may also be a topic that we should include in our UTAH discussions.

-- Bill Michener, North Inlet LTER

Good Tools And Programs


PC-FILE-DB a brief review

PC-FILE-DB is a shareware relational database program for PCs. It is unlikely to replace DBASE and other commercial programs in professional or specialized applications, but it is much easier to use for small projects. I was able to generate a simple database (including a customized input screen and menu) in only about 10 minutes. Doing the same thing in DBASE would take at least an hour. If I need to do something more complicated than PC-File-DB can handle, DBASE can read the data files without translation (this also works in reverse, PC-FILE-DB can read existing DBASE files directly and can translate from numerous other formats, including Lotus).

PC-FILE-DB supports report writers, label makers and even graphical output of database contents. As with database setup, I found it much easier to use than DBASE for simple tasks such as queries. In its TEACH mode, help screens appear automatically as you select options, but I found that I seldom needed help due to the straight-forward menus. Because it is shareware, it is possible to legally distribute it to researchers for use at remote locations. Documentation is extensive and readable.

PC-FILE-DB (abbreviated PCFDB on many BBS systems) is a shareware product, so you can give it a try at the "right price." It takes up about 900K of disk space for the full system, but if you are willing to sacrifice certain functions, you can fit it into much less. Where space is really a factor, a smaller version called PCFILE is available. It does not directly create DBASE compatible files, but PC-FILE-DB can convert files from PC-FILE to DBASE format. Both programs are available on many PC bulletin board systems and via anonymous FTP over the Internet. If you have trouble locating a copy, send me e-mail and we can work out a way to transfer you copies.

-- John Porter, Virginia Coast LTER

DOS Batch Files

by Dr. DOS

I had a chance to look at the UNIX submission prior to the publication deadline. Just what you would expect from a UNIX type. Well, DOS can handle BATCH FILES too. Here are some tips that will help you do some useful work with your computer.

CLEANING UP .BAK FILES (and ways to use EDLIN that will amaze your friends)

The first batch file I'll do is for those few of us who tend to leave .BAK files accumulate on our disk until DOS reminds us that we are not going to be able to save the file we just spent 3 hours creating because there is no room left. I call this batch file RMBAK.BAT, and it is here to demonstrate why EDLIN is worth knowing how to use. What the batch file is supposed to do is locate every .BAK file on the disk and delete it.

Here is what it looks like:

ECHO OFF
CHKDSK /V | FIND ".BAK"> %TMP%\BAKFILE.BAT
EDLIN %TMP%\BAKFILE.BAT
< /BATCH\RM.ED
%TMP%\BAKFILE

The CHKDSK /V command lists every file on the disk. Its output is piped through FIND to extract just the .BAK files. The output from FIND is redirected to a file called BAKFILE.BAT which is placed in a directory identified in the environment as TMP. If you don't designate a directory for temporary files in your environment, just replace %TMP% with whatever directory you want to use to receive the file BAKFILE.BAT. The DOS command processor, COMMAND.COM, substitutes for variables surrounded by % characters the strings stored in the environment with that label. If you are going to try this under DOS 2.x you will need to put the BAKFILE.BAT file in a directory listed in your path, and can then omit %TMP% in the last statement of the batch file.

The file BAKFILE.BAT now contains a list of fully qualified filenames that have the .BAK extension. To convert this list of file names into a list of DEL commands just requires a little editing. EDLIN can do the job easily and automatically by redirecting the editing commands from a file. In this case the file would look like:

1,10000R <F6>DEL <F6>
E

where <F6> means the character you get when you press the F6 function key. The first line of the command file tells EDLIN to replace the first 4 blanks on the first 10000 lines of the file with "DEL ". The E tells EDLIN to write the file and exit. The file is now a list of commands deleting each of the .BAK files. One caution about the command file for EDLIN is that the file itself cannot be edited. Type it in, the exit EDLIN without listing it within EDLIN. The F6 key is a Control-Z, which DOS uses as an end-of-file mark, so if you TYPE this file or try to edit it it will look like it only contains "1,10000 ". Another caution is that when using command files with EDLIN you always must remember to have the E command in the file. If you forget the E edlin will just sit there waiting for its next command, which will never come. You'll have to reboot if that happens. I have not yet seen another editor that will take commands from redirection like EDLIN will.

The final line in the RMBAK.BAT file executes the BAKFILE.BAT batch file that was just created, deleting all of those .BAK files that you have been hoarding.

this batch file. First, if you want to be cautious, stick

MORE < %TMP%BAKFILE.BAT
PAUSE

commands after the EDLIN command. If you see something that you don't want to delete, just press Control- Break when you get to the PAUSE "Press any key to continue" message to abort deleting the files. Also, you might want to delete the BAKFILE.BAT and BAKFILE.BAK files that are left behind. If you put those commands at the end of the batch file remember to execute the BAKFILE command using

COMMAND /C %TMP%BAKFILE or
CALL %TMP%\BAKFILE (if your version of DOS supports CALL)

so that you are returned to the RMBAK batch file.

Every so often I find the need to perform some simple editing job on a lot of files, like changing the INCLUDE statements in a Ryan-McFarland Fortran program to the format required for Microsoft Fortran. The ability to redirect commands into EDLIN combined with the DOS FOR command has always improved my attitude toward doing such tasks.

SPEAKING OF FOR LOOPS ...

The next batch file shows how you can use FIND the number all off the lines in a file, and also how you can write recursive batch files. I use the script to produce numbered listings of programs. Each listing starts at the top of a new page.

The /n argument to FIND tells it to number the lines it prints. The /v flag tell FIND to print all lines that DON'T match the string. The trick to having all lines numbered is to search for a character that does not exist in the file. A safe character to use is usually one from the extended character set. These have codes greater that 127, and can be entered by holding the ALT key down while you enter the characters value on the numeric keypad (the numbers along the top of the keyboard won't work). For example, to enter the character whose code is 155, type 155 while holding down the ALT key. The character will be printed when you release the ALT key. The name of the batch file is NUMBER.BAT. To use it, enter

NUMBER file_name ~ [file_name][file_name]

One or more arguments can be used, and the file names can contain wildcard characters. For example,

NUMBER *.ASM *.INC

will number the lines in all the the .ASM and .INC files in the currrent directory. (In the batch file below I replace character 155 (a "cent" symbol) with # and character 156 (the English "pound" sign") with &, to improve the chances that John could print it --TBK.) The <FormFeed> notation represents where I put a formfeed character (ASCII code 12, or Control-L). The SHIFT statement shifts the second argumment into the postion of the first, etc. I use the ! when checking for equality (==) to avoid the error that would be generated if the right side was empty because there was no argument. I use the special character # as the second argument to signal to the batch file which branch to take. You could do the same thing with 2 different batch files, but keeping everything in one seems cleaner to me.

ECHO OFF
IF %2!==#! GOTO START
:LOOP
FOR %%F IN (%1) DO COMMAND /C NUMBER %%F #
SHIFT
IF NOT %1!==! GOTO LOOP
GOTO END
:START
IF EXIST %1 FIND /V /N "&" %1
ECHO <FormFeed>
:END

If you are familiar with batch files, you may be thinking "Ok, this will list the files to the screen, but how do you redirect them to a printer or to another file?". The problem is that if you run

NUMBER *.ASM > LPT1:

you will still only get listings printed to the screen, not redirected to the printer. COMMAND.COM interprets each line of a batch file, and will redirect output only on a command by command basis. You could build in the redirection by adding the >LPT1: to the appropriate commands, but that limits its flexibility. The trick in this case is to run

COMMAND /C NUMBER *.ASM > LPT1:

In this case, the redirection applies to the output of the command processor that is running NUMBER, so all of the output from COMMAND, which includes all of the output from the batch file is redirected to the printer.

This last trick is handy for many tasks where you might us a FOR loop, such as in compiling programs where the compiler will only accept 1 argument. The command

FOR %F in (*.BAS) DO BC %F; > ERRORS

will only capture the errors reported for the last file, since the ERRORS file is reopened on each loop of the FOR command. You could use >> ERRORS to append each compilations output to the file, but then you have to remember to delete the file prior to running the command. Using

COMMAND /C FOR %F in (*.BAS) DO BC %F; >ERRORS<

will redirect all of the output from the FOR command into a single errors file.

If you have any questions for Dr. DOS or Mr. UNIX, I'll pass them along to them/him. You can e-mail them to me at tom@chloris.nrel.colostate.edu.

-- Tom Kirchner, Central Plains LTER

UNIX SCRIPTS by Mr. UNIX

Here are a couple of examples of scripts that I created to help keep my SunView display organized. These scripts both open new windows, and are designed to put a label on the window and on the icon that is displayed when you close the window.

The first script is just a general purpose window. I named my version of this script "task". It is a single command line and takes one argument. The argument is just a string to be used as a label.

shelltool -Wp 199 100 \
-WP 772 0 -Wh 44 -Ww 80 -Wf 170 0 0 \
-WI /usr/include/images/terminal.icon \ -WL "$1" -Wl "Task: $1" &

Although this is one command line, it is split across 2 lines in the file by placing a \ at the end of the first line. The \ character indicates to the C-shell that the next line feed should be ignored. The $1 token in the command line is replaced by the argument. For example, if I want to run a simulation in a window so that I can check on its progress once in a while I'll enter

task model

to label it "TASK:model". If I close the window, the icon will be labeled "model". If you want to have a label that includes blank spaces, enclose the label in quotes, as in

task "process data"

The quotes around the $1 argument insure that it will work if you give it an argument that has embedded spaces. Also notice the ampersand at the end of the command. The & causes the shell to be backgrounded. If you don't background the shell, then the first window will be left running the second window as its foreground process, and thus not be of much use.

The next script is almost identical to the first, but includes a command to run once the window is opened. The command in this case is rlogin, the remote login command. I call my script rl, so when I run

rl geococcyx

I open a window labeled "Computer:geococcyx" and have a remote login session started in that window. If I close the window the icon is labeled "geococcyx". Notice the "; exit" after the "rlogin $1" part of the command. The ; is used to seperate two commands on a single command line. The "exit" command automatically terminates the window once you end the rlogin session by logging out of the remote computer.

shelltool -Wp 199 100 -WP 772 0 \
-Wh 44 -Ww 80 -Wf 170 0 0 \
-WI /usr/include/images/terminal.icon \
-WL "$1" -Wl "Computer: $1" \
-I "rlogin $1; exit" &

If you create these scripts, remember to place them in a directory listed in your path (~/bin is usually recommended as a place for such things) and make them executable by using chmod (chmod 777 task, for example).

Launching Unix Jobs From A DOS Window

I helped Bill Lauenroth get the TIME-ZERO modeling software running on the College's 386i computers this Spring. TIME-ZERO is DOS software, but creates models in Fortran that can be compiled and run under UNIX. The advantage of running the models under UNIX is that the performance is much better, since you are making full use of the 32 bit processor, and you can run long simulations in the background. (It really amuses me to read about "power" users running on the 32 bit '386 and '486 PCs under DOS, which can in itself only make use of 16 bits and address 640K of memory). I was glad to see that Bill finally saw the light and was making the change to UNIX. In getting things to work reasonably well I discovered a few things about the DOS/UNIX interface. First, here are the scripts to compile the models. I had to use 2 scripts because I couldn't find a way to get the second script quoted properly to nest within the first script. If anyone tries this and finds a way to do it, I'd like to see it!

The script dof77 simply opens a small window, labels it, and runs the script called donext. I wanted to open a window separate from the DOS window to signal the fact that compilation was in process (students often get impatient when nothing appears to be happening). The donext script actually does the compilation. The name of the model is passes to dof77, then to donext, as the first argument, which is denoted $1 in the scripts.

Notice that standard output and standard error are redirected from the f77 command in donext to a file called f77.errors (the >& redirects the two "streams"). The donext script makes use of the "logical or" capabilities of the shell. If the first command fails, as it will if there are compilation errors, the second command will execute. If the first command succeeds, then there is no need to do the "or" clause, so the shell skips it. The second command opens a new window, colored red, and displays the errors using the "more" filter. The first line of the scripts,

#!/bin/csh

are simply used to insure the commands are interpreted by the C-shell, not the Bourne shell. The Bourne shell doesn't use the same notation for redirection of standard error.

dof77:
#!/bin/csh
shelltool -Wp 600 7 -Ws 500 128 \
-Wf 0 255 0 -Wb 0 0 0 -Wl \
Compiling -I "/usr/local/time0/donext \
$1 ; exit "
donext:
#!/bin/csh
f77 -O -o $1 $1.f -ltime0 >& \
f77.errors || shelltool -Wp 650 50 \
-Ws 500 256 \-Wf 255 0 0 -Wb 0 0 0 \
-Wl Errors -I \
"/usr/5bin/pg f77.errors ;exit"

These scripts can be used from UNIX as they are for compilation, although you will probably want to customize the f77 command line to suit your needs. The -ltime0 is used to link to the TIME-ZERO library, which you will not need.

(Warning: Mr. UNIX started to lose it here, and this next section may be hazardous to your sanity, unless you have worked with UNIX long enough to take perverse pleasure from its design, or feel that you could intelligently follow the conversation if you were in Alice's place at the tea party, TBK)

UNIX commands can be run from the DOS window by prepending "unix" to the command line. Below is the batch file we ran from DOS to compile the models. I used "sed" to convert from DOS to UNIX formats rather than dos2unix because I had to take care of a few other differences between Microsoft Fortran and Sun's Fortran as well as the ^M (carriage returns) at the end of the DOS lines. "tr" was used to convert the files to lower case.

Editor's note: Some of the following lines were too long to fit in a single column of text. A ~ has been used to indicate where a line was broken for printing purposes. Lines separated by a ~ should be joined when attempting to run these programs.

F77.BAT: 
ECHO OFF
REM Convert file to UNIX format
unix sed -f ~
/usr/local/time0/sedfile %1.for >%1.x
unix tr A-Z a-z < %1.x > %1.f
DEL %1.x
REM Now compile it under UNIX
unix /usr/local/time0/dof77 %1
REM If it compiled Ok, should be a ~
file called model_name (the first
REM argument to F77.BAT)
IF NOT EXIST %1 GOTO FAILED
REM Link to the generic "run this ~
model" routine
unix ln -s ~
/usr/local/time0/modelexe.exe %1.exe
ECHO Compilation completed
GOTO EXIT
:FAILED
ECHO Compilation apparently failed
PAUSE
:EXIT

The last trick demonstrated in this batch file is related to creating a link to a file called modelexe.exe. This last step was necessary in order to allow the DOS software to directly execute the UNIX models. The link is named the same as the model. For example, if the model was named STREAMS, then STREAMS.EXE would be linked to MODELEXE.EXE. MODELEXE.EXE is a DOS program which does nothing more than look to see what name it was run under, and then execute a DOS system command to run the command

unix task model_name

where model_name is the name of the UNIX executable file for the model. The purpose of all these contortions is simply to allow one to enter the model name as a DOS command and have it run the UNIX version of the model. For example, if one enters

STREAMS

as a DOS command, DOS will execute STREAMS.EXE (which is in reality MODELEXE.EXE, because of the link). STREAMS.EXE will look at its own command line, extract the name STREAMS from it, and build a new DOS command that looks like

unix task streams

This command line is passed back to DOS via a system command (like the SHELL command of Microsoft Basic, or the exec command in C), which then launches the UNIX program named streams.

(If at this point you think it would take a madman to come up with a scheme like this, you are probably correct ... but try following the trail of your f77 and cc commands sometime to see where they lead you. Also, if you have been using one of the versions of DOS that includes XCOPY, take a look in your manual to see if it was the version that suggested you rename it to NCOPY to change its behavior. TBK)

This next material was dropped off the next afternoon. "Dr. DOS" asked me if I knew who wrote the UNIX piece, and was giving me strange looks. I explained that I only found it in my mailbox, but I'd let him know if I found out. TBK.

Good Reads


Helpful Laws, Rules, and Axioms

Meskimen's Law
There's never time to do it right, but always time to do it over.

The Fifth Rule
You have taken yourself too seriously.

Law Of Communications
The inevitable result of improved and enlarged communication between different levels in a hierarchy is a vastly increased area of misunderstanding.

Lord Falkland's Rule
When it is not necessary to make a decision, it is necessary not to make a decision.

The Army Axiom
Any order that can be misunderstood has been misunderstood.

Sevareid's Law
The chief cause of problems is solutions.