SUBMISSION:  VARIOUS SOFTWARE ITEMS FROM COMPASSION INTERNATIONAL AND/OR
	     KEN RICHARDSON - 05-Dec-1990

Submitted by:

	Ken Richardson
	Compassion International
	PO Box 7000
	Colorado Springs, CO  80933

	Phone:		(719) 594-9900
	FAX:		(719) 594-6271
	TELEX:		(025)910-380-9380 (CMPASHUN)
	Easylink:	62868920

Disclaimer:

	This software is made available to the public with no warranties,
	guarantees, or liability for its use or any consequences thereof.
	After all, it's free.  However, I wouldn't submit it if I didn't think
	it worked correctly.  And the code written at our site tends to be
	well-structured, efficient, clean, and debugged.

Contacting the contributor:

	If you have any questions or comments, you can find me at the address or
	phone number listed above.  I don't mind phone calls.  However, I'm not
	easy to reach by phone, so feel free to leave a message.

General description:

	This submission contains my "standard" DECUS contribution.  Some items
	have been upgraded since the last Fall DECUS tape.  Some have not.
	Executables are provided for every program; source code for most.
	Probably the most popular programs are SYSTATUS and ENPAGE.
	New this year:  EATCPU.

Philosophical comments:

	In the past, I've rarely included the sources.  Why?  Because I wanted
	to know that if any bugs were ever reported, they weren't due to
	program changes that I didn't know about.  (As it turns out, no bugs
	have ever been reported, although I've heard from several sites that
	use this software.)

	However, I've had a change of heart about including the sources.  This
	is because I read a notes file on DECUSERVE that praised one of my
	programs, but lamented that the source code wasn't provided.  I guess
	I'm willing to risk some spurious bug reports if the source code will
	really be useful to somebody.  (It sure warms your heart to hear one of
	your programs praised!)

	I've also read that many sites won't use contributed software without
	the sources, because of the security risk.  That makes sense.  However,
	I GUARANTEE that none of my software does anything inappropriate.  Now,
	won't your security manager be THRILLED to hear that there's nothing to
	worry about, because Ken said so! :-)  Anyway, I go to the DECUS
	symposia every year, so contributing rogue software would be a good way
	to commit suicide.  I'd have 7,000 people taking turns wringing my
	neck.  Of course, I'm assuming that 100% of the attendees have the good
	sense to use MY wonderful software.  They do, don't they?

Detailed descriptions:

	The following are descriptions of most of the files you'll find in this
	submission.


CLOSE_VMS_ACCT.COM

	We use this command procedure to close our VMS accounting files every 
	month.  This facilitates usage analysis and archiving of accounting data
	by month.  Nothing fancy, but if you don't have it, here it is.

CONCATENATE_SIXEL.EXE

	This program concatenates SIXEL graphs side-by-side.

	At our site, we do Datatrieve graphs of CPU performance statistics.
	Lots of them.  So I wrote this program to minimize paper by printing
	these graphs in two columns.  First we run our REGIS graphs through
	RETOS, which gives us SIXEL graphs.  Then we run the SIXEL graphs
	through this program.

CONCATENATE_SIXEL_EXAMPLE.COM

	This little command procedure shows the basics of using
	CONCATENATE_SIXEL.

COUNTREC.EXE

	I got tired of copying files to the null device in order to find out how
	many records they contain (copy/log file.dat nl:), which can be quite
	slow and resource-intensive with large files, so I wrote this simple
	record-counting program.  If you define it as a foreign command, you can
	specify the input file on the command line.  Otherwise, it prompts you.
	Wildcards are not implemented yet; however, COUNT_RECORDS.COM provides
	this.

COUNT_RECORDS.COM

	This procedure allows wild-carded counting with COUNTREC.EXE.  We have a
	COUNT command defined as @CI$COMMAND:COUNT_RECORDS.COM, which lets us
	type "COUNT filespec" to count records in a bunch of files. 

