B00101
------------------------------------------------------------------------------
DISKISREADY B001
DETERMINE WHETHER A DISK IS ON LINE AND READY
------------------------------------------------------------------------------
Contribution Name......(16).: DISKISREADY
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. DISKISREADY.SBMT
: 02. DISKISREADY.FTN
: 03. DISKISREADY.LOD
: 04. DISKISREADY.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN77
Keywords.................: 1. DISK
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 19 Dec., 2001
Program Abstract............:
DISKISREADY reports back whether or not a disk is up and ready. It
will not itself cause the disk LU to be put DOWN.
If the disk is ready, DISKISREADY exits with PRTN(1) set = 0 (ready).
If not, it exits with PRTN(1) = 1 (not ready).
An example of use in the WELCOME file:
IF DISKISREADY 44
THEN
MC 44
MC 45
ELSE
ECHO `LU 44 is not ready`
FI
In this example DISKISREADY tests LU 44. If LU 44 is ready, then LUs
44 and 45 are mounted. If not, an error message is displayed.
See also the WAITFORDISK contribution, which actually waits for a disk
to come up ready, with a timeout.
See source for more documentation.
B00201
------------------------------------------------------------------------------
IFSETTIME B002
BOOTUP OR LOGON TIME/DATE SAFETY CHECK
------------------------------------------------------------------------------
Contribution Name......(16).: IFSETTIME
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. IFSETTIME.SBMT
: 02. IFSETTIME.FTN
: 03. IFSETTIME.REL
: 04. IFSETTIME.LOD
: 05. TIME.FTN
: 06. TIME.REL
: 07. TIME.LOD
Operating System(s)......: RTE-A, untested on RTE-6 but might work
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1. TIME
: 2. DATE
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...: TIME portion resubmitted for convenience
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
The system clock is initially set to April 1, 1983 at bootup.
IFSETTIME checks to be sure that the system time has been changed,
i.e that the system date exceeds 1993 (the year the program was put
into service). If not, then the system's automatic time-setting
means (if any) has failed, and IFSETTIME schedules the program named
TIME to collect the correct time and date from the operator instead.
Note: the value 1993 can easily be changed in the source. For
example, to allow only the years 2002 through 2037, change line 20 to
read thus:
IF (TIMEDATE.LT.'02' .OR. TIMEDATE.GT.'37') THEN
...
IFSETTIME is normally used in the WELCOME file or an operator's HELLO
(logon) file, or both. If used in the WELCOME file, the bootup
process will halt until the operator manually responds to the TIME
program's prompts.
Schedule it as follows: RU, IFSETTIME
A program called TIME is recontributed here as part of this contrib-
ution, but any program named TIME will do. You may prefer your own.
This version of TIME will only allow the time to be changed by a
superuser or by the system session in the bootup WELCOME file.
See source for more documentation.
B00301
------------------------------------------------------------------------------
WAITFORDISK B003
WAIT FOR A DISK TO COME ON LINE, WITH TIMEOUT
------------------------------------------------------------------------------
Contribution Name......(16).: WAITFORDISK
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. WAITFORDISK.SBMT
: 02. WAITFORDISK.FTN
: 03. WAITFORDISK.LOD
: 04. WAITFORDISK.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN77
Keywords.................: 1. DISK
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 19 Dec., 2001
Program Abstract............:
WAITFORDISK just waits for a disk to come on line.
It can be used at bootup in systems with multiple disks, where some
disks don't spin up as quickly as the boot disk (e.g 7933, 7935 are
slow). In such an application it prevents the slow disk from being
put DOWN because it was accessed too soon. WAITFORDISK will not
itself cause the disk to go DOWN.
When the disk comes on line, WAITFORDISK exits with PRTN(1) set = 0
(successful). If the runstring supplied timeout occurs first, it
exits with PRTN(1) = timeout value (unsuccessful). If it detects the
BReak flag, it exits with PRTN(1) = 32767 (unsuccessful).
An example of use in the WELCOME file:
IF WAITFORDISK 44 1200
THEN
ELSE
ECHO `LU 44 failed to come up`
FI
In this example WAITFORDISK waits for LU 44, timing out after 1200
seconds (20 minutes).
See also the DISKISREADY contribution, which reports whether a disk is
ready without waiting.
See source for more documentation.
B00401
------------------------------------------------------------------------------
COPYDISKFAST B004
COPY ONE DISK LU TO ANOTHER, WITH PROGRESS
------------------------------------------------------------------------------
Contribution Name......(16).: COPYDISKFAST
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. COPYDISKFAST.SBMT
: 02. COPYDISKFAST.FTN
: 03. COPYDISKFAST.REL
: 04. COPYDISKFAST.LOD
: 05. COPYDISKFAST.SEND
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1. DISK
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
COPYDISKFAST copies one LU to another, as rapidly as possible, with a
%-completion progress display. It is as fast as COPYL or faster. In
particular, it seems to be faster than COPYL when copying to optical
disks. In addition, it offers options such as:
* Optional pre-read with abort if the source disk has any errors
(avoids copying a bad disk over a better one).
* Optional locking of the source disk during the copy.
* Optional inhibit of all terminal display.
* Optional verify of the copy.
* Optional local handling of disk I/O errors (avoids a disk going
DOWN during the copy).
As with COPYL, the disk LUs must be the same size, in blocks.
However, they need not be the same type of disk or the same number of
blocks per track.
Example application: Used disks are cheap now. COPYDISKFAST can be
scheduled every night to make a warm backup, e.g copy LU 44 on one
disk mechanism to LU 54 on another in the background as follows:
XQ COPYDISKFAST 44 54 ELPQV
See source for more documentation, particularly error reporting.
See also the previous OSAVE/ORSTR submission, in CSL release 3326,
which allows rapid copy of a disk LU to a FILE on another (larger,
possibly optical) disk LU. These programs mimic ASAVE and ARSTR but
with the archive file saved on disk rather than tape, and with
progress reporting.
B00501
------------------------------------------------------------------------------
COPYSCREEN B005
COPY ANY SCREEN TO TERMINAL, PRINTER, OR FILE
------------------------------------------------------------------------------
Contribution Name......(16).: COPYSCREEN
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. COPYSCREEN.SBMT
: 02. COPYSCREEN.FTN
: 03. COPYSCREEN.REL
: 04. COPYSCREEN.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 22 Dec., 2001
Program Abstract............:
COPYSCREEN copies the screen of any terminal connected to the HP
1000, displaying the results on your terminal and optionally also
writing them to a file or another device, such as a printer.
It is very helpful for debugging users' problems or looking at the
system console screen without actually being there. Also, it can
easily copy your own screen to a printer or a file.
At ICT it is often used to view the system console or a user's screen
by dialup on a system hundreds or thousands of miles away.
COPYSCREEN is an enhancement of Don Clapp's program CTOME,
contribution 2730 L048, 1987.
Usage:
RU COPYSCREEN [FromTerm [DestFile [Opts]]]
Where:
FromTerm is the system LU of the HP terminal we will read. If
not supplied, default is your own terminal screen.
DestFile is a destination file or device in addition to your
terminal.
Opts (may be supplied in any combination):
A Append this data if the file already exists.
C Clear FromTerm screen after copying it.
D Overwrite preexisting DestFile without asking.
F Force cursor to bottom of screen after copying.
H Write a 1-line Header/timestamp at the destinations.
L Copy only from the current cursor position (Line) down.
Q Quiet (inhibit) the display on your terminal.
COPYSCREEN will not attempt to copy through a pending read on the
FromTerm device. If you need to copy the screen of a terminal which
has a pending read from an active program, you must first suspend the
active program (SS,PROG/LU) and then abort the pending read
(CN,LU,AB) before running COPYSCREEN. Afterward, you should resume
the program (GO,PROG/LU).
Your terminal must support normal HP control sequences, i.e it must
allow EDIT to run in screen mode.
It has not been tested with TELNET terminals but it should work.
I recommend that you put COPYSCREEN in your list of Prototype IDs to
be RP'd at bootup.
See source for more documentation.
See also the PSCREEN contribution for a simple command which copies
your screen to a printer.
B00601
------------------------------------------------------------------------------
FCS80 B006
WAIT FOR CS/80 TAPE READY, FORMAT IF NECESSARY
------------------------------------------------------------------------------
Contribution Name......(16).: FCS80
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. FCS80.SBMT
: 02. FCS80.FTN
: 03. FCS80.REL
: 04. FCS80.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
FCS80 waits for a CS/80 tape drive to come up and ready, checks to
see if the tape has been certified (formatted), and schedules FORMC
to certify it if not. After the tape is ready and certified, FCS80
exits. Certification, if needed, will be done whether or not the
operator is a superuser.
This program is very helpful in command files which write to CS/80
tapes, such as FST backups. Prior to scheduling FST, schedule FCS80
as follows:
RU FCS80 LU
Where LU is the logical unit of the tape.
This allows an operator to put a tape in the drive, start the backup
operation, and leave without waiting for the tape to come ready.
More important, if the tape is already certified, the time necessary
to certify it is not wasted.
FCS80 exits if it detects the BReak flag. It does not use the PRTN()
parameters on any exit.
See source for more documentation.
See also WAITFORCS80, which also waits for the tape to be ready but
does not certify the tape.
B00701
------------------------------------------------------------------------------
FILELU B007
REPORT THE LU CONTAINING A SPECIFIED FILE
------------------------------------------------------------------------------
Contribution Name......(16).: FILELU
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. FILELU.SBMT
: 02. FILELU.FTN
: 03. FILELU.REL
: 04. FILELU.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
FILELU reports in $RETURN1 (PRTN(1)) and $RETURN_S the LU number of
the volume containing a specified file. If no file is specified, it
returns the LU number of the volume containing the file /SYSTEM.DIR.
It is used in CI command files which need to know the LU numbers of
specified files. For example, a CI command file could issue the
correct ASAVE commands after first determining the LU numbers.
Invoke FILELU as follows:
RU FILELU [FileDescriptor]
On exit, $RETURN1 and $RETURN_S will contain the same information:
File found: LU number of the CI volume containing the file.
Not found or other FMP error: Negative FMP error code, e.g -6.
See source for more documentation.
B00801
------------------------------------------------------------------------------
FIXRPL B008
FIXES RPL CHECKSUMS OF ALL FILES IN A MASK
------------------------------------------------------------------------------
Contribution Name......(16).: FIXRPL
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. FIXRPL.SBMT
: 02. FIXRPL.FTN
: 03. FIXRPL.REL
: 04. FIXRPL.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
FIXRPL fixes the RPL checksum on all type-6 files in a mask. For
example, the command FIXRPL /PROGRAMS/@ will fix the RPL checksum in
all type-6 files in the /PROGRAMS directory, if possible.
Errors are reported for any that cannot be fixed. Those must be
relinked. Files which are included in the mask but are not type-6
are ignored without error messages.
FIXRPL is particularly useful when a new RTE-A system generation
changes the RPL checksum, or when already-linked programs are copied
from one system to another with a different RPL checksum. Then any
already-linked programs will fail on first execution with the message
"Changed RPL checksum." FIXRPL can be run once to correct ALL of the
errant checksums.
To fix all of the programs in the system: FIXRPL, @.@.E
See source for more documentation.
B00901
------------------------------------------------------------------------------
KERMIT B009
FILE TRANSFER PROTOCOL PROGRAM
------------------------------------------------------------------------------
Contribution Name......(16).: KERMIT
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. KERMIT.SBMT This file
: 02. CMDSTACK.MAC Command stack source
: 03. CMDSTACK.REL Command stack relo
: 04. CONNECT.HELP Kermit Help File
: 05. INDEX1.MAC Character search source
: 06. INDEX1.REL Character search relo
: 07. KERLIB.FTN Library primary source
: 08. KERLIB.MER Library merge file
: 09. KERLIBA.LIB Library relocatables - A
: 10. KERMEM.INCL Include file
: 11. KERMIT.COMP Compile everything
: 12. KERMIT.FTN Program source
: 13. KERMIT.INCL Include file
: 14. KERMIT.USER User Guide by Columbia
: 15. KERMIT6.CMD Link program for RTE-6/VM
: 16. KERMITA.CMD Link program for RTE-A
: 17. KERMITA.REL Program relocatable - A
: 18. KERMITMASTER.INCL Include file master
: 19. LEFTJUSTIFY.MAC Subroutine source
: 20. LEFTJUSTIFY.REL Rubroutine relo
Operating System(s)......: RTE-A and RTE-6/VM
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X mostly, MACRO slightly
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...: No
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 23 Dec., 2001
Program Abstract............:
KERMIT is a well-known file-transfer program, available free on
almost all computers since the early 1980s. Versions of Kermit
submitted by Paul Schumann of E-Systems have been in the HP 1000 CSL
since 1986. This version of Kermit was derived from an early
Schumann version, incorporated into the commercial CONNECT package,
and regularly revised and improved until about 1997.
Some possible differences between this version and others:
1. Handles Long Packets, up to 9024 bytes in length (default 2048).
2. Supports HP-1000 to HP-1000 transfer for all file types without
loss of any file attributes, including update date.
3. You can run other programs from the KERMI> prompt.
4. Does NOT have terminal-emulation mode (CONNECT does that part),
but will work fine as a remote host or server for a PC.
If you own the CONNECT package, any revision, this version of KERMIT
should be compatible with it. If you do not, you can still use this
KERMIT as the remote host for PC terminal emulators like Reflection.
Note: See Reflection configuration, below.
Though this Kermit can handle packets of 9024 bytes, a packet size of
2048 is recommended because more program space is available for file
operations. At 19,200 baud, tests at ICT show that the throughput
improvement going from a packet size of 2048 bytes up to 9024 bytes
is less than 5% with direct-connected computers. However, if you
have large turnaround delays in your connection, such as a satellite
hop, the larger packets may be more helpful.
Of course, this Kermit will scale back to standard 93-byte packets
when communicating with another Kermit which does not support long
packets. But, because of turnaround delays inherent in the HP 1000
and its MUX, the throughput will be approximately one third of what
it would be with long packets.
Sliding windows are not implemented, nor are checksums larger than
one byte.
Installation notes:
1. You shouldn't have to recompile for RTE-A; the KERMITA relocatable
and KERLIBA library are supplied. For RTE-6/VM you will have to
recompile, see KERMIT.COMP below.
2. Execute the command file KERMITA.cmd to install on RTE-A,
KERMIT6.CMD to install on RTE-6/VM.
3. KERMIT's help file is CONNECT.HELP. KERMIT looks for it first on
/SYSTEM and then on /CONNECT, so copy it to one of those.
4. To completely recompile everything for both RTE-A and RTE-6/VM,
except a few MACRO routines that never need recompiling, execute
the command KERMIT.COMP. Then you might as well go out to lunch.
5. The file KERMIT.USER is a user manual written by the original
authors of the first Kermit. It's interesting reading, but you
will make more use of the Help facility within Kermit.
Reflection is the most common PC terminal emulator for the HP 1000.
Here are some setup suggestions for Reflection on your PC:
FILE TRANSFER SETUP: In my version of Reflection: File -->
Transfer Setup... --> Protocol (select Kermit) --> Kermit Tab
(Transfer Type = ASCII, Checksum = 1 byte, Character Set
Translation Off, File Name Translation On, Automatic Server Mode
Off, Packet Size = 2048, Window Size = 1).
HOST PROMPT: If you leave the host prompt set to anything except
"none" or blank, you may get endless timeouts during file
transfers. In my version of Reflection: Setup --> Terminal...
--> Emulation --> Advanced --> Host Prompt (set it to none or
blank).
See source for more documentation.
B01001
------------------------------------------------------------------------------
LOGTIME B010
LOG THE DATE/TIME OF EVENTS SUCH AS BOOTUP
------------------------------------------------------------------------------
Contribution Name......(16).: LOGTIME
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. LOGTIME.SBMT
: 02. LOGTIME.FTN
: 03. LOGTIME.REL
: 04. LOGTIME.LOD
: 05. EMACOPY.MAC
: 06. EMACOPY.REL
: 07. LEFTJUSTIFY.MAC
: 08. LEFTJUSTIFY.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X, MACRO
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 22 Dec., 2001
Program Abstract............:
LOGTIME keeps track of repeated events, such as bootups, successful
backups, or even logons. It reads up an existing log file, puts the
current time on TOP of the file, and rewrites the file. Thus the
most-recent information is always on top of the file.
When the file reaches LOGTIME's 1000-record limit, an old record is
deleted to make room for each new record, thereby keeping the file
to a nominal size. As submitted, that size cannot exceed about 330
blocks. Thus no maintenance is required.
Usage:
RU LOGTIME File [Prepend Text]
Where:
File is the descriptor of the file to be used. If it does not
exist, it will be created.
"Prepend Text" is text to be inserted in front of the date, e.g
the text "Booted" or the text "Backup Successful". The program
will always insert one space between the last nonblank
character in the text and the date/time string.
Usage examples:
RU LOGTIME /SYSTEM/EVENTS.TXT `System booted` {in WELCOME file}
RU LOGTIME /SYSTEM/EVENTS.TXT `Logon: `$LOGON`, session# `$SESSION
{in logon HELLO file, makes an entry which looks like this:
Logon: DON.NOGROUP, session# 70 Sat Dec 22, 2001, 2:18:00 pm}
LOGTIME actually writes each new record in the file's SECOND record
location, leaving the first record unchanged and pushing the old
second record down to third, etc. Therefore, the top record in the
file never moves and may be used as a title for the file, e.g "ICT HP
1000 Events."
Have you ever wondered whether or not a user (or you yourself)
performed a backup, or rebooted the system, or logged on, or
whatever? Now you can keep track by inserting a LOGTIME command in
the CI command file that the user would necessarily execute.
LOGTIME calls EMACOPY and LEFTJUSTIFY, included in this contribution.
See source for more documentation.
B01101
------------------------------------------------------------------------------
NULLJOB B011
DISPLAY TOTAL PERCENTAGE OF CPU UTILIZATION
------------------------------------------------------------------------------
Contribution Name......(16).: NULLJOB
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. This file
: 02. NULLJOB.SBMT
: 03. NULLJOB.FTN
: 04. NULLJOB.REL
: 05. NULLJOB.CAL
Operating System(s)......: RTE-A or RTE-6/VM
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...: No longer requires calibration file
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 21 Dec., 2001
Program Abstract............:
NULLJOB reports the total percentage of CPU utilization by all
processes including the operating system and its drivers. Previous
versions required a calibration file (/SYSTEM/NULLJOB.CAL), but this
version determines the CPU type and uses an internal calibration
table if there is no calibration file.
NULLJOB runs at priority 32767 (lowest possible) and executes a task
previously calibrated to take 1.00 seconds. When the task completes,
NULLJOB determines how long it really took, and uses that information
to calculate the percentage of CPU time used by all OTHER tasks
during the run period.
NULLJOB takes into account not only all other running programs but
all operating-system and driver activity as well, and is therefore
quite accurate. It often reports substantially higher total CPU
utilization than does HP's METER program, though METER has improved
in recent RTE releases.
To load it: LINK NULLJOB.REL NULLJOB.RUN::PROGRAMS.
To run it: RU, NULLJOB.
To stop it: CM> BR, NULLJ.
When the system is running with no active programs, NULLJOB should
report an execution time of 1.00 (seconds), corresponding to CPU
utilization of 0.0%. It may jump up to 1.0% now and then, but should
come back to 0.0%. If it does not, then the file NULLJOB.CAL should
be edited and put on the /SYSTEM directory to provide correct
calibration for the particular CPU.
Only the first line of NULLJOB.CAL is used by NULLJOB; the remaining
lines are documentation showing typical calibration values for
several different CPU types. The calibration value for one CPU may
be different than that for another of the same type, though in my
experience this is rare. Adjust the value in the first line of
NULLJOB.CAL::SYSTEM until NULLJOB displays every 1.00 (never 0.99,
occasionally 1.01) seconds on an otherwise completely idle system.
If you come up with a calibration value for an A700, please let me
know what it is. The value in NULLJOB's internal table is a dummy,
because I haven't had an A700 to calibrate it on.
See source for more documentation.
B01201
------------------------------------------------------------------------------
NUMERICCENTURY B012
LIKE NUMERICTIME BUT WITH 4-DIGIT YEAR
------------------------------------------------------------------------------
Contribution Name......(16).: NUMERICCENTURY
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. NUMERICCENTURY.SBMT
: 02. NUMERICCENTURY.FTN
: 03. NUMERICCENTURY.REL
Operating System(s)......: RTE-A or RTE-6/VM
Uses hierarchical files?.: N/A
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
NUMERICCENTURY is a subroutine which mimics NUMERICTIME, except that
it returns a 15-character string including a 4-character year, in the
format CCYYMMDD.HHMMSS. NUMERICTIME returns a 13-character string
including a 2-character year, in the format YYMMDD.HHMMSS.
Thus NUMERICCENTURY returns values which can be sorted correctly,
between the dates January 1, 1970, through January 18, 2038. It is
called as follows:
CALL NUMERICCENTURY (SS70, TIMEDATE15)
Where:
SS70 is the INTEGER*4 number of seconds since 1/1/1970.
TIMEDATE15 is the output character string.
It is meant to be used in new applications.
See source for more documentation.
B01301
------------------------------------------------------------------------------
PSCREEN B013
COPY YOUR SCREEN TO YOUR PRINTER
------------------------------------------------------------------------------
Contribution Name......(16).: PSCREEN
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. PSCREEN.SBMT
: 02. PSCREEN.FTN
: 03. PSCREEN.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 22 Dec., 2001
Program Abstract............:
PSCREEN is a simple command which prints your screen to your printer
with a one-line time/date header at the top. It actually schedules
the COPYSCREEN program to do the heavy lifting.
Usage: PSCREEN
There are no run-time parameters.
Your terminal must support normal HP control sequences, i.e it must
allow EDIT to run in screen mode.
Before using PSCREEN at your site, you must modify it to print to the
correct printer LU, and you may want to comment out line 33 (reset
printer) if you are not printing to a laser jet.
I recommend that you put both PSCREEN and COPYSCREEN in your list of
Prototype IDs to be RP'd at bootup.
See source for more documentation.
See COPYSCREEN contribution, in this same CSL release.
B01401
------------------------------------------------------------------------------
RENAMEFORWINDOWS B014
RENAME FILES FOR TRANSFER TO A WINDOWS PC
------------------------------------------------------------------------------
Contribution Name......(16).: RENAMEFORWINDOWS
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. RENAMEFORWINDOWS.SBMT
: 02. RENAMEFORWINDOWS.FTN
: 03. RENAMEFORWINDOWS.REL
: 04. RENAMEFORWINDOWS.LOD
Operating System(s)......: RTE-A or RTE-6/VM
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 21 Dec., 2001
Program Abstract............:
RENAMEFORWINDOWS examines the files in a mask for file-name
characters which are illegal in Windows. It creates a list of those
filenames in a list file, along with the name that it would prefer to
use instead. If "OK" is supplied, it will actually rename the files
in accordance with that list file.
Files are renamed by sustituting a specific legal character for each
Windows-illegal character (\ * ? " < > and |). After renaming, the
files can be transferred to a Windows PC without difficulty.
Usage:
RU RENAMEFORWINDOWS mask [outfile] [OK]
Where:
Outfile is the list file, default RENAMEDFILES.TXT.
OK gives permission to actually do the renaming.
The lists of illegal characters and substitute characters can easily
be changed if you wish.
See source for more documentation.
B01501
------------------------------------------------------------------------------
RUNCI B015
RUN CI AT BOOTUP IN FMGR-ONLY SYSTEM
------------------------------------------------------------------------------
Contribution Name......(16).: RUNCI
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. RUNCI.SBMT
: 02. RUNCI.FTN
: 03. RUNCI.REL
: 04. RUNCI.LOD
Operating System(s)......: RTE-A
Uses hierarchical files?.: That's the issue, none are available
Language(s)..............: FTN7X
Keywords.................: 1. BOOT
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
This very simple program offers a way to have CI execute a WELCOM
file in a FMGR-only system. CI otherwise looks for its WELCOMExx.CMD
file on the /SYSTEM directory, and will not find it on a FMGR LU.
RUNCI is scheduled as the START program in the SYSTEM (BOOTEX
command) file, and in turn runs CI to execute a command file called
WELCOM::0.
Why would anyone want to do this?
You may want to set up a FMGR-only system (no CI volumes) for these
reasons, among others:
1. To have a very minimal (emergency) disk-based system allowing
operations such as backup or MPACK without any CI volumes mounted.
2. To put a simple operating system (e.g for backup) on a floppy or
an optical disk.
In either case, CI can be scheduled at startup for such tasks as
initializing terminals or whatever.
See source for more documentation.
B01601
------------------------------------------------------------------------------
TERMINALID B016
RETURN A TERMINAL'S ID IN $RETURN_S
------------------------------------------------------------------------------
Contribution Name......(16).: TERMINALID
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. TERMINALID.SBMT
: 02. TERMINALID.FTN
: 03. TERMINALID.REL
: 04. TERMINALID.LOD
: 05. GETSTAT.FTN
: 06. GETSTAT.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: n/a
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
TERMINALID queries a specified terminal for its ID (terminal type)
and reports that back in the $RETURN_S string. For example, if the
specified terminal is a 2392A, the returned string will contain the
string "2392A".
This can be useful in for correct initialization of some application
programs that depend upon a specific terminal type. For example, the
graphics programs for a 2623A are different from those for a 2397A.
Therefore, knowledge of the actual terminal type will allow the
correct application program to be invoked at startup.
See source for more documentation.
B01701
------------------------------------------------------------------------------
TERMSTAT B017
OBTAIN AND DISPLAY A TERMINAL'S STATUS
------------------------------------------------------------------------------
Contribution Name......(16).: TERMSTAT
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. TERMSTAT.SBMT
: 02. TERMSTAT.FTN
: 03. TERMSTAT.REL
: 04. TERMSTAT.LOD
: 05. TERMSTAT.SEND
: 06. GETSTAT.FTN
: 07. GETSTAT.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1. TERMINAL
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
TERMSTAT reads and displays the configuration of another terminal.
The other terminal must be turned on, connected, and with no other
I/O pending.
It is useful in some cases for diagnosing problems with a terminal or
its configuration, especially when the terminal is not nearby.
It has not been tested on terminals connected via TELNET.
This is a typical display for a 2392:
CI> termstat 70
5 2392A -1 2392A -2 2392A -3 2392A -4 2392A -5 2392A
Primary Status: 4008000
Secondary Status: 0500000
1K Bytes F
2K Bytes F
4K Bytes T
8K Bytes F
A Transmit Func Ky F
B Space Overwrite F
C Inh EOL Wrap F
D Space Overwrite F
E F
F F
G DC2 handshake F
H Inhibit DC2 F
Caps Lock Key F
Block Mode Key F
Auto LF Key F
Secondary stat yes T
Cursor sense pend F
Func Key pending F
ENTER Key pending F
Secondary stat pen F
Data Comm Error F
Self Test error F
Device Error F
Device Stat pend F
Device Op Stat pen F
1K Bytes buffer F
2K Bytes buffer F
4K Bytes buffer F
8K Bytes buffer F
I/O Firmware in T
APL Firmware in F
Term IDs itself T
Programmable term F
J Auto Terminate F
K Clear Terminator F
L Self Test Inhib F
M F
N Prt Esc Code Xfr F
P Compat Mode Scal F
Q Compat Mode Unsc F
R F
S F
T F
U F
V F
W Data Comm Test F
X F
Y F
Z F
Mem Ovflow Prot F
Memory Lock F
Memory Full F
CI>
See source for more documentation.
B01801
------------------------------------------------------------------------------
TOPSORT B018
FAST EMA SORT OF LARGE STRING ARRAYS
------------------------------------------------------------------------------
Contribution Name...........: TOPSORT
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. TOPSORT.SBMT This file
: 02. TOPSORT.FTN Source
: 03. TOPSORT.REL Relocatable
: 04. EMACOPY.MAC Source
: 05. EMACOPY.REL Relocatable
Operating System(s)......: RTE-A
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X, MACRO
Keywords.................: 1. EMA/VMA
: 2. SORT
: 3. STRINGS
External Support Req'd...: This is a Fortran-callable subroutine
If Re-submission, Reason.: Enhanced string length, improved documentation
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
Date..........: 22 Dec., 2001
Program Abstract............:
This submission of TOPSORT is enhanced to allow sorting of strings
up to 128 characters in length, and is further enhanced with improved
documentation in the source. It is well tested now, and very fast.
TOPSORT is an in-memory insert-sort routine which adds a new
character item to an ordered list of character items each time it is
called. The character items may be either in local space or EMA.
It uses three tricks in an attempt to achieve speed: 1) Binary
searches are used to find the insertion point for the incoming item;
2) The hardware MVW instruction is used to move data aside to create
space for each insertion; 3) The character items themselves are not
physically moved - instead, a list of integer pointers to the items
are physically sorted.
TOPSORT is used at ICT to sort IMAGE records according to a specified
sort key. In most application programs the records are read twice:
Once to build the ordered (sorted) array of keys with associated
record numbers, and then again to read the complete records in sorted
order and perhaps produce an appropriate report or mailing.
The time required to sort a list of items is proportional to N*LogN,
where N is the number of items. Speed measurements were done on an
A400, using up to 1 Mbyte of memory for the item array and two
different sizes of item. Items were artificially generated, in a
non-sequential order, and all unique with the differences in the
rightmost characters. Time required to generate the items was
compensated out. The following actual sort times were measured:
Item |<-------TEST 1------->| |<-------TEST 2------->|
Array, Item Item
Kbytes Length # Items Seconds Length # Items Seconds
------ ------ ------- ------- ------ ------- -------
128 78 1680 13 32 4096 30
256 78 3361 28 32 8192 76
512 78 6721 66 32 16384 214
1024 78 13443 179 32 32766 468
Notes: 1) The amount of time required seems closely related to the
number of items and relatively independent of the item length. 2) An
A900 or A990 would be 3 to 8 times faster.
I am not an expert on sorting methodology and do not know how this
method compares with more sophisticated techniques. However, for
more than a few hundred items it is MUCH faster than QUERY, which
apparently uses a crude disk sort with time proportional to N**2 (N
squared) or worse. To do much better, see the concurrently-submitted
program FILESORT.
TOPSORT may be compiled with CDS off or on. It could be used in a
VMA (rather than EMA) program but there is reason to believe that
other sorting methods might be more appropriate if the entire item
array cannot be contained within the working set.
See the source itself for a description of procedures for calling
TOPSORT from a Fortran program. TOPSORT calls EMACOPY, a macro
routine, previously contributed in 1988 and supplied again here.
Both relocatables must be available when linking an application
program which uses TOPSORT.
See source for more documentation.
See also the concurrent submissions TOPFIND and FILESORT. TOPFIND is
a TOPSORT-style subroutine which finds items in the sorted array, but
without modifying the array. FILESORT is a complete application
which sorts files containing up to 25,000 records, each 80 up to
characters long.
Also see the EMACOPY macro subroutine, which can copy data into, out
of, and within EMA arrays at the speed of the MOVEWORDS routine.
It's a poor man's Vector Instruction Set, never changed since 1988
because it works really really well.
B01901
------------------------------------------------------------------------------
TOPFIND B019
FIND AN ITEM IN A TOPSORT ARRAY
------------------------------------------------------------------------------
Contribution Name......(16).: TOPFIND
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. TOPFIND.SBMT
: 02. TOPFIND.FTN
: 03. TOPFIND.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1. EMA/VMA
: 2. SORT
: 3. STRINGS
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 21 Dec, 2001
Program Abstract............:
TOPFIND is a Fortran-callable function which searches for a character
item in a sorted EMA array created by TOPSORT, also submitted in this
CSL release. If an item matching the supplied key value is found,
TOPFIND returns a TRUE value and the location of the item. If a
match is not found, TOPFIND returns FALSE and points to the next-
smaller item in the array.
Because it uses a very fast binary search, it works only on an
already-sorted TOPSORT-style array.
TOPFIND calls the MACRO subroutine EMACOPY, which is contributed in
this CSL release as part of the TOPSORT contribution.
See source for more usage documentation.
B02001
------------------------------------------------------------------------------
FILESORT B020
SORT A FILE QUICKLY IN EMA
------------------------------------------------------------------------------
Contribution Name......(16).: FILESORT
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. FILESORT.SBMT
: 02. FILESORT.FTN
: 03. FILESORT.REL
: 04. FILESORT.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1. EMA/VMA
: 2. SORT
: 3. STRINGS
: 4.
: 5.
External Support Req'd...: TOPSORT routines, submitted concurrently
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 22 Dec., 2001
Program Abstract............:
FILESORT sorts the records in a file according to the standard ASCII
collating sequence. Its output is a new file - the original is
unmodified.
It uses the TOPSORT routines to perform the sort in EMA, and as
submitted can sort a file of up to 25,000 records, each up to 80
characters in length.
Usage:
RU, FILESORT, infile, outfile
Where:
Infile is the input file to be sorted.
Outfile is the output file to receive the sorted records. It
may be the same as Infile, but FILESORT will ask if it's OK
to overwrite it.
FILESORT will prompt for Infile or Outfile if not supplied.
As submitted FILESORT is large, requiring a 1012-page partition, but
can easily be made smaller for smaller arrays. To do so, set the
ASIZE and MXCHR parameters to your actual maximum record count and
record size.
FILESORT can be similarly modified for different record counts and
record lengths. For example, it can handle up to 32,766 records of
62 characters, or 16,351 records of 128 characters. The limit is the
maximum EMA size of 1022 pages (just under 2 MBytes). VMA is another
possible solution, but will slow the sort down a lot - other sort
techniques might be preferable.
FILESORT calls TOPSORT and EMACOPY, both submitted concurrently with
FILESORT.
See source for more documentation.
B02101
------------------------------------------------------------------------------
WHATCPU B021
REPORT CPU ID IN $RETURN1
------------------------------------------------------------------------------
Contribution Name......(16).: WHATCPU
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. WHATCPU.SBMT
: 02. WHATCPU.FTN
: 03. WHATCPU.REL
: 04. WHATCPU.LOD
: 05. CPUID.MAC
: 06. CPUID.REL
Operating System(s)......: RTE-A only
Uses hierarchical files?.: N/A
Language(s)..............: FTN7X, MACRO
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
WHATCPU returns the CPU ID in $RETURN1 (PRTN(1)).
Schedule it as follows: RU, WHATCPU
The possible values in $RETURN1 are:
2 = A600
3 = A700
4 = A900
5 = A600+
7 = A400
10 = A990
This program is used in WELCOME file or other command files to
customize actions to the CPU. For example, if the CPU is an A400,
execute the commands to initialize the OBIO ports. Or for example,
if the CPU is an A990, use the A990 boot clock to set the system
date/time, otherwise get the time and date another way.
Note: WHATCPU calls the RTE-A function CPUID, which is not provided
(or not documented?) in early revisions of RTE-A. If the link fails
because CPUID is missing, link in the version of CPUID supplied with
this submission.
See source for more documentation.
B02201
------------------------------------------------------------------------------
WAITFORCS80 B022
WAIT FOR CS/80 TAPE DRIVE TO COME READY
------------------------------------------------------------------------------
Contribution Name......(16).: WAITFORCS80
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. WAITFORCS80.SBMT
: 02. WAITFORCS80.FTN
: 03. WAITFORCS80.REL
: 04. WAITFORCS80.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Sure
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 20 Dec., 2001
Program Abstract............:
WAITFORCS80 waits for a CS/80 tape drive to come up ready, then exits
with status indicating whether or not the tape is certified.
It is used in CI command files which certify tapes (regardless
whether they have been certified before) or wherever an automatic
wait-for-ready is needed.
Schedule it as follows:
RU WAITFORCS80 LU
Where LU is the logical unit of the CS/80 tape.
On exit, $RETURN1 (PRTN(1)) contains the following:
0 = Tape is not certified.
1 = Tape is certified.
See source for more documentation.
See also FCS80, which waits for the tape ready and then certifies it
if it is not certified.
B02301
------------------------------------------------------------------------------
SPACE B023
DISPLAY DB DATA SET CAPACITIES & UTILIZATION
------------------------------------------------------------------------------
Contribution Name......(16).: SPACE
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. SPACE.SBMT
: 02. SPACE.FTN
: 03. SPACE.REL
: 04. SPACE.LOD
Operating System(s)......: RTE-A, not tested on RTE-6/VM
Uses hierarchical files?.: Yep
Language(s)..............: FTN7X
Keywords.................: 1. IMAGE
: 2.
: 3.
: 4.
: 5.
External Support Req'd...: IMAGE/1000-II
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 01 Jan., 2002
Program Abstract............:
SPACE reports the utilization of the space in an IMAGE/1000-II data
base. You give it the DB root file descriptor and the lowest level
word, and it examines the DB, reporting the capacity and the percent
utilization of each data set. The report is immediate, in a format
similar to that of the DBSPA utility.
SPACE opens the DB in shared read/write mode, but it doesn't actually
read or write anything. Rather, it uses DBINF calls to determine the
list of data sets, and the capacity and utilization of each.
Run SPACE as follows:
RU SPACE [DBName [Level [LU]]]
Where:
DBName is the file descriptor of a data base. If omitted, you
will be prompted for it. You can easily change the program to
specify a default name and avoid the prompt.
Level is a level word giving at least read-access to at least
one data set in the data base. If omitted, you will be
prompted. You can easily change the program to specify a
default level.
LU is the LU# of an output device, or the name of a file to
which the report will be sent.
To examine several data bases at once, simply set up a command file
which runs SPACE successively on each data base.
SPACE is supplied with CDS ON, but will compile, link, and run just
fine with CDS OFF. Link it with at least 2 pages of space above the
data partition, preferably 6 for large data bases.
See source for more documentation.
B02401
------------------------------------------------------------------------------
DBREPORTERROR B024
REPORT & DESCRIBE IMAGE/1000 ERROR
------------------------------------------------------------------------------
Contribution Name......(16).: DBREPORTERROR
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. DBREPORTERROR.SBMT
: 02. DBREPORTERROR.FTN
: 03. DBREPORTERROR.REL
Operating System(s)......: RTE-A, not tested on RTE-6/VM
Uses hierarchical files?.: Yes
Language(s)..............: FTN7X
Keywords.................: 1. IMAGE
: 2.
: 3.
: 4.
: 5.
External Support Req'd...: IMAGE/1000
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 01 Jan., 2002
Program Abstract............:
DBREPORTERROR reports an Image/1000 error to LU 1 in a manner similar
to FMPREPORTERROR, displaying the error number, the description of
that error, and the data base name. Not every error is described,
but the most likely ones are.
The purpose is to avoid running to the Image/1000 manuals on every
error, especially in the field where a manual may not be available.
Call this routine whenever an Image call is finished.
Call as follows:
CALL DBREPORTERROR (ISTAT, DBNAME)
Where:
ISTAT is the error code. Positive for Image errors, negative
for FMP errors.
DBNAME is the name of the data base or file, to be reported
along with the error description. DBNAME is reported verbatim,
so you could also include other information such as the Image
call that caused the error.
Example:
CALL DBREPORTERROR (119, '/PRODUCTION/INVENTORY')
The display on LU 1 would be:
IMAGE Error 119 Root file not found /PRODUCTION/INVENTORY
Example 2:
CALL DBREPORTERROR (ISTAT, 'Stmt 300 DBFND') Where ISTAT =107
The display on LU 1 would be:
IMAGE Error 107 No master entry with key value Stmt 300 DBFND
It's a fairly large subroutine, over 700 words, but it will normally
be used with CDS ON.
See source for more documentation.
B02501
------------------------------------------------------------------------------
DDESCRIBE B025
RETURN CS/80 DISK SIZE IN $RETURN & $RETURN_S
------------------------------------------------------------------------------
Contribution Name......(16).: DDESCRIBE
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. DDESCRIBE.SBMT
: 02. DDESCRIBE.FTN
: 03. DDESCRIBE.REL
: 04. DDESCRIBE.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Yes
Language(s)..............: FTN7X
Keywords.................: 1.
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 01 Jan., 2002
Program Abstract............:
DDESCRIBE issues a DESCRIBE command to a CS/80 disk and returns the
disk's highest block address as a double integer in $RETURN2 and
$RETURN3 (PRTN(2&3)), and in the return string $RETURN_S (EXEC(14)).
The returned value represents the size of the physical disk, not just
the LU in the schedule call.
The purpose is to allow CI or any other application program to know
the actual size of the connected disk.
Run it as follows:
RU, DDESCRIBE, LU
Where LU is one of the logicals unit on the physical disk.
Values returned in RMPAR are:
Word
1 0 if no error
2 \
3 / Double integer block count
4,5 0
DDESCRIBE uses a subroutine in the $DTCLB library, and must be linked
with a reference to it.
See source for more documentation.
B02601
------------------------------------------------------------------------------
YYMMDD B026
RETURN DATE TO CI, OPTIONALLY WITH OFFSET
------------------------------------------------------------------------------
Contribution Name......(16).: YYMMDD
Title...............(64).: Return Date to CI, Optionally with Offset
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. YYMMDD.SBMT
: 02. YYMMDD.FTN
: 03. YYMMDD.REL
: 04. YYMMDD.LOD
: 05. YYMMDD.HLP
Operating System(s)......: RTE-A, RTE-6/VM
Uses hierarchical files?.: N/A
Language(s)..............: FTN7X
Keywords.................: 1. DATE
: 2.
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 15 January, 2002
Program Abstract............:
YYMMDD determines the current date and returns it to the scheduling
program in the EXEC 14 return string, in YYMMDD format. Optionally,
it can calculate a specified offset (+/- days) from the current date
and return that date instead. Run it as follows:
RU YYMMDD [+/-offset]
Where:
+/-offset is the arithmetic operator plus (+) or minus (-),
followed by an integer expressing an offset in days. There may be
no blanks between the operator and the integer offset. Default is
no offset. An integer by itself with no operator is ignored and
results in no offset.
Example: Today is January 14, 2002, and the runstring is RU, YYMMDD,
-14. The returned 6-digit string will be 011231.
In CI, the YYMMDD return value is in $RETURN_S.
YYMMDD was created to provide CI with a modest ability to manipulate
dates. For example, a CI script could schedule YYMMDD to calculate
today's date minus 31 days, and then delete all files which match a
mask and are that old or older. This script uses the RM program to
silently delete all files in /TEMP which were last updated 31 days
ago or earlier:
YYMMDD, -31
RM, -Q, `/TEMP/@.@.U-`$RETURN_S
Install the help file as follows: CO, YYMMDD.HLP, /HELP/YYMMDD.
YYMMDD does no error checking or reporting; garbage in, garbage out.
The source is also documented.
B02701
------------------------------------------------------------------------------
PORTMON B027
MONITOR I/O PORTS FOR UNAUTHORIZED LOGONS
------------------------------------------------------------------------------
Contribution Name......(16).: PORTMON
Title...............(64).: Monitor I/O Ports for Unauthorized Logons
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. PORTMON.SBMT
: 02. PORTMON.FTN
: 03. PORTMON.REL
: 04. PORTMON.LOD
: 05. PORTMON.DAT
: 06. GETTIME.MAC
: 07. GETTIME.REL
: 08. STOPTIME.MAC
: 09. STOPTIME.REL
: 10. SYLIBA.LIB
Operating System(s)......: RTE-A only
Uses hierarchical files?.: Yes
Language(s)..............: FTN7X
Keywords.................: 1. LOGON/LOGOFF
: 2. MONITOR
: 3. SECURITY
: 4. TERMINAL
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 19 March, 2002
Program Abstract............:
PORTMON monitors a specified list of terminal logical units, to be
sure that no unauthorized user logs on there. Each LU in the list
can have its own list of authorized user names, normally a small
subset of the actual usernames on the system.
PORTMON lurks in the system session, watching all of the ports in its
list. Its name is converted to lower case, to make it hard for even
a superuser to shut it off. When an unauthorized user does log on,
PORTMON immediately and summarily deletes the user's session,
reporting that to the system console and to the system error log
file. It also disables the port LU for one minute (a changeable
parameter) so that the port will appear to be dead for that time.
PORTMON was initially developed to protect the dialup ports on a
machine which had many users. When a user left the organization the
system manager did not necessarily know it, and the user's account
was not always deleted. Neither did the system manager want to
implement a practice of regular password changes, because of the
large number of users. Further, most users did not need dialup
access anyway. With PORTMON, the dialup ports are protected from all
but the very few users who really need to have dialup access.
PORTMON could also be used in applications with different groups of
users, where some users should not be allowed to log on at other
users' terminals. For example, the system console might be protected
from all users except the system manager.
PORTMON gives no preference to superusers; an unauthorized superuser
will be denied access just as a normal user would be.
Configuration is done in the text file /USERS/PORTMON.DAT.
PORTMON was written for a system with unsophisticated users. Its
weakest point is that PORTMON.DAT configuration file, which is
accessible to any superuser. Indeed, a clever superuser could figure
out how that file is used and modify it, thereby nullifying the
security provided by PORTMON. However, a clever system manager can
hide or protect the file if more security is required. For example,
the contents of the file could be incorporated right into the
PORTMON.FTN source, the program compiled and linked, and then the
source moved off the computer to a secure location.
PORTMON does not add any extra levels of usernames or passwords. It
merely limits the number of usernames with access to the computer at
the most sensitive ports.
As supplied, PORTMON runs every 10 seconds, which is frequent enough
to achieve the desired result. At that setting, on an A400 CPU,
PORTMON consumes about 0.1% (one tenth of one percent) of the total
available CPU time.
PORTMON is an adaptation of the ICT program AUTOLOGOFF, a part of the
SYLOG package. Consequently, it uses a few calls from the library
SYLIBA.LIB. That relocatable library is included here. The sources
are omitted, however, not because they have any real value but
because they are quite numerous and get into really systemy stuff.
If you need something in particular, give me a call.
See source for more documentation, particularly regarding the
PORTMON.DAT file.
B02801
------------------------------------------------------------------------------
USERIDTABLE B028
DISPLAY THE RTE-A USERID TABLE IN DETAIL
------------------------------------------------------------------------------
Contribution Name......(16).: USERIDTABLE
Title...............(64).: Display the RTE-A User ID Table in Detail
File Names...............: 00. Rename Transfer File (INTEREX supplied)
: 01. USERIDTABLE.SBMT
: 02. USERIDTABLE.FTN
: 03. USERIDTABLE.REL
: 04. USERIDTABLE.LOD
Operating System(s)......: RTE-A only
Uses hierarchical files?.: N/A
Language(s)..............: FTN7X
Keywords.................: 1. ACCOUNTS
: 2. LOGON/LOGOFF
: 3.
: 4.
: 5.
External Support Req'd...:
Reason if resubmission...:
Contributor's Name..........: Donald A. Wright
Company.......: Interactive Computer Technology
Street........: 2069 Lake Elmo Avenue North
City..........: Lake Elmo
State.........: MN
Zip Code......: 55042
Country.......: USA
Phone Number..: 651/770-3728
eMail.........: Don@DonWright.com
Date..........: 28 Jan., 2002
Program Abstract............:
USERIDTABLE examines the requested session table entries and displays
most of the nuts and bolts information in those entries. It is more
of a diagnostic tool than a display of user activity. See the RTE-A
System Design Manual, Page 11-32 (7th Edition, Apr. 1995, Rev. 6.2)
for a full description of the display.
Schedule USERIDTABLE as follows:
RU, USERIDTABLE [ALL]
[L1 [,L2 ]]
Where:
'ALL' means display all session table entries, empty or not.
L1 is the starting LU (session number) to be displayed. In this
mode only entries in use will be displayed.
L2 is the ending LU to be displayed. If not supplied, only the
L1 session will be displayed.
L1 and L2 have no meaning if 'ALL' is specified.
Example display on system with user DON at three terminals:
CI> useridtable all
Words per table entry: 22, Number of currently logged on users: 3
ENT SESSN USERNAME S SEQ STAT L PROGS UID CPU SESPR GID CAP
0 0 SYSTEM 1 0 3 0 17 2 141976 2 31
1 70 DON 0 13 2 0 2 5 3717 CI 0 20
2 90 DON 0 9 2 0 2 5 55283 CI 0 20
3 103 DON 0 39 2 0 1 5 3 CI 0 20
4 0 0 0 0 0 0 0 0 0 0
5 0 0 0 0 0 0 0 0 0 0
6 0 0 0 0 0 0 0 0 0 0
CI>
Source is documented.
B02901
------------------------------------------------------------------------------
DISKCOPY B029
COPY'S DISK LU TO DISK LU
------------------------------------------------------------------------------
Contribution Name...........: DISKCOPY
Title....................: Copy's disk LU to disk LU
File Names...............:00. Rename Transfer File
:01. diskcopy.sbmt
:02. diskcopy.ftn
:03. diskcopy.rel
Operating System.........: RTE-A
Uses hierarchical files?.:
Language(s)..............: Ftn7x
Keywords.................: 1.DISC
: 2.COPY
: 3.BACKUP
External Support Req'd...: No
If Re-submission, Reason.:
Contributor's Name..........: Don Pottenger
Company.......: hp
Street........: 11000 Wolfe Rd.
:
City..........: Cupertino
State.........: CA
Country.......: USA
Zip Code......: 95014
Phone Number..:
Program Abstract............:
This program does a disk track to track copy using VMAIO reading and
writing 4 tracks at a time. It does not use FMP and the contents of
the disks are not examined.
Note: If the destination disk LU is larger then the source, the copy
will proceed, however, D.RTR will not be able to mount the copied
volume because some FMP file structures must be on the last track
of the LU.
See comments for other "features".
Additional Documentation....: source file
B03001
------------------------------------------------------------------------------
DXREF B030
DXREF
------------------------------------------------------------------------------
Contribution Name...........: DXREF
Title....................: Relocatable Cross-Referencer and Searcher
File Names...............:00. Rename Transfer File
:01. DXREF.SBMT Submission file
:02 DXREF.FTN
:03 DXREF.LOD
:04 DXREF.REL
:05 MAKEFILE
:06 QSORT.PAS
:07 QSORT.REL
:08 NAMCK.REL
:09 NAMCK.MAC
:10 %INITS
:11 %ISOL8
:12 %NAMCK
:13 &INITS
:14 &ISOL8
:15 DXREF.HLP
Operating System.........: 6/VM, A
Language(s)..............: FTN7X, ASMB, Pascal
Keywords.................: 1. Cross Reference
: 2. Library
: 3. Relocatable
: 4. Subroutine
: 5. Entry Points
External Support Req'd...: (only if recompiling) $PLIB
If Re-submission, Reason.: Many changes since first submission.
New file system support. New relocatable
record support among other improvements.
Contributor's Name..........: Don Pottenger
Company.......: Hewlett-Packard
Street........: Data Systems Division
: 11000 Wolfe Road
City..........: Cupertino
State.........: CA
Country.......: USA
Zip Code......: 95014
Phone Number..:
Program Abstract............: This submission is a part of HP GJOB/1000.
DXREF, the SSK utility, allows you to find out many things about a
relocatable file. It can display the NAM record (including the type,
priority, and comment field), whether the module is an extended record
(it's marked with a * if it is), and its entry points and externals.
You can also search for an entry point or external using a filter
similar to DLX's - and + file name filter. Its input can be one file or
(using the BA batch option) many files; thus a mass search of several
relocatables and libraries, scanning for an entry point, is possible.
Additional Documentation....: In the file DXREF.HLP
Disclaimer: The documentation has not been updated to reflect new file
system terminology but still refers to FMGR NAMR file name and
"cartridge reference numbers" (CRNs) etc.
Also, the batch file capibilities of DXREF have problems.
B03101
------------------------------------------------------------------------------
GLOBALSPACE B031
GLOBALSPACE
------------------------------------------------------------------------------
Contribution Name...........: GLOBALSPACE
Title....................: Global directory disk space reporting.
File Names...............:00. Rename Transfer File (Interex-supplied)
:01. GLOBALSPACE.SBMT
:02. DISCSPACE.FTN
:03. DISCSPACE.REL
:04. GLOBALSPACE.FTN
:05. GLOBALSPACE.LOD
:06. GLOBALSPACE.REL
:07. MAKEFILE
Operating System(s)......: RTE-A, RTE-6/VM
Language(s)..............: FTN7X
Keywords.................: 1. Disc
: 2. Management
: 3. Directory
External Support Req'd...:
If Re-submission, Reason.: New version
Contributor's Name..........: Don Pottenger
Company.......: Hewlett Packard
Street........: 11000 Wolfe Rd.
City..........: Cupertino
State.........: CA
Country.......: USA
Zip Code......: 95014
Phone Number..:
Fax Number....:
E-mail address: don_pottenger@hp.com
Contribution Abstract.......:
Reports disk space utilization under global directories on an LU by LU
basis. Requires 6.1 rev of FOWN (which it calls). RU,GLOBALSPACE,??
shows help.
Note: This is an updated version of the same program that was submitted
in 1997 (Release 3735). This version added the disk size reporting
options for Kbytes and Megabytes.
B03201
-----------------------------------------------------------------------------
QXREF B032
EMA QXREF
-----------------------------------------------------------------------------
Contribution Name...........: QXREF
Title....................: EMA QXREF
File Names...............: 0. Rename transfer file
: 1. QXREF.SBMT - this file
: 2. QXREF.FTN
: 3. QXREF.REL
: 4. QXREF.LOD
Operating System(s)......: RTE-6, RTE-A
Language(s)..............: FTN7X
Keywords.................: 1. CROSS-REFERENCE
: 2. RELOCATABLE
External Support Req'd...:
If Re-submission, Reason.: Resubmission of 2625 QXREF, K136
by Don Pottenger
Contributor's Name..........: Don Pottenger
Company.......: Hewlett-Packard
Street........: 11000 Wolfe Rd.
City..........: Cupertino
State.........: CA
Country.......: USA
Zip Code......: 95014
Phone Number..:
Program Abstract............: This program reads relocatable files
and prints out information about the modules found in them. It tells
which module calls which module, which file each module is found in,
and more. This program greatly eases the pain of maintaining a large
program (we found it essential when we modified the program SKETCH),
libraries, or any large programming project.
Additional Documentation....: This update fixes some looping problems
with multilevel references and large numbers of variables (moved to EMA).
Works with CDS variables now. Other minor changes.
B03301
------------------------------------------------------------------------------
WEEKDATE B033
WEEKDATE
------------------------------------------------------------------------------
Contribution Name...........: WEEKDATE
Title....................: Calculate ISO 8601 week number
File Names...............:00. Rename Transfer File
:01. weekdate.sbmt
:02. weekdate.ftn
:03. weekdate.rel
Operating System.........: RTE-A
Uses hierarchical files?.:
Language(s)..............: Ftn7x
Keywords.................: 1.DATE
: 2.CALENDAR
: 3.TIME
External Support Req'd...: No
If Re-submission, Reason.:
Contributor's Name..........: Don Pottenger
Company.......: hp
Street........: 11000 Wolfe Rd.
:
City..........: Cupertino
State.........: CA
Country.......: USA
Zip Code......: 95014
Phone Number..:
Program Abstract............:
WeekDate returns year, week number, and day of the week for the
current system time/date.
Usage: ru,weekdate
Return parameters: r1 = 0
r2 = year (1970:2038)
r3 = week # (1:53)
r4 = day of week (1:7) 1 = Monday
Return String: 'yyyy-Www-d' Where: yyyy - year
ww - week number
d - day of week
(ISO 8601 specifies that Week 01 of the year is the week containing
the first Thursday.)
A special thanks to Rick McCarty
who provided the algorithm used in this program.
( see http://www.personal.ecu.edu/mccartyr/ISOwdALG.txt )
His ISO Week Date Calendar can be found at:
http://www.personal.ecu.edu/mccartyr/isowdcal.html
B03401
------------------------------------------------------------------------------
AB2MI B034
AB2MI
------------------------------------------------------------------------------
Contribution Name...........: AB2MI
Title....................: Absolute to memory image
File Names...............:00. Rename Transfer File
:01. ab2mi.sbmt
:02. ab2mi.ftn
:03. ab2mi.ftni
Operating System.........: RTE-A
Uses hierarchical files?.:
Language(s)..............: Ftn7x
Keywords.................: 1.BINARY
: 2.BOOT-UP
External Support Req'd...: No
If Re-submission, Reason.:
Contributor's Name..........: Alan Tibbetts
Company.......: Strobe Data, Inc.
Street........: 8405 165th Ave. NE
:
City..........: Redmond
State.........: WA
Country.......: USA
Zip Code......: 98052-3913
Phone Number..: 425-861-4940
Program Abstract............:
* The basic idea of this program is that it emulates the procedure of
* loading paper tapes into core memory. A memory image array of 32KW
* is first initialized to zeroes. If the specified output file exists,
* the current contents are then read into the memory image. Next, the
* specified input file is read and stored into the memory image. The
* final step is to write the revised memory image to the output file.
* The default output file size is 256 blocks (32k words).
* For use in creating the memory image of the VCP code, two optional
* parameters allow the user to emit only a portion of the memory image
* to the output file.
Additional Documentation....: see the source code