![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: RE call 3276 I would like to thank the wizard very much for answering my XQP file header question, it not only solved the last problem with my project but also opened up many possibilities (useful ones too). >>Indexf.sys - how do I recalculate the CRC in >>the file headers. However why did the wizard negate my efforts by informing the world what I was doing could not be expected to work. >The OpenVMS Wizard would not expect the >Microsoft FAT disk format and the OpenVMS >ODS-2 disk format to be able to coexist on the >same volume, due to an expectation of file >structure block-level collisions between >the two formats. This last statement is just not true, in fact both disk formats can be accomodated on the same volume and can be dove tailed to fit like a glove, zero collisions-n-all. So much so that when I first considered this it looked to me like there had been co-op eration it was so easy. I do thank again the wizard for his/her/their assistance but please be kinder to me after all I am up there with the best of them in the UK when it comes to being a fan of OpenVMS and my stated opinion has always been that it's capable of anything. Ex UK badge # 64344 The Answer is : This is a reference to the existing Ask The Wizard topic 3276... Coexistence using a "container file" scheme or a mapped "virtual disk partition" scheme is certainly quite feasible, but the on-disk formats and disk block assignments -- unlike those of ODS-2 and ISO 9660, for instance -- are expected to be physically incompatible. (Both ODS-2 and FAT, for instance, prefer to use the first LBN on the disk...) The single biggest hassle of foreign file system support is the record structure support, akin to the "fun" of the existing /UNDEFINED_FAT mechanism, or of the more dynamic mechanisms such as that used by NFS within the TCP/IP Services package.
|