Most recent software version of CMS

[GuentherF]

I have a client getting this error:

$ CMS FETCH EXEC-GRUP /OUTPUT=test.log "test" /NOLOG
%CMS-F-BUG, there is something wrong with CMS or something it calls
-CMS-F-SYSFAIL, LIB$FREE_VM system service request failed
-LIB-F-BADBLOADR, bad block address

...which sounds like a bug in CMS to me.

I am thinking maybe this has been fixed since CMS version V4.6 - the version my client is running.

Does someone have the most recent version number of CMS? Or, a pointer to find it out myself?

Thanks,

Guenther

[Hein van den Heuvel]

Hi Guenther,

Seems like too basic an operation to fail. What is special here?

Tried minor variants of the command? Does it work for other files?

Maybe this file has 'funky' attributes? odd RFM like UDF? odd LRL/MRS?

Google found a similar error, but long since fixed (cms 3.9) when fetching an indexed file.

Is there a verify or rebuild option in CMS?

I like using SET FULE /WATCH=MAJOR to see which files it is reaching out to, and check/compare  those with working situations.

fwiw,

Hein

The following bugs were fixed and restrictions were
              removed in CMS Version 3.9:

              o  Bug 68 - A CMS library's subdirectories are no longer
                 accepted as a valid default directory.

              o  Bug 74 - Alpha LIB-F-BADBLOADR, bad block address.

                 The problems CMS on Alpha OpenVMS had fetching and
                 reserving index files have been resolved.

[H.Becker]

Hi Guenther,

Which DECset version for which platform? Any ECOs applied? CMS V4.6 seems to be in ECO2 for DECset 12.8. Did you see http://h30499.www3.hp.com/t5/General/Memory-leak-in-CMS/td-p/4760372?

[Craig A Berry]

Try the following commands and see if anything interesting happens:

$ CMS SHOW ELEMENT/FULL EXEC-GRUP

$ CMS VERIFY

[John McL]

EXEC-GRUP as a filename?  No "." or file type ?

What's the name in the VMS directory that CMS is using?

I'm not sure that this is your problem.  I ask the question out of interest.

[GuentherF]

Version is DECset 12.8 ECO-2/Itanium.

Seems like a .FLB (FORMS library) file caused the error. All other CMS groups (no .FLBs there) worked fine.

The client has since then removed the .FLBs and the goup fetch "survived".

Haven't looked at .FLBs for a long time but if I remember right they are 512-byte fixed length record format. CMS should be able to handle that.

Thanks for all the replies!

Guenther

[GuentherF]

I forgot to mention that this is a GROUP fetch and not an individual file (or ELEMENT) fetch. There are hundreds of ELEMENTs in this group. They have other GROUPs as well which do not contain binary files...which I think might trigger the bug.

/Guenther

[Hein van den Heuvel]

FMS Forms Libraries appear to be variable length record binary file with no CR attribute.

Same for the FRM files. Maybe try with different (print) attributes?

CMS is supposed to handle that, but maybe you want to wrap them in a ZIP or saveset container.

CMS is not going to add much value to those files (no DIFF, no incrementals) other then the important value of adding files within a generation together.

You could checkout using FMS /DESC/FULL to generate the ASCII representation in a .FLG file.

Those can be TRANSLATED back to .FLB, and for the FLG files  you can 'see' the differences if needed.

fwiw,

Hein

[GuentherF]

Hein, good idea! I have to refresh my FORMS knowledge a bit.

/Guenther