VSSI Home
Product Support
Release 5.2.00 VPARS/VTAPE updates.
Last modified on 08/28/07
There are several critical updates on the VSSI 293 FTP download disk.
You can change directories to that disk to download the required updates
We recommend you download the latest build and apply only updates that
apply to that build however you can download and apply all critical
updates for the build you are currently running.
The update descriptions and apply instructions are in the prolog of
the update file contained in the VMARC file on the 193 disk.
Update 520086 and above apply to build 5216
Update 520072 and above apply to build 5214
Update 520054 and above apply to build 5212
Update 520048 and above apply to build 5210
Update 520029 and above apply to build 5208
Update 520023 and above apply to build 5206
Update 520020 and above apply to build 5204
Update 520007 and above apply to build 5202
All updates apply to build 5200
VS520102 VMARC 8/27/07 15:52:02 * RVSPRM set cond code after HCPXSERV
Update VS520102 applies to VSSI installation builds through 5216
Symptom: * Users hung after soft abend prm201
Description: RVSPRM was incorrectly branching to the soft abend
when a lock was granted with a delay. This was caused
by the lock call doing a BNZ on return from the lock
code. A test on R15 should have been done because the
lock routine wasn't setting the condition code. Because
the routine requesing the lock didn't think is was
granted it exited holding the lock and other request for
the lock hung.
Resolution: The routine requesting the lock was changed to test R15
and the BNZ was removed.
VT520086 VMARC 3/23/07 23:54:02 * Remove vdev from CFG data sequence number
Update VT520086 applies to VSSI installation builds through 5217
Symptom: * Error after redefining a tape drive vdev to a new number
Description: The vdev was set in the VTAPE vdev extension block when
a drive was defined. The value in the extension block
was used as part of the manufacture sequence number in
the Read Configuration Data returned for an RCD CCW.
This caused a problem for TPF when a drive number was
redefined and later defined at the redefined address.
Resolution: The vdev number is now set for non-shared drives when the
RCD is received so it always reflects the current vdev
number. For shared drives the vdev number is not stored
in the manufacture sequence number because each shared
drive is assigned a unique sequence number when it is
defined.
VT520081 VMARC 3/06/07 12:07:32 * Lockout VTXSHRLK&VTABQLK Unload from RVTCCW
Update VT520081 applies to VSSI installation builds through 5215
Symptom: *
VT520081 5200 VT52081 * Lockout VTXSHRLK&VTABQLK Unload from RVTCCW
Description: HCPIOV acquired the share lock to serialize a VTAPE I/O.
VTQUERY ACTIVE ALL acquired the mounted tape queue lock
to display mounted tapes
VTQUERY ACTIVE atempted to acquire the shared drive lock
for every drive with a mounted tape to list any
shared drives and was waiting for the lock acquired
by HCPIOV
HCPIOV called by RVTCCW to handle an unload CCW and
RVTCCW called RVTREW to unload the tape
RVTREW atempted to acquire the mounted tape queue lock to
remove the tape from the mounted tape queue causing
the interlock
Resolution: This is a fix for users that do not use the shared tape
drive feature of VTAPE which is 99.9% of users. The share
drive feature was developed for a small subset of VTAPE
users to test shared drives between multiple z/OS systems.
The problem is the share lock was being acquired whether
the drive was defined as eligible to be shared or not.
This update tests the VDEV to determine if it was defined
with the share option and never acquires the share lock
if the drive was not defined as sharable.
A second update is being designed to correct the interlock
described above for users that use shared VTAPE drives.
Two other interlock situations for shared drives reported
by users that don't use shared drives have already been
corrected but no shared drive user has ever reported a
problem.
VS520074 VMARC 1/26/07 2:58:36 * Convert err in IOR does not return to caller
Update VS520074 applies to VSSI installation builds through 5214
Problem: * After the development for the architecural changes in
z/VM 5.2 for some errors the VPARS and VTAPE I/O modules
did not return to the call but only stacked the I/O error
to the interrupt address. This caused a hung user
situation.
Resolution: The I/O modules now stack the I/O interrupt and return to
call as they should.
VP520072 VMARC 1/26/07 2:58:28 * Lock VPARS DB key for duration of open
Update VP520072 applies to VSSI installation builds through 5214
Problem: * A problem was reported where two users opening a VPARS
with coupled and clear was causing a failure in the
clear and a corrupded database. The current locking
structure of VPARS was not catching this problem.
Resolution: This update adds a symbolic lock of the database key to
VPARS and serializes VPOPEN so the second user opening
the VPARS database does enter open until the clear for
first user has completed.
VP520071 VMARC 1/14/07 19:19:37 * Nobase & REQOL IPL fails Bad CD data length
Update VP520071 applies to VSSI installation builds through 5212
Problem: * TPF IPL fails with IPL text on nobase VPARS database.
RVPCSP is incorrectly processing a chain data read of IPL
record 2 that is splits record 2 into two storage
locations.
Resolution: The routine for chain data CCWs in RVPCSP has been
corrected.
VP520070 VMARC 1/10/07 1:50:19 * HTT001 DDR TYPE Read HA 1A CCW not in ARMODE
Update VP520070 applies to VSSI installation builds through 5212
Problem: * HTT001 in RVPCSP processing a 1A Read Home Address CCW
during a DDR TYPE 0 0 0 to 0 0 3.
RVPCSP was entering normal AR (Access Register) mode and
then doing a test on the CCW the required full storage AR
mode.
Resolution: The switch of AR mode was moved to follow the test.
VP520065 VMARC 12/02/06 19:35:49 * SIT002,RVPCSP bits 0-31 not clred, 64 bit mode
Update VP520065 applies to VSSI installation builds through 5212
Problem: * SIT002 in RVPCSP processing a data chain move for track
zero I/O. Whe entering 64 bit mode register 2 was not
specified in the MAKE31B64 register list and it was used
in a move instruction. It appears register 2 had a value
in the high half of the register causing the SIT002 abend.
Resolution: Register 2 was added to the MAKE31B64 register list.
VS520061 VMARC 11/18/06 10:25:46 * CMS modules built incorrectly in z/VM 5.1
Update VS520061 applies to VSSI installation builds through 5213
Symptom: *
VS520061 5200 VS52061 * CMS modules built incorrectly in z?VM 5.1
Description: VSSI version 5.2 incorrectly builds its CMS modules
in a z/VM 5.1 install. The resulying modules have
missing entry points and fail with a PRG001.
Resolution: The VSSASM and VSCMSBLD EXECs were corrected to work in
both z/VM 5.1 and 5.2
VT520060 VMARC 11/18/06 10:25:42 * HTT001 HCPENTER BASEREG s/b HCPENTER GOTO
Update VT520060 applies to VSSI installation builds through 5213
Symptom: *
VT520060 5200 VT52060 * HTT001 HCPENTER BASEREG s/b HCPENTER GOTO
Description: Two CPEBK return points were set up as BASEREG
instead of GOTO for entry type. This caused an
HTT001 when the CPEBK was unstacked.
Resolution: The HCPENTER type was changed to GOTO
VT520055 VMARC 11/08/06 10:33:06 * LCK003/PRG004 during VTRUN command
Update VT520055 applies to VSSI installation builds through 5213
Symptom: *
VT520055 4200 VT40132 * LCK003/PRG004 during VTRUN command
Description: After update VT400078 08/20/2002 a VTRUN specifying
a userid of the current user as other user branched
to the wrong label and the VDEV block scan was not
done so R6 was invalid.
Resolution: The code was updated to branch to the correct label.
VS520054 VMARC 11/08/06 10:33:00 * HTT001 defer flag cleared prior to exit
Update VS520054 applies to VSSI installation builds through 5212
Symptom: HTT001, PRG004 and LCK001 abends in VPOPEN or VPADD.
Description: These errors started occuring for two users after they
upgraded to 2107/8300 Shark dasd. However one user
had the LCK001 failure on 2105 shark dasd. The problem
is caused by a synchronization/timing problem in the
VSSI synchronous I/O code. The only system change made
by the user that received the LCK001 on 2105 dasd was a
change in their allocation of main and xstore.
Resolution: The VSSI I/O routines have been change in the way they
handle stacking and processing of synchronous I/O
requests.
VT520053 VMARC 10/18/06 22:20:09 * Tape operator id for all VSSI CMS tape commands
Update VT520053 applies to VSSI installation builds through 5210
Symptom: * No facility to send tape messages to a tape operator
Description: VTBKUP and VTREST did not provide a facility to send
tape messages to a tape operator the way VPARS utilities
do.
Resolution: The OPerator keyword was added to VTBKUP and VTREST to
sent all mount, keep and intervention required messages
to a tape operator userid. OPerator userid
VP520048 VMARC 9/26/06 20:34:43 * PRG004 in RVPDBS during data chain move
Update VP520048 applies to VSSI installation builds through 5210
Problem: * PRG004 in RVPDBS processing a data chain move fo track
zero I/O. This only occurs in z/VM 5.1. with VSSI version
5.2. z/VM 5.2 never executes the failing code because
If always uses format 2 IDA words. Three instructions
in the failing code were using the wrong registers after
register changes in VSSI version 5.2.
Resolution: The three instructions were corrected to use the correct
registers.
VT520035 VMARC 7/16/06 11:46:24 * VTSABQLK not released during detach, lockout
Update VT520035 applies to VSSI install builds through 5208 for
VPARS and VTAPE users. 5209 for VTAPE only users.
Symptom: * Guests hung waiting for VTSABQLK lock.
Description: After update VT520023 was applied for an HTT001 problem
detach processing could exit without realeasing the
VTSABQLK. This caused all users that mounted a tape to
hang waiting for the lock.
Resolution: Change RVTSV2RS to always check for holding the VTSABQLK
before exiting.
VS520033 VMARC 6/28/06 13:14:09 * Rejcted I/O with SHARK in native mode
Update VS520033 applies to VSSI installation builds through 5208
Symptom: After IBM PTF H63855HP SLU UM31771 for PAV support all
VPARS and VTAPE CP CCW chains fail with a command reject
incorrect length indication on the Locate Record X'47'
CCW.
Description: The ESS(SHARK) control unit is set native mode after
PAV support is applied. VPARS and VTAPE were not
correctly setting up the I/O control blocks when the
control unit was set to native mode.
Resolution: VPARS and VTAPE no longer check the control unit type.
Support for any control unit that does not support
extended count, key, data has been removed.
VS520029 VMARC 6/21/06 7:53:28 * RVP/RVTIOR I/O error test invalid real address
Update VS520029 applies to VSSI installation builds through 5208
Problem: * I/O recovery fails in VPARS and VTAPE because compares
for the failing CCW are using virtual instead of real
storage addresses.
Resolution: The I/O error recovery code has been corrected to use
real storage addresses for the compares.
VP520028 VMARC 6/14/06 15:20:00 * Incorrect code for format write CCWs in 5.2
Update VP520028 applies to VSSI installation builds through 5206
Problem: * In z/VM 5.2 CCW chains that contain format write X'1D'
CCWs are being rejected by VPARS. Also X'9D' format
write next track CCWs were being ignored.
Resolution: The VSSI code that supports format write CCWs was
corrected and support for X'9D' CCWs was added. Code
was also added to display the CCWs for any CCW chain
rejected by VPARS. The code that displays the CCWs for
a rejected CCW is the same code used to display the CCW
chain when VPARS determins it is processing a chain
it can't support.
VP520025 VMARC 6/03/06 16:05:58 * sv1001 buffer lock not released fast enough
Update VP520025 applies to VSSI installation builds through 5206
Problem: * After update VP510021 a buffer could be released by the
directory split routine before all tasks waiting on the
buffer had released their shared lock causing an sv1001
abend.
Resolution: Check the buffer lock in the directory split code and
wait for all shared locks to be released.
VT520023 VMARC 5/30/06 10:30:10 * HTT001 in RVSUTLMS called by AMNTED2 in RVTSCR
Update VT520023 applies to VSSI install builds through 5206 for
VPARS and VTAPE users. 5207 for VTAPE only users.
Symptom: * HTT001/STK017 Abend. These failures can only occur for
VTAPE drives shared by multiple guests.
Description: An HTT001 can occur if a guest participating in a
shared VTAPE drive configuration detaches their drive
or logs off while a tape mounted by another user is on
the drive. VTAPE reset code does not always remove the
detached VDEV from the chain of shared drives. When a
VTSCR or VTQ ACT is later issued the code attmpts to
process the released control blocks causing the HTT001.
The STK017 can occur when a VTCLOSE or System SHUTDOWN
is done after a released block has been left on the
queue, when VTAPE attempts to unload the device for
close.
Resolution: VTAPE reset code was changed to always remove the
detached VDEV from the VDEV extension block queue.
Code was also changed to correct a locking error
between the VTAPE device reset code and VTSCR and VTQ
ACT. Code was also changed to correct an error where
a VTQ ACT did not show a user an active tape on a shared
drive if that user did not issue the mount.
VP520022 VMARC 5/07/06 22:57:02 * VPARS uses real cyl for record key on mdisk sys
Update VP520022 applies to VSSI installation builds through 5204
Problem: * In the processing rewrite for z/VM 5.2 VPARS is
incorrectly using the real cylinder number for the TPF
record key in the VPARS record directory. This does not
cause a problem for TPF systems that begin on cylinder
zero of the real disk because real = virtual. However
if the TPF system is mdisks that do not start on cylinder
zero the TPF records cannot be processed VPUTIL functions.
Resolution: VPARS was update to corrctly use the virtual cylinder
number.
VP520021 VMARC 5/05/06 22:26:46 * Rescan dir after directory read completes
Update VP520021 applies to VSSI installation builds through 5204
Problem: * This update corrects two errors in VPARS. The first is if
two requests enter RVPDBM for records that are in the
record directory and that RD needs to be read all requests
are defered until the RD read completes. The second is if
a shutdown is issued and a VPARS database is hung holding
the RDQ lock RVPSHU loops forever due to a incorrect
branch instruction.
Resolution: RVPDBM was updated to release the RDQ lock if the required
RD buffer is being read. RVPSHU was updated to correct
the invalid branch address.
VP520020 VMARC 5/05/06 13:08:39 * RVPRCC does not wait for sync to complete
Update VP520020 applies to VSSI installation builds through 5204
Problem: * VPARS reset RVPRCCRR does not wait for directory sync to
complete. A test for sync complete was incorrectly
coded in an update applied in 2001. A branch following
a TM for multiple was coded as BO instead on BNZ.
Resolution: The branch to wait for sync to complete was changed to
Branch Not Zero (BNZ).
VP520018 VMARC 4/12/06 18:39:11 * Change queue search default to NOGAL
Update VP520018 applies to VSSI installation builds through 5202
Problem: * ior004 and HTT001 abends using HCPGAL for VPARS queue
searches.
Resolution: Change the VPARS queue search default to SEARCH from GAL
as a circumvention until the problem can be resolved.
Search was the default in all VPARS versions prior to 5.2
and few if any users specified GAL in their config files.
VS520011 VMARC 4/04/06 0:46:39 * VSSI utilities enter CP after update VS520007
Update VS520011 applies to VSSI installation builds through 5203
Symptom: * CP mode is entered when a VSSI CMS command is issued
requiring a Begin to continue.
Description: Update VS520007 left an extra DIAG X'A8' in VSSUBR
causing CP mode to be entered.
Resolution: The extra DIAG X'A8' was deleted.
VS520007 VMARC 3/24/06 11:10:23 * Don't show set MDCACHE off messages
Update VT520007 applies to VSSI installation builds through 5200
Symptom: * MDCACHE set message for VSSI CMS commands.
Description: Code was added in VSSI version 5.2.0 to ensure MDISK
CACHE was off for VPARS amd VTAPE disks. The new code
caused a message to be issued for each mdisk being
processed.
Resolution: Code was added to suppress the CACHE messages.
VT520009 VMARC 3/22/06 18:16:19 * RVTQLB cleanup
Update VT520009 applies to VSSI installation builds through 5203
Symptom: * Logic errors in VTQuery LIbrary
Description: RVTQLB was doing mutiple scans of thr volume ranges
and reading directory blocks that were not required
for the requested volumes.
Resolution: Code in RVTQLB was was restructuredd to not scan the
ranges multiple times and only read required directory
blocks
VT520008 VMARC 3/22/06 18:16:15 * HTT001 abend in RVTQLB at +2D8
Update VT520008 applies to VSSI installation builds through 5203
Symptom: * HTT001 abend in RVTQLB
Description: RVTQLB was incorrectly setting up registers causing a
non CP owned page to be referenced.
Resolution: Code in RVTQLB was changed to correctly set up the
register
VS520001 VMARC 1/13/06 19:02:36 * VSSLTAPE no value error volser s/b tvolser
Update VS520001 applies to VSSI installation builds through 5200
Symptom: * A no value error we encountered in user code in the
VSSLTAPE EXEC.
Description: MSG2301 Mount was using volser as a variable and all other
tape messages were using tvolser for the variable. This
caused confusion in the user interface code to the tape
management system.
Resolution: Set both the tvolser and volser variables to the volume
serial for MSG2301. This will not cause existing user
code that uses the volser variable to break but will allow
the tvolser variable to be used for all tape message
entries.