Problem to install C compiler 73

[noneofthis]

Hi,,

I've got via hobbyist license, C compiler 73 from HP ftp (together with openvms 84...) and when trying to install, vmsinstall do not recognize cc073.A as save set and stop.

How to install this???

thanks

[Volker Halle]

If you expect help, please provide a qualified problem description.

In this case, the command used and the resulting error message(s) would be nice...

Volker.

[noneofthis]

I've done the following:
unzip c_compiler_73.zip get from HP ftp
I got:
Archive: DKA200:[000000]C_COMPILER_73.ZIP;1
inflating: cc073.a
inflating: cc073.b
inflating: cc073_iguide.txt

then
GFI>SET DEFAULT SYS$UPDATE
GFI>@SYS$UPDATE:VMSINSTAL CC073 $dka100:[temp] OPTIONS N


OpenVMS Software Product Installation Procedure V8.4


It is 1-APR-2012 at 00:30.

Enter a question mark (?) at any time for help.

* Are you satisfied with the backup of your system disk [YES]? y
* Where will the distribution volumes be mounted: dka100:[temp]


The following products will be processed:

CC V7.3


Beginning installation of CC V7.3 at 00:33

**********************************************************************
%VMSINSTAL-I-VALSIGN, Performing product kit validation of signed kits ...
%VMSINSTAL-I-NOVALDONE, Product is not signed by HP
* Do you want to install this product [NO]?y
%VMSINSTAL-I-RESTORE, Restoring product save set A ...
%BACKUP-F-NOTSAVESET, DKA100:[temp]CC073.A;1 is not a BACKUP save set
%VMSINSTAL-E-NOSAVESET, Save set A cannot be restored.


VMSINSTAL procedure done at 00:35


GFI>

So the installation do not install anything!


I do not understand since the c_compiler_73.zip is directly coming from HP ftp.

The fortran, form the same source give not problem of installtion, but was not set of save_set but compressed PSI to be installed with product.

What(s wrong???

[Volker Halle]

The record attributes of the product savesets (CC073.%) are most likely incorrect. You can verify this by trying a simple BACKUP/LIS CC073.A/SAVE -> it will also fail with the same %BACKUP-F-NOTSAVESET error message.

You need to correct the record attributes. There is a FIXBCK tool on the OpenVMS Freeware CDs as [000TOOLS]RESET_BACKUP_SAVESET_FILE_ATTRIBUTES.COM.

But you can probably also get away with:

$ SET FILE/ATTR=(RFM:FIX,RECL=32256) CC073.%

In the future, consider to use the HELP/MESSAGE utility to get a more detailled description of the error message. In this case: HELP/MESSAGE NOTSAVESET 

Volker.

[noneofthis]

THanks a lot,

Your solution with RESET_BACKUP_SAVESET_ATTRIBUTES.COM solve my problem.

Your other solution with your set file did not work since "recl" is not a recognized attribute.

Best regards

[Volker Halle]

Sorry 'bout that.

$ HELP SET FILE/ATTRIBUTE would have shown, that LRL would have been the correct keyword.

OpenVMS has a very detailled HELP system. When you know what you want to do, figuring out the correct command is easy when using HELP.

HELP/MESS IVKEYW would have pointed you to the OpenVMS HELP utility and you could have figured out the correct keyword by yourself. On OpenVMS, HELP is always there to help you ;-)

Volker.

[H.Becker]

Unfortunately VMS doesn't have a utility to display the file attributes with the keywords as expected by SET FILE/ATTRIBUTE. A SHOW FILE/ATTRIBUTE or the DIRECTORY command would be the right utility. Unfortunately a DIR/FILE displays the file ID and a DIR/ATTR (yeah, not explained in the HELP) does something else. If there is interest, I can make my simple

$ mc []fats fats.exe

File EISNER$DRA3:[DECUSERVE_USER.BECKER_H]FATS.EXE;1

credate=" 4-OCT-2011 12:15:30.21"

revdate=" 4-OCT-2011 12:15:30.22"

expdate="17-NOV-1858 00:00:00.00"

bakdate="31-MAR-2012 03:36:06.35"

org=seq

rfm=fix

rat=none

lrl=512

hbk=30

ebk=29

ffb=0

bks=0

