[273,20]	RRMS, RMS


RRMS - a remotable RMS for DECUS C - 18th October 1984 Dean Elsner
					16th June 1985 Dean Elsner

The RMS package supplied with DECUS C has some drawbacks:
1	you must know at RMSsubs ASSEMBLY time how many files
	you want to use, and some of how you want to use them.
2	RMS can take up a lot of room in your task.
3	Memory that RMS MIGHT use some of the time is lost to your
	program ALL the time. (This is like FCS does if you just copy
	code from the I/O Operations Reverence Manual as is done for
	DECUS C run-time system.)

This RMS package dynamically allocates memory only as needed
and lets RMS use the C runtime system memory allocator (Malloc() and
friends) so there need be no conflict between RMS and your C program.

In lb:'<libuic>'rms.olb will be ForTran callable RMS subroutines
that let you do most anything with RMS. My C stuff uses them.

One flavour of this package keeps RMS code and buffers in your task
virtual address space. It lives inter alia on 11/23 RSX-11/M.

The other flavour uses a remote RMS: another task has RMS & buffers
while your task has applications code. The tasks use variable length
send/receive. It lives inter alia on 11/23 RSX-11M+.
A sub-package allows DECUS C to use variable send/receive exec directives.
This is V*.MAC.
The remote flavour will let you trace (to any file) transactions
between your application task(s) and the remote RMS server task.
The RRMSST just writes to stdout. You send it a message to toggle the
trace bit.

Both flavours use an IDENTICAL interface to your applications code, shown
in RMSDOC.H and demonstrated in RMSTST.C .

Bugs:
1	The code is sloppy. (I don't touch it until someone pays me!)
	I submit this because it seems so much nicer than current C/RMS
2	Variable Send/Receive doesn't happen on RSX-11M. This stuff is
	M+ only. However the send/receive is modular: roll your own.
3	As noted in RMS.H the RMS.C/RRMS.C module includes stuff most
	people don't need. Split it into maybe 20 smaller modules.
4	No support for records exceeding about 490 bytes.
	Such a package is brewing, but I don't want to release it
	to DECUS yet.
5	(Because I do kinky things to M systems) the logic of rmscs()
	explicitly creates a server task name. I should just use RRT
	instead of RRTtnn. Please change it if you like, the next
	release will do it different anyway. Now the next release
	has happened: you still need a call to rmscs(), which
	kickstarts lots of things.
6	General rampant featuritus. Most unUnixy.
	Sorry, I have been managed here: my public commands this slop.
7	NO SECURITY IS ATTEMPTED. Smart programmers may rape YOUR
	RMS files (or just inspect your transactions on the fly).
	Roll your own security, hooks are there.

Experience:
	Some really gross programs (My clients can write C with a heavy
COBOL accent) have run without overlays using RRMS. The RRMS server
task itself uses RMS.C . No known bugs. The system needs re-writing
for a nicer interface than this one, but my application programmers
don't want me to change anything. A CPM-86 version of these calls
also runs with no bugs known. A CP/M-80 version is around.
	The tracing and testing (RMSTRC & RMSTST) suffice to show
that all bugs reported in the past 13 months aren't in this stuff.
I can't think of any more feature(?)s to add to RMSTST/TRC.
Well... actually, an RMSDDT would be nice ... STOP THAT !!!

	June 1985. The COBOL reached critical mass. We decided
to use more tricknology to allow yet bigger applications. I
actually got paid to make DECUS C run I/D tasks. They never
needed that. Overlays were "too hard" because the "structured
applications code" could not adapt to the idea. Actually I
think it might have, but we didn't need overlays anyway.
	This crud works with I/D, supervisor etc. Seems robust.
Would somebody try DECnet? Tell me about the bugs.

	As always, a sensible "structured" version is coming
"real soon now". It takes me about 8 hours to test each new
version, so I won't make minor mods.

Maintenance:	+61(9)322-6048 Dean Elsner @ ML Silbert Ltd
		26 Queen Street Perth Western Australia 6000
		Telex (Aust) 9325       GPO Box S1525 Perth

More:	README.2ND is a flame. (removed to protect the guilty!)
	README.3RD is installation guide.
	README.4TH is a software bill of materials

Liability: Ha! Ha! I will try to help, but will NOT be liable for
any function or dysfunction of this software. When you feel sick
enough to re-write this software, send rewritten files to DECUS or me.
The first rewrite commands in TECO read HK ... .

ALSO: to confuse the enemy (that's you) RMSCHECK.C was part of
a desperate effort to scrape records from a disk for a government
which scrambled 5 years of records, without a backup. It worked.
Likewise G.C H.C I.C were used to re-construct RSTS RMS files. Worked.
		[end README.1ST]
