RMS and user data

[ptrskg]

Hi,

I have some RMS sequential files where I need to store additional information, less then 10 bytes, which will be used by the program to determine how to access the records. Of course I can store this in the file itself, or in the file name, but I'm not so keen to change the layout of the file or the specific file name pattern.
My question:
Is there any place in the RMS file header(s) where I can put this kind of data when the file is created and later on retrived when the file is opened.

Thanks,
Peter

[David Jones_21 · Accepted solution]

You can use an application ACE to store the data. You use the function SYS$GET_SECURITY and SYS$SET_SECURITY to manipulate the ACL on a file. The documenation for SYS$FORMAT_ACL describes the layout of the different ACE types (including application ACEs).

[Wim Van den Wyngaert]

This is a starting point for more info.
http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_088.html#10_overviewofvmsprotectionsche

DECWRITE is an example of an applic that uses it.

Wim

[David Jones_21]

I've attached a ZIP file containg a C source module (~430 lines) I use in several programs.

/*
* protoypes for application ACE access functions.
*/
#define AACE_DATA_LIMIT 244
int aace_get ( char *fname, int tag, char *key, char ace_data[AACE_DATA_LIMIT],
int *dlen );
int aace_put ( char *fname, int tag, char *key, char *ace_data, int dlen );
int aace_delete ( char *fname, int tag );
/*
* Save list of strings in ace, useful for saving command line arguments
* for programs running detached. Note 244 character limit.
*/
struct aace_tag_info {
int n; /* ACE tag for save/restore */
int space; /* data bytes available in ACE */
};
int aace_save_argv ( char *fname, int tag, char *key, int argc, char **argv );
int aace_restore_argv ( char *fname, int tag, char *key, int *argc, char ***argv
);
int aace_get_tags ( char *fname, struct aace_tag_info **tag_list );

[Hein van den Heuvel]

As David indicates, an ACE is probably the best way to go.

For just 10 byte I would possibly use a filename or filetype hack.

'Stored Semantics' as Wim indicates allow mutliple streams of data to be part of the same file, but that seems way overkill here and restricts the usaeg of the files outside the application somewhat (if there is a legit use).

An obvious other alternative is of course a 'dictionary' (indexd) file where you can lookup the 10 bytes, or maintaining a 'parallel' file: filename.data, filename.access. I like th elast one th eleast.

Hein.

[Hoff]

The file record structure requirements here sound reminiscent of what CDD/Repository can provide. That may well be overkill, though.

And as for new sequential files, XML can work nicely for storing this sort of information. Even if it's just to "wrap" the information from the original file internal organization, and store that block as a big wad of data, as part of moving toward a more modern solution for data storage. Whether that's XML, or a database.

PATHWORKS stores certain filename information in an ACE.

One downside of an ACE: the ACLs tend to get stripped off when files are moved around with some tools, particularly when the files are moved off-node.

Unlike some other operating systems, OpenVMS doesn't readily offer any room in the file header (other than the ACL), nor does OpenVMS support threaded/forked file structures.

It may also be feasible to store the structural data in a file architected and managed by the application (if not within something like CDD); the application can then detect a matching file in its cache using, for instance, the FID or (far better) filename as a key in an application-specific indexed file.

Stephen Hoffman
HoffmanLabs LLC

[Robert Gezelter]

Peter,

While ACEs are a good solution, Hoff is correct, there are situations where ACEs have been stripped off when files are moved (unknowingly) by those who are not aware of their importance.

In general, there is a cautionary note when using all "User Defined" reserved fields. When creating them, and then using them, it is a VERY sound practice to build in self-check values to ensure that some other program, using the same "reserved to users" field, does not confuse ones software.

- Bob Gezelter, http://www.rlgsc.com

[Jur van der Burg]

There's a reserved area in the fileheader that you can use for this type of thing. Completely supported. Look in the i/o users guide for IO$_ACCESS and the ATR$C_RESERVED field. The only gotcha is that if you write that field there may not be already an ACL on the file. Also, if you have a parent directory with a default ace on it that will propagate to the file you will get in trouble. The solution would be to create a TMP file (which has no directory entry), write the reserved area and then enter it into a directory. No big deal but you should handle these things.

Jur.

[ptrskg]

Thanks all,
I didn't know of the possibilities with ACE's, OpenVMS surprise you all the time.