fsz=0

deq=0

mrs=512

gbc=0

vrs=0

$ 

available.

[Hoff]

In no particular order...

• ftp strips off VMS file system metadata.
• stripped metadata leads to various errors in various tools.
• binary-mode transfers can sometimes help, but BACKUP has issues irrespective of proper ftp file transfer mode selection.
• Storing a VMS file on a Linux, OS X or Windows box during a transfer can (also) corrupt/strip the file system metadata.

When you are moving these files around yourself, zip "-V" can be your friend here.  That's a quoted capital V there, and the quotes and the capitalization are required syntax.  Zip (and unzip) know how to protect the file system metadata.

The OpenVMS FAQ is here: www.hoffmanlabs.com/vmsfaq  This is covered in the FAQ, as well as at other sites around the net.

OpenVMS V8.4 does (twenty years along) have a (sort-of, kind-of, mostly) fix for BACKUP saveset corruptions, with the advent of the BACKUP /REPAIR command.  But the DCL command procedure you're using is equivalent, and it works across any recent OpenVMS version.

Google is also your friend with OpenVMS, as cases such as this have twenty years of folks having slammed into this particular ftp issue, bug, error, whatever.   These days, most VMS bugs are old bugs.  And Google means you get a quicker answer than you would from posting here.

[abrsvc]

Interestingly enough, I have had similar problems in the past with kits FTPd from HP.  I found that making sure that the FTP was in binary mode and that the UNZIP is done on VMS results in correct behavior.  UNZIPing on a Windows system even with a binary transfer to a VMS system afterwards will fail more times that not.

Dan

[Hoff]

>Interestingly enough, I have had similar problems in the past with kits FTPd from HP. 

That isn't particularly unusual, in my experience.   

I have a posting on how to detect whether -V was used when the archive was zipped.

HP also commonly uses very old versions of zip and unzip as part of their operations.

>I found that making sure that the FTP was in binary mode and that the UNZIP is done on VMS results in correct behavior.  UNZIPing on a Windows system even with a binary transfer to a VMS system afterwards will fail more times that not

Again, Microsoft Windows, Unix, HP-UX, Linux and OS X do not preserve the OpenVMS file system metadata, so any storage of an OpenVMS file on a non-OpenVMS platform can and will strip off the file system metadata.    

Unzip an archive on a non-OpenVMS platform, and the metadata will be stripped, irrespective of whether "-V" was used when the archive was created.

Some RMS file formats are portable, and will transfer to and from these non-OpenVMS platforms.  These formats are not sensitive to the loss of the metadata. 

Those OpenVMS files using formats dependent on the metadata will not transfer cleanly.  BACKUP is one such format; savesets get the necessary metadata stripped.

[Maurizio De Tommaso_]

It is possible also to reset the RMS file attribute of a saveset file, which gets corrupted while the saveset is transferred through World Wide Web (WWW) or copied using FTP or compressed and uncompressed using ZIP, using the qualifier  "/Reset" of the Backup utility  :

$ Backup /List save_set_name /Save /Repair

This qualifier is supported starting from OpenVMS V8.3 and later (Alpha and Integrity).

Best Regards,

/Maurizio

[John Gillings]

Maurizio,

> This qualifier is supported starting from OpenVMS V8.3

Sorry to be a pedant, but strictly speaking it's NOT supported at all, it's just a (very) useful undocumented feature.

Although it made it into the released codestream, it's never been documented or announced except by word of mouth. A parting gift from a good friend of OpenVMS, Guy Peleg, implementing a product enhancement request I submitted in the early 1990s. It probably took him all of 20 minutes to implement.

[H.Becker]

>>> ... undocumented feature.

It's documented in 8.4: http://h71000.www7.hp.com/doc/84final/6048/6048pro_025.html. 

[Maurizio De Tommaso_]

John,

this new feature is now officially supported and it is also well documented into the OpenVMS V8.4 manual

"HP OpenVMS System Management Utilities Reference Manual: A–L Order, Number: BA555-90008, Jun-2010".

http://h71000.www7.hp.com/doc/84final/6048/ba555_90008.pdf

paragraph 7, page 7-84.

Also the V8.4 help library of the backup utility was modified to include this new qualifier.

Regards,

/Maurizio