DIALUPINI.EXE

	We use US-ROBOTICS hayes-compatible modems on our dialups (the kind that
	use the AT command set).  They work fine; we use the same lines both for
	dialing in and for dialing out.  However, when the modems power up, they
	default to sending extra information to VMS (like "RING<CR>" and
	"CONNECT<CR>") every time someone dials in.  This causes VMS to complain
	that username RING is trying to break in.  So we run DIALUPINI.EXE to
	tell the modems to be quiet, and everything works much better.

	DIALUPINI.EXE expects a logical name (DIALUP) to point to the port that
	needs to be reset, and it expects you to already have allocated the port
	and set the appropriate speed (assuming you are using autobaud on the
	port).  You might need a privilege to allocate the dialup port,
	depending on how your ports and system parameters are set.  I think it's
	SYSPRV.  For more info about DIALUPINI.EXE, see INIT_DIALUPS.COM.

DROIDS.EXE

	This game lets you get chased by robots on a 24x40 field.  Only in a
	weak moment will I confess who wrote it.  It runs efficiently, using
	only one QIO per screen update and one per input.  It requires write
	access to a CI$GAMES directory, which is where it stores the "droids
	champions" list (droids.dat).  If more than one player will be using the
	same droids.dat file, you need to SET FILE/PROT=W:RW to the file after
	the first player creates it.

EATCPU.EXE

	This program consumes an (almost) exact percentage of a VAX's CPU
	capacity.  It is typically used to test the response time of various
	software packages under controlled load conditions.  For example, "How
	fast (slow) is product X when the CPU is Y% saturated?"

	If you are considering using a slower processor for an application,
	response times on slower processors can also be predicted fairly
	reliably by slowing down the faster processor by the appropriate
	ratio.

EMPTY.SIXEL

	This "empty" sixel graph is used by CONCATENATE_SIXEL_EXAMPLE.COM.  It
	is used as the "left-hand" graph in a concatenation operation in order
	to indent a SIXEL graph.  It has the minimum SIXEL codes needed by
	CONCATENATE_SIXEL for a successful concatenation operation.

ENPAGE.DOC

	ENPAGE.DOC is a documentation file describing the ENPAGE utility.
	For more info, see ENPAGE.EXE or read ENPAGE.DOC.

ENPAGE.EXE

	When we got our nifty new LN03 laser printers, we needed a way to put
	all that power in the hands of our office staff.  ENPAGE is how we did
	it.  This version uses less CPU time than the Fall 1989 version.

	ENPAGE reformats a text document, adjusting margins (left, right, top,
	& bottom), pitch (both vertical & horizontal), orientation (portrait or
	landscape), point-size, and stuff like that.  It compensates for
	embedded tabs regardless of the left margin you specify.  If you've
	never encountered that problem, please ignore the previous sentence.

	For people who write letters, ENPAGE can optionally output the first
	page separately from the rest of the document.  We use this feature
	because we have one printer loaded with letterhead and one loaded with
	plain-bond.

	ENPAGE output can be directed either to devices or to files.  ENPAGE
	output is suitable primarily for LN03 laser printers (it inserts LN03
	control sequences into the results).  To use the output on some other
	printer, you'd probably have to edit the device control sequences out
	of the first and last lines of the output files.

FORCEX.EXE

	Have you ever had a program get into an infinite loop?  Well, neither
	have I, but just in case it ever happens, this program will exercise the
	VMS system services just enough to list out all the processes on the
	system and ask you if you want to force-exit any of them.  The display
	format has been upgraded since Fall 1989.

	It's not any fantastic new discovery, but it does have the advantage of
	stopping just the current image rather than the entire process.  The
	process returns to the $ if it's interactive, or to the next line in
	the command procedure if it's batch.  FORCEX requires WORLD privilege,
	GROUP privilege, or the same username, depending on the target process.

