|
HP OpenVMS Systemsask the wizard |
|
The Question is:
Question: Is there anyway to switch off RMS?
We have an application that has been ported to 7 different UNIX platforms
and Windows-NT successfully and we are now trying to port to VMS.
Our application will start up 3 (or more) independent processes which
will access central "database" files. These central database files consits
of a set of fix length records, which can either be read/updated/deleted
or a new one appended to the end.
To be portable across different OS's we made it *very* simple. We only
use open (), read (), write () lseek () and close ().
It is quite normal for a file to open by two or more processes at one
time and we use semaphores, so only one transaction (either read or write)
is in operation at anyone time! Therefore no locking is required (or
assumed) in the operating system.
Each transaction is a simple lseek () followed by a read () or write ().
This is *VERY* simple record system as all records are fixed size - it
does precisely what we need and has been *very* portable.
So far we have tried using:
fd = open (file, O_RDWR, 0644, "ctx=rec", "shr=mse", "shr=upi",
"shr=del", "shr=put", "shr=upd", "rop=rrl");
The first question has to be are these the settings we should be using?
Ideally we would like to open a simple file, no record services, no RMS
etc.
Secondly, am I correct in assuming that all writes in VMS are synchronous?
This would be ideal for us, so we know what when the write () finished,
all the other processes with this file open on the system have latest data.
Thirdly, the main problem we have seen, is that when we try and add a
record to the end of the file, we lseek () to the end and the write ()
fails with errno 65535 (end of file detected).
We might be doing a major BOBO here with the way we open the file i.e. the
settings but the C-documentation does not give any major lead.
Best Regards & Thanks for this excellent service
Arve
The Answer is :
The basic record management system used in OpenVMS is RMS. It can
operate synchronously or asynchronously. RMS is layered onto the
file system interface provided by the OpenVMS XQP. By default, RMS
access is synchronous (see the asynchronous option if you want to
turn this off), and all RMS caches are kept coherent across multiple
accessors across all nodes in the cluster.
The C run-time library emulates the UNIX file system using RMS, and
this is likely where you will run into most of your problems -- you
are not looking to use the UNIX file system, you have a very simple
file system of your own in mind here.
An example of a moderately complex open is:
fp = open( filename, "w",
"ctx=bin,rec", /* Record mode, no newline */
"shr=get,put,upd,del" /* File access sharing */
"mbf=10", /* Multi-buffer count */
"mrs=0", /* Maximum record size */
"rat=none", /* Record attribute */
"rfm=fix", /* Record format */
"rop=wbh" ); /* Write behind caching */
You may well want to open the file with "wb" or similar for the open
call, as it appears you may have a binary file.
While calls to the C RTL (or direct to RMS) can likely also be used,
you are looking to disable the very reasons that most folks want to
use C or RMS.
When using memory semiphores, be very aware of the rules for accessing
and interlocking memory, particularly on Alpha systems -- the rules are
covered in the Alpha Architecture Reference Manual, as well as the VAX
rules in the VAX Architecture Reference Manual for VAX systems. When
using disk-based semiphores, be very aware of the rules for accessing
and keeping caches -- the XQP and RMS will keep the caches coherent for
you. If you wish your application to operate in a cluster, you will
want to be aware of the ability for applications to operate and to share
file access from other nodes.
Given this particular situation (wishing to disable or bypass much of
RMS and not even using the features of the file access routines in the
C library), the Wizard would tend to create and utilize a set of small
routines that call the low-level logical block accesses to the XQP file
system directly. The calls will be via sys$qio and/or the asychronous
sys$qiow system service calls, specifying the READVBLK and WRITEVBLK
itemcodes. Start with a call to sys$open with the UFO option to open
the file, then use the channel number returned in the RMS STV field
and the information in the OpenVMS I/O User's Reference Manual to code
up the necessary sys$qio and/or sys$qiow calls.
At a slightly higher level, RMS can be used directly and can provide
you with many advantages over direct use of sys$qio or sys$qiow.
Using the more basic file formats (block, relative, or fixed-length
sequential) you can perform most everything you will need to here.
Example C source code is available from DSN and the customer support
center, on the freeware CD-ROM, and various websites around the 'net.
|