10-24-2011 08:23 AM
We are running OpenVMS 8.3 on Alpha GS60.
I tried installing the VMS patches for a piece of software we need to run that requires Java 5.0-7 JDK but was unsuccessful. The patches needed to be installed before installing Java.
The following VMS 8.3 Alpha patch could not be completed: DEC AXPVMS VMS83A_UPDATE V15.0.
The only requirement for the V1500 is VMS83A_PCSI-V0300, which I installed previously. We are running Process Software's Multinet product for TCP/IP, so no HP TCP/IP patch was needed.
This V1500 patch contains the required Java updates (ACRTL & PTHREAD) .
It would stop at %50 completion due to insufficient diskspace, even though about 2.7 million free blocks existed:
$ SHOW DEV DSA0
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 AXPVMSSYS 2699001 855 1
$1$DKB500: (LNOCA1) ShadowSetMember 0 (member of DSA0:)
$1$DKD0: (LNOCA1) ShadowSetMember 2 (member of DSA0:)
Execution phase starting ...
The following product will be installed to destination: DEC AXPVMS VMS83A_UPDATE V15.0 DISK$AXPVMSSYS:[VMS$COMMON.]
Portion done: 0%...10%...20%...30%...40%...50%
%PCSI-E-OPENOUT, error opening DISK$AXPVMSSYS:[SYS0.SYSCOMMON.][SYSLIB]DECC$SHR. EXE_OLD; as output -RMS-F-FUL, device full (insufficient space for allocation)
%PCSI-E-COPERR, error copying DISK$AXPVMSSYS:[PCSI$UNDO_001.][SYSLIB]DECC$SHR.EX E;1 %PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES]
%PCSI-E-CANCEL_WIP, termination resulted in an incomplete modification to the system
%PCSI-E-S_OPCAN, operation cancelled by request
Recovery pass starting ...
Don’t get it. It should only use ariound 450,000 blocks or so.
I thought maybe it was a quota issue so , I increased the quotas on the system account to 4096 for WSDEF and WSQUO.
All the prerequisite patches have been installed. The installation is being done on an ODS-5 disk as required.
Also, a colleage of mine tried to install this patch on his system for the same reasons and experienced the exact same issue, so I know this isn't just an isolated incident.
Thank you for any help you can provide!
10-24-2011 08:30 AM - edited 10-24-2011 09:03 AM
There could be a problem with contiguous disk space on your system disk. DECC$SHR. EXE is probably a contiguous file and there may not be enough contiguous space on that disk to save a contiguous copy of that file.
If you have some downtime, run a BACKUP/IMAGE on your system disk. You have a 2-member shadowset, so you could just remove a member and run the BACKUP/IMAGE from one member to the other. Then boot from that newly restored member.
10-24-2011 08:43 AM
Could be that file, or it could be a big directory.
Defrag that system disk, or move to larger disks in this HBVS volume, or both.
Set up fragmentation monitoring, or check fragmentation with (for instance) the Freeware DFU tool.
10-24-2011 08:45 AM
I'm not sure that is the problem. My co-worker had the same issue and he had 6.5 million free blocks. His installation also stopped at the 50 percent completion stage. We run a standalone backup of the system disk every week, so we are doing image backups.
10-24-2011 08:55 AM - edited 10-24-2011 08:59 AM
... but are you BOOTING from the restored system disk after BACKUP/IMAGE ?
Try $ COPY/CONTIG/ALLOC=10000 NLA0: x.x into a directory on your system disk. Does it work ? Then delete x.x again.
Also note that DECC$SHR.EXE may not have too many extents, especially NOT a file extension header, to allow OpenVMS to boot and access that file with the primitive file system early during boot.
10-24-2011 09:26 AM
This is how many total files I have:
sysmgr> dir/grand dsa0:[000000...]*.*;*
Grand total of 1336 directories, 33105 files, 5614852 blocks.
I'll try you suggestion with the copy operation. That won't lock our system up, will it? This is production system.
10-24-2011 09:30 AM
sysmgr> dire /full sys$library:DECC$SHR.EXE
DECC$SHR.EXE;1 File ID: (20983,2,0)
Size: 5537/5544 Owner: [SYSTEM]
Created: 1-MAY-2007 07:04:49.23
Revised: 21-SEP-2011 20:04:17.96 (10)
Expires: <None specified>
Backup: 22-SEP-2011 00:15:10.31
Effective: <None specified>
Recording: <None specified>
Accessed: <None specified>
Attributes: <None specified>
Modified: <None specified>
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 5544, Extend: 0, Global buffer count: 0
No version limit, Contiguous
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:RE
Access Cntrl List: None
Client attributes: None
Total of 1 file, 5537/5544 blocks.
10-24-2011 10:40 AM
First, given you have a support contract, call HP support. (Y'all pay them to sort this out, after all.)
Second, the files installed are generally not contiguous, but the directories are continuous and must be. However and IIRC, this particular file has issues around contiguity as this file is used early in the bootstrap, and the Primitive File System is fairly limited around the number of file extents permitted.
Again, use DFU or other similar tools, and see how fragmented this disk is.