INIT_DIALUPS.COM

	We have three dialup lines; they are known by system-wide logicals
	ci$dialup_1, ci$dialup_2, and ci$dialup_3.  We initialize the modems on
	those lines during system startup and once per hour (in case someone has
	been using a modem and left it in a non-standard condition).

	The INIT_DIALUPS.COM command procedure looks for all devices pointed to
	by ci$dialup_n.  For each such unallocated device, INIT_DIALUPS.COM
	allocates the device, sets the speed, initializes the modem (using
	DIALUPINI.EXE), and deallocates the device.

	The maximum speed for each modem must be specified by the logical
	ci$dialup_max_speed_n (e.g. ci$dialup_1 = "TXA0" and
	ci$dialup_max_speed_1 = "2400").

LASER2.COM

	This is the procedure that drives the ENPAGE utility.  Actually, at our
	site we have another procedure that provides novice users with somewhat
	simple access to rather sophisticated printer characteristics on several
	printers throughout the office, including our plain-bond laser printer.
	However, LASER2.COM shows the basics of using ENPAGE.EXE when driving a
	letterhead/plain-bond printer combination.

LOCK_TERMINAL.EXE

	This is a simple program that accepts and verifies a password, then
	locks your terminal until you type the password again.  Useful for
	leaving an account logged in while you go away for a couple of minutes.
	It traps CONTROL-C and CONTROL-Y.  However, if you are logged-in
	remotely using $SET HOST, CONTROL-Y could still be used by a malicious
	user to return to your original process on the local node.  For this
	reason, I use it mainly on local nodes.

REMINDPRT.COM

	This is a simple command procedure to provide access to REMINDPRT.EXE.

REMINDPRT.EXE

	We are using a REMINDER utility that came from a DECUS tape a few years
	ago.  It was written by someone at AT&T.  If you are using the same
	REMINDER program, you might find REMINDPRT.EXE useful.  It is NOT
	compatible with other reminder programs from more recent DECUS tapes!

	We needed more flexibility in printing out reminders, so we wrote this
	program to print simple calendars from the reminder file.  No REMINDER
	user should be without it.  Output goes to CI$OUTPUT.

REMRESCHD.EXE

	One of the annoying things about that AT&T REMINDER utility is that it
	deletes old reminders automatically, even if you never got to see it.
	Well, every night right after midnight I run REMRESCHD.EXE to reschedule
	old reminders up to today.  That way REMINDER becomes a to-do list that
	won't let me forget a reminder unless I explicitly delete it.

	Caution:  If your login.com automatically displays your reminders
	($REMIND ME) like mine does, you need to jump over that line when f$mode
	is "BATCH" so your midnight rescheduling job can run REMRESCHD on your
	reminder file before REMINDER gets to it.

SHUT_LOGS.COM

	We use this command procedure to close our OPERATOR.LOG file nightly and
	open a new one.  It also closes our database monitor logfiles, which are
	produced by VAX DBMS.  It resubmits itself nightly, skipping weekends
	automatically.  Again, nothing fancy, but if you don't have it, here it
	is.

	For some reason, the VMS developers wrote the $REPLY/LOG command to
	require a terminal as its sys$command device.  Therefore, in order to
	shut OPERATOR.LOG, this procedure temporarily grabs the operator console
	as its sys$command device.  Back when I wrote this procedure, it
	wouldn't work from batch unless it did some sort of trick like this.  I
	haven't checked to see if VMS has lifted this requirement since.

