[Info-vax] CMS glitch

[Stephen Hoffman]

On 2018-08-26 16:21:33 +0000, John Reagan said:

> On Sunday, August 26, 2018 at 11:52:08 AM UTC-4, Marc Van Dyck wrote:
>> I'm a long time VAXSET user and often issued the following command when 
>> I wanted to have a quick look at a CMS element :
>> 
>> $ cms fetch/out=tt: <CMS library element> ""
>> 
>> I have - see my previous topic - returned to development activities 
>> after a long pause, and when I issue that command, I now get the 
>> following error :
>> 
>> %CMS-F-BUG, there is something wrong with CMS or something it calls
>> -CMS-F-NOQIO, $QIO failed
>> -RMS-F-SYS, QIO system service request failed
>> -SYSTEM-F-NOT64DEVFUNC, 64-bit address not supported by device for 
>> this> function
>> 
>> This is the VSI version of CMS and OpenVMS running on a BL870c-I4.
>> ...
> I assume it works with /OUT=filename.ext ?
> 
> CMS has had some issues with 64-bit addresses.  It started using P2 
> heap several versions back and has issues with 32-bit vs 64-bit 
> descriptors inside of CMS.  I don't know enough about the internals of 
> CMS to survey the various $QIOs to see if there is some itemcode that 
> needs changing if you start to pass in 64-bit pointers?

Assuming extracting to HDD or SSD works, that's almost certainly a CMS 
bug.  Hopefully (probably?) pretty easy to reproduce on V8.4-2 and CMS 
v? and a FT terminal device, too.

Likely workaround is to wrap the CMS FETCH command in some DCL 
procedure that extracts the element off to SYS$SCRATCH and TYPEs and 
then deletes the output, or some similar ilk.

It might be possible to enable and use a reference directory within 
your CMS library as another sort of workaround, though the reference 
directory isn't always applicable.

I've also seen some CMS library corruptions, and older CMS libraries 
were notorious for latent corruptions.  Usual workaround for those is 
to use a tool to extract the entire contents of the CMS library and 
rebuild it.   VSI probably has one of those, if there's not one already 
posted on the freeware or elsewhere.

ps: Welcome to the "fun" of 64-bit addressing on OpenVMS.  That design 
was a very clever and good for the upward-compatibility of existing 
apps, and it allowed a migration path for working with un-updated and 
deprecated 32-bit frameworks.   But the limitations  inherent in the 
OpenVMS 64-bit design are not something anybody working on or migrating 
to 64-bit apps would prefer; we're forever stuck in the transition.  
Other similar designs for compatibility tend to create or increase the 
costs and complexity of new work, too.




-- 
Pure Personal Opinion | HoffmanLabs LLC