Hi Keith,
It seems to me this should have been addressed years ago - wasn't the
Spectrum Manfacturers' thing a waste of space? IBM, holding 2 big
cards at the multivalue game, ought to be taking a lead on this, but
they'll probably leave it to Martin
I haven't been following this thread too carefully but I latched onto the
above paragraph, wondering if this was a reference to OpenQM. (I do wish
that people would refer to the product, not me. I may lead the technical
direction of the product but I'm not alone!).
We already have a READONLY qualifier to OPEN, OPENPATH and OPENSEQ. This
mode is also set automatically if the user opens an item to which he does
not have write access. The open mode can be confirmed via a mode of the
FILEINFO() function. As far as I am aware, these features are not in the U2
products and probably ought to be recommended as enhancements.
Like UV, we return the permission flags via the STATUS statement. I cannot
recall seeing this in Unidata but I may be wrong.
I recall that early postings in this thread led to a discussion of the
mysteries of the ON ERROR clause to WRITE. This is just about the only place
that most applications might find it useful. Those of us who have used UV
for many years may recall the wonderful feature of ED where you could do a
massive edit to a program, go to file it away and abort with a "disk full"
message, losing your edit. If you were really unlucky it had already deleted
the old version too! This was fixed by adding an ON ERROR clause to the
write so that you stay in the editor while sorting out the problem.
When I teach U2 programming courses, I suggest that the ON ERROR clause is
almost useless to most applications. I get very annoyed when I see live
applications the have something like
WRITE REC TO FVAR, ID ON ERROR ABORT "Write failed"
as this message is significantly less informative that what the system would
have done without the ON ERROR clause being present. The ON ERROR clause
should only be used if you need to stay alive and take some recovery action.
Although disk full situations are becoming mush less of a problem with
today's hardware sizes and permissions errors should be resolved long before
the application gets this far, I tend to suggest that an ON ERROR on a WRITE
has its uses, especially with directory type files. Most of the other places
where it can be used are irrelevant as there is little that an application
can do to recover sensibly.
What is less obvious to most developers is that ON ERROR might just be
useful on a DELETE too as it is technically possible to run out of disk
space while deleting a record. (How? Think about a dynamic file where the
delete causes a merge that results in overflow).
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
