VSI PASCAL 6.3-143 files missing files on kit installation

[nortonti]

Hi,

I'm trying to install VSI Pascal Compiler V6.3-143 and received error message during installation (see attached image).

The file PASCAL063.C is empty and it´s not a valid saveset backup file.

I execute "backup/list pascal063.c/save" command and I can not to see any files inside of saveset neither the stamp of backup command executed for create the saveset.

The others saveset PASCAL063.A, PASCAL063.B and PASCAL063.D from kit downloaded from VSI are right and I can to see the files inside of each saveset using "backup/list savesetname/save" command.

Thank you.
José Norton A. Oliveira
Norton Tecnologia da Informação - IT Services Brazil

[jreagan]

I make all 4 savesets with the same command file and the same BACKUP command (I use SYS$UPDATE:SPKITBLD.COM)

I can't get to the portal this morning to double check the PDF file but that file is created by the support organization after extracting the RELEASE_NOTES file from saveset A.

I've read all the replies but I can't tell, do I have a problem somewhere? As part of our verification, somebody besides me downloads the ZIP, expands it on the x86-64 system, and then installs it.

John

P.S. And yes, I intend to convert to use PCSI. The post-installation portion to create all the PEN files is a little tricky since the current VMSINSTAL.COM uses a COM file buried inside of SYS$LIBRARY:STARLETPAS.TLB that is written (by me) assuming that it will be invoked from a running VMSINSTAL installation. Not difficult to handle, but I've been busy with other things.

[nortonti]

Martin,

I extract zip file downloaded from VSI in a Windows OS before to transfer for OpenVMS for a my option, because even work changing block size to 32256. It's the standard.

When create a disk saveset, the standard is block size 32256 not 9000 as showed in Arne screenshot. It doesn't make sense.
If it's the problem, i'll to change block size to 9000.

I'll transfer zip file downloaded from VSI for OpenVMS first and I'll extract using unzip.exe inside of OpenVMS.

Jouk,

I'll test your script too.

Maurizio,

I'll test your sugestion.

Thank you everbody !!!

José Norton
NortonTI Brazil

[sms]

Code: Select all

> [...] extracted files from zip and after transfer for OpenVMS system.

   Not the most reliable scheme for files with VMS attributes.

> [...] changing block size to 32256. It's the standard.

   That's one opinion.

> I'll test your script too.

   RESET_BACKUP_SAVESET_ATTRIBUTES.COM (or a similar script or program)
extracts the original block size from the save set, whether or not it's
"the standard".

      http://antinode.info/dec/sw/fixrec.html

[joukj]

John: You do not have a problem!!! Other OS's have the problem not knowing the variety of different file headers OpenVMS can have in its filesystem.

To avoid problems you might create a .zipexe which has to be unpacked on the target system

[sms]

Code: Select all

> [...] a .zipexe which has to be unpacked on the target system

   There is no such thing.

   UnZip on any system can extract files from a self-extracting (zip)
archive for any system.  (Without even emitting a warning, if the
self-extracting archive is made/adjusted properly.)

   A self-extracting zip archive (SFX) comprises an unzip program with a
normal zip archive appended to it.  Any competent unzip program can
ignore the unzip program in the SFX, and work with the
normal-zip-archive part of the SFX.  A self-extracting archive imposes a
restriction only if you don't have an unzip program other than the one
in the SFX.

   For "adjusted properly", see Zip's "-A" option.  (VSI tends to skip
that step, causing UnZip to emit an annoying warning before working as
usual.)

   If you have some self-extracting archives for different
architectures/operating systems lying around, it's easy to demonstrate
this for yourself.  (If you get the extra-bytes warning, you can also
use Zip with "-A" to remove that annoyance.)

[arne_v]

UNZIP on other platforms may be able to unpack a VMS self extracting ZIPEXE.

But Windows File Explorer will not recognize it as a ZIP archive.

[sms]

Code: Select all

> But Windows File Explorer will not recognize it as a ZIP archive.

   And the Mac "Archive Utility" sees it as a plain file, and
wants/tries to put it into a new archive, rather than extracting its
contents.  (But The Unarchiver can cope.)

  I did specify "Any competent unzip program".

   One annoying thing about using only self-extracting archives for
VMSware is that in a multi-architecture cluster, you can't do all the
extraction for different architectures on one system.  Unless, of
course, you use UnZip on the self-extracting archives.

[jreagan]

Thanks to all for digging thru this. I didn't think I messed anything up. And the PDF release notes are created elsewhere in the company from the TXT file and we've seen "extra" linefeeds, etc.

ZIPEXEs are considered a security nightmare by some customers. Yes, we could provide checksums/fingerprints/etc. but it still isn't something people want. And yes, the multi-architecture aspect would mean having to bounce around from system to system (but you have to do that any way if you are going to install them after you expand them)

[sms]

Code: Select all

> ZIPEXEs are considered a security nightmare by some customers. [...]

   That's one reason.  Years ago, Compaq/HP[E] used an old/lame UnZipSFX
program to make its SFX kits, missing out on a (pretty old)  I/O
optimization (more/bigger RMS buffers).  So I got into the habit of
using a newer/better external UnZip program instead of the old/lame one
in the kits, usually saving measurable time.  (It's less of a problem
now, with VSI-made SFX kits.)

> [...] (but you have to do that any way if you are going to install
> them after you expand them)

   Sure, "if", but "install" isn't the only possible goal.  For example,
one might wish to view some part of the kit (release notes, say) without
involving a system of the target type.  (Just as one might wish to build
the kit itself on a different-architecture system.)

   Of course, one could slap any desired UnZipSFX program onto the front
of an archive to make an SFX of the desired type on any system type.

   The real mystery here might be the motivation behind "/BLOCK=9000"
(resulting in "Block size: 9216") in the kit construction.

> [...] changing block size to 32256. It's the standard.

   I wouldn't say "standard", but I would say "usual" (or "default").

   Note that I'm not promoting the use of self-extracting archives.  I
_am_ promoting the use of Zip "-A" to correct the offsets in the things
when they are used.

[arne_v]

Maybe some text on download page saying:

PLEASE UNZIP ON VMS