FORDENV.DIR;1             1/1       18-DEC-1987 13:05
			FORD AEROSPACE & COMMUNICATION CORP.

			WILLIAM BAKER
			SYSTEM MANAGER

			713-483-5353
-------------------------------------
SETUSER:

	PROGRAM TO CHANGE USERNAME TO THAT OF SOME OTHER USER ON THE
	SYSTEM.  PROVIDES A GOOD UTILITY FOR SOME SYSTEM MANAGER FUNCTIONS.
-------------------------------------
MAILUTIL:

	PROVIDES THE CLOSEST THING TO A VMS VERSION OF RETURN RECEIPT
	AVAILABLE.  LET'S A USER SEE IF HIS MAIL HAS BEEN READ BY
	ANOTHER USER.  PROXIES MUST BE ESTABLISHED FOR NETWORK FUNCTION.
-------------------------------------
SPEEDLOGIN:
	SPEEDS UP THE DEFINITION OF THOSE SYMBOLS THAT ARE DEFINED
	GLOBALLY IN THE SYLOGIN.COM FILE.
LABSTAR.DIR;1             2/2       18-DEC-1987 13:06
	I JUST STARTED WORK ON THESE PROGRAMS FOR RUNNING A LABSTAR SYSTEM.
	THEY ARE NOT PROVEN, AND ARE STILL IN THE DEVELOPMENT STAGE.
	HOWEVER THEY ARE FAR ENOUGH ALONG THAT WITH A LITTLE EFFORT,
	THEY COULD BE OF BENEFIT TO SOMEONE.

	THE GENERAL IDEA IS THAT WHEN PERFORMING A/D IO (OR D/A IO) ON A
	LABSTAR, YOU DON'T WANT TO REWRITE THE IO ROUTINES EVERY TIME.
	YOU COULD USE A OBJECT LIBRARY TO GET AROUND THIS, BUT IN ESSENCE
	YOU'D STILL BE AT THE MERCY OF THE OBJECT LIBRARY FOR YOUR
	PARTICULAR TEST ENVIRONMENT.  WHAT I'M TRYING TO DO HERE IS TO
	CREATE AN ENVIRONMENT THAT ALLOWS THE USER TO CONFIGURE THE A/D
	DEVICES ON HIS SYSTEM AND RUN A TEST WITHOUT THE NEED TO WRITE
	SPECIAL LIO$ CODE.  I'VE CREATED A SHARED COMMON DATABASE THAT
	CONTAINS ALL THE CURRENT DATA, AND A BUFFER OF THE LAST 120
	DATA POINTS RECEIVED.  THEN I HAVE A MAINIO PROGRAM THAT PERFORMS
	ALL THE SETUP OF THE DEVICES AND THE IO TO THE SHARED COMMON.
	IN ADDITION I'VE CREATED TWO PROGRAMS WHOSE JOB IT IS TO FILE
	THE DATA TO DATAFILES WHEN THE BUFFERS BECOME FULL.  FINALLY
	I'VE ATTEMPTED TO CREATE A MENU DRIVEN ENVIRONMENT FOR CONTROLLING
	THE A/D BOARDS, AND DISPLAYING ANY DATA RECEIVED IN THE COMMON.
PRINT.DIR;1               1/1       18-DEC-1987 13:07
	TPRINT ALLOWS THE USER TO PRINT TEXT FILES TO A LOCAL PRINTER
	ATTACHED TO HIS VT102 TYPE TERMINAL.   TPRINT PROVIDES A
	COMMAND LANGUAGE INTERFACE FOR THE PROGRAM TO DETERMINE THE
	TYPE OF PRINTER ATTACHED TO THE TERMINAL.  THIS IS VALUABLE
	FOR THOSE PEOPLE USING PC VT102 EMULATORS.  ADDITIONAL
	FEATURES ALLOW FOR DIFFERENT STYLES OF PRINT.  THE MOST
	COMMON STYLES OF PRINT ARE:  NEAR LETTER QUALITY, BOLD,
	AND COMPRESSED.
TAPECNTRL.DIR;1           1/1       18-DEC-1987 13:07
	THIS PROGRAM WAS INTENDED TO BE A QUICK ROUTINE FOR LOADING FOREIGN
	TAPES WHERE YOU HAD WORKED OUT A PROCEDURE FOR LOADING, OR KNOW THE
	THE CONTENTS OF THE TAPE AHEAD OF TIME.  IT SEEMS TO WORK WELL WITH
	LITTLE SYSTEM IO OVERHEAD INVOLVED.  IT SHOULD WORK ON ANY TAPE DRIVE
	ATTACHED TO A VAX SYSTEM.  I HAVE NOT TRIED IT ON A TK50, BUT THAT
	SHOULD NOT BE A PROBLEM.  I HAVE USED IT ON TU77'S AND TU78'S.
TELEMAIL.DIR;1            1/1       18-DEC-1987 13:07
	William Baker
	Ford Aerospace & Communication Corporation
	1322 Space Park Drive
	MS: B2C
	Houston, Texas  77058

	NASA Life Sciences Project
	NASA/JSC, Building 37
	MS:  SD
	Houston, Texas 77058

=========================================================================

GENERAL COMMENTS:

	The following set of command procedures and programs were written
	in order to support the NASA Life Sciences Division.  There purpose
	is to provide an environment where mail on the GTE/TELENET system
	(or any system using the GTE/TELENET mail protocol) can be read
	via a batch program and delivered to the users VAX mail or A1
	mail.  As such, logical outcomes of the project were programs to
	send mail to the TELEMAIL system, and to read bulletin boards
	on the TELEMAIL system.  The basic programs were written with the
	use of the DECUS VAXNET program as the seed program.  In fact many
	of the major modules still maintain 100% integrity with the latest
	version of VAXNET, leaving on 2 or 3 main driving routines that
	were added to make the system work.  As the source code is written
	now, only the modem control module needs to modified to allow
	this set of programs to be run outside the NASA/JSC telephone system.
	When the NASA/JSC phone system was recently brought into the 20th
	century, I decided not to try and support all the modem protocols
	that VAXNET currently supports.  However, since the calls to the
	modem module from the main program are fairly standard (and I beleive
	the same as what VAXNET uses) you should have no difficult in just
	substituting the VAXNET version of MODEM.FOR for my MODEM.FOR.
WATCH.DIR;1               1/1       18-DEC-1987 13:09
	Short program to watch other processes...