Unix/Windows vs. VMS - suggestion

[Willem Grooters]

I was just wondering.
In a number of threads some (including me) signelled concern about the way applications are being ported to VMS. In cases it may render the applications unusable since co-operations with VMS-native applications difficult, error-prone, troublesome, or worst case, impossible.
Some issues are obvious, others are more or less hidden, or just pop up in particular situations.
Could a list be created to hold these issues?
These can be discussed and eventually be solved in some way, in order to assure ported programs are really co-operational with VMS-native ones.

[Ian Miller.]

ok - to start things off.
Not following VMS filenameing conventions. I know ODS5 supports all sorts of bizarre filenames but.

Not correctly using VMS file attributes. VMS files are record structured unlike unix etc. File attributes should be properly set so that native VMS utilities can correctly deal with files.

[Jan van den Ende]

My own favorite:

Proper, VMS-compliant, exit codes, especially in ALL failure modes.

eg: predefine your exit-code to -F-NOMSG, and in ALL specified conditions give (or pass on from VMS) a meaningfull code. Of course, normal termination would be SS$_SUCCESS.
But certainly, in ANY unplanned termination, NEVER report success!

Jan

[Jan van den Ende]

Another one.
Maybe trivial, but...

ALWAYS check for BufferOverflow (and UnderFlow). Even (just!) against the argument that that costs performance!

Jan

[Antoniov.]

Printer usage.
Vms support all file type but doesn't support printer type. I wrote a my own printer driven queue processor to make it.

@Antoniov

[Martin P.J. Zinser]

To kind of counter balance Ians request:

Correct support of ODS-5 filenames in older tools ;-)

For me the ideal solution is if a tool does
not require ODS-5 (I also think this is annoying), but does handle it correctly in case it is encountered.

Greetings, Martin

[Willem Grooters]

Having a day off, I could try to start of some discussion :-)

"Filename conventions"
Agreed that there should be no requirement for ODS-5, but I don't think it right either to stick to ODS-2. The distiction should be made on run-time.
If the spec concerns an existing file, there will be (or: should be) just ONE valid translation.
If the spec concerns a new file, it could depend on the disk where the file is to be created. If it's an ODS-2 disk, take the ODS-2 translation, is it ODS-5, use the ODS-5 one.
However, I can see Martin's point as well - that an older application doesn't understand ODS-5 naming and would therefore reject it. So translation conform ODS-5 format may need to be suppressed.

"Not correctly using VMS file attributes"
As we all knoew, this is a major difference between VMS and Unix - and has repercussions in file-access as well. SoI'd like to extend this to "File access" in general, not only to VMS file attributes (which is something dictated by RMS) but with organisation as well. VMS has (by RMS) very workable implementations for accessing 'records' - an concept missing in Unix - in different ways: sequentially, by record number or by some key value. AFAIK, Native Unix only knows sequential files, and, if data is stored in equally sized chunks, these can be accessed like relative files on VMS. But the concept of Indexed-sequential files is implemented very differently - and as an "add-on".
Basically, I think the idea needs to be:
* When creating a file, it should be in some NATIVE format, holding (correct) NATIVE attributes.
* When opening a file, is should be opened AS-IS. NO CONVERSION SHOULD BE NEEDED
* Accessing a file should be done in a way that is consistent with the file. Is it a record-oriented file, read it by record.
* Closing a file should keep the attribuets AS-IS AND DO NOT CHANGE IT.
That would, indeed, mean that all file-IO on a file, that is NOT strictly internal, shhould be done with some routine, allowing OS-specific implementation of the functionality.

"Proper, VMS-compliant errocodes"
Again: some generalization - I would suggest "Exception handling", which is more generic.
The ONLY thing that is fixed in both Unix and VMS is some "SUCCESS" status (well, Unix is more precise). I would prefer to check on a value named "success" - whatever value is named that way. You could make some distiction, in VMS there luckily is "severity". That could be a start.
Another problem is despite UNix has one single "SUCCESS" value, any other value can mean quite different things, depending on which routine/execuatble is used. Again, this could be handled by NAMING them - and one value could have differnt names. The big advantage would be that, when given correct names, this exception hadling would be self-documentative.

"Buffer over/underflow"
The easy one.
Blunt (and __very__ shortminded): DON'T USE C (or C++). Passing parameters BY VALUE (the default!) is definitely part of the trouble.
Parameters should be passed BY REFERENCE or BY DESCRIPTOR, and, only in specific cases, BY VALUE could be usefull.
Just kidding....Of course: if anyone can create a module that prevents this (it can be done, of course) C is very powerful and could well be used. But preventing buffer overflow ought to be a second nature

Could we get to some kind of "draft" recommendation on these issues?
- DO's and DON'Ts on writing REALLY portable code for USABLE programs
- Specifications of functionality (in particular file-io, exception handling....)
- definitions (header/include-files), routiens, objetc-libraries, in which this functionality is implemented (for each of VMS, LINUX, HPUX, ...) (FUTURE...)

Willem