Wim,
This may not be OpenVMS at all. For some combinations of controller and disk drive, the HWM ERASE function is done in the drive itself. Just an I/O ERASE operation, rather than a series of writes to individual blocks, then wait for it to return (or, to be more precise, one I/O per allocated extent). So, all the stuff you CAN do may be the result of caching, or operations that the drive and/or controller can handle in parallel. Anything else just has to wait.
Bottom line, this IS the "performance impact" that the documentation talks about. You can argue about other ways of doing things, but they're all tradeoffs. That's what engineering is all about - picking the least worst choice.
With security, there are always nasty things to think about. For example, suppose we didn't lock the disk and zeroed the allocated blocks in small chunks, obviously that would take MUCH longer to complete. Apart from the cumulative cost of multiple I/O's, we'd have to write actual blocks, so data would need to be buffered and sent over the wires to the disk.
Worse, maybe it would be possible to request the CREATE asynchronously and access the blocks from a parallel thread, ahead of the ERASE fence, thus defeating HWM?
The engineers who designed this weren't complete morons, so if they've taken the fairly drastic step of holding a lock for a long time, it definitely wasn't without good reason. If you really want to know the answer, log a case with your local customer support centre and have it escalated into engineering. They will either say "of course! how stupid" and fix it, or they may explain why it has to be that way to guarantee security, or they may say "it has to be that way, but we're not going to tell you why becuase it involves security".
This is the burden of being OpenVMS. Other operating systems can take short cuts, possibly leaving security or reliability holes around the place, but we have to keep everything secure and failsafe, sometimes at the cost of performance.
A crucible of informative mistakes