SYSTATUS.EXE

	This is SYSTATUS version 5.5 for VMS version 5.2 or later.  It's a
	system status monitor with some interesting display flexibility.  We
	use it constantly at our site.

	I frankly don't know how people can manage a VAX without being able to
	see the info that SYSTATUS provides (like which program everyone is
	running).  One of the most useful features is the ability to limit the
	display just to busy processes (this can reduce a 100-process display
	down to 20 or so processes).  To try this feature, run SYSTATUS and type
	the three letters SAD (Select Attribute Dormant).

	To use SYSTATUS, you just type RUN SYSTATUS at the $ (we have a STATUS
	foreign-command defined to do this).  Most commands are one character
	(no <CR>).  On-line help is available by typing the letter "H" while
	SYSTATUS is running.

	Significant changes since SYSTATUS version 5.2 (on the Fall 1989 DECUS
	tape):

	    1.	Several efficiency upgrades.  SYSTATUS now uses less CPU time
		(it wasn't bad before).

	    2.	A bug fix.  SYSTATUS would occasionally "hang" when the user
		entered a scan time during program activation.

	    3.	Improved avoidance of inswapping other processes.  Prior to VMS
		V5.2, SYSTATUS avoided inswapping through knowledge of which
		GETJPI items caused inswapping and which didn't.  However, this
		no longer worked as of VMS V5.2, so the GETJPI flag
		jpi$m_no_target_inswap, a new feature in VMS V5.2, became
		important to use in SYSTATUS.

	    4.	Delete-pending processes are now visible.  These are processes
		that you've tried to delete, but they're waiting for something
		important, like a MUTEX semaphore for example.  (I think I said
		that right.)  These processes have always shown up on SHOW
		SYSTEM, but a new feature in VMS V5.2 made them available to
		SYSTATUS.  So naturally I took advantage of it.

	Setting up SYSTATUS:

	SYSTATUS is easy to set up.  Minimally, you can just RUN it.  However,
	it needs GROUP or WORLD privilege to look at processes outside your own
	UIC.  We install it without these on most of our machines, so that only
	users who normally have these privileges can watch other users'
	processes.  If you want everyone to be able to look at other processes
	in their UIC group, install it with GROUP.  If you want everyone to be
	able to look at all other processes, install it with WORLD.

	We have SYSTATUS installed SHARED to save memory when multiple people
	use it at the same time.

	I recommend you install it with ALTPRI.  If you do, SYSTATUS
	temporarily boosts its own priority to 16 during each brief
	data-collection interval, thus improving the accuracy of the results.
	It disables control-y before boosting the priority, and restores the
	previous state of control-y (usually enabled) after dropping back down
	to the original base priority.  If you're running any realtime stuff on
	your system at priority 16, I suppose you wouldn't want to install
	SYSTATUS with ALTPRI (nor run it from an account with ALTPRI turned
	on).  For the other 99% of VAX sites, I do recommend that you install
	it with ALTPRI for the most accurate results.

	SYSTATUS automatically senses your terminal width and height.  If your
	terminal is in 132-column mode, you get more info than in 80-column
	mode.  If you have a terminal with more or fewer than 24 lines, the
	display will scroll correctly.  This all assumes that you have done a
	$SET TERMINAL/WIDTH=n/PAGE=n type of command.

	SYSTATUS does screen output with as few QIOs as possible, usually just
	one.  If it can't display its buffer with one QIO, it tells you why and
	exits.  The reason for the QIO failure is usually EXQUOTA.  This can be
	corrected by increasing the SYSGEN parameter MAXBUF, which I have set at
	something like 10000 for our systems.

SYSTATUS_VMS_V3.EXE

	This is an older version of SYSTATUS for VMS version 3.

SYSTATUS_VMS_V4.EXE

	This is SYSTATUS version 5.0 for VMS version 4.

USING COMPASSION INTERNATIONAL SOFTWARE

	If you use any of the software in this submission, you will probably
	need to edit our command procedures or define logical names to account
	for the conventions that we use at Compassion.  The items you will
	probably need to change or define include:

	LOGICAL NAMES:

	ci$command	The directory that holds our local command procedures.
	ci$dialup_n	The dialup ports at our site (n = 1, 2, 3, etc.).
	ci$dialup_max_speed_n
			The dialup port speeds at our site (n = 1, 2, 3, etc.).
	ci$games	The directory that holds games and related files.
	ci$images	The directory that holds our local images.
	ci$input	The primary input device for a program.
	ci$output	The primary output device for a program.
	ci$output_2	The secondary output device for a program.
	ci$workfiles	The intermediate directory commonly used at our site.

	QUEUE NAMES:

	laser$print_1	The name of our plain-bond print queue.
	laser$print_2	The name of our letterhead print queue.
	normal$batch	The name of our priority-4 batch queue.

	FORM NAMES:

	letter1		The form type normally mounted on laser$print_2.
	plain_bond	The form type normally mounted on laser$print_1.