[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:''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]