VSSI Home    Product Support   

Release 55xx VPARS Updates

Last modified on 12/06/18
Current Package Build: 5524

VSSI

The PTFs below apply to the VSSI product version listed at the top of this page. As VSSI generates new packages (e.g., from 5522 to 5524), all outstanding updates are rolled into the new package version. You can determine your package version by running the VSQPKG exec on your VSSI Install disk; e.g.: . vsqpkg You can determine if a particular PTF is applicable for download and installation on your site, as follows: If your Package version is... Recommended Action . less than or equal to the Download and install the PTF. package build associated with the PTF . greater than the Ignore the PTF, since it package build associated is already incorporated into with the PTF your package. The update descriptions and apply instructions are in the prolog of the update file contained in the VMARC file on the 193 disk. Things to remember: 1. All PTFs specify a minimum version of the VSSI VSTOOLS package (i..e., the BUILD EXECs required to apply the PTF). The latest version of VSTOOLS VMARC can always be obtained via FTP from /193. You can check your installed VSSI package and VSTOOLS levels as follows: . VSQPKG (displays the current VSSI package build level) . VSQTOOLS (displays the current VSTOOLS version) 2. The VSPTF EXEC is used to install the PTF(s). This EXEC accepts VMARC files only. If specified with no parameters, VSPTF searches for VMARC PTF files on any accessed disk, evaluates them for inclusion, and installs any validated PTFs found. You can therefore download multiple PTFs and install them with a single VSPTF command. 3. The BUILD_Reqd: tag in the PTF summary specifies the user actions required after application of the PTF, as follows: TagID Actions to be taken VSSIPL . vsbldnuc . vscopy nuc . re-IPL VSSICP . vscopy nuc -or- vscopy parm . vscpx disable/enable -or- re-IPL VSSICMS . vscopy cms, vscopy help VSSMMAC Macro updates only; no action required Most PTFs have multiple BUILD_Reqd: tag values; in this case, take all actions required by all specified tags.

PTFs below apply to Packages at 5524 and lower

VP550386 VMARC 12/06/18 14:27:29 * Guest disabled wait loop

Update VP550386 applies to VSSI installation builds through 5524 Symptom: * Guest disabled wait loop Problem: Customer is running TPF in an MP guest (with 10 virtual CPUs) and using VPARS. The VPARS database fills. VPARS' response to that condition is to place the guest into a disabled wait (a condition VM's CP recognizes and stops further running of the guest). However, in this case the guest continues to run and continues to be repeatedly placed into a disabled wait. They must log the guest off to stop the disabled wait loop. The problem is in routine RVPSV1VS. It (correctly) obtains the local cyclic list lock in order to safely walk through the chain of the MP guest's virtual CPUs and then it (incorrectly) updates the PSW in each virtual CPU's SIEBK to place each of the guest's virtual CPUs into a disabled wait. However, at this point we only hold VMDBK dispatched serialization which allows us to update our own virtual CPU's PSW but not any of the PSWs of the guest's other virtual CPUs. On a system with multiple real CPUs, some (or all) of the guest's other virtual CPUs could be concurrently dispatched and in SIE. When they exit SIE the hardware updates their PSW (and registers) in the SIEBK thereby undoing our placing of the virtual CPU into disabled wait. As well it appears that TPF subsequently SIGPs the virtual CPUs that have been (successfully) placed into disabled wait to kickstart them and get them going again thus causing the cycle to repeat endlessly. Resolution: RVPSV1VS is updated to place the virtual CPU we are dispatched on into a disabled wait, and, if the guest is a virtual MP, to stack a second call to RVPSV1VS in console function mode (CFM). CFM serialization guarantees that only the CFM task is active and no other virtual CPUs are dispatched or in SIE, thus the PSWs in their SIEBKs can be safely updated. This is a very old bug, the code has been like this for 20 or more years. In the above discussions virtual CPU is synonymous with VMDBK. Real CPU is a real CPU. BUILD_Reqd: VSSICP Toolmin: 1.0 422 (2018-11-12) Modules: RVPRCC ASSEMBLE RVPSV1 ASSEMBLE

VP550385 VMARC 12/06/18 14:27:05 * VPOPEN fails with a large VPTPFDEV

Update VP550385 applies to VSSI installation builds through 5524 Symptom: * VPOPEN fails with a large VPTPFDEV Problem: Customer changed their procedure for creating their device table files. This resulted in a VPTPFDEV file with a large number of entries (110 records). At VPOPEN time, VPARS reads this file record by record into an internal control block with room for slightly more than 250 entries. As VPARS reads each record it wants to insert one in sorted order. With an unsorted VPTPFDEV file VPOPEN fails with the following error messages: VPOPEN failed with rc 3: RVSCFG011E File ........ VPTPFFMT C was not found. RVPIFC003E VPARS open failed This is a very old bug. The code has been like this for about 20 years. Resolution: The problem is in routine RVPPRC below label RVPPRC12. As it tries to make space to insert the new entry in its sorted position it uses an EX'ed MVC. Each entry is 16 bytes so the most entries that can be correctly moved with an EX'ed MVC is 16. If we had to move more than 16 entries to make room for the new entry we do it wrong. As a bypass the customer (manually) sorted the VPTPFDEV file so RVPPRC didn't have to sort the entries. Then the file was read correctly. RVPPRC has been updated to properly make space for each new entry. Additionally coalesce logic has been added. This will allow a VPTPDEV file to be created with one record for each device and still not exceed the maximum of 251 entries in the device table. Finally, updates from a number of other VPARS parts with pending minor refactoring have been included. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 422 (2018-11-12) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE VPBLDFMT ASSEMBLE VPFMT ASSEMBLE

VP550383 VMARC 12/06/18 14:25:23 * Write Track Data (0xA5) chaining errors

Update VP550383 applies to VSSI installation builds through 5524 Symptom: * Write Track Data (0xA5) chaining errors Problem: Recent ShadowDisk CCW translation has problems with Write Track Data (0xA5) CCWs. RVDCSP builds a CCW chain containing one entry for each record on the track to be written by the intercepted A5 CCW. The current CHAINCCW structure currently allows for a maximum of 8 records to be processed in response to the A5 CCW, when a maximum of 12 are required. The result is an incomplete CCW chain, which causes soft ABENDs. Resolution: CHAINCCW modified to hold a maximum of 12 record entries per A5/A6 CCW. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 422 (2018-11-12) Modules: VPCHCCW COPY

VP550381 VMARC 12/06/18 14:23:49 * dbs007 if CP allocates IORBK on real page 7FFFFxxx

Update VP550381 applies to VSSI installation builds through 5524 Symptom: * dbs007 if CP allocates IORBK on real page 7FFFFxxx Problem: RVPDBS is checking the address portion of a translated CCW against PFXPGNUM (7FFFF000). If the address is not less than that the CCW is rejected. CP has allocated an IORBK on a host logical page that has been mapped to host absolute page 7FFFFxxx. The translated CCW for the Define Extent points to the IORDEXNT field in the IORBK resulting (in this case) the CCW having host host absolute address 7FFFF558 which is above 7FFFF000 resulting in the I/O being rejected and a dbs007 soft abend. This is is a very old bug, these tests have been in place for approximately 20 years. Resolution: RVPDBS is updated to delete the checks. That address was invalid for an ESA guest address. It is not invalid as a host address. BUILD_Reqd: VSSICP Toolmin: 1.0 422 (2018-11-12) Modules: RVPDBS ASSEMBLE

VS550380 VMARC 11/12/18 11:38:29 * ccw001 abend while VPFMT'ing a pool disk

Update VS550380 applies to VSSI installation builds through 5524 Symptom: * ccw001 abend while VPFMT'ing a pool disk Problem: ccw001 hard abend while VPFMTing a VPARS pool minidisk. VPARS thought it should intercept the formatting I/Os but the guest did not have a VPARS database open yet. Resolution: Three issues are being addressed by this fix. First, the reported ccw001 is resolved by updating VSCKVDEV so it expands properly in HCPIOS. Second, we have finally been able to diagnose a long standing problem with pages missing from soft abend dumps. IBM has taken APAR VM66218 and will supply a PTF for 7.1. Customers on 7.1 should apply the PTF for that APAR when it is available. Included here is an update to HCPABH to address the problem for our customers on 6.3 and 6.4. Thirdly, a VSSI option is added to TRSOURCE to enable TRSOURCEing against CPXLOADed code. Lastly, minor refactoring and preparatory changes for subsequent updates have been done to common parts and various control blocks. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 422 (2018-11-12) Modules: VSMODID COPY RVSCBI ASSEMBLE RVSCMD ASSEMBLE RVSMSG ASSEMBLE RVSSTA ASSEMBLE RVSUTL ASSEMBLE RVSVPY ASSEMBLE

VP550379 VMARC 11/12/18 11:25:36 * ccw001 abend while VPFMT'ing a pool disk

Update VP550379 applies to VSSI installation builds through 5524 Symptom: * ccw001 abend while VPFMT'ing a pool disk Problem: ccw001 hard abend while VPFMTing a VPARS pool minidisk. VPARS thought it should intercept the formatting I/Os but the guest did not have a VPARS database open yet. Resolution: For VPARS this is a refactoring only update. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 422 (2018-11-12) Modules: RVPEQUAT COPY RVPFMTBK COPY VPCHCCW COPY VPCTLBK COPY VPTCCTBK COPY VP1WRKBK COPY

VT550379 VMARC 11/11/18 09:38:47 * ccw001 abend while VPFMT'ing a pool disk

Update VT550379 applies to VSSI installation builds through 5524 Symptom: * ccw001 abend while VPFMT'ing a pool disk Problem: ccw001 hard abend while VPFMTing a VPARS pool minidisk. VPARS thought it should intercept the formatting I/Os but the guest did not have a VPARS database open yet. Resolution: For VTAPE this is a refactoring only update. BUILD_Reqd: VSSIPL Toolmin: 1.0 421 (2018-11-07) Modules: VT55MAC $EXEC RVTEQUAT COPY RVTSALIB COPY RVTSYSBK COPY VTACTBK COPY VTBMAPBK COPY VTEXTBK COPY VTIOTBK COPY VTMDSKBK COPY VTMNTBK COPY VTOPRMBK COPY VTSCRBK COPY VTSCTLBK COPY VTVDSCBK COPY VTXRELBK COPY VTCPYASM ASSEMBLE

VS550379 VMARC 11/12/18 11:10:33 * ccw001 abend while VPFMT'ing a pool disk

Update VS550379 applies to VSSI installation builds through 5524 Symptom: * ccw001 abend while VPFMT'ing a pool disk Problem: ccw001 hard abend while VPFMTing a VPARS pool minidisk. VPARS thought it should intercept the formatting I/Os but the guest did not have a VPARS database open yet. Resolution: Three issues are being addressed by this fix. First, the reported ccw001 is resolved by updating VSCKVDEV so it expands properly in HCPIOS. Second, we have finally been able to diagnose a long standing problem with pages missing from soft abend dumps. IBM has taken APAR VM66218 and will supply a PTF for 7.1. Customers on 7.1 should apply the PTF for that APAR when it is available. Included here is an update to HCPABH to address the problem for our customers on 6.3 and 6.4. Thirdly, a VSSI option is added to TRSOURCE to enable TRSOURCEing against CPXLOADed code. Lastly, minor refactoring and preparatory changes for subsequent updates have been done to common parts and various control blocks. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 422 (2018-11-12) Modules: VS55MAC $EXEC RVSCHKPR COPY VSCFGBK COPY VSMODID COPY VSMSGPBK COPY VSSECTOR COPY VSCKVDEV MACRO VSIPROLG MACRO VSMSGH MACRO RVSSTL LAS55379

VT550378 VMARC 10/17/18 13:50:19 * END on MDISK statement allows EAV in library

Update VT550378 applies to VSSI installation builds through 5524 Symptom: * END on MDISK statement allows EAV in library Problem: Fix VT550357 fenced EAV minidisks to keep them from being part of a VTAPE library. It is possible to sneak a minidisk with EAV cylinders into the library if the ending cylinder is specified as END rather than an actual cylinder number. Resolution: VTAPE is updated to properly validate a library minidisk that has END specified. A volume defined with via DEVNO rather than cylinder or block range is likewise not valid as a library disk. Further, while researching this, it was found that everytime a VTAPE library was VTOPENed or a disk was added to an existing open library with VTADD the LKBK allocated was orphaned rather than being fret'ed. This is a very minor storage cancer with one orphaned LKBK for each minidisk in each open library. RVTOCS has been updated to fret the LKBK upon completion of LINKing each library disk. This is a very old bug. BUILD_Reqd: VSSICP Toolmin: 1.0 420 (2018-10-08) Modules: RVTOCS ASSEMBLE RVTSV5 ASSEMBLE

VT550377 VMARC 10/05/18 12:02:03 * VTAPE ASR001 abends with SET CPCHECKING ON

Update VT550377 applies to VSSI installation builds through 5524 Symptom: * VTAPE ASR001 abends with SET CPCHECKING ON Problem: A couple VTAPE modules are failing assertions when running with SET CPCHECKING ON. We are seeing an ASR001s in RVTSV5 because a register isn't pointing to an expected control block and in RVTSV1 when a lock is not held. Resolution: RVTSV5 is updated to check the correct register. RVTSV1 is updated to not check the lock. It was expected to be held here. Minor code refactoring has been done on other VTAPE parts reviewed while investigating this. BUILD_Reqd: VSSICP Toolmin: 1.0 419 (2018-10-14) Modules: RVTIOR ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTPRC ASSEMBLE RVTSCR ASSEMBLE RVTSV1 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VS550375 VMARC 10/05/18 11:38:32 * Show BUILD date via VSQUERY VSLEVEL

Update VS550375 applies to VSSI installation builds through 5524 Symptom: * Show BUILD date via VSQUERY VSLEVEL Problem: The current VSQuery VSLevel command displays: ------------------------------------ Value Example ------------------------------------ Build version 5500 Build level 5524 PTF level 550374 Package generation date 8 Feb 2017 z/VM release 6.4.0 ------------------------------------ The package generation date is the date that VSSI generated the product package (i.e., not very informative). Several customers have requested that we show the actual BUILD date (i.e., the date when the customer built/updated the system as a result of PTFCUM application and VSCOPY command execution). Resolution: The value in "package generation date" above has been replaced by the customer build date; i.e., VSQ VSL will now show when the system was rebuilt. BUILD_Reqd: VSSICP Toolmin: 1.0 419 (2018-10-14) Modules: RVSCMD ASSEMBLE

VP550374 VMARC 10/04/18 10:08:49 * Possible HTT001 displaying periodic status

Update VP550374 applies to VSSI installation builds through 5524 Symptom: * Possible HTT001 displaying periodic status Problem: A customer was testing the 550373 code level. They run their test system with SET CPCHECKING ON which activates any HCPASERTs. They took an ASR001 abend in RVPQY3ST due to a failed assert. The assert that failed was: HCPASERT CB,BLOCK=VPCTLBK,GR=R9 and R9 was pointing to a fret'ed VPCTLBK. The call to RVPQY3ST with the stale R9 value originated in the database timer task. It was supposed to display the periodic automatic database status. Problem was - at the exact same instant the database timer task stacked the call to RVPQY3ST the user issued VPCLOSE. Commands (eg: VPCLOSE) always run under console function mode (CFM) serialization. Since the periodic automatic database status is the moral equivalent of a VPQUERY STATUS command it is stacked as a call with CFM. Only one CFM task can be active at a time. The VPCLOSE got in first and the VPQUERY STATUS was forced to wait until it completed at which point the database had been closed resulting in the stacked call having a stale database pointer in R9. This resulted in the ASR001 due to CPCHECKING being active. In a production environment if the page R9 was pointing to had been marked invalid an HTT001 would have resulted. If the page was still valid, the VPQUERY STATUS would display incorrect results. Resolution: Rather than call RVPQY3ST directly, the database timer task is updated to call a new entry point RVPQY3AS. RVPQY3AS will verify the database is still open and hence that R9 remains valid and then it will call RVPQY3ST. If the database is no longer open, RVPQY3AS simply returns and the periodic automatic database status is not done (which is fine, a final status was issued as part of VPCLOSE processing). BUILD_Reqd: VSSICP Toolmin: 1.0 417 (2018-08-08) Modules: RVPCCW ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPQY3 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VP550373 VMARC 09/28/18 12:32:37 * Various csp007 soft abends

Update VP550373 applies to VSSI installation builds through 5524 Symptom: * Various csp007 soft abends Problem: Fix VP550342 added a USERSTATE=NOCHANGE soft abend to a code path where we were reflecting an I/O error to a guest. At this point in the code, it is most likely we are reflecting an I/O error not because there was something wrong with the guest's I/O but because VPARS was unable to simulate it properly (eg: this is a VSSI error not a guest error). Formerly an error message had been issued here but there is no point in issuing an error message if the user can do nothing to fix the problem, hence the change to a soft abend. Further, we had had none of these error messages reported to us in the preceding several years so it was believed these errors were very rare. Resolution: They turned out not to be so rare after all. If we've learned anything it is that users will ignore error messages, but systems programmers will not ignore dumps. We have had several csp007 soft abends submitted. This fix is addressing all the problems we have seen thus far. First, we were reflecting an I/O error when a guest's VPARS database filled. This does not indicate an error in VPARS code so the dump will be suppressed in this case. Second, we were reflecting an error if the length in the CCW was zero. Zero is an invalid length if the CCW is format 0, but this was a format 1 CCW so the length of zero is valid and is now recognized as such. Third, we were reflecting an error when the host absolute address of the storage where CP had translated the guest's CCWs into exactly matched the host logical address of the storage VPARS had allocated as a CCW work area. Although the addresses are the same they do not represent the same storage location. The code is updated to properly differentiate between these two addresses. BUILD_Reqd: VSSICP Toolmin: 1.0 417 (2018-08-08) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE

VT550372 VMARC 09/21/18 16:42:16 * System hung - hard loop in RVTCON

Update VT550372 applies to VSSI installation builds through 5524 Symptom: * System hung - hard loop in RVTCON Problem: The problem reported by VT550343 was corrected by reverting part of VT550027's fix. Part of that reversion in RVTCON was incorrect resulting in in a loop when a VTQ ACT command was issued. Resolution: RVTCON has been updated to correct the loop. Additionally a number of other VTAPE parts with pending minor refactoring have been included in this fix. BUILD_Reqd: VSSICP Toolmin: 1.0 417 (2018-08-08) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY2 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VP550371 VMARC 09/07/18 12:26:51 * VPLINK errors after VP550342

Update VP550371 applies to VSSI installation builds through 5524 Symptom: * VPLINK errors after VP550342 Problem: After VP550342 is applied, VPLINK commands fail in two different ways; e.g., VPLINK 3390 1 may result in one of the following: . RVPCON013E 3390 is an invalid option . RVPCON050E No pool disks of the requested type and size are available Resolution: VP550342 revised the option parsing in RVPCON so it used logic similar to other VPARS modules. This introduced the above noted regression and has been corrected. Additionally, a number of half-word operations (such as those performed against VDEV values) were unsafe, and hence modified. Arithmetic instructions were used, which treated things like minidisk device numbers and cylinder ranges as signed values when they should be considered unsigned. Logical instructions are now used. BUILD_Reqd: VSSICP Toolmin: 1.0 417 (2018-08-08) Modules: RVPCON ASSEMBLE

VP550370 VMARC 07/25/18 15:24:48 * Soft abend throttling

Update VP550370 applies to VSSI installation builds through 5524 Symptom: * Soft abend throttling Problem: Add clarifying comments to several control blocks. Resolution: Add clarifying comments to several control blocks. BUILD_Reqd: VSSMMAC Toolmin: 1.0 414 (2018-07-14) Modules: VPTCCTBK COPY VPUSERBK COPY

VT550370 VMARC 07/25/18 15:25:30 * Soft abend throttling

Update VT550370 applies to VSSI installation builds through 5524 Symptom: * Soft abend throttling Problem: Add clarifying comments to several control blocks. Resolution: Add clarifying comments to several control blocks. BUILD_Reqd: VSSMMAC Toolmin: 1.0 414 (2018-07-14) Modules: VTSCTLBK COPY

VS550370 VMARC 07/25/18 15:23:45 * Soft abend throttling

Update VS550370 applies to VSSI installation builds through 5524 Symptom: * Soft abend throttling Problem: If a second soft abend comes in before the first has completed CP "upgrades" the second abend to hard. This is done because soft abend creation makes use of some static work areas. These static work areas are only serially reusable. If they are in use by the first dump they are unavailable for the second dump. The solution to this paradox chosen by the CP developers was to hard abend if the static work areas are already in use. When a soft abend is issued, if the issuer can tolerate a loss of control they take the default of synchronous processing. If they can not tolerate a loss of control they specify asynchronous processing. There is no need to turn the soft abend into a hard abend if the abending task can tolerate a loss of control. Just delay until the first abend has completed. Resolution: When a soft abend is in the processing of being created and a second one comes in, HCPABNDS is updated to check whether synchronous or asynchronous processing was requested. If asynchronous the second abend becomes a hard abend as is done today. If synchronous, the abending thread is delayed until the active dump completes and then it creates the requested soft abend. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 414 (2018-07-14) Modules: VSMODID COPY RVSCMD ASSEMBLE RVSPRM ASSEMBLE

VP550369 VMARC 07/23/18 10:11:34 * Deadlock after VP550350/PRG001 in RVPSET after VP5

Update VP550369 applies to VSSI installation builds through 5524 Symptom: * Deadlock after VP550350/PRG001 in RVPSET after VP550342 Problem: Two problems are being addressed. The first is many users hung. Some users go logoff/force pending if they try to log off. A restart dump was taken and the system re-IPLed to recover. Analysis of the dump indicates it is a VPARS problem. Many users are wanting the VP6VPCLK lock. This lock protects the chain of control blocks representing open VPARS databases. USERA has issued: VPQUERY STATUS USER USERB The VPQUERY command is processed in module RVPCQY and the first thing it does when starting a VPQUERY is obtain a share on the VP6VPCLK lock. Now, because the query is for another user, USERA also wants to obtain CFM serialization on USERB to ensure they don't change something about their database during query processing. USERA has called HCPCFMAN to annex CFM on USERB. Meanwhile at the exact same instance USERB has issued: VPCLOSE NORESET All commands run with CFM serialization so USERB holds CFM on themselves. Because they are closing their database they need to remove it from the chain of open databases and so try and get the VP6VPCLK lock exclusive. That lock is held shared by USERA who will not release it until it gets CFM on USERB. USERB will not exit CFM until it gets the VP6VPCLK which USERA holds. Textbook deadlock situation. The timing must be absolutely perfect for this to happen. If USERA or USERB had issued their command a fraction of a second either way this wouldn't have happened. The second is a possible ABEND PRG001 due to a wild branch in RVPSET after fix VP550342. A branch table was shared by both the VPFCLOSE command and the VPSET MAXDBUSERS command causing VPFCLOSE to take a wild branch. Resolution: RVPCQY is updated to wait until it has annexed CFM on any potential target of the query before obtaining a share of the VP6VPCLK lock. RVPSET is updated so VPFCLOSE uses its own branch table. BUILD_Reqd: VSSICP Toolmin: 1.0 414 (2018-07-14) Modules: RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPIFC ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPPRC ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE

VP550368 VMARC 07/12/18 10:10:28 * Excessive ccw006 soft abends

Update VP550368 applies to VSSI installation builds through 5524 Symptom: * Excessive ccw006 soft abends Problem: Fix 550342 added a USERSTATE=NOCHANGE soft abend when an I/O error occurs against the VPARS database. The belief was that I/O errors were rare events and a soft abend was the best way to capture the data needed to diagnose an I/O error. When the VPARS database hits 100% an I/O error is generated in response. It was not anticipated that some sites would run with VPARS databases close to capacity with a database full condition being a routine event. These sites are seeing excessive ccw006 soft abends. Resolution: RVPCCW has been updated to skip ccw006 soft abends when the reason for the I/O error is the VPARS database hitting 100%. BUILD_Reqd: VSSICP Toolmin: 1.0 413 (2018-07-05) Modules: RVPCCW ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPEXT ASSEMBLE RVPPRC ASSEMBLE

VT550367 VMARC 07/12/18 10:09:31 * PRG004 in RVTLD1 after fix VT550359

Update VT550367 applies to VSSI installation builds through 5524 Symptom: * PRG004 in RVTLD1 after fix VT550359 Problem: In addition to the storage management change VT550359 updated how the return code was initialized for three entry points in RVTLD1. A coding error in the revised initialization code resulted in an attempt to store into low storage. Resolution: RVTLD1 is updated to correct the coding error. A number of other routines have had code clarification done. BUILD_Reqd: VSSICP Toolmin: 1.0 413 (2018-07-05) Modules: RVTCMD ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTOPC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTSCR ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE

VS550366 VMARC 06/20/18 11:21:24 * Assembly errors in HCPCBI after 550358

Update VS550366 applies to VSSI installation builds through 5524 Symptom: * Assembly errors in HCPCBI after 550358 Problem: Assembly errors in HCPCBI after fix 550358. Resolution: HCPCBI is an OCO module so the design of 550358 did not take it into consideration. However, some VSSI customers have source for HCPCBI and get an assembly error when re-assembling it after 550358 has been applied. Revise the update to the IDOFFSET MACRO to take into consideration an expansion during an assembly of HCPCBI. BUILD_Reqd: VSSMMAC Toolmin: 1.0 412 (2018-06-12) Modules: VSMODID COPY

VS550365 VMARC 06/18/18 16:53:28 * RVSSTL contains release specific code

Update VS550365 applies to VSSI installation builds through 5524 Symptom: * RVSSTL contains release specific code Problem: RVSSTL must contain only generic code that can run at any site without being re-assembled. After 550358 it contained code (the HCPGETST and HCPRELST expansions) that were tied to the release and service level it was assembled on. Resolution: RVSUTL is updated to provide a service routine that can obtain and release the control block needed by RVSSTL. RVSSTL is updated to use this service routine. RVSCMD is updated to have a new VSQ LICense command as an alternative to VSLSHOW. BUILD_Reqd: VSSICP Toolmin: 1.0 412 (2018-06-12) Modules: VSMODID COPY RVSCMD ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55365

VP550364 VMARC 06/18/18 12:49:58 * HTT001 during VPARS database close

Update VP550364 applies to VSSI installation builds through 5524 Symptom: * HTT001 during VPARS database close Problem: An MP guest had issued a VPOPEN from a virtual CPU that was not its base CPU (aka a secondary VMDBK). As part of VPOPEN processing VPARS retains the address of the VMDBK that opened the database. Subsequently the user logs off so VM disposes of the secondary CPUs and then starts termination of the base/primary CPU. Since the user has a VPARS database open VPARS is called to close the database the user has open. As part of close processing VPARS attempts to stack a final sync call on the VMDBK that opened the database (using the VMDBK address it saved at open time). Since that was not the primary CPU for the guest that CPU is already gone when VPARS attempts to stack work on it. CP storage management has marked the (former) VMDBK page as invalid so the HTT001 results. If the page had not been marked invalid, it is likely a STK017 would have happened instead. It is possible that VP550287's change may have exacerbated this. In the above discussion CPU and VMDBK have been used interchangeably. Resolution: RVPOPS is updated to save the VMDBASE VMDBK address at open time. This CPU will always be around at close time. Additionally minor code refactoring was performed on another dozen or so parts. In the above discussions CPU and VMDBK have been used interchangeably. BUILD_Reqd: VSSICP Toolmin: 1.0 412 (2018-06-12) Modules: RVPBUF ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBM ASSEMBLE RVPMSG ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE

VP550363 VMARC 06/11/18 22:39:10 * Soft abend diagnostic changes

Update VP550363 applies to VSSI installation builds through 5524 Symptom: * Soft abend diagnostic changes Problem: A number of soft abends have come in with insufficient information to allow them to be solved. Resolution: The soft abend logic in RVPDBT has been re-worked so the soft abends are taken closer to when the error is detected. RVPSV1OB/RB (obtain and release buffers) now cut private trace entries to allow us to see buffer usage. RVPSV1OB also does additional checking before returning a buffer. As a result we may now see an sv1002 soft abend were in the past we had a dbt002. Again this is detecting the problem earlier. RVPRCC is updated to return all buffers via RVPSV1RB. This fixes a minor storage leak. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 411 (2018-06-06) Modules: RVPCCW ASSEMBLE RVPCLR ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPOPN ASSEMBLE RVPPRC ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE VPUNLD ASSEMBLE

VP550362 VMARC 06/11/18 16:05:37 * Private trace table infrastructure

Update VP550362 applies to VSSI installation builds through 5524 Symptom: * Private trace table infrastructure Problem: Problems that result in a soft abend can be difficult to diagnose due to the limited data available. Private trace tables for VSSI components would help by providing a fuller picture of the problem. Resolution: MACRO and COPY file changes in support of the above. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 411 (2018-06-06) Modules: RVPEQUAT COPY VPBXAHDR COPY VPCHCCW COPY VPCTLBK COPY VPIOTBK COPY VPMDSKBK COPY VPTPFKEY COPY RVPSCFBK MACRO

VT550362 VMARC 06/11/18 16:11:53 * Private trace table infrastructure

Update VT550362 applies to VSSI installation builds through 5524 Symptom: * Private trace table infrastructure Problem: Problems that result in a soft abend can be difficult to diagnose due to the limited data available. Private trace tables for VSSI components would help by providing a fuller picture of the problem. Resolution: MACRO and COPY file changes in support of the above. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 411 (2018-06-06) Modules: RVTEQUAT COPY VTIOTBK COPY

VS550362 VMARC 06/11/18 15:45:39 * Private trace table infrastructure

Update VS550362 applies to VSSI installation builds through 5524 Symptom: * Private trace table infrastructure Problem: Problems that result in a soft abend can be difficult to diagnose due to the limited data available. Private trace tables for VSSI components would help by providing a fuller picture of the problem. Resolution: The needed infrastructure to utilize private trace tables is provided. During system initialization, three private trace tables are opened. One for common parts, one for VPARS and one for VTAPE. Subsequent updates to those components will result in trace entries being added to those trace tables at key points. Additionally CP's soft abend dump generation logic is updated to include the VSSI private trace tables in any soft abend dump taken. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 411 (2018-06-06) Modules: VS55MAC $EXEC RVSEQUAT COPY VSMODID COPY VSQIOBK COPY VSSITRAC COPY VSIPROLG MACRO RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTN ASSEMBLE RVSSTL LAS55362

VP550361 VMARC 06/11/18 12:35:25 * Deprecate VSICALL, VSIGOTO and VSIABEND

Update VP550361 applies to VSSI installation builds through 5524 Symptom: * Deprecate VSICALL, VSIGOTO and VSIABEND Problem: Years ago these VSSI macros provided some extra function over and above the base VM macros. The base VM macros have been repeatedly enhanced over the years and now the VSSI macros simply invoke the base VM macros. Resolution: Since the VSSI macros no longer provide any value add they are deprecated and replaced with the base VM macros. This change is refactoring work. There is no functional change. In most cases text decks compare before and after. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 411 (2018-06-06) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE VPBXRCTL ASSEMBLE

VT550361 VMARC 06/11/18 12:35:32 * Deprecate VSICALL, VSIGOTO and VSIABEND

Update VT550361 applies to VSSI installation builds through 5524 Symptom: * Deprecate VSICALL, VSIGOTO and VSIABEND Problem: Years ago these VSSI macros provided some extra function over and above the base VM macros. The base VM macros have been repeatedly enhanced over the years and now the VSSI macros simply invoke the base VM macros. Resolution: Since the VSSI macros no longer provide any value add they are deprecated and replaced with the base VM macros. This change is refactoring work. There is no functional change. In most cases text decks compare before and after. BUILD_Reqd: VSSICP Toolmin: 1.0 411 (2018-06-06) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTL00 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VS550360 VMARC 06/09/18 08:53:50 * Deprecate VSICALL, VSIGOTO and VSIABEND

Update VS550360 applies to VSSI installation builds through 5524 Symptom: * Deprecate VSICALL, VSIGOTO and VSIABEND Problem: Years ago these VSSI macros provided some extra function over and above the base VM macros. The base VM macros have been repeatedly enhanced over the years and now the VSSI macros simply invoke the base VM macros. Resolution: Since the VSSI macros no longer provide any value add they are deprecated and replaced with the base VM macros. This change is refactoring work. There is no functional change. In most cases text decks compare before and after. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 411 (2018-06-06) Modules: VSMODID COPY VSCPXGT MACRO VSMSGH MACRO VSMSGHMR MACRO VSMSGHMS MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE RVSSTL LAS55360

VP550359 VMARC 06/08/18 15:06:46 * Storage management changes - exploitation

Update VP550359 applies to VSSI installation builds through 5524 Symptom: * Storage management changes - exploitation Problem: - VSSI's storage management is not as efficient as possible - VSSI is unable to make use of the HCPASERT facility to assert our control blocks Resolution: Fix 550358 laid the groundwork to allow VSSI control blocks to be allocated by HCPGETST with ID= specified. A block must be allocated in this manner in order to make use of the HCPASERT CB parameter. This fix exploits those changes in the VPARS code base. All storage is now obtained/released via HCPGETST/HCPRELST for maximum efficiency. Customers that review our source code changes will have seen, over the past couple of years, numerous HCPASERT statements added that were commented out similar to this: *someday HCPASERT CB,BLOCK=VPCTLBK,GR=R9 Well - someday has finally arrived and all those HCPASERT have been uncommented and made active. The assert facility will help us improve our code robustness. Additionally allocating storage in this manner will help with debugging from a dump as the free storage trailer now contains the block identifier and the module that obtained/released the storage. Finally the reduced path length from switching to HCPGETST/HCPRELST may be measurable on a busy VPARS system. BUILD_Reqd: VSSICP Toolmin: 1.0 411 (2018-06-06) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPL00 ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VT550359 VMARC 06/08/18 15:06:51 * Storage management changes - exploitation

Update VT550359 applies to VSSI installation builds through 5524 Symptom: * Storage management changes - exploitation Problem: - VSSI's storage management is not as efficient as possible - VSSI is unable to make use of the HCPASERT facility to assert our control blocks Resolution: Fix 550358 laid the groundwork to allow VSSI control blocks to be allocated by HCPGETST with ID= specified. A block must be allocated in this manner in order to make use of the HCPASERT CB parameter. This fix exploits those changes in the VTAPE code base. All storage is now obtained/released via HCPGETST/HCPRELST for maximum efficiency. Customers that review our source code changes will have seen, over the past couple of years, numerous HCPASERT statements added that were commented out similar to this: *someday HCPASERT CB,BLOCK=VTACTBK,GR=R8 Well - someday has finally arrived and all those HCPASERT have been uncommented and made active. The assert facility will help us improve our code robustness. Additionally allocating storage in this manner will help with debugging from a dump as the free storage trailer now contains the block identifier and the module that obtained/released the storage. Finally the reduced path length from switching to HCPGETST/HCPRELST may be measurable on a busy VTAPE system. BUILD_Reqd: VSSICP Toolmin: 1.0 411 (2018-06-06) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTL00 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE RVTTBL ASSEMBLE

VP550358 VMARC 06/08/18 13:56:35 * Storage management changes - infrastructure

Update VP550358 applies to VSSI installation builds through 5524 Symptom: * Storage management changes - infrastructure Problem: - VSSI's storage management is not as efficient as possible - VSSI is unable to make use of the HCPASERT facility to assert our control blocks Resolution: This fix lays the groundwork to allow VSSI control blocks to be allocated by HCPGETST with ID= specified. A block must be allocated in this manner in order to make use of the HCPASERT CB parameter. The common parts (RVSxxx) are updated to use HCPGETST/HCPRELST for their storage management calls. A subsequent fix will exploit this change in VPARS and VTAPE. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 411 (2018-06-06) Modules: RVPCCTBK COPY RVPCFGBK COPY RVPCMPBK COPY RVPEXCBK COPY RVPSYSBK COPY VPCHCCW COPY VPCTLBK COPY VPIOCBK COPY VPOPENBK COPY

VT550358 VMARC 06/08/18 14:50:08 * Storage management changes - infrastructure

Update VT550358 applies to VSSI installation builds through 5524 Symptom: * Storage management changes - infrastructure Problem: - VSSI's storage management is not as efficient as possible - VSSI is unable to make use of the HCPASERT facility to assert our control blocks Resolution: This fix lays the groundwork to allow VSSI control blocks to be allocated by HCPGETST with ID= specified. A block must be allocated in this manner in order to make use of the HCPASERT CB parameter. The common parts (RVSxxx) are updated to use HCPGETST/HCPRELST for their storage management calls. A subsequent fix will exploit this change in VPARS and VTAPE. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 411 (2018-06-06) Modules: RVTCMPBK COPY RVTEQUAT COPY RVTEXCBK COPY RVTSYSBK COPY VTBMAPBK COPY VTDATABK COPY VTEXTBK COPY VTIOCBK COPY VTLSTBK COPY VTSCTLBK COPY VTVDSCBK COPY VT9CFDAT COPY VT9CFGBK COPY VT6ANCH MACRO

VS550358 VMARC 06/08/18 13:29:58 * Storage management changes - infrastructure

Update VS550358 applies to VSSI installation builds through 5524 Symptom: * Storage management changes - infrastructure Problem: - VSSI's storage management is not as efficient as possible - VSSI is unable to make use of the HCPASERT facility to assert our control blocks Resolution: This fix lays the groundwork to allow VSSI control blocks to be allocated by HCPGETST with ID= specified. A block must be allocated in this manner in order to make use of the HCPASERT CB parameter. The common parts (RVSxxx) are updated to use HCPGETST/HCPRELST for their storage management calls. A subsequent fix will exploit this change in VPARS and VTAPE. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 411 (2018-06-06) Modules: VS55MAC $EXEC RVSCMPBK COPY VSCFGBK COPY VSDATEFM COPY VSMDEBK COPY VSMODID COPY VSSICBID COPY RVSMDLAT MACRO RVSMDLAX MACRO VSMSGH MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSL00 ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE RVSSTB ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55358

VP550357 VMARC 04/30/18 10:25:17 * Fence EAV minidisks

Update VP550357 applies to VSSI installation builds through 5524 Symptom: * Fence EAV minidisks Problem: As of APARs VM65943 and VM65945 VM now supports minidisks on real cylinders above 65519. VSSI has no support for VTAPE libraries or VPARS databases to reside on EAV cylinders. Resolution: The following commands have been updated: VPFMT, VPADD, VPOPEN, VTFMT, VTADD and VTOPEN For CKD DASD they verify that any minidisks involved are not on EAV cylinders. For FBA DASD they verify the minidisk starts on an 8 block boundary, its size is a multiple of 8 and it is wholly contained below real block 134217720 (64GB-1). If any check fails an error message is issued and the respective command fails. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 410 (2018-04-10) Modules: RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPRCC ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE VPBXREF ASSEMBLE VPFMT ASSEMBLE

VT550357 VMARC 04/30/18 10:25:26 * Fence EAV minidisks

Update VT550357 applies to VSSI installation builds through 5524 Symptom: * Fence EAV minidisks Problem: As of APARs VM65943 and VM65945 VM now supports minidisks on real cylinders above 65519. VSSI has no support for VTAPE libraries or VPARS databases to reside on EAV cylinders. Resolution: The following commands have been updated: VPFMT, VPADD, VPOPEN, VTFMT, VTADD and VTOPEN For CKD DASD they verify that any minidisks involved are not on EAV cylinders. For FBA DASD they verify the minidisk starts on an 8 block boundary, its size is a multiple of 8 and it is wholly contained below real block 134217720 (64GB-1). If any check fails an error message is issued and the respective command fails. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 410 (2018-04-10) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTIOR ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTSCR ASSEMBLE VTFMT ASSEMBLE

VS550357 VMARC 04/30/18 10:25:02 * Fence EAV minidisks

Update VS550357 applies to VSSI installation builds through 5524 Symptom: * Fence EAV minidisks Problem: As of APARs VM65943 and VM65945 VM now supports minidisks on real cylinders above 65519. VSSI has no support for VTAPE libraries or VPARS databases to reside on EAV cylinders. Resolution: The following commands have been updated: VPFMT, VPADD, VPOPEN, VTFMT, VTADD and VTOPEN For CKD DASD they verify that any minidisks involved are not on EAV cylinders. For FBA DASD they verify the minidisk starts on an 8 block boundary, its size is a multiple of 8 and it is wholly contained below real block 134217720 (64GB-1). If any check fails an error message is issued and the respective command fails. BUILD_Reqd: VSSICMS Toolmin: 1.0 410 (2018-04-10) Modules: VSSUBR02 ASSEMBLE

VT550356 VMARC 04/30/18 10:24:10 * Soft abend sv1106 after fix VT550343

Update VT550356 applies to VSSI installation builds through 5524 Symptom: * Soft abend sv1106 after fix VT550343 Problem: Fix VT550343 added a USERSTATE=NOCHANGE soft abend into a code path where a counter goes negative to help us better understand the scenarios when that happens. Resolution: We require no future dumps so delete the soft abend. Additionally comments were clarified and code revised in a number of other modules. BUILD_Reqd: VSSICP Toolmin: 1.0 410 (2018-04-10) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VT550355 VMARC 04/09/18 09:17:09 * TPF must ZTVAR VTAPE drives after VT550343

Update VT550355 applies to VSSI installation builds through 5524 Symptom: * TPF must ZTVAR VTAPE drives after VT550343 Problem: After fix VT550343 frequently VTAPEs must be ZTVAR'ed back online after an IPL of a TPF guest. Resolution: VT550343 simplified the code for generating the device sequence number returned in response to Read Configuration Data CCW (x'FA'). Prior to 343 the code was dual pathed with one path for non-shared drives, returning essentially constant data and the other path for shared drives returning dynamic data that was influenced by the number of drives defined thus far, &c.. After 343 the dynamic data was always being returned, so a non-shared drive was not returned the same constant data it always had. TPF retains a copy of the information returned in response to a Read Configuration Data in the tape status table. During the IPL TPF issues Read Configuration Data CCWs to the various devices. It compares the returned configuration data against the saved data in the tape status table. If it matches the drive is automagically ZTVAR'ed online. If it doesn't match TPF assumes the device is different and leaves it offline. The portion of VT550343 related to creation of the device sequence number is reverted to pre-343 logic so non-shared drives see the same constant data as they have in the past. This allows TPF to recognize the VTAPE drives and bring them online as part of the IPL. BUILD_Reqd: VSSICP Toolmin: 1.0 408 (2018-04-09) Modules: RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTMSG ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTSV2 ASSEMBLE RVTTBL ASSEMBLE

VS550354 VMARC 04/05/18 23:44:52 * Enhance CPXLOAD usability, CMS cleanup

Update VS550354 applies to VSSI installation builds through 5524 Symptom: * Enhance CPXLOAD usability, CMS cleanup Problem: CPXLOAD imposes restrictions on dynamically loaded code VSSI would like relaxed. Resolution: Following changes are made to CPXLOAD processing: - the INCLUDE directive is enhanced to allow the use of an equals sign ("=") for the filename and filetype to indicate the member being loaded should be loaded from the same source file as the INCLUDE was loaded from. This allows the generated TXTLIB to behave correctly if renamed. - MEMBER operand is no longer restricted by filetype. This allows a TXTLIB to have a filetype other than TXTLIB. A TXTLIB may now have anything the CMS filesystem considers valid as its filetype. - a new OPTION ("VSSI") is defined. Specifying the VSSI option enables cross module resolution of external symbols for for modules loaded with the TEMPORARY attribute. This is safe since VSSI strictly manages the order of module load/unload. Any customer exploiting this must be equally cautious of loading/unloading in the correct sequence (or "bad things"(TM) will happen!). Application of this PTF will additionally force cleanup of orphaned (deprecated) CMS modules (i.e., VSSUBR). BUILD_Reqd: VSSMMAC Toolmin: 1.0 406 (2018-02-24) Modules: VS55MAC $EXEC VSMODID COPY

VS550353 VMARC 04/04/18 10:07:50 * Invalid NUC externs in non-CPXLOAD environment

Update VS550353 applies to VSSI installation builds through 5524 Symptom: * Invalid NUC externs in non-CPXLOAD environment Problem: In a static NUC (non-CPXLOAD) environment, all VSSI modules are compiled directly into the NUC. Several VTAPE entry points removed via prior PTFs have non-CPXLOAD calls expressed in module RVSSTQ. Resolution: Staic calls commented out in RVSSTQ. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVSSTQ ASSEMBLE

VP550352 VMARC 03/27/18 09:24:53 * dbm004 inserting record in VPARS database

Update VP550352 applies to VSSI installation builds through 5524 Symptom: * dbm004 inserting record in VPARS database Problem: dbm004 soft abend when attempting to insert a record into a VPARS database. R7 contains the address where the record is to be inserted and it points to the page following the buffer page. R7 not being within the buffer page is why the insert is rejected and the dbm004 taken. Resolution: RVPDBTBS (binary search) is updated to return CC1 in all cases when a record is not found in the database. RVPDBMVR is updated to recognize that when R7 points to the start of the following page the record is to be inserted after the last entry in the buffer page. The code has been like this for many years (>25) and over the years, we have seen a handful of dbm004 soft abends but due to (IBM) bugs in soft abend dump generation, the dumps have always been missing some crucial bit of information needed to debug the problem. Fortunately(?) one customer took a hard abend (fixed by VP550334) and this gave us the needed information to debug this problem. It seems the linear nature of TPF's I/O writes is why this hasn't been more of an issue. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVPCCW ASSEMBLE RVPCLR ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPSV1 ASSEMBLE RVPSV3 ASSEMBLE

VT550351 VMARC 03/24/18 13:48:07 * Deadlock during virtual tape rewind unload

Update VT550351 applies to VSSI installation builds through 5524 Symptom: * Deadlock during virtual tape rewind unload Problem: Many users hung. Some users go logoff/force pending if they try to log off. A snap dump was taken and the system re-IPLed to recover. Resolution: Analysis of the dump indicates it is a VTAPE problem. Many users are wanting the VTSABQLK lock (this lock manages the queue of VTACTBKs (the control block that represents an active virtual tape)). Further analysis indicates this is a textbook example of a deadlock problem (exactly as you would have learned in your third year operating systems concept class). Thread 1 holds lock A and wants lock B. Thread 2 holds lock B and wants lock A. In our case thread 1 originates in RVTCCWSM when the guest issues a x'0F' CCW (rewind and unload) against its device number 520. Since there is a tape mounted on 520 before beginning CCW simulation RVTCCW obtains the VTACTLK exclusive (the lock for the tape active on 520). Subsequently we end up in RVTREWUC to do the rewind and unload of the virtual tape. Unloading the tape will make it no longer active so we call RVTSV2RA to release any control blocks related to that virtual tape. RVTSV2RA attempts to get the VTSABQLK lock exclusive in order to remove the VTACTBK from the queue of active tapes. However we hang waiting for the lock since it is held by thread 2. Thread 2 originates in HCPVDICA (clear an active guest I/O). This is being done against the guest's 520 device and since 520 is a virtual tape we end up in RVTSV2RS (reset virtual tape device). RVTSV2RS obtains the VTSABQLK exclusive and then, when it finds an active tape on the drive, wants the VTACTLK exclusive which is being held by thread 1. DEADLOCK! Obviously the sequence of events and timing needs to be just right for this to happen. The locks involved here have been obtained in this order for many years (more than 10) and to the best of our knowledge, this is the first occurrence of this deadlock, so it is very rare. The classical approach to resolving this is to define a lock heirarchy and that is what we do here. If both the VTACTLK and the VTSABQLK need to be held exclusive concurrently, VTACTLK must be obtained first. RVTSV2RS is updated to do just that. Lastly a number of other modules were updated with clarifying comments and refactoring. This completes the refactoring work on the VTAPE ASSEMBLE parts. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOPC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE RVTTBL ASSEMBLE

VP550350 VMARC 03/24/18 13:47:35 * VPQUERY STATUS displays incorrect values

Update VP550350 applies to VSSI installation builds through 5524 Symptom: * VPQUERY STATUS displays incorrect values Problem: Very rarely VPQUERY STATUS displays some incorrect values. In discussion with the reporting site the VPQUERY STATUS is being done against another user and that user may be doing a VPADD at the time of the incorrect VPQUERY STATUS. Resolution: Entry point RVPCQYQU (VPQUERY) is updated to annex CFM (console function mode) serialization on the target user if a VPQUERY is issued with the USERID option. This ensures the target user is not running a command that can change the VPARS database while the VPQUERY is active. Additionally it was found that not all callers of entry point RVPCONFP (check if a minidisk being added to a VPARS database is part of a pool) were holding the required lock (VP6POOLK) prior to the call. Those not holding the lock have been updated to obtain the lock before calling RVPCONFP (which now HCPASERTs that the lock is held on entry). Lastly a number of other modules were updated with clarifying comments and minor refactoring. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE

VP550349 VMARC 03/15/18 08:44:55 * Some VPSET options not valid after VP550342

Update VP550349 applies to VSSI installation builds through 5524 Symptom: * Some VPSET options not valid after VP550342 Problem: After fix VP550342 some VPSET options are no longer valid. Resolution: Across the VPARS and VTAPE code base several methods of parsing/handling command options were in use. Part of VP550342 and VT550343 code clean up was to standardize on a common method of parsing command options. A regression crept in to the VPSET table of valid options so some VPSET options were no longer recognized as valid. Module RVPSET has had its table of command options corrected. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVPSET ASSEMBLE

VP550348 VMARC 03/04/18 04:42:32 * Annual re-sequence VPARS parts

Update VP550348 applies to VSSI installation builds through 5524 Symptom: * Annual re-sequence VPARS parts Problem: Due to updates a number of files are getting tight on sequence numbers. This impacts the fit of future fixes. Proactively address. Resolution: We use the following rules of thumb to decide whether or not a source file needs to be re-sequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is re-sequenced. In the past we have re-sequenced with an arbitrary gap of 10000. To maximize the gap between lines (and thus minimize future re-sequencings) the gap is now tailored to each individual file based on the number of records in the file. The sequence number range is 00000000-99999999 and we attempt to pick a gap that best exploits the full range. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPQY1 ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE

VT550348 VMARC 03/04/18 04:42:40 * Annual re-sequence VTAPE parts

Update VT550348 applies to VSSI installation builds through 5524 Symptom: * Annual re-sequence VTAPE parts Problem: Due to updates a number of files are getting tight on sequence numbers. This impacts the fit of future fixes. Proactively address. Resolution: We use the following rules of thumb to decide whether or not a source file needs to be re-sequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is re-sequenced. In the past we have re-sequenced with an arbitrary gap of 10000. To maximize the gap between lines (and thus minimize future re-sequencings) the gap is now tailored to each individual file based on the number of records in the file. The sequence number range is 00000000-99999999 and we attempt to pick a gap that best exploits the full range. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVTADD ASSEMBLE RVTSV1 ASSEMBLE

VP550347 VMARC 03/04/18 16:21:54 * Annual re-sequence COPY parts

Update VP550347 applies to VSSI installation builds through 5524 Symptom: * Annual re-sequence COPY parts Problem: Due to updates a number of files are getting tight on sequence numbers. This impacts the fit of future fixes. Proactively address. Resolution: We use the following rules of thumb to decide whether or not a source file needs to be re-sequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is re-sequenced. In the past we have re-sequenced with an arbitrary gap of 10000. To maximize the gap between lines (and thus minimize future re-sequencings) the gap is now tailored to each individual file based on the number of records in the file. The sequence number range is 00000000-99999999 and we attempt to pick a gap that best exploits the full range. BUILD_Reqd: VSSMMAC Toolmin: 1.0 406 (2018-02-24) Modules: VPTCCTBK COPY

VT550346 VMARC 03/04/18 03:15:59 * VTQUERY SPACE fields too small for large library

Update VT550346 applies to VSSI installation builds through 5524 Symptom: * VTQUERY SPACE fields too small for large library Problem: VTAPE message 025 allows 8 digits for the blocks and in-use fields. This is too small for a large VTAPE library. Resolution: Increase the blocks and in-use fields from 8 to 10 digits. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVTMSG ASSEMBLE

VS550345 VMARC 03/04/18 03:10:25 * Deprecate VSADCON macro

Update VS550345 applies to VSSI installation builds through 5524 Symptom: * Deprecate VSADCON macro Problem: Early in release 55 development, CP's methodology for structuring debased modules was not well understood and homebrew approaches to dealing with base register limitations were developed. One approach was to explicitly define all externals used in a module via VSADCON marcos. However, now that all modules are properly debased, workarounds such as VSADCON are no longer needed so - deprecate VSADCON. Resolution: The VSADCON macro is changed to a no-op and as subsequent updates hit parts they will remove VSADCON macros from them. VSILX's logic is reverted to no longer expect VSADCON generated labels. BUILD_Reqd: VSSMMAC Toolmin: 1.0 406 (2018-02-24) Modules: VSADCON MACRO VSILX MACRO

VP550344 VMARC 03/04/18 02:55:05 * rcc003 soft abend during logoff

Update VP550344 applies to VSSI installation builds through 5524 Symptom: * rcc003 soft abend during logoff Problem: Very rarely a non-disruptive rcc003 soft abend is taken while a database is being closed. Resolution: Fix 550316 changed the serialization in effect during database close. With the new serialization it was unclear whether or not a section of close code was still required. A non-disruptive rcc003 soft abend was added to the code in question. We've now seen a handful of rcc003 dumps from a number of customers and understand when and why that portion of the close code is entered. This update deletes the rcc003 abend and some surrounding code. BUILD_Reqd: VSSICP Toolmin: 1.0 406 (2018-02-24) Modules: RVPRCC ASSEMBLE

VT550343 VMARC 03/04/18 11:38:06 * PRG004 in HCPVSP during VTAPE detach

Update VT550343 applies to VSSI installation builds through 5524 Symptom: * PRG004 in HCPVSP during VTAPE detach Problem: In a shared VTAPE environment the count of users sharing a drive may not be properly maintained. If the count is wrong when the second to last shared user detaches a shared drive we can mistakenly conclude a unit record device is being detached and end up in HCPVSP where we PRG004. Resolution: Fix 550027 reworked the shared VTAPE management and was the source of the miscount error. That code has been reverted. Additionally this fix carries on with the code refactoring started with fixes 550330 and 550331. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 406 (2018-02-24) Modules: COPYTAPE ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTCPYASM ASSEMBLE VTFMT ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE VTSCR1 ASSEMBLE

VP550342 VMARC 03/04/18 11:37:02 * VPARS code refactoring; NOBASE updates

Update VP550342 applies to VSSI installation builds through 5524 Symptom: * VPARS code refactoring; NOBASE updates Problem: Code refactoring in preperation for future updates and to maintain consistency with the VTAPE code base. Additionally the CMS based NOBASE utilities have also been refactored for greater clarity. Resolution: Fixes 550341, 550342 and 550343 need to be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 406 (2018-02-24) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE VPBLDFMT ASSEMBLE VPBXLTP ASSEMBLE VPBXPLTB ASSEMBLE VPBXREF ASSEMBLE VPBXREST ASSEMBLE VPCPYASM ASSEMBLE VPUNLD ASSEMBLE

VP550341 VMARC 03/15/18 14:04:57 * COPY and common member updates for 342/343

Update VP550341 applies to VSSI installation builds through 5524 Symptom: * COPY and common member updates for 342/343 Problem: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Resolution: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Fixes 550341, 550342 and 550343 need to be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 406 (2018-02-24) Modules: VP55MAC $EXEC RVPCCTBK COPY RVPCMPBK COPY RVPEQUAT COPY RVPEXCBK COPY RVPFMTBK COPY RVPSYSBK COPY VPBXACFG COPY VPBXAHDR COPY VPBXIOWK COPY VPBXPOOL COPY VPBXRPL COPY VPCTLBK COPY VPDCSBK COPY VPINDXBK COPY VPIOTBK COPY VPOPENBK COPY VPPOOLBK COPY VPTCCTBK COPY VPTPFKEY COPY VP1WRKBK COPY RVPSCFBK MACRO

VT550341 VMARC 03/15/18 14:44:22 * COPY and common member updates for 342/343

Update VT550341 applies to VSSI installation builds through 5524 Symptom: * COPY and common member updates for 342/343 Problem: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Resolution: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Fixes 550341, 550342 and 550343 need to be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 406 (2018-02-24) Modules: RVTCMPBK COPY RVTEQUAT COPY RVTEXCBK COPY VTACTBK COPY VTBMAPBK COPY VTENTBK COPY VTEXTBK COPY VTIOTBK COPY VTLDRBK COPY VTLSTBK COPY VTMNTBK COPY VTQRPTS COPY VTQRYBK COPY VTSCTLBK COPY VTSETWK COPY VTVDSCBK COPY

VS550341 VMARC 03/15/18 13:11:30 * COPY and common member updates for 342/343

Update VS550341 applies to VSSI installation builds through 5524 Symptom: * COPY and common member updates for 342/343 Problem: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Resolution: Macro, copy, common and CP updates in support of fixes 550342 and 550342. Fixes 550341, 550342 and 550343 need to be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 406 (2018-02-24) Modules: VSSUME $REPOS RVSCMPBK COPY VSLCKXST COPY VSMSGPBK COPY VSCKVDEV MACRO VSLCKDEF MACRO VSLCKOP MACRO VS6ANCH MACRO RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTF ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE VSLABSL ASSEMBLE

VS550340 VMARC 02/07/18 18:15:18 * Placeholder Update - start 5524

Update VS550340 applies to VSSI installation builds through 5524 Symptom: * Placeholder Update - start 5524 Problem: Dummy update to mark the start of Build 5524. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 401 (2017-12-07) Modules: VSMODID COPY

PTFs below apply to Packages at 5522 and lower

VS550339 VMARC 12/13/17 15:01:51 * Placeholder Update - end 5522

Update VS550339 applies to VSSI installation builds through 5522 Symptom: * Placeholder Update - end 5522 Problem: Dummy update to mark the end of Build 5522. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 401 (2017-12-07) Modules: VSMODID COPY

VP550338 VMARC 12/19/17 14:02:53 * Possible LAL008 abend after 550330

Update VP550338 applies to VSSI installation builds through 5522 Symptom: * Possible LAL008 abend after 550330 Problem: This is a RAS only change to VPARS. This update simply changes what is included in trace table entries to aid with debugging future problems. Resolution: Call trace entries to RVPIORTR/RVPIORTC will now include the address of the virtual page to be translated. Return trace entries from RVPIORTR/RVPIORTC will include the host logical address being used to back the virtual page. BUILD_Reqd: VSSICP Toolmin: 1.0 401 (2017-12-07) Modules: RVPBUF ASSEMBLE RVPCLR ASSEMBLE RVPDBT ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VT550338 VMARC 12/19/17 14:06:59 * Possible LAL008 abend after 550330

Update VT550338 applies to VSSI installation builds through 5522 Symptom: * Possible LAL008 abend after 550330 Problem: In addition to fixing the reported problems, 550330 also did code refactoring/modernizing to approximately one third of the VTAPE code base. The intent of the refactoring work is to make the code easier to understand/support without introducing any functional change. Unfortunately in an effort of this size problems can creep in despite extensive testing. This is one such case. A label was moved a couple of statements causing a buffer not to be locked as expected. Resolution: The following modifications were made: . Label was moved back to its correct location. Buffer pages are now locked and unlocked in tandem (the LAL008 was the result of unlocking a page that hadn't been locked). Additionally a RAS change was done. Call . RAS change was done so that call trace entries in RVTIORTR will now include the address of the virtual page to be translated. Return trace entries from RVTIORTR will include the host logical address being used to back the virtual page. . Misc regressions (e.g., CLM offset) fixed. BUILD_Reqd: VSSICP Toolmin: 1.0 401 (2017-12-07) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST2 ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VP550337 VMARC 12/11/17 10:16:18 * CMS OCO module removal

Update VP550337 applies to VSSI installation builds through 5522 Symptom: * CMS OCO module removal Problem: Several CMS utility modules use object decks which are deleted by update VS550336. Additionally, a few modules have invalid ("dangling") continuation lines via macro calls. Resolution: Made the following changes: . Applicable PRODUCT file updated to reflect exclusion of the deprecated object decks. . "Dangling" continuation lines fixed. BUILD_Reqd: VSSICMS Toolmin: 1.0 401 (2017-12-07) Modules: VPBXREF ASSEMBLE VPUNLD ASSEMBLE

VT550336 VMARC 12/11/17 10:15:55 * Remove deprecated CMS OCO modules

Update VT550336 applies to VSSI installation builds through 5522 Symptom: * Remove deprecated CMS OCO modules Problem: Several CMS utility modules were originally generated using IBM Toolkit macros. This decision required us to ship those modules as Object-Code-Only (OCO), since most customers do not have Toolkit installed (and hence cannot assemble Toolkit-enabled modules from source). Since that time: . VSSI has decided to abandon Toolkit use in source code in order to avoid extra product dependencies; . Most of the affected CMS modules are deprecated anyway. The following modules are affected: Component Module Status VTAPE VTCOMPAR deprecated VTMCMA used by VTCOMPAR VTMCMB used by VTCOMPAR VTMCPR used by VTCOMPAR VTMIMS used by VTCOMPAR VTMMSG used by VTCOMPAR VTSTRC was used by VTBKVOL (i.e., VTBKUP|VTREST) VTSTRF deprecated Resolution: Made the following changes: . VTBKUP and VTREST modified to remove VTSTRCx calls (homebrew TRACE tables no longer needed) . Applicable PRODUCT file updated to reflect exclusion of the above modules. . Application of this PTF will result in the deletion of the above module objects (AUX|PTF|TXT). BUILD_Reqd: VSSICMS Toolmin: 1.0 401 (2017-12-07) Modules: VTBKVOL ASSEMBLE

VS550336 VMARC 12/11/17 10:15:47 * Remove deprecated CMS OCO modules

Update VS550336 applies to VSSI installation builds through 5522 Symptom: * Remove deprecated CMS OCO modules Problem: Several CMS utility modules were originally generated using IBM Toolkit macros. This decision required us to ship those modules as Object-Code-Only (OCO), since most customers do not have Toolkit installed (and hence cannot assemble Toolkit-enabled modules from source). Since that time: . VSSI has decided to abandon Toolkit use in source code in order to avoid extra product dependencies; . Most of the affected CMS modules are deprecated anyway. The following modules are affected: Component Module Status Common VSDTIO no longer used VSSPIP no longer used VSTRCDIF deprecated Resolution: Made the following changes: . Applicable PRODUCT file updated to reflect exclusion of the above modules. . Application of this PTF will result in the deletion of the above module objects (AUX|PTF|TXT). BUILD_Reqd: VSSMMAC Toolmin: 1.0 401 (2017-12-07) Modules: VSMODID COPY

VS550335 VMARC 10/22/17 16:35:48 * Correct CPUTYPE symbols in license code

Update VS550335 applies to VSSI installation builds through 5522 Symptom: * Correct CPUTYPE symbols in license code Problem: RVSSTL uses VSSI-generated symbols CTYCP (CP engine) and CTYIFL (IFL engine) to interrogate the current system hardware configuration. Since the appropriate CPUTYPE symbols exist in HCPEQUAT, use of VSSI-named symbols for the same values are inappropriate. Resolution: VSSI symbols replaced with IBM symbols PUCCP and PUCIFL. BUILD_Reqd: VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: VSMODID COPY RVSSTL LAS55335

VP550334 VMARC 10/22/17 09:51:25 * HTT001 during record insert into VPARS database

Update VP550334 applies to VSSI installation builds through 5522 Symptom: * HTT001 during record insert into VPARS database Problem: RVPDBM encountered an error adding a record to a VPARS database. In the process of gathering information for a dbm004 soft abend a register has an invalid pointer resulting in an HTT001 hard abend. Resolution: There was no need to gather the information being loaded into registers, as it would be in the dump anyway. When a soft abend is taken any page pointed to by a register is automatically included in the dump. The dump generation code validates each register prior to using it, so HTT001's are avoided. The fix then is simply to delete the few lines gathering information below label ENTMVCAB. That code has been around for a long time, added by fix 210066 (circa 1990), but this abend has only been possible since the storage changes in z/VM 5.2 (circa 2009) with CP running in a host logical system execution space. The identical logic preparing for a soft abend was also found in RVPDBT and has been removed from there as well. Additionally code in RVPDBM and RVPDBT was updated with some reformatting. Likewise code reformatting was done on ten additional parts. Text decks compare before and after for those parts. BUILD_Reqd: VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPQY1 ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE

VP550333 VMARC 09/29/17 13:29:22 * VPARS, ShadowDisk/Z sync

Update VP550333 applies to VSSI installation builds through 5522 Symptom: * VPARS, ShadowDisk/Z sync Problem: Sync several ShadowDisk/Z CMS modules with their VPARS counterparts. Resolution: The following changes were made: . VPCPYASM updated to include VSSIEQU copybook. BUILD_Reqd: *None* Toolmin: 1.0 396 (2017-09-27) Modules: VPCPYASM ASSEMBLE

VP550332 VMARC 09/29/17 13:14:53 * STK017 when ShadowDisk user logs off with open dat

Update VP550332 applies to VSSI installation builds through 5522 Symptom: * STK017 when ShadowDisk user logs off with open database Problem: A ShadowDisk user logs off the system without first closing their database. A few moments later the system crashes with a STK017 abend as the user was allowed to complete logging off without the open database being detected and closed during log off. Resolution: Fix VS550236 defined an independent set of environment variables in VSSIEQU COPY. It updated code to use these to check the VPTFLG3 field in the VPTCCTBK rather than the ones defined for that field. Eventually the two sets of values diverge resulting in this abend. Code is updated to define one sets of values dependent on the other so they can never diverge in the future. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 396 (2017-09-27) Modules: VPTCCTBK COPY

VS550332 VMARC 09/29/17 13:13:45 * STK017 when ShadowDisk user logs off with open dat

Update VS550332 applies to VSSI installation builds through 5522 Symptom: * STK017 when ShadowDisk user logs off with open database Problem: A ShadowDisk user logs off the system without first closing their database. A few moments later the system crashes with a STK017 abend as the user was allowed to complete logging off without the open database being detected and closed during log off. Resolution: Fix VS550236 defined an independent set of environment variables in VSSIEQU COPY. It updated code to use these to check the VPTFLG3 field in the VPTCCTBK rather than the ones defined for that field. Eventually the two sets of values diverge resulting in this abend. Code is updated to define one sets of values dependent on the other so they can never diverge in the future. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: VSMODID COPY VSSIEQU COPY RVSSTL LAS55332

VT550331 VMARC 10/20/17 12:33:40 * Restore VTSET vdev LIMIT nn processing

Update VT550331 applies to VSSI installation builds through 5522 Symptom: * Restore VTSET vdev LIMIT nn processing Problem: Two regressions crept into VTAPE with recent fixes. After VT550326 VTSET LIMIT was not being respected and after VT550330 an HTT001 was possible during a tape rewind. Resolution: The regressions have been fixed. Additionally this update carries on the code refactoring started with VT550330 and updates/modernizes another approximatley 1/3 of the VTAPE code base in preperation for upcoming fixes. BUILD_Reqd: VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOPC ASSEMBLE RVTPRC ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE

VT550330 VMARC 10/20/17 12:33:24 * Fix various VTAPE problems

Update VT550330 applies to VSSI installation builds through 5522 Symptom: * Fix various VTAPE problems Problem: HTT001 at RVSSTG+2CA after failed conditional HCPGETST during VTADD command FRE016 on call from RVTOCT+2AE during VTCLOSE command PRG001 after wild branch out of RVTSHU during shutdown Resolution: The HTT001 and FRE016 are both related. A customer was still using an old VTFMT module (level V1R1 from 2001) to prepare VTAPE library minidisks. A number of halfword fields are used at level V1R1 and if a disk larger than 32767 cylinders, these are mistakenly taken as negative values. The current VTFMT module (level V5R3 released circa 2007) changed to fullword values and would have had no problems with the larger volume. When a disk larger than 37267 and formatted in V1R1 style is VTADD'ed an HTT001 abend occurs. The volume is recognized when the library is VTOPEN'ed after the abend but all space is marked as used. A VTCLOSE of the library results in a FRE016 abend. Although it is very unlikely we'll ever see another larger disk formatted with the old formatter code has been updated to properly treat the halfword values as logical rather than signed. The PRG001 abend fix being included is unrelated to the use of the old VTFMT module. The system is being shutdown using a WITHIN interval. This resulted in shutdown signals being sent to registered guests. At least one guest is recalcitrant and does not complete its termination by the specified interval. This results and two timers popping at approximately the same time and HCPSIGTO calling HCPWRPSD twice. VSSI has a hook in HCPWRPSD to close any open VTAPE libraries or VPARS databases at system shutdown. We are not expecting that two threads of execution can be running through HCPWRPSD concurrently and VTAPE shutdown can abend as a result. VSSI considers this an IBM bug and has requested an APAR. However, we will harden our code so regardless whether IBM fixes theirs we do not abend during shutdown. BUILD_Reqd: VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTSHU ASSEMBLE RVTSV1 ASSEMBLE

VT550329 VMARC 10/20/17 12:13:06 * Fix various VTAPE problems (macros/control blocks)

Update VT550329 applies to VSSI installation builds through 5522 Symptom: * Fix various VTAPE problems (macros/control blocks) Problem: HTT001 at RVSSTG+2CA after failed conditional HCPGETST during VTADD command FRE016 on call from RVTOCT+2AE during VTCLOSE command PRG001 after wild branch out of RVTSHU during shutdown Resolution: This fix includes the changes to macros, control blocks, IBM parts and common parts needed by the fix for VT550330. See it for a full description of the changes. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 396 (2017-09-27) Modules: VT55MAC $EXEC RVTEQUAT COPY VTBMAPBK COPY VTCLBLBK COPY VTEXTBK COPY VTMDSKBK COPY VTPACKBK COPY VT9CFDAT COPY VT9CFGBK COPY VT5ANCH MACRO VT6ANCH MACRO

VS550329 VMARC 10/20/17 11:29:42 * Fix various VTAPE problems (macros/control blocks)

Update VS550329 applies to VSSI installation builds through 5522 Symptom: * Fix various VTAPE problems (macros/control blocks) Problem: HTT001 at RVSSTG+2CA after failed conditional HCPGETST during VTADD command FRE016 on call from RVTOCT+2AE during VTCLOSE command PRG001 after wild branch out of RVTSHU during shutdown Resolution: This fix includes the changes to macros, control blocks, IBM parts and common parts needed by the fix for VT550330. See it for a full description of the changes. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 396 (2017-09-27) Modules: VS5ANCH MACRO VS6ANCH MACRO RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSSTF ASSEMBLE RVSSTN ASSEMBLE

VP550328 VMARC 08/10/17 16:48:00 * Hung user while attempting sync during logoff

Update VP550328 applies to VSSI installation builds through 5522 Symptom: * Hung user while attempting sync during logoff Problem: A user with an open database logs off. As part of database close processing we write any changed records to disk (colloquially the code refers to this as a sync). Additionally each open database has a timer that pops every second to determine whether any database maintence activities are required. One such maintenance task is syncing. As part database of close processing we also stop the database's timer. A window exists where sometimes the timer gets stopped with close's sync still pending. Close then waits forever for a sync that will never be initiated. Resolution: Close processing has been updated to ensure there is no race condition between close's sync request and stopping the timer. This bug was introduced by fix 550191. Additionally code refactoring was done to improve and modernize the module. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVPRCC ASSEMBLE

VP550327 VMARC 07/27/17 15:56:10 * Database full error not detected properly

Update VP550327 applies to VSSI installation builds through 5522 Symptom: * Database full error not detected properly Problem: Entry point RVxSV1OA used R4 to hold to total space used and also to hold flags when issuing a warning when the database was approaching full. If the database was 100% full the wrong code path was taken. Resolution: RVxSV1OA is updated to use R6 to hold the message flags so R4 still has the correct value after a warning has been issued. This bug was introduced by fix 520072. Additionally code refactoring was done to improve and modernize the module. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVPSV1 ASSEMBLE

VS550326 VMARC 07/01/17 22:39:18 * HCP Module Sync

Update VS550326 applies to VSSI installation builds through 5522 Symptom: * HCP Module Sync Problem: Several HCP module hokks are missing from the current PTFCUM packages due to BUILD exec regressions (now fixed). Resolution: The attached HCP module hooks are applicable to 6.4 only, and are ignored for older systems. BUILD_Reqd: VSSMMAC Toolmin: 1.0 392 (2017-05-15) Modules: VSMODID COPY

VT550325 VMARC 06/29/17 09:06:20 * Relax overly-strict tape volume size semantics

Update VT550325 applies to VSSI installation builds through 5522 Symptom: * Relax overly-strict tape volume size semantics Problem: Customer experienced several errors running z/OS batch jobs on VTAPE-defined devices. . Intervention-Requested on stacked tapes . Miscellaneous OPEN ABENDs (e.g., 613) Each time a block is written to virtual tape, RVTCCW performs the following limit checks, and returns a simulated Unit Exception (volume or DB near threshold) or Unit Check (DB full) indication to the current I/O requestor: 1. Library MDISK blks available check 2. User tape volume data size limit (MEGs) check 3. Logical tape devtype max blks-per-volume checks The 3rd check is overly restrictive in most cases, since we have no need to limit the virtual volume size to what a "real" 3480|3490|3590 volume holds. Check #3 was the cause of the I/O disruption. Resolution: Check #3 removed. The only limits that we need to consider are already covered via checks 1 and 2 above. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVTCCW ASSEMBLE

VP550324 VMARC 06/12/17 14:51:49 * Orphaned TRQBKs with concatenated databases

Update VP550324 applies to VSSI installation builds through 5522 Symptom: * Orphaned TRQBKs with concatenated databases Problem: VPOPEN (RVPOPNOP) was always allocating a new TRQBK (timer request block). However, if joining a shared concat database a TRQBK would already be active and allocating a new one would orphan the existing one Resolution: RVPOPNOP is updated to only allocate a TRQBK if it is the first user opening a database. A TRQBK is no longer allocated when joining an existing database. This bug was introduced by fix 550095. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVPOPN ASSEMBLE

VP550323 VMARC 06/12/17 14:51:26 * VPOPEN with checkpoints and concatenated DBs

Update VP550323 applies to VSSI installation builds through 5522 Symptom: * VPOPEN with checkpoints and concatenated DBs Problem: Customer was running with a concatenated database environment (i.e., with a primary R/W database and one or more concatenated R/O databases). The customer set several checkpoints (R/W DB), closed the database, then attempted to re-open with the following command: . VPOPEN NORESET DEVTABLE VSSI CONFIG CFG1 CONCAT CCT1 CHECKPOINT 1 This resulted in the following error: RVPOPS081E Cannot open to checkpoint 1, only 0 checkpoints have been set RVPIFC003E VPARS open failed Post-mortem inspection of the database indicated that the checkpoints had in fact been set in the R/W DB. Resolution: RVPOPN is attempting to apply the checkpoint level against all databases being opened. The primary (R/W) database was successfully rolled back to checkpoint 1 but when it tried to roll a concatenated database back to checkpoint 1 it did not have a checkpoint 1 set and thus the command failed. RVPOPN has been updated to only apply the checkpoint to the primary database. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVPOPN ASSEMBLE RVPOPS ASSEMBLE

VT550322 VMARC 06/06/17 15:00:43 * PRG004 in RVTSV1 after fix 550295

Update VT550322 applies to VSSI installation builds through 5522 Symptom: * PRG004 in RVTSV1 after fix 550295 Problem: Incorrectly coded MVC results in PRG004 in RVTSV1. Resolution: RVTSV1 has had MVC corrected. This bug was introduced by fix 550295. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVTSV1 ASSEMBLE

VP550321 VMARC 05/31/17 09:31:51 * LCK001 during VPCLEAR CHECKPOINT 1

Update VP550321 applies to VSSI installation builds through 5522 Symptom: * LCK001 during VPCLEAR CHECKPOINT 1 Problem: Code in RVPCLR (the VPCLEAR command processor) was releasing a lock it did not hold. Resolution: RVPCLR (at label CLOSE) has been updated to check that the lock is held before attempting to release it. This bug was introduced by update VP550177. BUILD_Reqd: VSSICP Toolmin: 1.0 392 (2017-05-15) Modules: RVPCLR ASSEMBLE

VP550318 VMARC 05/18/17 12:41:33 * NOBASE utilities require FORM=E added to FS macros

Update VP550318 applies to VSSI installation builds through 5522 Symptom: * NOBASE utilities require FORM=E added to FS macros Problem: NOBASE utilities do not include FORM=E on FS macros to read/write CMS files. This artificially constrains the size of files. Resolution: FORM=E added to FS macros where appropriate. Additionally code refactoring was done where appropriate. BUILD_Reqd: VSSICMS Toolmin: 1.0 392 (2017-05-15) Modules: VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXPLTB ASSEMBLE VPBXRCTL ASSEMBLE VPBXREF ASSEMBLE VPBXREST ASSEMBLE

VS550318 VMARC 05/18/17 12:41:45 * NOBASE utilities require FORM=E added to FS macros

Update VS550318 applies to VSSI installation builds through 5522 Symptom: * NOBASE utilities require FORM=E added to FS macros Problem: VSFSERR, the routine to translate file system error codes into textual messages contains some typos in the error message text. Resolution: Typos corrected. Additionally code refactoring was done were appropriate. BUILD_Reqd: VSSICMS Toolmin: 1.0 392 (2017-05-15) Modules: VSFSERR ASSEMBLE

VP550317 VMARC 05/11/17 09:37:10 * Hard abend rcc001 on VPOPEN error

Update VP550317 applies to VSSI installation builds through 5522 Symptom: * Hard abend rcc001 on VPOPEN error Problem: A VPOPEN command encounters an error while opening a database. It then calls the database close routine to clean up the partially opened database. Close attempts to obtain a lock that has been destroyed and abends. Resolution: One of the database locks was being destroyed in two places. In open (RVPOPN) if open encountered an error and in close (RVPRCC) for normal close processing. Prior to fix 550316 RVPRCC treated a destroyed lock the same as an obtained lock. As part of fix 550316's serialization overhaul and general code enforcement, a destroyed lock was treated as an error condition and abend rcc001 was added. RVPOPN has been updated to no longer destroy the lock when it encounters an error. The lock will now be destroyed by RVPRCC close processing for all types of closes, both error and normal. Additionally obsolete trace code is deleted from a number of other routines. BUILD_Reqd: VSSICP Toolmin: 1.0 391 (2017-04-26) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE

VP550316 VMARC 04/14/17 12:39:09 * Improve serialization during database close

Update VP550316 applies to VSSI installation builds through 5522 Symptom: * Improve serialization during database close Problem: Various abends (we've seen FRE016 and HTT001s) in RVxRCC during database close/reset usually while the user is being FORCEd. Resolution: Fix 550063 updated HCPUSO to add a call to RVxRCCCL to close any open database. The point were the call was inserted is in the execution path for both LOGOFF and FORCE processing. However, if we are here for a FORCE we do not have the same serialization as we have for LOGOFF. The close processing needs to be entered under console function mode (CFM) serialization and without that we can have more than one close thread executing concurrently which results in double fret'ing of storage (FRE016 abends) or referencing storage that has been fret'ed (HTT001 abends). The call added to HCPUSO has been eliminated and any open database will now be closed by the preexisting call from HCPUSP which does have the proper CFM serialization. Additionally code has been updated to ensure proper serialization in all cases during the close/reset of a database. The following modules have been amended to conform to the updated Database OPEN/CLOSE semantics shown above. Additionally, HCPASERT statements have been added to the code in order to trap serialization errors; these ASSERTS are triggered if the user issues the SET CPCHECKING ON comand prior to database OPEN. . RVxCLR (database clear) . RVxIFC (database OPEN|CLOSE command processor) . RVxOPN (database OPEN) . RVxRCC (database CLOSE|RESET) . RVxSET (database SET command processor) BUILD_Reqd: VSSICP Toolmin: 1.0 390 (2017-04-14) Modules: RVPCLR ASSEMBLE RVPIFC ASSEMBLE RVPOPN ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE

VP550315 VMARC 03/30/17 14:16:44 * VPUTIL failing if invalid metadata detected

Update VP550315 applies to VSSI installation builds through 5522 Symptom: * VPUTIL failing if invalid metadata detected Problem: Customer reported that VPUTIL MOVE fails if an invalid database record is encountered (e.g., bad metadata). A better solution is to give the customer the option of bypassing any bad DB records and restoring the remaining valid DB records. Since any corrupted records typically represent a tiny fraction of the total database records, a failure of a single DB record can potentially stop the movement of the bulk of the database data. Resolution: VPUTIL amended to support the NOStop option. This option will still report on any invalid database records, but will continue with the next database record. VPUTIL invocations without the NOSTOP option specified will continue to function as before. BUILD_Reqd: VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: VPUTIL ASSEMBLE

VS550314 VMARC 04/14/17 12:38:51 * Improve serialization during database close

Update VS550314 applies to VSSI installation builds through 5522 Symptom: * Improve serialization during database close Problem: Various abends (we've seen FRE016 and HTT001s) in RVxRCC during database close/reset usually while the user is being FORCEd. Resolution: Fix 550063 updated HCPUSO to add a call to RVxRCCCL to close any open database. The point were the call was inserted is in the execution path for both LOGOFF and FORCE processing. However, if we are here for a FORCE we do not have the same serialization as we have for LOGOFF. The close processing needs to be entered under console function mode (CFM) serialization and without that we can have more than one close thread executing concurrently which results in double fret'ing of storage (FRE016 abends) or referencing storage that has been fret'ed (HTT001 abends). The call added to HCPUSO has been eliminated and any open database will now be closed by the preexisting call from HCPUSP which does have the proper CFM serialization. Additionally code has been updated to ensure proper serialization in all cases during the close/reset of a database. The attached update modifies the following HCP modules: . HCPRST - renamed CPU reset entry point from RVxRCCXR(RR) to RVxRCCXS(RS) . HCPUSO - removes the VSSI Database Reset hook . HCPUSP - all VSSI Database Reset code invoked here BUILD_Reqd: VSSMMAC Toolmin: 1.0 390 (2017-04-14) Modules: VSMODID COPY

VP550313 VMARC 03/01/17 14:06:50 * ccw004 soft ABEND after database closed

Update VP550313 applies to VSSI installation builds through 5522 Symptom: * ccw004 soft ABEND after database closed Problem: A lock is unavailable when RVPCCWTM conditionally tries to obtain it. Code delays for 100 milliseconds to try again. While delayed, the database is closed and its control blocks are fret'ed. When RVPCCWTM resumes running after the delay it incorrectly assumes it is still dealing with valid control block pointers. Resolution: RVPCCWTM is updated to simply exit rather than try and obtain the lock when the database is pending close. The only reason we wanted the lock was to possibly issue status messages to the database users and update counters. This doesn't need to be done if the database is pending close. In addition to a ccw004 soft abend, this problem could result in a storage overlay, turning 00000000 into FFFFFFFE. A HTT001 hard abend is another possibility. This bug was introduced by fix 550137. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVPCCW ASSEMBLE

VP550312 VMARC 02/06/17 15:43:33 * CMS Module Consolidation

Update VP550312 applies to VSSI installation builds through 5522 Symptom: * CMS Module Consolidation Problem: VPARS CMS utilities can be re-purposed as ShadowDisk/Z utilities, with a few internal differences. This update therefore does the following: 1. Brings several CMS macros in-line with their CP counterparts (e.g., VSSPROLG vs VSIPROLG); 2. Prepares the VPARS modules to accept macros which can respond to the calling program name (e.g., SDFMT (a copy of VPFMT module) will correctly format ShadowDisk/Z databases when called as SDFMT, and VPARS databases when called as VPFMT). The intent here is to maintain fewer (almost-identical) source copies of similar functionality. Resolution: Amended code attached to this update. BUILD_Reqd: VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: VPBXRCTL ASSEMBLE VPBXRES2 ASSEMBLE

VS550311 VMARC 02/06/17 15:39:02 * CMS Module Consolidation

Update VS550311 applies to VSSI installation builds through 5522 Symptom: * CMS Module Consolidation Problem: VPARS CMS utilities can be re-purposed as ShadowDisk/Z utilities, with a few internal differences. This update therefore does the following: 1. Brings several CMS macros in-line with their CP counterparts (e.g., VSSPROLG vs VSIPROLG); 2. Prepares the VPARS modules to accept macros which can respond to the calling program name (e.g., SDFMT (a copy of VPFMT module) will correctly format ShadowDisk/Z databases when called as SDFMT, and VPARS databases when called as VPFMT). The intent here is to maintain fewer (almost-identical) source copies of similar functionality. Resolution: Amended code attached to this update. BUILD_Reqd: VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: VS55MAC $EXEC VSMODID COPY VSDBDID MACRO VSSPROLG MACRO VSXCALL MACRO VSDBSCAN ASSEMBLE VSDCHK ASSEMBLE VSDLBL ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSSUBDT ASSEMBLE VSSUBR ASSEMBLE VSSUBR01 ASSEMBLE VSSUBR02 ASSEMBLE VSDTIO LAS55311 VSTRCDIF LAS55311

VP550310 VMARC 02/06/17 08:36:19 * Fix VxBLDFMT Display Errors

Update VP550310 applies to VSSI installation builds through 5522 Symptom: * Fix VxBLDFMT Display Errors Problem: VxBLDFMT builds a format table representing the z/TPF record ranges (start CCHH, end CCHH, blksize) for all mapped areas on a specified input BASE disk. However, the VxBLDFMT console display is incorrect if the cylinder range value exceeds 32767 (x'7FFF'). The generated format table is correct; the console display is -not- correct for cylinder ranges > 32767. Resolution: VxBLDFMT amended to load all halfword display values (e.g., CC, HH, and BLKSZ values): via -----------> ICM R1,B'0011',hword_value instead of ---> LH R1,hword_value. BUILD_Reqd: VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: VPBLDFMT ASSEMBLE

VP550309 VMARC 02/05/17 17:45:21 * Sync PRODUCT files with code base

Update VP550309 applies to VSSI installation builds through 5522 Symptom: * Sync PRODUCT files with code base Problem: The current PTFCUM is (deliberately) missing PTF 550296, which split the CMS routine VSSUBR into 2 modules, VSSUBR01 and VSSUBR02. However, the z/VM 6.4 product package inadvertently pulled in the 550296 PRODUCT files (i.e., the files which drive CMS assemblies and link-edits). The 6.4 packages are therefore receiving CMS assembly/link errors, because the files that they are calling for (VSSUBR01 and VSSUBR02) are -not- present in the package. Resolution: This PTF is a dummy update to which the correct PRODUCT file is attached. Application of this PTF will put the PRODUCT file in sync with the code base contained in the package, thus eliminating CMS assembly/link errors. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVPCCW ASSEMBLE

VT550309 VMARC 02/05/17 17:45:26 * Sync PRODUCT files with code base

Update VT550309 applies to VSSI installation builds through 5522 Symptom: * Sync PRODUCT files with code base Problem: The current PTFCUM is (deliberately) missing PTF 550296, which split the CMS routine VSSUBR into 2 modules, VSSUBR01 and VSSUBR02. However, the z/VM 6.4 product package inadvertently pulled in the 550296 PRODUCT files (i.e., the files which drive CMS assemblies and link-edits). The 6.4 packages are therefore receiving CMS assembly/link errors, because the files that they are calling for (VSSUBR01 and VSSUBR02) are -not- present in the package. Resolution: This PTF is a dummy update to which the correct PRODUCT file is attached. Application of this PTF will put the PRODUCT file in sync with the code base contained in the package, thus eliminating CMS assembly/link errors. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVTCCW ASSEMBLE

VS550309 VMARC 02/05/17 17:45:16 * Sync PRODUCT files with code base

Update VS550309 applies to VSSI installation builds through 5522 Symptom: * Sync PRODUCT files with code base Problem: The current PTFCUM is (deliberately) missing PTF 550296, which split the CMS routine VSSUBR into 2 modules, VSSUBR01 and VSSUBR02. However, the z/VM 6.4 product package inadvertently pulled in the 550296 PRODUCT files (i.e., the files which drive CMS assemblies and link-edits). The 6.4 packages are therefore receiving CMS assembly/link errors, because the files that they are calling for (VSSUBR01 and VSSUBR02) are -not- present in the package. Resolution: This PTF is a dummy update to which the correct PRODUCT file is attached. Application of this PTF will put the PRODUCT file in sync with the code base contained in the package, thus eliminating CMS assembly/link errors. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVSCFG ASSEMBLE

VP550308 VMARC 12/29/16 03:13:55 * Resequence ASSEMBLE members

Update VP550308 applies to VSSI installation builds through 5522 Symptom: * Resequence ASSEMBLE members Problem: A number of files are getting tight on sequence numbers. This impacts future fixes. Proactively address Resolution: VSSI source files start out with a sequence number gap of 10000 between each source line. Over time, as fixes and enhancements are developed, this gap gets filled. We use the following rules of thumb to decide whether or not a source file needs to be resequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is resequenced to reinstate a gap of 10000 between each source line. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPMSG ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV2 ASSEMBLE VPBXPLTB ASSEMBLE VPBXRES2 ASSEMBLE

VT550308 VMARC 12/29/16 03:14:28 * Resequence ASSEMBLE members

Update VT550308 applies to VSSI installation builds through 5522 Symptom: * Resequence ASSEMBLE members Problem: A number of files are getting tight on sequence numbers. This impacts future fixes. Proactively address Resolution: VSSI source files start out with a sequence number gap of 10000 between each source line. Over time, as fixes and enhancements are developed, this gap gets filled. We use the following rules of thumb to decide whether or not a source file needs to be resequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is resequenced to reinstate a gap of 10000 between each source line. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVTCCW ASSEMBLE RVTCON ASSEMBLE RVTDEF ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE

VS550308 VMARC 12/29/16 03:14:12 * Resequence ASSEMBLE members

Update VS550308 applies to VSSI installation builds through 5522 Symptom: * Resequence ASSEMBLE members Problem: A number of files are getting tight on sequence numbers. This impacts future fixes. Proactively address Resolution: VSSI source files start out with a sequence number gap of 10000 between each source line. Over time, as fixes and enhancements are developed, this gap gets filled. We use the following rules of thumb to decide whether or not a source file needs to be resequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is resequenced to reinstate a gap of 10000 between each source line. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 385 (2016-09-02) Modules: RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTQ ASSEMBLE VSSUBR ASSEMBLE

VP550307 VMARC 12/29/16 02:14:11 * Resequence COPY members

Update VP550307 applies to VSSI installation builds through 5522 Symptom: * Resequence COPY members Problem: A number of files are getting tight on sequence numbers. This impacts future fixes. Proactively address Resolution: VSSI source files start out with a sequence number gap of 10000 between each source line. Over time, as fixes and enhancements are developed, this gap gets filled. We use the following rules of thumb to decide whether or not a source file needs to be resequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is resequenced to reinstate a gap of 10000 between each source line. BUILD_Reqd: VSSMMAC Toolmin: 1.0 385 (2016-09-02) Modules: VPBXRCF COPY

VS550307 VMARC 12/29/16 02:13:53 * Resequence COPY members

Update VS550307 applies to VSSI installation builds through 5522 Symptom: * Resequence COPY members Problem: A number of files are getting tight on sequence numbers. This impacts future fixes. Proactively address Resolution: VSSI source files start out with a sequence number gap of 10000 between each source line. Over time, as fixes and enhancements are developed, this gap gets filled. We use the following rules of thumb to decide whether or not a source file needs to be resequenced: - if there are any lines with a gap of 10 or less - if 20% or more of the source lines have gaps of 100 or less. If either of the above applies, the source file is resequenced to reinstate a gap of 10000 between each source line. BUILD_Reqd: VSSIPL VSSMMAC Toolmin: 1.0 385 (2016-09-02) Modules: RVSCMPBK COPY VSMEQU COPY VSMODID COPY

VP550306 VMARC 01/03/17 16:26:43 * HTT001 ABENDs during CCW interpretation

Update VP550306 applies to VSSI installation builds through 5522 Symptom: * HTT001 ABENDs during CCW interpretation Problem: While translating guest CCWs to VPARS database references the following HTT001 abends may occur: HTT001 at RVPCSP+86C on CLI 0(R1),X'A5' HTT001 at RVPDBS+9CA on LG R2,8(R2) Resolution: RVPCSP+86C is at label CDM120 while processing a Write Track Data CCW with the data areas specified by IDAWs. The address in R1 was a host absolute address and this expected to be resolved in AR mode using the ALET in AR1. However, this portion of CCW simulation runs in primary space mode. Code is updated to use a host logical address here and thereby avoid the need for AR mode. This bug was introduced by fix 550205. . RVPDBS+9CA is at label DATAF2D2 while processing a Search ID Equal CCW which has its five byte search argument crossing a page boundary and addressed via a pair of format 2 IDAWs. The address in R2 was the correct host absolute address from the second IDAW and we were in AR mode with the appropriate ALET in AR2. However, a comma had been omitted causing R2 to default to be an index rather than a base register so the address was not resolved using AR mode. A comma has been added to force R2 to be a base register. It seems this bug has been extant since RVPDBS was initially coded circa 2002. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVPCSP ASSEMBLE RVPDBS ASSEMBLE

VS550305 VMARC 12/05/16 16:31:42 * RAS changes to improve dump readability (CP)

Update VS550305 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (CP) Problem: While working on recent problems it became clear that the stack/unstack IORBK/TRQBK trace entries would be more useful if they could be tied back to their related thread of execution. Resolution: The stack and unstack IORBK/TRQBK trace entries contain a fullword eyecatcher. It's been several decades since trace tables were read by eyeballing raw unformatted pages, so the eyecatcher is no longer of any use. In place of the eyecatcher, if we're dealing with an IORBK include IORSAVE and if we're dealing with a TRQBK include TRQWRK1. If any customer reads dumps and wants the updated trace formatting logic to exploit this change please contact VSSI support. BUILD_Reqd: VSSIPL Toolmin: 1.0 385 (2016-09-02) Modules: VSMODID COPY

VP550304 VMARC 12/01/16 04:20:25 * RAS changes to improve dump readability (VPARS/VTA

Update VP550304 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (VPARS/VTAPE) Problem: While working on recent problems it became clear that code could be tweaked to clarify its affects and help with diagnosing problems from dumps in the future. Resolution: Three main changes are addressed by this update. First, throughout the code base there are numerous cases of HCPCOUNT and HCPMINUS being used and code following assuming the macros expanded using certain registers. Where this happening the macros have been updated with the COUNT= parameter to explicitly define which register should be used to contain the updated value during macro expansion. Second, control block chain anchors typically have two words, a forward and a backward pointer. The routines to add and remove control blocks to/from a chain know this and only take the forward anchor as a parameter implicitly knowing the backward anchor follows it. Update code where the routines are called to explicitly HCPXREF the backward pointers so it is clear when they are being referenced/updated. Thirdly, due to changes made by fix 302 any part that invoked the VS6ANCH macro must now also include the VPOPTNS copy member. All parts invoking VS6ANCH now also include VPOPTNS. Additionally, in parts that were hit the opportunity was taken to improve code formatting and modernize the code. Fixes 302, 303 and 304 must be applied together. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VT550304 VMARC 12/01/16 04:20:32 * RAS changes to improve dump readability (VPARS/VTA

Update VT550304 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (VPARS/VTAPE) Problem: While working on recent problems it became clear that code could be tweaked to clarify its affects and help with diagnosing problems from dumps in the future. Resolution: Three main changes are addressed by this update. First, throughout the code base there are numerous cases of HCPCOUNT and HCPMINUS being used and code following assuming the macros expanded using certain registers. Where this happening the macros have been updated with the COUNT= parameter to explicitly define which register should be used to contain the updated value during macro expansion. Second, control block chain anchors typically have two words, a forward and a backward pointer. The routines to add and remove control blocks to/from a chain know this and only take the forward anchor as a parameter implicitly knowing the backward anchor follows it. Update code where the routines are called to explicitly HCPXREF the backward pointers so it is clear when they are being referenced/updated. Thirdly, due to changes made by fix 302 any part that invoked the VS6ANCH macro must now also include the VPOPTNS copy member. All parts invoking VS6ANCH now also include VPOPTNS. Additionally, in parts that were hit the opportunity was taken to improve code formatting and modernize the code. Fixes 302, 303 and 304 must be applied together. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVTADD ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST1 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE

VS550303 VMARC 11/26/16 01:06:55 * RAS changes to improve dump readability (common)

Update VS550303 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (common) Problem: While working on recent problems it became clear that a number of structures could be improved to help with diagnosing problems from dumps in the future. Resolution: Update code to accomodate structure changes made by fix 302, including storing a TOD for each lock operation. Fixes 302, 303 and 304 must be applied together. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTF ASSEMBLE

VP550302 VMARC 11/26/16 01:01:19 * RAS changes to improve dump readability (macros/co

Update VP550302 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (macros/copy) Problem: While working on recent problems it became clear that a number of structures could be improved to help with diagnosing problems from dumps in the future. Resolution: First, most locks have an adjunct defined that includes information about who and which routine obtained/released the lock last. The LKSTAT (lockword status area) is defined by the VSLCKXST macro. Add a field to the status area to hold the TOD when the last operation was performed on the lock. Second, the VPARS root anchor block (VS6ANCH) has had a field added to indicate which VMDUSER field the installation is using. This makes writing dump macros and diagnosis tools that run on the live system easier and less error prone. Additionally numerous other copy members and macros have had their commentary improved in various ways. Fixes 302, 303 and 304 must be applied at the same time. BUILD_Reqd: VSSMMAC Toolmin: 1.0 385 (2016-09-02) Modules: VPCTLBK COPY VPMDSKBK COPY VPTCCTBK COPY VPUSERBK COPY

VT550302 VMARC 11/26/16 01:01:11 * RAS changes to improve dump readability (macros/co

Update VT550302 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (macros/copy) Problem: While working on recent problems it became clear that a number of structures could be improved to help with diagnosing problems from dumps in the future. Resolution: First, most locks have an adjunct defined that includes information about who and which routine obtained/released the lock last. The LKSTAT (lockword status area) is defined by the VSLCKXST macro. Add a field to the status area to hold the TOD when the last operation was performed on the lock. Second, the VPARS root anchor block (VS6ANCH) has had a field added to indicate which VMDUSER field the installation is using. This makes writing dump macros and diagnosis tools that run on the live system easier and less error prone. Additionally numerous other copy members and macros have had their commentary improved in various ways. Fixes 302, 303 and 304 must be applied at the same time. BUILD_Reqd: VSSMMAC Toolmin: 1.0 385 (2016-09-02) Modules: VTSETWK COPY

VS550302 VMARC 11/26/16 01:01:35 * RAS changes to improve dump readability (macros/co

Update VS550302 applies to VSSI installation builds through 5522 Symptom: * RAS changes to improve dump readability (macros/copy) Problem: While working on recent problems it became clear that a number of structures could be improved to help with diagnosing problems from dumps in the future. Resolution: First, most locks have an adjunct defined that includes information about who and which routine obtained/released the lock last. The LKSTAT (lockword status area) is defined by the VSLCKXST macro. Add a field to the status area to hold the TOD when the last operation was performed on the lock. Second, the VPARS root anchor block (VS6ANCH) has had a field added to indicate which VMDUSER field the installation is using. This makes writing dump macros and diagnosis tools that run on the live system easier and less error prone. Additionally numerous other copy members and macros have had their commentary improved in various ways. Fixes 302, 303 and 304 must be applied together. BUILD_Reqd: VSSMMAC Toolmin: 1.0 385 (2016-09-02) Modules: VSLCKXST COPY VSQIOBK COPY VSLCKDEF MACRO VSLCKOP MACRO VSMSGH MACRO VS6ANCH MACRO

VP550301 VMARC 11/21/16 03:23:00 * Possible hung users after fix 288

Update VP550301 applies to VSSI installation builds through 5522 Symptom: * Possible hung users after fix 288 Problem: Users logging off with an open database may hang waiting for a database sync request to complete. The sync request is never recognized so we wait forever. This results in the user stuck in logoff force pending. Resolution: Fix 288 removed a timer short circuit added by fix 191 since it was felt that this short circuit was the cause of an abend. The short circuit had been added to address users hung waiting on a sync (very similar to this problem). With this fix we have been able to dig down to the root cause of the syncs not completing. Code added by fix 97 would skip checking for a sync request if the user was in the midst of a logoff. That code has been reworked so sync requests will be recognized and acted on in all cases. BUILD_Reqd: VSSICP Toolmin: 1.0 385 (2016-09-02) Modules: RVPCCW ASSEMBLE

VP550298 VMARC 08/25/16 08:25:47 * Long delays during system shutdown

Update VP550298 applies to VSSI installation builds through 5522 Symptom: * Long delays during system shutdown Problem: System shutdowns delay for several minutes while VPARS closes it databases. Resolution: Delay during shutdown in a manner that opens an interrupt window allowing timer pops to be recognized in a timely fashion. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPSHU ASSEMBLE

VT550298 VMARC 08/25/16 08:25:51 * Long delays during system shutdown

Update VT550298 applies to VSSI installation builds through 5522 Symptom: * Long delays during system shutdown Problem: System shutdowns delay for several minutes while VTAPE closes it databases. Resolution: Delay during shutdown in a manner that opens an interrupt window allowing timer pops to be recognized in a timely fashion. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVTSHU ASSEMBLE

VP550297 VMARC 08/25/16 08:22:07 * Correct hung user on VxSET CHECKPOINT and LOGOFF

Update VP550297 applies to VSSI installation builds through 5522 Symptom: * Correct hung user on VxSET CHECKPOINT and LOGOFF Problem: Concurrently a VxSET CHECKPOINT is issued while a database reset is underway (often due to a LOGOFF). The VxSET CHECKPOINT thread of execution may not complete resulting in a hung user. Resolution: Fix 272 was a bypass to prevent the hung user. This fix is addressing the root cause. Serialization is improved between RVxSET and RVxRCC so a checkpoint thread can no longer start on a database that is being reset. The bypass added by 272 has been removed. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE

VT550295 VMARC 08/18/16 01:46:08 * ior101 soft abend after VTAPE unload

Update VT550295 applies to VSSI installation builds through 5522 Symptom: * ior101 soft abend after VTAPE unload Problem: Soft abend ior101 possible after a rewind unload of a virtual tape. Internally, VTAPE keeps three (3) counters for active I/O, as follows: 1. Physical I/Os active to the VTAPE database; 2. Logical reads active to the VTAPE database; 3. Logical writes active o the VTAPE database. The logical count is incremented when a buffer is locked in storage for I/O, which can be well before the call to start the physical I/O (where a CP IORBK is allocated and the physical count incremented) and the logical counts are decremented when the buffer is no longer locked. This can happen well after the I/O interrupt comes in which signifies the completion of the physical I/O and the fret of the IORBK and decrement of the physical I/O count. However, the code that was cleaning up when a tape was no longer active on a drive was only considering the physical I/O count when deciding whether the VTAPE was still in use. Finding the physical I/O count zero it fret'ed control blocks and unlocked buffers that were still logically in use. When the CPEBK to complete the logical I/O was dispatched the control blocks and buffer it expected were no longer assigned to their expected roles. In addition to ior101 soft abends, we have also seen a LCK001 hard abend. An HTT001 abend is also a possibility due to this problem. Storage corruption is also possible. Resolution: Code in RVTREWRW has been updated to consider all three counts rather than just the physical I/O count when determining whether all activity for a virtual tape has completed. Additionally, other code reviewed while diagnosing this has had minor updates and clarifications. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTOCT ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTREW ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE

VP550294 VMARC 08/14/16 14:05:07 * Correct defects found during code inspection

Update VP550294 applies to VSSI installation builds through 5522 Symptom: * Correct defects found during code inspection Problem: During code inspections a number of incorrect references to prefix page constants were found. RVxRCC contained MVC SAVER2-SAVBK(R2),PFX8 where R2 was taken as the length rather than as the base register. This bug was introduced by fix 550272. RVxQY3 contained two CLC VPCCKNUM-VPCTL(R8),PFXH1 where R8 was taken as the length rather than as the base register. This bug was introduced by update 530049. RVxDBM contained CH R2,PFX6 doing a halfword compare against a fullword value (the high half of which would always be zero rather than the expected 6). This bug was introduced by update 210066. Resolution: The MVC and CLC's have had commas inserted to force the register to be taken as a base register rather than a length. The CH, has been changed to a CHI. Additionally other code in the area of these updates has had minor cleanup. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPCLR ASSEMBLE RVPDBM ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE

VS550293 VMARC 08/11/16 09:39:34 * Minor MACRO fixups

Update VS550293 applies to VSSI installation builds through 5522 Symptom: * Minor MACRO fixups Problem: Minor MACRO fixups required for the following MACROs: Macro Description VSIPROLG Changed PTF_TAG parameter to PTFID. VS6ANCH Prettification to declare addresses as DC A(0), counters as F'0'. Resolution: The above changes have been made. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: VSMODID COPY VSIPROLG MACRO VS6ANCH MACRO RVSSTL LAS55293

VS550291 VMARC 08/04/16 13:05:03 * New VSIPROLG macro

Update VS550291 applies to VSSI installation builds through 5522 Symptom: * New VSIPROLG macro Problem: The current VSIPROLG macro may be potentially incompatible with future versions of the HCPPROLG macro in the future. This is because VSIPROLG is currently marked as an IBM CP update; it should be marked as a normal VSSI code update. Resolution: Made the following changes: . VSIPROLG has been marked as a normal VSSI code macro via a name change to its AUX file (i.e., from AUXCVSxx (IBM CP) to AUXAVSxx (VSSI CP). . The macro now supports a new parameter (PTFID=), which forces the PTF ID string closer to the top of the module as a debugging aid. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 376 (2016-07-17) Modules: VSMODID COPY VSIPROLG MACRO RVSSTL LAS55291

VP550290 VMARC 08/04/16 14:33:07 * Improve our usage of HCPCOUNT/HCPMINUS

Update VP550290 applies to VSSI installation builds through 5522 Symptom: * Improve our usage of HCPCOUNT/HCPMINUS Problem: HCPCOUNT and HCPMINUS need to "guess" what size operand we've passed them when we just give a base and displacement. Explicitly define the object size. Resolution: HCPCOUNT and HCPMINUS invocations that used only a base and displacement to reference the operand have been updated to explicitly state the operand's size, thereby allowing the macros to accurately determine what instructions need to be generated. BUILD_Reqd: VSSICP Toolmin: 1.0 378 (2016-08-04) Modules: RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPRCC ASSEMBLE

VT550290 VMARC 08/04/16 14:33:13 * Improve our usage of HCPCOUNT/HCPMINUS

Update VT550290 applies to VSSI installation builds through 5522 Symptom: * Improve our usage of HCPCOUNT/HCPMINUS Problem: HCPCOUNT and HCPMINUS need to "guess" what size operand we've passed them when we just give a base and displacement. Explicitly define the object size. Resolution: HCPCOUNT and HCPMINUS invocations that used only a base and displacement to reference the operand have been updated to explicitly state the operand's size, thereby allowing the macros to accurately determine what instructions need to be generated. BUILD_Reqd: VSSICP Toolmin: 1.0 378 (2016-08-04) Modules: RVTDEF ASSEMBLE RVTOPN ASSEMBLE RVTSV2 ASSEMBLE

VP550289 VMARC 08/24/16 17:24:25 * Checkpoints fail after fix 284

Update VP550289 applies to VSSI installation builds through 5522 Symptom: * Checkpoints fail after fix 284 Problem: Checkpoints fail after application of fix 284. Resolution: Fix 284 performed significant code clean up and refactoring. As part of that effort routine RVxSV1OB no longer set its CC to zero (since there is no error exit condition, only successful exits). Since it can't fail, the vast majority of callers already were not checking the CC after calling RVxSV1OB to obtain a buffer. However, the code for SET CHECKPOINT and SET PTV ON were checking the (now indeterminate) CC from RVxSV1OB. Code has been updated to no longer check the CC after calling RVxSV1OB. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPSV3 ASSEMBLE

VP550288 VMARC 08/24/16 17:19:40 * HTT001 during VPARS database reset

Update VP550288 applies to VSSI installation builds through 5522 Symptom: * HTT001 during VPARS database reset Problem: HTT001 after an I/O completes and tries to return to the initiator of the I/O. The control block representing the I/O (an IOTBK) should contain the registers from the initiator of the I/O so they can be restored into a CPEBK and the initiator resumed once the I/O has completed, however, the IOTBK appears to have been released and reused since its save area contains registers unrelated to the just completed I/O. Concurrent with the I/O the user is in process of logging off so their database is being closed. It is believed that the closing code released the IOTBK for the active I/O. The closing code should be waiting for all active I/O to complete but it does contain a very short timer to override waiting for an I/O. Resolution: Code in RVPRCC has had the timer short circuit removed. We will now wait until all active I/O to a database completes before initiating database close. Additionally minor code clean up was performed in related modules. Fix VS550287 contains the CP portion of this fix. VS550287 and VP550288 must be put on at the same time. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCLR ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPIOR ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPSYN ASSEMBLE

VS550287 VMARC 07/17/16 21:00:32 * CP updates for fix 288

Update VS550287 applies to VSSI installation builds through 5522 Symptom: * CP updates for fix 288 Problem: HCPPRV is calling RVPRCCRR to reset the VPARS database for every CPU as it is reset. VPARS only cares when the base CPU goes away. Resolution: Update HCPPRV to only call RVPRCCRR when the base CPU is reset. Note fixes 287 and 288 must go on concurrently. BUILD_Reqd: VSSMMAC Toolmin: 1.0 376 (2016-07-17) Modules: VSMODID COPY

VT550286 VMARC 07/18/16 10:43:49 * Virtual tapes allowed to exceed their size by 1M

Update VT550286 applies to VSSI installation builds through 5522 Symptom: * Virtual tapes allowed to exceed their size by 1M Problem: Unit exception was not being presented when a tape reached its defined size. Data could continue to written until the defined size had been exceeded by 1Meg at which point a unit exception was presented. Resolution: RVTCCW is updated to properly present a unit exception when the defined volume size is reached. A unit check will now be presented when the tape exceeds the defined volume size by 1Meg. This bug was introduced by fix VT550093. Several other modules also have had minor updates (mostly to correct comments). BUILD_Reqd: VSSICP Toolmin: 1.0 376 (2016-07-17) Modules: RVTCCW ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VS550285 VMARC 07/10/16 15:12:15 * HCPABN mod to dump CPXLOADed symbols

Update VS550285 applies to VSSI installation builds through 5522 Symptom: * HCPABN mod to dump CPXLOADed symbols Problem: CPXLOAD symbols are not dumped via soft ABEND. Resolution: Made the following changes to HCPABN: . Added code to store current CR12 value as an aid to soft ABEND dump readability. . Requisite code added to dump CPXLOADed symbols used by VSSI code. BUILD_Reqd: VSSIPL VSSMMAC Toolmin: 1.0 374 (2016-07-08) Modules: VSMODID COPY

VP550284 VMARC 08/24/16 17:14:19 * Clean up VPIOTBK related code

Update VP550284 applies to VSSI installation builds through 5522 Symptom: * Clean up VPIOTBK related code Problem: The VPIOTBK is a control block used for I/O against a VPARS database. Some of the code for managing them is duplicated, some not clear, etc.. Some soft abends are not as helpful as they should be. Resolution: The following changes are included with this fix: - RVxDBM is not defined as a longreg module in RVxMDLAT but is using full 64 bit registers. Since it doesn't have the longreg attribute only the low 32 bits of the registers are saved/restored on module entry and exit. The only reason 64 bit registers were in use was the decision to build the snap dump snaplist in the 64 bit format. This isn't needed so build a 31 bit snap list and stop using the high half of the registers. - Fix an incorrect return branch in the SETMAXU subroutine in RVxSV1. - Both RVxDBM and RVxOPS contain their own code for allocating a VPIOTBK and associated buffers. RVxSV1OB is the canoncial routine for allocating a VPIOTBK. Change RVxDBM and RVxOPS to call RVxSV1OB. - RVxDBM contains code for locking, clearing and unlocking an IOTBK's associated buffer. RVxIOR contains entry points with identical routines for these functions. Call them rather than the duplicated code. - Here's the definitions of VPIOBUF and VPIREALA in VPIOTBK: VPIOBUF DS 0D Host Logical page address $510026 VPIOBUFH DS F Host Logical page high order$510026 VPIOBUFL DS F Host Logical page low order $510026 * $520056 VPIREALA DS 0D Host real page address $510026 VPIREALH DS F Host real page High order $510026 VPIREALL DS F Host real page Low order $510026 The strong implication is that they are both 64 bit addresses but in reality both are 31 bit addresses and used as such via the names VPIOBUF and VPIREALA. So in fact VPIOBUFH and VPIREALH contain the actual addresses not just the high half. Mostly VPIOBUF and VPIREALA are used but the odd time VPIREALH is used. Additionally the name VPIREALA and many comments imply this is a host real address. In fact it is a host logical address. So clean this up by defining VPIOBUF as a 31 bit address and, as well as making VPIREALA a 31 bit address change the name to VPIHOSTA to better reflect its contents (and also clean up the numerous incorrect comments). Additionally field VPIREAL was used to indicate when the value in VPIREALA was actually from free storage and not the address of a translated system virtual page (only done when reading a minidisk's primary control record at open time). Rename this field to VPIFRES and change the flag from R to F. - Many callers of RVxIORTC/RVxIORTR are checking the condition code in case there was some error during translation. However, those two routines only return CC0 and in fact do not even check that HCPTRANS was successful. Add code to reflect back the result of HCPTRANS. - Change when the soft abends are taken to improve problem diagnosis data gathering. Delete code at label BSR997 that attempts to access a previous page. Life doesn't work like that anymore and an HTT001 is the likely result. - We are likely to get an sv1001 soft abend at some point in the future after taking a dbt002 soft abend. The problem is the VPIOTBK is put on the queue before we've fully validated it. When validation fails and the dbt002 is taken we do not remove it from the queue. Delay adding the VPIOTBK to the queue until after it has passed validation. Additionally RVxDBTQA is changed to a dynamic save area rather than savig its registers into the unvalidated VPIOT passed to it. Lastly, fixes 276, 283 and 284 should all be put on at the same time. Failure to apply all three concurrently will result in either assembly errors and/or run time errors. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 382 (2016-08-10) Modules: RVPBUF ASSEMBLE RVPCLR ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE VPFMT ASSEMBLE

VD550283 VMARC 07/08/16 12:52:32 * Macro and copy updates for fixes 276 and 284

Update VD550283 applies to VSSI installation builds through 5522 Symptom: * Macro and copy updates for fixes 276 and 284 Problem: Macro and copy updates for fixes 276 and 284 Resolution: Fixes 276, 283 and 284 should all be put on at the same time. Failure to do so will result in either assembly errors and/or run time errors. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 371 (2016-04-23) Modules: RVDMDLAT MACRO

VP550283 VMARC 07/09/16 03:57:35 * Macro and copy updates for fixes 276 and 284

Update VP550283 applies to VSSI installation builds through 5522 Symptom: * Macro and copy updates for fixes 276 and 284 Problem: Macro and copy updates for fixes 276 and 284 Resolution: Fixes 276, 283 and 284 should all be put on at the same time. Failure to do so will result in either assembly errors and/or run time errors. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 374 (2016-07-08) Modules: VPIOTBK COPY RVPMDLAT MACRO

VS550283 VMARC 07/08/16 13:17:16 * Macro and copy updates for fixes 276 and 284

Update VS550283 applies to VSSI installation builds through 5522 Symptom: * Macro and copy updates for fixes 276 and 284 Problem: Macro and copy updates for fixes 276 and 284 Resolution: Fixes 276, 283 and 284 should all be put on at the same time. Failure to do so will result in either assembly errors and/or run time errors. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 1.0 371 (2016-04-23) Modules: VSDEFXBK COPY VSLOCRBK COPY VSMEQU COPY

VT550282 VMARC 06/03/16 09:14:53 * Soft abend ld1002 on vtape with autoloader

Update VT550282 applies to VSSI installation builds through 5522 Symptom: * Soft abend ld1002 on vtape with autoloader Problem: A tape with an outstanding auto mount is detached. When the mount code gets control the VDEV pointer is no longer valid and the ld1002 soft abend occurs. Resolution: The device number rather than VDEV address is passed to the auto mount code. This is used to look up the VDEV address thus ensuring it is valid. BUILD_Reqd: VSSICP Toolmin: 1.0 371 (2016-04-23) Modules: RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTREW ASSEMBLE

VP550281 VMARC 05/23/16 10:12:26 * Invalid free storage release call in VPUTIL

Update VP550281 applies to VSSI installation builds through 5522 Symptom: * Invalid free storage release call in VPUTIL Problem: When using VPUTIL if error 2150 is received indicating a disk is unavailable for processing, then on exit exit an invalid free storage call is likely. Resolution: VPUTIL is updated to properly dequeue control blocks prior to fret'ing them. BUILD_Reqd: VSSICMS Toolmin: 1.0 371 (2016-04-23) Modules: VPUTIL ASSEMBLE

VP550280 VMARC 08/24/16 17:06:51 * PRG004 in RVxSV1 after timer pop

Update VP550280 applies to VSSI installation builds through 5522 Symptom: * PRG004 in RVxSV1 after timer pop Problem: Each open database has a timer active to ensure periodic maintenance on the database is performed. When the database is closed the timer should be stopped. Occasionally the timer remains running and when it pops it attempts to reference storage that was fret'ed when the database was closed. Resolution: Additional validation is done in the timer pop routine to ensure the database is still open. BUILD_Reqd: VSSICP Toolmin: 1.0 382 (2016-08-10) Modules: RVPCCW ASSEMBLE RVPSV1 ASSEMBLE

VP550278 VMARC 05/05/16 13:59:56 * Failing WRITE CKD for Track 0 records

Update VP550278 applies to VSSI installation builds through 5522 Symptom: * Failing WRITE CKD for Track 0 records Problem: Customer experienced IPL errors after issuing the following commands: . VxSET CHECKPOINT . VxCLOSE . IPL CMS . VxCLEAR CHECKPOINT n . IPL The IPL started normally, but failed with DBM004 after TAPE RESTART was completed. The received error messages were as follows: RVxDBM235E CCW ERROR(CMDREJ) DETECTED AT BLOCK(0000000002); EVENTID(313) RVxDBS055E UNSUPPORTED OR FAILING TPF WRITE CCW CHAIN, VDEVNO=vdev The dumped CCW chain indicated an error on CCHHR 0/0/2 (CCW opcode x'85' - Write Update Data). Resolution: Made the following changes: . Modified RVxDBM Track0 delete/readd procedure to exclude Track0 records if: . Update_Read or Update_Write indicated; . part of a checkpointed set. . Reformatted RVxDBM for better code readability (i.e., EJECT and SPACE directives) . Added diagnostic console output messages as a workaround for z/VM soft ABEND deficiencies. BUILD_Reqd: VSSICP Toolmin: 1.0 371 (2016-04-23) Modules: RVPDBM ASSEMBLE

VP550277 VMARC 04/09/16 10:29:17 * Misc. VPARS/SHDSK CMS updates

Update VP550277 applies to VSSI installation builds through 5522 Symptom: * Misc. VPARS/SHDSK CMS updates Problem: Enhancements requested or required. Resolution: Added the following enhancements: 1. VxUTIL message VSSVxU2152 emitted at the start and end of job, as follows: . VSSVxU2152I Start time: 04/08/16 14:44:40 . VSSVxU2152I End time: 04/08/16 14:45:03 (nnn record(s)/sec) 2. VxUTIL record processing messages now contain timestamps, as follow: Old: VSSVxU2152I 6176 record(s) processed for MOVE New: VSSVxU2152I +hhhh:mm:ss.uuuuuu 6176 record(s) processed for MOVE The timestamp above represents the elapsed time (hh:mm:ss.millionths-seconds) since the start of the job. 3. VxUTIL record directory errors will now print the 1st 16 bytes of the erroneous directory entry. 4. User field (VPUSRUF1 DS F) added to RVPCFGBK (per customer request). BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 370 (2015-08-29) Modules: RVPCFGBK COPY VPUTIL ASSEMBLE

VS550277 VMARC 04/09/16 10:30:25 * Misc. VPARS/SHDSK CMS updates

Update VS550277 applies to VSSI installation builds through 5522 Symptom: * Misc. VPARS/SHDSK CMS updates Problem: Enhancements requested or required. Resolution: Added the following enhancements: 1. VxUTIL message VSSVxU2152 emitted at the start and end of job, as follows: . VSSVxU2152I Start time: 04/08/16 14:44:40 . VSSVxU2152I End time: 04/08/16 14:45:03 (nnn record(s)/sec) 2. VxUTIL record processing messages now contain timestamps, as follow: Old: VSSVxU2152I 6176 record(s) processed for MOVE New: VSSVxU2152I +hhhh:mm:ss.uuuuuu 6176 record(s) processed for MOVE The timestamp above represents the elapsed time (hh:mm:ss.millionths-seconds) since the start of the job. 3. VxUTIL record directory errors will now print the 1st 16 bytes of the erroneous directory entry. 4. User field (VPUSRUF1 DS F) added to RVPCFGBK (per customer request). BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 1.0 370 (2015-08-29) Modules: VSSUME $REPOS

VP550276 VMARC 04/23/16 14:27:44 * Added NOPROMPT to VxFMT command

Update VP550276 applies to VSSI installation builds through 5522 Symptom: * Added NOPROMPT to VxFMT command Problem: VxFMT prompts for the disk volume serial during MDISK format. Resolution: A new option, NOPROMPT, was added to the VxFMT command. If specified, volume serial prompted is bypassed if specified on the command line. BUILD_Reqd: VSSICMS Toolmin: 1.0 371 (2016-04-23) Modules: VPFMT ASSEMBLE

VP550275 VMARC 05/23/16 09:50:55 * RVxDBM Resequence

Update VP550275 applies to VSSI installation builds through 5522 Symptom: * RVxDBM Resequence Problem: RVxDBM has reached its limit on sequence number intervals. Resolution: This update resequences RVxDBM in order to create sufficient space for future updates. No functionality is affected. BUILD_Reqd: VSSICP Toolmin: 1.0 371 (2016-04-23) Modules: RVPDBM ASSEMBLE

VP550274 VMARC 03/03/16 20:45:13 * VxLINK command ignoring CONFIG parameter

Update VP550274 applies to VSSI installation builds through 5522 Symptom: * VxLINK command ignoring CONFIG parameter Problem: Customer was unable to specify the VxLINK command with the CONFIG parameter; the following error was always returned: . RVSCFG011E File VxCONFIG [fm] was not found. Use of VxLINK -without- the CONFIG parameter was processed correctly. The code in RVxCONLK (which processes the command-line parameters) had an incorrect HCPUSING around the EXECUTE instruction used to copy the parameter into the MFCFGNM field, which effectively left the field with all-spaces. Subsequent CONFIG table processing failed because no CONFIG file could be found with a fileid of [all-spaces] VxCONFIG [fm]. Resolution: Code amended to correctly process the CONFIG parameter. BUILD_Reqd: VSSICP Toolmin: 1.0 370 (2015-08-29) Modules: RVPCON ASSEMBLE

VP550273 VMARC 01/19/16 13:48:56 * CCW Command Rejects (code 408) in RVxDBS

Update VP550273 applies to VSSI installation builds through 5522 Symptom: * CCW Command Rejects (code 408) in RVxDBS Problem: Customer experienced CCW command rejects during utility FILECOPY operations. The operation was using Keyed Read/Write CCW commands (Read Count/Key/Data, Write Count/Key/Data) against disk block addresses not located on Cylinder 0, Track 0. CP generated additional CCWs on behalf of the Format Write operation: . 0x07 Seek . 0x31 Search ID Equal . 0x5E Read Multiple Count/Key/Data Read Multiple Count/Key/Data (0x5e) processing in RVxCSP was not properly incrementing through the multiple COUNT fields read from the BASE disk, causing an early termination of the record stream. As a result, BASE disk records were being returned to the guest, even when the corresponding records existed on the database. This particular sequence of Keyed CCW operations (i.e., insertion of the above CP-generated CCWs) rarely occurs during regular TPF or Linux operations. Module RVxCSP harvests IDAWs from each CCW if the CCW needs to come back to VPARS code for further processing. Prior to Keyed IDAW harvesting, RVxCSP decrements the CCW length in order to bypass the Count field of the CCW whose data was just read, or is about to be written. The IDAL data address and length is then passed to the IDAL harvesting routine. In this case, the adjusted length (i.e., original length - 8) was passed (incorrect) instead of the original CCW data length, resulting in the harvesting of less IDAWs than were actually passed by the original guest CCW. When RVxDBS subsequently attempted to move the data to the user's buffers, the operation was rejected (internal event code 408) due to insufficient IDAWs. Resolution: Made the following changes: 1. RVxCSP modified to correctly step through the following multiple-record CCWs: . 0x5E Read Multiple Count/Key/Data . 0xDE Read Track 2. RVxCSP modified to harvest the correct IDAW count. 3. Additional TRACE code added to RVxDBS for diagnostic purposes if the problem should ever recur. BUILD_Reqd: VSSICP Toolmin: 1.0 370 (2015-08-29) Modules: RVPCSP ASSEMBLE RVPDBS ASSEMBLE

VP550272 VMARC 12/01/15 11:06:51 * Hung user if VxSET issued after LOGOFF/FORCE

Update VP550272 applies to VSSI installation builds through 5522 Symptom: * Hung user if VxSET issued after LOGOFF/FORCE Problem: Customer issued a VxCLOSE, followed by a VxSET. CLOSE processing stopped the data timer, but a database SYNC was pending, which prevented the user from full database cleanup. A subsequent SET command (which requires a running DB timer) hung because no timer was active. Resolution: RVxRCC has been modified to check for a pending SYNC operation, and to re-drive the pending SYNC after timer expiration. This action allows the user to clean up all pending activity prior to full LOGOFF. BUILD_Reqd: VSSICP Toolmin: 1.0 370 (2015-08-29) Modules: RVPRCC ASSEMBLE RVPSET ASSEMBLE

VP550270 VMARC 12/01/15 11:03:35 * RVxCSP Resequence

Update VP550270 applies to VSSI installation builds through 5522 Symptom: * RVxCSP Resequence Problem: RVxCSP has reached its limit on sequence number intervals. Resolution: This update resequences RVxCSP in order to create sufficient space for future updates. No functionality is affected. BUILD_Reqd: VSSICP Toolmin: 1.0 370 (2015-08-29) Modules: RVPCSP ASSEMBLE

VS550269 VMARC 08/29/15 16:56:45 * Regression Test Program (RTP)

Update VS550269 applies to VSSI installation builds through 5522 Symptom: * Regression Test Program (RTP) Problem: New Regression Test program VSRPT01. Resolution: New RTP added. No product code is changed. BUILD_Reqd: VSSMMAC Toolmin: 1.0 370 (2015-08-29) Modules: VSMODID COPY

VP550268 VMARC 08/27/15 13:21:00 * Hung user after CSP001 or CCW001 soft ABEND

Update VP550268 applies to VSSI installation builds through 5522 Symptom: * Hung user after CSP001 or CCW001 soft ABEND Problem: Customer experienced the following scenario: . Database reset (via VPCLOSE, LOGOFF, or FORCE); . A pending I/O interrupt occurred after the reset; . CSP001 soft ABEND issued because the VSSI anchor pointer in the VMDBK had already been removed via the database reset code in RVxRCC. In this scenario, the code in RVxCSP: . issues the soft ABEND because the VMDBK anchor was not found; . returns to the dispatcher (HCPDSPCH), leaving the running CPEBK hanging indefinitely. A subsequent LOGOFF or FORCE also hangs indefinitely, because the VMDBK deferred work counter is 1 (representing the hanging CPEBK in the I/O interrupt code path). HCPUSP is waiting until the deferred work counter drops to 0 (which never happens), prior to completing the LOGOFF. Resolution: RVxCSP and RVxCCW have been amended to return an error condition in the calling thread (CPEBK) instead of blindly returning to the dispatcher. BUILD_Reqd: VSSICP Toolmin: 1.0 369 (2015-08-18) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE

VP550267 VMARC 08/19/15 10:33:13 * PRG004 in HCPDGG during volume serial relabel

Update VP550267 applies to VSSI installation builds through 5522 Symptom: * PRG004 in HCPDGG during volume serial relabel Problem: Customer received spurious PRG004 ABENDs when attempting to relabel (via CMS program) a BASE device belonging to an open database configuration. Upon inspection, it was determined that HCPDGG was handling an IORBK that contained a VSSI WRKBK address (VP1WRKBK) instead of the original user SAVEBK address. The address was originally modified by RVxCCW, but not restored when it was determined that the I/O should be passed to HCPIOS (i.e., read the base device directly because the requested record was not found in the VDISK/VPARS database). This is essentially a timing error based on the size of the CCW chain, which determines when the VSSI-modified VP1WRKBK gets freed. Resolution: RVxCCW modified to restore the IORSAVE contents: . after determining the this I/O is actually a BASE I/O; -- and -- . prior to VP1WRKBK release BUILD_Reqd: VSSICP Toolmin: 1.0 369 (2015-08-18) Modules: RVPCCW ASSEMBLE

VP550266 VMARC 08/19/15 08:04:08 * Fix SPXTAPE device error

Update VP550266 applies to VSSI installation builds through 5522 Symptom: * Fix SPXTAPE device error Problem: Customer experienced a situation where virtual tapes were unusable as SPXTAPE devices. The following message was received: . HCPSPK1903E Virtual device xxxx not supported for SPXTAPE A regression in Version 55 returned incorrect Entry Point Addresses (EPAs) for SPXTAPE routing calls. Resolution: Several comments reworked; updated PRODUCT files added. BUILD_Reqd: VSSICP Toolmin: 1.0 369 (2015-08-18) Modules: RVPMSG ASSEMBLE

VT550266 VMARC 08/19/15 08:04:21 * Fix SPXTAPE device error

Update VT550266 applies to VSSI installation builds through 5522 Symptom: * Fix SPXTAPE device error Problem: Customer experienced a situation where virtual tapes were unusable as SPXTAPE devices. The following message was received: . HCPSPK1903E Virtual device xxxx not supported for SPXTAPE A regression in Version 55 returned incorrect Entry Point Addresses (EPAs) for SPXTAPE routing calls. Resolution: Made the following changes: . RVTSPXSU amended to return a valid return code in R15 as well as setting the condition code (cc). . Updated PRODUCT files added. BUILD_Reqd: VSSICP Toolmin: 1.0 369 (2015-08-18) Modules: RVTMSG ASSEMBLE RVTSPX ASSEMBLE RVTSV2 ASSEMBLE

VS550265 VMARC 08/19/15 07:47:29 * Fix SPXTAPE device error

Update VS550265 applies to VSSI installation builds through 5522 Symptom: * Fix SPXTAPE device error Problem: Customer experienced a situation where virtual tapes were unusable as SPXTAPE devices. The following message was received: . HCPSPK1903E Virtual device xxxx not supported for SPXTAPE A regression in Version 55 returned incorrect Entry Point Addresses (EPAs) for SPXTAPE routing calls. Resolution: Made the following changes: . SPXTAPE function EPAs fixed. . Additional support added to correctly return EPAs for stacked use via HCPSTKGT (used by SPXTAPE) BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 369 (2015-08-18) Modules: VSMODID COPY RVSMDLAT MACRO RVSMDLAX MACRO VSCPXCL MACRO VSCPXGT MACRO VSCPXIT MACRO RVSGTA ASSEMBLE RVSGTB ASSEMBLE RVSSKA ASSEMBLE RVSSTL LAS55265

VP550264 VMARC 08/04/15 20:20:56 * New device checker function

Update VP550264 applies to VSSI installation builds through 5522 Symptom: * New device checker function Problem: VRDCBLOK missing from CPYASM listing. Resolution: COPY VRDCBLOK added. BUILD_Reqd: *None* Toolmin: 1.0 368 (2015-07-14) Modules: VPCPYASM ASSEMBLE

VS550263 VMARC 08/07/15 13:16:49 * New device checker function

Update VS550263 applies to VSSI installation builds through 5522 Symptom: * New device checker function Problem: Simple DIAG X'210' device reporter. Resolution: VSDCHK added. BUILD_Reqd: VSSICMS Toolmin: 1.0 368 (2015-07-14) Modules: VS55MAC $EXEC VSDBRDBK MACRO VSDCHK ASSEMBLE VSSUBR ASSEMBLE

VS550262 VMARC 08/04/15 11:46:09 * Add volume serial RELABEL utility

Update VS550262 applies to VSSI installation builds through 5522 Symptom: * Add volume serial RELABEL utility Problem: Customer requested a method for relabeling BASE volumes while the VPARS/VDSIK database is open. Resolution: VSDLBL program added to relabel MDISKs. If the MDISK is linked R/W, the volume serial is updated. If the MDISK is linked R/O and is part of the BASE volumes in an open database, any relabel I/O get written to the VPARS/VDISK database; the underlying MDISK is not modified. BUILD_Reqd: VSSICMS Toolmin: 1.0 368 (2015-07-14) Modules: VSXENTR MACRO VSXEXIT MACRO VSDLBL ASSEMBLE VSSTRC ASSEMBLE VSSUBR ASSEMBLE

VS550260 VMARC 08/04/15 11:33:15 * CMS message repository additions

Update VS550260 applies to VSSI installation builds through 5522 Symptom: * CMS message repository additions Problem: New CMS disk relabel function added. New message numbers required. Resolution: CMS message repository updated. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 1.0 368 (2015-07-14) Modules: VSSUME $REPOS VSMEQU COPY

VP550259 VMARC 07/30/15 12:50:52 * Hung I/O at 100% CPU Utilization

Update VP550259 applies to VSSI installation builds through 5522 Symptom: * Hung I/O at 100% CPU Utilization Problem: Near 100% CPU utilization, code in RVPCCW attempted to delay (pacing) invocation of the next timer interval. This action caused lost interrupts at congestion intervals (i.e., at 100% CPU). Resolution: Pacing code removed; the current timer will always invoke the scheduling of the next timer. BUILD_Reqd: VSSICP Toolmin: 1.0 368 (2015-07-14) Modules: RVPCCW ASSEMBLE

VP550258 VMARC 07/27/15 21:55:16 * Hung I/O at 100% CPU Utilization

Update VP550258 applies to VSSI installation builds through 5522 Symptom: * Hung I/O at 100% CPU Utilization Problem: Near 100% CPU utilization, code in RVPCCW attempted to delay (pacing) invocation of the next timer interval. This action caused lost interrupts at congestion intervals (i.e., at 100% CPU). Resolution: Pacing code removed; the current timer will always invoke the scheduling of the next timer. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 368 (2015-07-14) Modules: VPIOTBK COPY

VP550257 VMARC 06/22/15 11:29:03 * Cleanup queue add/remove calls

Update VP550257 applies to VSSI installation builds through 5522 Symptom: * Cleanup queue add/remove calls Problem: Many VSSI modules make heavy use of the queue management ADD and REMOVE calls (RVSUTLXC, RVSUTLXU) to manage their respective data queues. Each invocation of these calls involves CPXLOAD/CPXUNLOAD code. Resolution: The above calls comprise approximately 75-80% of the CPXLOAD calls into VSSI common code. The above code (approximately 40 lines) has been moved into the static NUC module RVSSTB; all queue management calls will now bypass CPXLOAD semantics. BUILD_Reqd: VSSICP Toolmin: 1.0 363 (2015-06-20) Modules: RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE

VT550257 VMARC 06/22/15 11:29:18 * Cleanup queue add/remove calls

Update VT550257 applies to VSSI installation builds through 5522 Symptom: * Cleanup queue add/remove calls Problem: Many VSSI modules make heavy use of the queue management ADD and REMOVE calls (RVSUTLXC, RVSUTLXU) to manage their respective data queues. Each invocation of these calls involves CPXLOAD/CPXUNLOAD code. Resolution: The above calls comprise approximately 75-80% of the CPXLOAD calls into VSSI common code. The above code (approximately 40 lines) has been moved into the static NUC module RVSSTB; all queue management calls will now bypass CPXLOAD semantics. BUILD_Reqd: VSSICP Toolmin: 1.0 363 (2015-06-20) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQY2 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE

VP550256 VMARC 06/02/15 15:06:13 * FRE016 ABENDs at 100% CPU Utilization

Update VP550256 applies to VSSI installation builds through 5522 Symptom: * FRE016 ABENDs at 100% CPU Utilization Problem: Customer experienced FRE016 ABEND under high (100%) CPU utilization. A race condition between pending database I/O and the VxCLOSE command caused VxCLOSE to free an I/O prior to cleanup by the I/O routines, thus triggering the ABEND. Resolution: Made the following changes: . RVxRCC amended to wait for buffer use to complete prior to cleaning up control blocks referenced by the buffer IOT. BUILD_Reqd: VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: RVPRCC ASSEMBLE

VP550255 VMARC 05/18/15 15:21:17 * Consolidate CPXLOAD Exit Effectors

Update VP550255 applies to VSSI installation builds through 5522 Symptom: * Consolidate CPXLOAD Exit Effectors Problem: Multiple VSCPXCL macros coded in most VSSI modules; this is a manual process which is prone to error. Resolution: New function added to auto-generate all CPXLOAD Exit Effector code for a given VSSI module. BUILD_Reqd: VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: RVPCCW ASSEMBLE RVPPRC ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSHU ASSEMBLE RVPSV2 ASSEMBLE

VT550255 VMARC 05/18/15 15:21:28 * Consolidate CPXLOAD Exit Effectors

Update VT550255 applies to VSSI installation builds through 5522 Symptom: * Consolidate CPXLOAD Exit Effectors Problem: Multiple VSCPXCL macros coded in most VSSI modules; this is a manual process which is prone to error. Resolution: New function added to auto-generate all CPXLOAD Exit Effector code for a given VSSI module. BUILD_Reqd: VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: RVTCCW ASSEMBLE RVTDEF ASSEMBLE RVTPRC ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE

VS550254 VMARC 05/20/15 17:38:25 * Consolidate CPXLOAD Exit Effectors

Update VS550254 applies to VSSI installation builds through 5522 Symptom: * Consolidate CPXLOAD Exit Effectors Problem: Multiple VSCPXCL macros coded in most VSSI modules; this is a manual process which is prone to error. Resolution: New function added to auto-generate all CPXLOAD Exit Effector code for a given VSSI module. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: VSMODID COPY VSCPXIT MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSPRM ASSEMBLE RVSSTF ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55254

VP550253 VMARC 05/18/15 15:20:05 * Updated BUILD function

Update VP550253 applies to VSSI installation builds through 5522 Symptom: * Updated BUILD function Problem: CPXLOAD Exit code generation is scattered over several MACRO/COPY files. Resolution: New function added to set and reset global data fields, eliminating VPTCCTBK dependencies in all HCP and static-NUC RVS modules. BUILD_Reqd: VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: RVPSV1 ASSEMBLE

VS550252 VMARC 05/18/15 15:12:48 * Updated BUILD function

Update VS550252 applies to VSSI installation builds through 5522 Symptom: * Updated BUILD function Problem: CPXLOAD Exit code generation is scattered over several MACRO/COPY files. Resolution: Made the following changes: . Code and BUILD execs consolidated into fewer source objects. . VSSI control block dependencies removed from all HCP modules. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 361 (2015-05-15) Modules: VSCKVDEV MACRO VSCKVMD MACRO VSCPTRC MACRO RVSSTA ASSEMBLE RVSSTB ASSEMBLE

VP550251 VMARC 05/07/15 15:19:46 * Eliminate global CS Lockwords in I/O path

Update VP550251 applies to VSSI installation builds through 5522 Symptom: * Eliminate global CS Lockwords in I/O path Problem: 2 Compare-and-Swap lockwords reside in global VSSI modules. These fullwords are directly in the I/O path, and can cause excessive CPU utilization under very heavy I/O loads. Resolution: Made the following changes: . Both lockwords are used to serialize per-VMDBK resource management (e.g., updating tables unique to each VPARS/VDISK user), and have been moved to a single lockword in the VPTCCTBK (one instance per user). This approach eliminates CS lock contention among all logged-on users for the same lockword. . Modules RVxCCW and RVxCSP amended to use the relocated lockword. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE

VP550250 VMARC 05/07/15 15:17:32 * Eliminate global CS Lockwords in I/O path

Update VP550250 applies to VSSI installation builds through 5522 Symptom: * Eliminate global CS Lockwords in I/O path Problem: 2 Compare-and-Swap lockwords reside in global VSSI modules. These fullwords are directly in the I/O path, and can cause excessive CPU utilization under very heavy I/O loads. Resolution: Both lockwords are used to serialize per-VMDBK resource management (e.g., updating tables unique to each VPARS/VDISK user), and have been moved to a single lockword in the VPTCCTBK (one instance per user). This approach eliminates CS lock contention among all logged-on users for the same lockword. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 355 (2015-04-07) Modules: VPTCCTBK COPY

VP550249 VMARC 04/29/15 10:11:15 * CPU Lockup at 100% Utilization

Update VP550249 applies to VSSI installation builds through 5522 Symptom: * CPU Lockup at 100% Utilization Problem: Customer experienced CPU lockups under high CPU load (98-100%) on a z/VM 6.3 system. Two VSSI locks were implicated in the subsequent dump: . Database WRITE lock (in RVxIOR); . CPXLOAD I/O entry point table lock (in RVSGTB). Excessive lock usage was hanging (throttling) CP during the high utilization periods. Resolution: RVxIOR database WRITE lock usage amended as follows: . VSSI database queue lock usage corrected. This approach should result in measurable savings in both CPU and I/O wait time. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: RVPIOR ASSEMBLE

VT550249 VMARC 04/29/15 10:11:27 * CPU Lockup at 100% Utilization

Update VT550249 applies to VSSI installation builds through 5522 Symptom: * CPU Lockup at 100% Utilization Problem: Customer experienced CPU lockups under high CPU load (98-100%) on a z/VM 6.3 system. Two VSSI locks were implicated in the subsequent dump: . Database WRITE lock (in RVxIOR); . CPXLOAD I/O entry point table lock (in RVSGTB). Excessive lock usage was hanging (throttling) CP during the high utilization periods. Resolution: RVxIOR database WRITE lock usage amended as follows: . VSSI database queue lock usage corrected. This approach should result in measurable savings in both CPU and I/O wait time. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: RVTIOR ASSEMBLE

VS550248 VMARC 04/28/15 18:14:48 * CPU Lockup at 100% Utilization

Update VS550248 applies to VSSI installation builds through 5522 Symptom: * CPU Lockup at 100% Utilization Problem: Customer experienced CPU lockups under high CPU load (98-100%) on a z/VM 6.3 system. Two VSSI locks were implicated in the subsequent dump: . Database WRITE lock (in RVxIOR); . CPXLOAD I/O entry point table lock (in RVSGTB). Excessive lock usage was hanging (throttling) CP during the high utilization periods. Resolution: RVSGTB amended to only use the CPXLOAD lock during the following states: . CPXLOAD initialization (i.e., at IPL time); . First VPARS/VDISK I/O (i.e., routing table initialization of I/O entry points). Previous per-I/O CPXLOAD lock usage (for I/O routing purposes) has been removed; the CPXLOAD lock is no longer in the normal I/O path. This approach should result in measurable savings in both CPU and I/O wait time. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 355 (2015-04-07) Modules: VSCPXGT MACRO

VP550247 VMARC 04/17/15 14:45:14 * LCK001 at VxCLOSE time

Update VP550247 applies to VSSI installation builds through 5522 Symptom: * LCK001 at VxCLOSE time Problem: Customer experienced LCK001 ABENDs under high CPU load (98-100%) on a z/VM 6.3 system. The user had issued a VxCLOSE, which attempted to destroy all database locks. However, the affected lock was not held by the user, resulting in the LCK001 ABEND. Resolution: RVxRCC amended to check lock status prior to attempting to destroy any locks. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: RVPRCC ASSEMBLE

VS550246 VMARC 04/12/15 17:59:39 * Multiple-machine license display is incorrect

Update VS550246 applies to VSSI installation builds through 5522 Symptom: * Multiple-machine license display is incorrect Problem: The VSLSHOW command displays invalid CPUID and serial data for the 2nd and 3rd machines. The internal license structures are fine; all machines will treat the license as valid. Resolution: Made the following changes: . RVSSTB modified to omit MACRO references for unlicensed/uninstalled product components. . RVSSTL modified to correctly display the 2nd and subsequent machine CPUIDs and serial numbers for VSSI multiple-machine licensees. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: VSMODID COPY RVSSTB ASSEMBLE RVSSTL LAS55246

VS550245 VMARC 04/10/15 15:07:57 * Include latest PTF ID in VSQ VSL message

Update VS550245 applies to VSSI installation builds through 5522 Symptom: * Include latest PTF ID in VSQ VSL message Problem: Several customers have requested an easier way to determine the highest PTF number on the system. Resolution: VSQUERY VSLEVEL message output now includes the last-applied PTF number. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: VS55MAC $EXEC RVSCMD ASSEMBLE RVSMSG ASSEMBLE

VP550244 VMARC 04/10/15 15:07:43 * Incorrect Lock Management during DB writes

Update VP550244 applies to VSSI installation builds through 5522 Symptom: * Incorrect Lock Management during DB writes Problem: Update 550217 introduced code that was too restictive, which caused system I/O STALLs, followed by PRG004/006 ABENDs during the following conditions: . Heavy CPU utilization (near 100%) . Large numbers of VPARS users The VSQIOLK lock is a per-MDISK lock; multiple WRITE I/O across multiple MDISKs in the same PMR were contending with SYNC I/O in the timer thread, since SYNC also requires WRITE access to the database. Resolution: RVxIOR amended to conform to pre-550217 behaviour. BUILD_Reqd: VSSICP Toolmin: 1.0 355 (2015-04-07) Modules: RVPIOR ASSEMBLE

VP550243 VMARC 03/30/15 10:37:07 * Database I/O errors after image reloads

Update VP550243 applies to VSSI installation builds through 5522 Symptom: * Database I/O errors after image reloads Problem: Customer encountered I/O errors attempting to reboot a PMR without using the VxOPEN CLEAR option. The PMR had previously been image reloaded, but the IPL records pointing to the alternate image were not found on the database, resulting in the I/O error. A previous update (550211) alterered Track 0 IPL TEXT record update and retrieval in order to allow users to rewrite those records to record sizes larger than those currently in the database (e.g., the user wanted to overlay IPL record 2 - currently at 512 bytes - with a larger image of 664 bytes). The following conditions caused the deletion of the requested Track 0 record from the database prior to the fulfillment of the current Track 0 I/O request: 1. the current request was a WRITE request (i.e., the record was going to be rewritten anyway); 2. the user was not running NOBASE (i.e., force the record to be obtained from the BASE system). Action 1 above is always correct; action 2 is not always correct, because the customer had previously altered the relevant Track 0 IPL TEXT records via an image load. During a subsequent reboot with VPOPEN NOCLEAR, the guest machine was requesting the altered Track 0 records (from the PMR), and -not- the original records from the BASE system. Hence, the returned BASE records did not correspond to the expected image environment, resulting in the I/O error. Resolution: RVxDBM amended to delete and rewrite Track 0 records for WRITE requests only (e.g., during image load generation). All Track 0 READ requests are now satisfied from the database if found there, regardless of BASE/NOBASE status. BUILD_Reqd: VSSICP Toolmin: 1.0 350 (2015-03-30) Modules: RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE

PTFs below apply to Packages at 5520 and lower

VP550242 VMARC 03/06/15 11:46:07 * VPBXPLTB PIST Table Expansion

Update VP550242 applies to VSSI installation builds through 5520 Symptom: * VPBXPLTB PIST Table Expansion Problem: VPBXPLTB currently has a maximum PIST table entry size of 42 entries. A customer attempted to code an OPMAAA table which required more than the maximum number of PIST slots, and was unsuccessful. Resolution: PIST entry table expanded to 256 entries. It is highly unlikely that the new maximum will ever be exceeded ("famous last words!!"). BUILD_Reqd: VSSICMS Toolmin: 1.0 350 (2015-02-20) Modules: VPBXPLTB ASSEMBLE

VP550241 VMARC 03/03/15 09:25:05 * Updated PRODUCT files

Update VP550241 applies to VSSI installation builds through 5520 Symptom: * Updated PRODUCT files Problem: PRODUCT files require miscellaneous updates. Resolution: Amended PRODUCT files attached to this PTF. The dummy update of the RVxMSG modules change no code. BUILD_Reqd: VSSICP Toolmin: 1.0 350 (2015-02-20) Modules: RVPMSG ASSEMBLE

VT550241 VMARC 03/03/15 09:24:52 * Updated PRODUCT files

Update VT550241 applies to VSSI installation builds through 5520 Symptom: * Updated PRODUCT files Problem: PRODUCT files require miscellaneous updates. Resolution: Amended PRODUCT files attached to this PTF. The dummy update of the RVxMSG modules change no code. BUILD_Reqd: VSSICP Toolmin: 1.0 350 (2015-02-20) Modules: RVTMSG ASSEMBLE

VS550241 VMARC 03/03/15 09:25:24 * Updated PRODUCT files

Update VS550241 applies to VSSI installation builds through 5520 Symptom: * Updated PRODUCT files Problem: PRODUCT files require miscellaneous updates. Resolution: Amended PRODUCT files attached to this PTF. The dummy update of the RVxMSG modules change no code. BUILD_Reqd: VSSICP Toolmin: 1.0 350 (2015-02-20) Modules: RVSMSG ASSEMBLE

VP550240 VMARC 02/19/15 17:40:10 * Misc. ABENDs in database queue management

Update VP550240 applies to VSSI installation builds through 5520 Symptom: * Misc. ABENDs in database queue management Problem: Customer encountered the following ABENDs while processing a multiple-MDISK database (PMR) during heavy I/O activity: . HTT001 during database directory scan error recovery . DBT002 during database directory scan error recovery . I/O errors while rebooting TPF (VPOPEN without CLEAR) These errors are all related to errors encountered while attempting to find the requested record in the database. The above errors do not occur if the database consists of a single MDISK. Resolution: RVxDBM amended to properly track database Relative Record values during record directory scans. BUILD_Reqd: VSSICP Toolmin: 1.0 349 (2015-02-11) Modules: RVPDBM ASSEMBLE RVPDBT ASSEMBLE

VP550239 VMARC 02/19/15 17:38:00 * Misc. ABENDs in database queue management

Update VP550239 applies to VSSI installation builds through 5520 Symptom: * Misc. ABENDs in database queue management Problem: Customer encountered the following ABENDs while processing a multiple-MDISK database (PMR) during heavy I/O activity: . HTT001 during database directory scan error recovery . DBT002 during database directory scan error recovery . I/O errors while rebooting TPF (VPOPEN without CLEAR) These errors are all related to errors encountered while attempting to find the requested record in the database. The above errors do not occur if the database consists of a single MDISK. Resolution: Additional bin-number (RELR) tracking fields added to VP1WRKBK. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 349 (2015-02-11) Modules: VP1WRKBK COPY

VS550238 VMARC 02/11/15 13:26:56 * Static-NUC control block cleanup

Update VS550238 applies to VSSI installation builds through 5520 Symptom: * Static-NUC control block cleanup Problem: Several VSSI control blocks are referred to in static-NUC modules. Any changes to these MACRO/COPY files currently force re-assembly of these modules; a subsequent re-IPL is required to integrate the changes. Resolution: This is a dummy update which will force re-assembly of all VSSI modules, thus properly incorporating previous updates 235-237. BUILD_Reqd: VSSMMAC Toolmin: 1.0 349 (2015-02-11) Modules: VSMODID COPY

VP550237 VMARC 02/11/15 13:23:14 * Static-NUC control block cleanup

Update VP550237 applies to VSSI installation builds through 5520 Symptom: * Static-NUC control block cleanup Problem: Several VSSI control blocks are referred to in static-NUC modules. Any changes to these MACRO/COPY files currently force re-assembly of these modules; a subsequent re-IPL is required to integrate the changes. Resolution: Made the following changes: . Several static-NUC modules amended to reduce or eliminate VSSI MACRO/COPY references. This approach should reduce IPL dependencies as VSSI MACRO/COPY files are modified in the future. . VSSIEQU COPY file removed from all VSSI modules and consolidated into the VSCPXID macro. BUILD_Reqd: VSSICP Toolmin: 1.0 349 (2015-02-11) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VT550237 VMARC 02/11/15 13:23:24 * Static-NUC control block cleanup

Update VT550237 applies to VSSI installation builds through 5520 Symptom: * Static-NUC control block cleanup Problem: Several VSSI control blocks are referred to in static-NUC modules. Any changes to these MACRO/COPY files currently force re-assembly of these modules; a subsequent re-IPL is required to integrate the changes. Resolution: Made the following changes: . Several static-NUC modules amended to reduce or eliminate VSSI MACRO/COPY references. This approach should reduce IPL dependencies as VSSI MACRO/COPY files are modified in the future. . VSSIEQU COPY file removed from all VSSI modules and consolidated into the VSCPXID macro. BUILD_Reqd: VSSICP Toolmin: 1.0 349 (2015-02-11) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VS550236 VMARC 02/11/15 13:20:27 * Static-NUC control block cleanup

Update VS550236 applies to VSSI installation builds through 5520 Symptom: * Static-NUC control block cleanup Problem: Several VSSI control blocks are referred to in static-NUC modules. Any changes to these MACRO/COPY files currently force re-assembly of these modules; a subsequent re-IPL is required to integrate the changes. Resolution: Made the following changes: . Several static-NUC modules amended to reduce or eliminate VSSI MACRO/COPY references. This approach should reduce IPL dependencies as VSSI MACRO/COPY files are modified in the future. . VSSIEQU COPY file removed from all VSSI modules and consolidated into the VSCPXID macro. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 349 (2015-02-11) Modules: VSMODID COPY VSSIEQU COPY VSCPXRM MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSPRM ASSEMBLE RVSSTD ASSEMBLE RVSSTG ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55236

VT550235 VMARC 02/11/15 13:20:03 * Static-NUC control block cleanup

Update VT550235 applies to VSSI installation builds through 5520 Symptom: * Static-NUC control block cleanup Problem: Several VSSI control blocks are referred to in static-NUC modules. Any changes to these MACRO/COPY files currently force re-assembly of these modules; a subsequent re-IPL is required to integrate the changes. Resolution: Made the following changes: . Several static-NUC modules amended to reduce or eliminate VSSI MACRO/COPY references. This approach should reduce IPL dependencies as VSSI MACRO/COPY files are modified in the future. . VSSIEQU COPY file removed from all VSSI modules and consolidated into the VSCPXID macro. BUILD_Reqd: VSSICP Toolmin: 1.0 349 (2015-02-11) Modules: RVTTBL ASSEMBLE

VP550234 VMARC 01/30/15 15:02:44 * HTT001 if database directory scan fails

Update VP550234 applies to VSSI installation builds through 5520 Symptom: * HTT001 if database directory scan fails Problem: A directory scan failed on a damaged database. RVxDBM then attempted to inform the user of the error, SNAPDUMP the user's storage, and generate a soft ABEND. However, the SNAPDUMP pointers were built incorrectly, resulting in a hard HTT001 ABEND. Resolution: RVxDBM amended to correctly build the SNAPDUMP pointers. BUILD_Reqd: VSSICP Toolmin: 1.0 344 (2015-01-30) Modules: RVPDBM ASSEMBLE

VT550233 VMARC 01/29/15 11:56:02 * HTT001 at shared-tape rewind

Update VT550233 applies to VSSI installation builds through 5520 Symptom: * HTT001 at shared-tape rewind Problem: Customer had an HTT001 aband during tape rewind in a multi-user, SHARED-tape (Path-Assign) environment. Resolution: RVTREW amended to always check for a valid VTAPE Extension Block address prior to attempted use. BUILD_Reqd: VSSICP Toolmin: 1.0 343 (2015-01-28) Modules: RVTREW ASSEMBLE

VT550232 VMARC 01/28/15 12:36:13 * Convert IOT spin lock to VM lock

Update VT550232 applies to VSSI installation builds through 5520 Symptom: * Convert IOT spin lock to VM lock Problem: The VTAPE IOT lock is a fullword which the code serializes via Compare-And-Swap logic. Resolution: Lock converted to a normal VM lock using VSSI lock management semantics. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTADD ASSEMBLE RVTIOR ASSEMBLE RVTOPN ASSEMBLE RVTSV2 ASSEMBLE

VT550231 VMARC 01/28/15 12:32:46 * Convert IOT spin lock to VM lock

Update VT550231 applies to VSSI installation builds through 5520 Symptom: * Convert IOT spin lock to VM lock Problem: The VTAPE IOT lock is a fullword which the code serializes via Compare-And-Swap logic. Resolution: Lock converted to a normal VM lock using VSSI lock management semantics. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 342 (2014-12-15) Modules: VTIOTBK COPY

VP550230 VMARC 01/28/15 10:07:06 * HTT001 ABEND if invalid DB record detected

Update VP550230 applies to VSSI installation builds through 5520 Symptom: * HTT001 ABEND if invalid DB record detected Problem: An invalid record was detected on the VPARS database. The code in RVPDBM attempted to determine the record ID, generate a soft ABEND DBM004, and reject the CCW. However, the register pointing to the record ID was invalid, generating a hard HTT001. Resolution: RVPDBM amended to bypass record ID determination; no longer required. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPDBM ASSEMBLE

VP550229 VMARC 01/26/15 19:23:55 * Automatic database status displays disabled

Update VP550229 applies to VSSI installation builds through 5520 Symptom: * Automatic database status displays disabled Problem: A regression in update 550174 effectively disabled automatic database status updates. Resolution: Regression removeed. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPCCW ASSEMBLE

VT550228 VMARC 01/26/15 12:41:29 * STK017 received at VTAPE REWIND time

Update VT550228 applies to VSSI installation builds through 5520 Symptom: * STK017 received at VTAPE REWIND time Problem: Customer was using SHARED tape (path-assign). ABEND STK017 occurred at tape rewind time because one of the users in the queue of users sharing the tape had already logged off the system. The resulting VMDBK address in the queue was therefore 0 (correct), but the code attempted to do a VMDBK switch (incorrect). Resolution: RVTREW amended to check for a 0 VMDBK address and bypass the queue entry if the address is 0. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTREW ASSEMBLE

VP550227 VMARC 01/21/15 16:08:27 * Device hangs in FORCE-LOGOFF, NOBASE hangs

Update VP550227 applies to VSSI installation builds through 5520 Symptom: * Device hangs in FORCE-LOGOFF, NOBASE hangs Problem: Customer experienced device hangs at LOGOFF or FORCE-LOGOFF time even after application of update 550219, which only partially addressed this issue. Resolution: RVxIOR amended to stack I/O completion even in the event of a LOGOFF or FORCE condition. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPIOR ASSEMBLE

VS550226 VMARC 01/21/15 16:37:57 * Invalid return code if CPEXIT inactive

Update VS550226 applies to VSSI installation builds through 5520 Symptom: * Invalid return code if CPEXIT inactive Problem: Customer experienced an invalid return code during a CPEXIT call. In a CPEXIT environment, if the requested exit point is not available, the VSCPXIT macro ends with an address in R15 (e.g., a pointer to the CPEXIT Bitmap Table) instead of a return code. Resolution: VSCPXIT macro amended to return rc=1000 if the exit point is not currently active. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 342 (2014-12-15) Modules: VSCPXIT MACRO VSCPXRM MACRO

VT550225 VMARC 01/21/15 07:53:01 * Invalid error code returned from initialization.

Update VT550225 applies to VSSI installation builds through 5520 Symptom: * Invalid error code returned from initialization. Problem: User receives an invalid error code from RVTSV2SI during initialization. Resolution: In RVTSV2SI we now clear SAVER15 on entry. At label SV2EXIT, we now store the correct return code to be evaluated by the caller. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTSV2 ASSEMBLE

VT550224 VMARC 01/16/15 09:01:35 * User recieves undocumented errors during initializ

Update VT550224 applies to VSSI installation builds through 5520 Symptom: * User recieves undocumented errors during initialization. Problem: User recieves undocumented errors during system initialization. User recieves PRG004 when issuing the VTQUERY DEF. Spurious return codes from VT commands when no errors were detected (i.e., no VTAPE error messages issued). Resolution: Made the following changes: Modified to clear the return code vector prior to processing for all calls to RVTSV2SI. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST1 ASSEMBLE

VT550223 VMARC 01/13/15 13:47:13 * ABEND PRG004 when issuing VTQUERY DEFAULTS

Update VT550223 applies to VSSI installation builds through 5520 Symptom: * ABEND PRG004 when issuing VTQUERY DEFAULTS Problem: Customer experienced the following issues: . PRG004 ABENDs when VTQUERY DEF entered, but no virtual tapes defined yet. This error was due due a regression caused by update 550209. . Spurious return codes from VTQUERY commands when no errors were detected (i.e., no VTAPE error messages issued). Resolution: Made the following changes. . RVTSV1 modified to bypass attempt to store a user count into a non-existent user info field. . RVTQY1/2 modified to clear the return code vector prior to processing. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTSV1 ASSEMBLE

VP550222 VMARC 01/21/15 15:56:16 * TRACE enhancements

Update VP550222 applies to VSSI installation builds through 5520 Symptom: * TRACE enhancements Problem: TRACE enhancements required for future CCW code-debugging. Resolution: Enhancements added. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPDBM ASSEMBLE

VS550221 VMARC 01/18/15 14:37:40 * PRG004 if VSLSHOW command issued

Update VS550221 applies to VSSI installation builds through 5520 Symptom: * PRG004 if VSLSHOW command issued Problem: Customer experienced PRG004 ABENDs when the VSLSHOW (Show License) command was issued. R1 at entry is pointing to a GSDBK (setup via CP) instead of to the expected VSSI CPEXIT Parameter List required by RVSSTLX2. The CPEXIT code at entry to RVSSTLX2 picks up the caller's registers from the GSDBK (which of course are invalid, since this is not a VSSI Parameter List), and passes control to RVSSTL02 with incorrect registers (e.g., R11, which now contains an invalid VMDBK address). Resolution: VSLSHOW entry point moved to static NUC module RVSSTB, which will ignore the input GSDBK (since no parameters are required by the command), and correctly set up the VSSI CPEXIT Parameter List. If you have update 550214 applied, it is STRONGLY RECOMMENDED that this update also be applied. In order to address this issue, the installation MUST do as follows after application of this PTF: vssetup setup VSSI SES disks vssiprep rebuild the MACLIB vsbldnuc rebuild static NUC vscopy nuc cf1 cf0 (force copy COMMANDS files to CP PARM disk BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVSSTB ASSEMBLE

VT550220 VMARC 01/05/15 10:03:27 * Resolved HTT001 abends in RVTREW

Update VT550220 applies to VSSI installation builds through 5520 Symptom: * Resolved HTT001 abends in RVTREW Problem: Some users had an HTT001 aband during tape rewind in a multi-user environment. Resolution: Added TPROT for R6 to make sure that VDEV was still valid during a rewind. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTREW ASSEMBLE

VP550219 VMARC 01/15/15 08:37:53 * Device hangs in FORCE-LOGOFF, NOBASE hangs

Update VP550219 applies to VSSI installation builds through 5520 Symptom: * Device hangs in FORCE-LOGOFF, NOBASE hangs Problem: Customer experienced the following issues: . Device hang at FORCE-LOGOFF time. This error is a race condition caused by the timing of the FORCE command vs. the in-flight status of a pending database I/O undertaken on behalf of the BASE disk I/O. . Disk READ errors during NOBASE operation. This issue was caused by a regression introduced by update 550211. Resolution: Made the following changes: . RVxIOR amended to ignore FORCE when transitioning between the I/O scheduling and the I/O interrupt. Once an I/O is started, it should always be allowed to complete. . RVxRCC amended to wait for any in-flight I/Os to BASE disks. . Several I/O-related modules amended to conform to renamed VP1WRKBK fields. . Several I/O-related modules amended to restore proper NOBASE operation. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPCCW ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPRCC ASSEMBLE

VP550218 VMARC 01/14/15 09:18:20 * NOBASE system hang at IPL time

Update VP550218 applies to VSSI installation builds through 5520 Symptom: * NOBASE system hang at IPL time Problem: Customer experienced a base system ABEND during NOBASE system operation. Resolution: Added additional TRACE flags to VP1WRKBK to better triage this issue. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 342 (2014-12-15) Modules: VP1WRKBK COPY

VS550218 VMARC 01/14/15 09:17:43 * NOBASE system hang at IPL time

Update VS550218 applies to VSSI installation builds through 5520 Symptom: * NOBASE system hang at IPL time Problem: Customer experienced a base system ABEND during NOBASE system operation. Resolution: Added additional TRACE flags to VP1WRKBK to better triage this issue. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVSSTF ASSEMBLE

VP550217 VMARC 12/16/14 18:37:59 * Throttled I/O during heavy database WRITEs

Update VP550217 applies to VSSI installation builds through 5520 Symptom: * Throttled I/O during heavy database WRITEs Problem: Customer experienced slow I/O during heavy database WRITE actiivity. A regression introduced by update 550032 changed the database I/O serialization mechanism to use z/VM locks instead of an infinite loop around a spin lock. This approach was correct; however, the selected z/VM lock was defined globally (within the module), and not locally (within the MDISK structures). The update thus had the effect of serializing all database WRITE I/O. Resolution: Code amended to use local MDISK lock (VSQIOLK). BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPIOR ASSEMBLE RVPOPS ASSEMBLE

VT550217 VMARC 12/16/14 18:38:09 * Throttled I/O during heavy database WRITEs

Update VT550217 applies to VSSI installation builds through 5520 Symptom: * Throttled I/O during heavy database WRITEs Problem: Customer experienced slow I/O during heavy database WRITE actiivity. A regression introduced by update 550032 changed the database I/O serialization mechanism to use z/VM locks instead of an infinite loop around a spin lock. This approach was correct; however, the selected z/VM lock was defined globally (within the module), and not locally (within the MDISK structures). The update thus had the effect of serializing all database WRITE I/O. Resolution: Code amended to use local MDISK lock (VSQIOLK). BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVTADD ASSEMBLE RVTIOR ASSEMBLE RVTOPN ASSEMBLE

VS550216 VMARC 12/16/14 18:34:58 * Throttled I/O during heavy database WRITEs

Update VS550216 applies to VSSI installation builds through 5520 Symptom: * Throttled I/O during heavy database WRITEs Problem: Customer experienced slow I/O during heavy database WRITE actiivity. A regression introduced by update 550032 changed the database I/O serialization mechanism to use z/VM locks instead of an infinite loop around a spin lock. This approach was correct; however, the selected z/VM lock was defined globally (within the module), and not locally (within the MDISK structures). The update thus had the effect of serializing all database WRITE I/O. Resolution: Serialization lock moved into the VSQIOBK structure (hung off the target database MDISK). I/O serialization now properly occurs among I/O queued to the same database MDISK (as it should be), and NOT across the entire system. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 342 (2014-12-15) Modules: VSQIOBK COPY

VP550215 VMARC 12/11/14 04:28:57 * Move static-NUC modules to CPXLOADed TXTLIB

Update VP550215 applies to VSSI installation builds through 5520 Symptom: * Move static-NUC modules to CPXLOADed TXTLIB Problem: VPARS initialization calls a static NUC entry point for license file checks, but the static entry point no longer exists (i.e., moved to the CPXLOAD environment by update 550214). Resolution: Calling sequence amended to call CPXLOADed entry point. BUILD_Reqd: VSSICP Toolmin: 1.0 341 (2014-12-11) Modules: RVPSV1 ASSEMBLE

VT550215 VMARC 12/11/14 04:29:09 * Move static-NUC modules to CPXLOADed TXTLIB

Update VT550215 applies to VSSI installation builds through 5520 Symptom: * Move static-NUC modules to CPXLOADed TXTLIB Problem: VTAPE initialization calls a static NUC entry point for license file checks, but the static entry point no longer exists (i.e., moved to the CPXLOAD environment by update 550214). Resolution: Calling sequence amended to call CPXLOADed entry point. BUILD_Reqd: VSSICP Toolmin: 1.0 341 (2014-12-11) Modules: RVTSV2 ASSEMBLE

VS550214 VMARC 12/11/14 04:23:58 * Move static-NUC modules to CPXLOADed TXTLIB

Update VS550214 applies to VSSI installation builds through 5520 Symptom: * Move static-NUC modules to CPXLOADed TXTLIB Problem: Several VSSI modules reside in the static CP nucleus which can be safely moved to the CPXLOADed TXTLIB. Resolution: Selected modules moved. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 341 (2014-12-11) Modules: VSMODID COPY RVSMDLAT MACRO RVSMDLAX MACRO VSCPTRC MACRO VSSTL MACRO RVSSTA ASSEMBLE RVSSTD ASSEMBLE RVSSTF ASSEMBLE RVSSTL LAS55214

VT550213 VMARC 11/26/14 16:45:10 * PRG0004 during RVTREW

Update VT550213 applies to VSSI installation builds through 5520 Symptom: * PRG0004 during RVTREW Problem: In a shared tape environment, the customer experienced intermittent PRG0004 ABENDs at tape rewind time. Module RVTREW assumed that the tape VDEV was an active VDEV device (VDEVVTXB = a valid address); this address was in fact zero. Resolution: RVTREW is modified to bypass further processing if the virtual device has already been released from VTAPE control (i.e, if VDEVVTXB = 0). BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTREW ASSEMBLE

VP550212 VMARC 11/14/14 13:30:33 * Prevent VPARS/VDISK command conflicts

Update VP550212 applies to VSSI installation builds through 5520 Symptom: * Prevent VPARS/VDISK command conflicts Problem: VPARS commands can operate on VDISK database structures, and vice-versa. This can cause database corruption and/or system ABENDs. Resolution: All command entry points will now check the operating environment, and disallow commands which do not match the current environment. Preliminary code has also been added to force users into WAIT mode across CPXUNLOAD/CPXLOAD recycles. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPIFC ASSEMBLE RVPSET ASSEMBLE RVPSV2 ASSEMBLE

VT550212 VMARC 11/14/14 13:30:41 * VTAPE command management

Update VT550212 applies to VSSI installation builds through 5520 Symptom: * VTAPE command management Problem: The VTAPE environment requires that users be placed into WAIT mode across CPXUNLOAD/CPXLOAD recycles. Resolution: Preliminary code added. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST1 ASSEMBLE RVTSV2 ASSEMBLE

VP550211 VMARC 12/16/14 18:31:59 * CCW IDAW Processing Errors (Phase 4 Final)

Update VP550211 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 4 Final) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. Resolution: RVPDBS IDAW processing code amended in order to conform to front-end code in RVPCSP. BUILD_Reqd: VSSICP Toolmin: 1.0 342 (2014-12-15) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE

VP550210 VMARC 11/04/14 14:02:29 * CCW IDAW Processing Errors (Phase 4 Final)

Update VP550210 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 4 Final) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. Resolution: VPCHCCW amended to final format. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VPCHCCW COPY

VS550210 VMARC 11/04/14 14:02:19 * CCW IDAW Processing Errors (Phase 4 Final)

Update VS550210 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 4 Final) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. Resolution: VSCMDCHK added to VS55MAC EXEC list. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VS55MAC $EXEC RVSSTB ASSEMBLE

VT550209 VMARC 11/14/14 13:28:28 * Fix "one-off" counters

Update VT550209 applies to VSSI installation builds through 5520 Symptom: * Fix "one-off" counters Problem: When a volume is scratched, the user volume count gets decremented twice. Resolution: Removed the offending code. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTSCR ASSEMBLE RVTSV1 ASSEMBLE

VT550208 VMARC 10/31/14 15:30:32 * Additional VTAPE TRACE points

Update VT550208 applies to VSSI installation builds through 5520 Symptom: * Additional VTAPE TRACE points Problem: Additional TRACE points needed for enhanced diagnosis. Resolution: TRACE points added. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTMET ASSEMBLE RVTQY2 ASSEMBLE RVTSCR ASSEMBLE RVTST1 ASSEMBLE RVTSV1 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VT550207 VMARC 10/31/14 15:20:11 * Additional VTAPE TRACE points

Update VT550207 applies to VSSI installation builds through 5520 Symptom: * Additional VTAPE TRACE points Problem: Additional TRACE points needed for enhanced diagnosis. Resolution: TRACE points added. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VTACTBK COPY

VS550207 VMARC 10/31/14 15:07:38 * Additional VTAPE TRACE points

Update VS550207 applies to VSSI installation builds through 5520 Symptom: * Additional VTAPE TRACE points Problem: Additional TRACE points needed for enhanced diagnosis. Resolution: TRACE points added. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VSCPTRC MACRO

VP550205 VMARC 11/18/14 16:50:05 * CCW IDAW Processing Errors (Phase 3)

Update VP550205 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 3) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. Resolution: VSSI front-end CCW processor (RVPCSP) amended to correctly manage 64-bit IDAWs for the above CCWs. Back-end support in RVPDBS will be provided in a separate update. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCSP ASSEMBLE

VP550204 VMARC 10/21/14 07:29:57 * CCW IDAW Processing Errors (Phase 3)

Update VP550204 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 3) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. Resolution: VPDCSBK and VPCHCCW structures amended to final format. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VPCHCCW COPY VPDCSBK COPY

VS550204 VMARC 10/21/14 07:29:21 * CCW IDAW Processing Errors (Phase 3)

Update VS550204 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 3) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. . LCK001 ABEND during VPCLOSE. During VPCLOSE cleanup, an attempt was made to serialize and then destroy a lock that had already been destroyed, resulting in a LCK001 ABEND. Resolution: Made the following changes: . VSCMDCHK macro added for future usage. (prevents VPARS command execution in a VDISK environment, and vice-versa) . LOCK entry points in RVSSTB amended to bypass processing if the lock is already destroyed. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VSCMDCHK MACRO RVSSTB ASSEMBLE

VP550203 VMARC 10/15/14 18:01:30 * HTT001 ABENDs if running in an XRC environment

Update VP550203 applies to VSSI installation builds through 5520 Symptom: * HTT001 ABENDs if running in an XRC environment Problem: Customer had the following processing environment: . a z/VM 6.3 system . a very heavy VPARS-related workload . an XRC-enabled DASD subsystem Occasionally, the system crashed with an HTT001 ABEND while performing VPARS I/O. Upon closer inspection, it was determined that a race condition existed between the freeing of a key control block used to manage I/O operations (VPCHCCW) and the use of fields within the VPCHCCW by I/O interrupt routines. z/VM 6.3 makes use of a more efficient memory allocation algorithm than previous z/VM releases, causing the system to reuse the same memory address (for the same size block) as old VPCHCCWs were freed, and new VPCHCCW blocks (or any other blocks within the same size range) were allocated. However, since these blocks were driving XRC-enabled DASD, I/O interrupt routines sometimes updated block data after the storage had already been released and reassigned to another task (e.g., to VSSI PARM disk parser code). The storage corruption caused the HTT001 ABEND. Resolution: I/O-related code amended to defer VPCHCCW release until the XRC timestamp has been updated by the I/O routines. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCSP ASSEMBLE

VP550201 VMARC 10/13/14 12:49:49 * HTT001 ABENDs if running in an XRC environment

Update VP550201 applies to VSSI installation builds through 5520 Symptom: * HTT001 ABENDs if running in an XRC environment Problem: Customer had the following processing environment: . a z/VM 6.3 system . a very heavy VPARS-related workload . an XRC-enabled DASD subsystem Occasionally, the system crashed with an HTT001 ABEND while performing VPARS I/O. Upon closer inspection, it was determined that a race condition existed between the freeing of a key control block used to manage I/O operations (VPCHCCW) and the use of fields within the VPCHCCW by I/O interrupt routines. z/VM 6.3 makes use of a more efficient memory allocation algorithm than previous z/VM releases, causing the system to reuse the same memory address (for the same size block) as old VPCHCCWs were freed, and new VPCHCCW blocks (or any other blocks within the same size range) were allocated. However, since these blocks were driving XRC-enabled DASD, I/O interrupt routines sometimes updated block data after the storage had already been released and reassigned to another task (e.g., to VSSI PARM disk parser code). The storage corruption caused the HTT001 ABEND. Resolution: I/O-related code amended to defer VPCHCCW release until the XRC timestamp has been updated by the I/O routines. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE

VP550200 VMARC 10/11/14 17:03:17 * HTT001 ABENDs if running in an XRC environment

Update VP550200 applies to VSSI installation builds through 5520 Symptom: * HTT001 ABENDs if running in an XRC environment Problem: Customer had the following processing environment: . a z/VM 6.3 system . a very heavy VPARS-related workload . an XRC-enabled DASD subsystem Periodically, the system crashed with an HTT001 ABEND while performing VPARS I/O. Upon closer inspection, it was determined that a race condition existed between the freeing of a key control block used to manage I/O operations (VPCHCCW) and the use of fields within the VPCHCCW by I/O interrupt routines. z/VM 6.3 makes use of a more efficient memory allocation algorithm than previous z/VM releases, causing the system to reuse the same memory address (for the same size block) as old VPCHCCWs were freed, and new VPCHCCW blocks (or any other blocks within the same size range) were allocated. However, since these blocks were driving XRC-enabled DASD, I/O interrupt routines sometimes updated block data after the storage had already been released and reassigned to another task (e.g., to VSSI PARM disk parser code). The storage corruption caused the HTT001 ABEND. Resolution: VP1WRKBK amanded to indicate I/O running for a XRC-capable device. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VPCHCCW COPY VP1WRKBK COPY

VP550199 VMARC 10/07/14 14:39:36 * Baseless addressing phase 5

Update VP550199 applies to VSSI installation builds through 5520 Symptom: * Baseless addressing phase 5 Problem: Several remaining EXECUTE instructions are not unbased; e.g: . BCTR R3,R0 (OK) . BrU *+10 (OK) . MVC STRUCT1,SOMEVAR (Problem; BASED target) . EX R3,*-6 (Problem; BASED instruc.) Resolution: Changed EXECUTE instructions to conform to unbased semantics; e.g: . BCTR R3,R0 . EX R3,MYLABEL . ... ... . ... ... . HCPDATA MAIN,CONTINUE,DATA . MYLABEL MVC STRUCT1,SOMEVAR . HCPDATA MAIN,CONTINUE,CODE BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCLR ASSEMBLE

VT550199 VMARC 10/07/14 14:39:47 * Baseless addressing phase 5

Update VT550199 applies to VSSI installation builds through 5520 Symptom: * Baseless addressing phase 5 Problem: Several remaining EXECUTE instructions are not unbased; e.g: . BCTR R3,R0 (OK) . BrU *+10 (OK) . MVC STRUCT1,SOMEVAR (Problem; BASED target) . EX R3,*-6 (Problem; BASED instruc.) Resolution: Changed EXECUTE instructions to conform to unbased semantics; e.g: . BCTR R3,R0 . EX R3,MYLABEL . ... ... . ... ... . HCPDATA MAIN,CONTINUE,DATA . MYLABEL MVC STRUCT1,SOMEVAR . HCPDATA MAIN,CONTINUE,CODE BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTCON ASSEMBLE

VT550198 VMARC 09/24/14 15:05:05 * Handle broken Volume Descriptor entries

Update VT550198 applies to VSSI installation builds through 5520 Symptom: * Handle broken Volume Descriptor entries Problem: A previous PTF release inadvertently changed the DSECT of the VTAPE Volume Descriptor. This problem was only in that one PTF and resulted in an issue when VTRPT1 created a scratch report. Any tapes created with the old PTF would not show thier Volser in the scratch report. Resolution: VTRPT1 has been updated to recognize the problem descriptor and extract the Volume and Library at the correct offsets. BUILD_Reqd: VSSICMS Toolmin: 1.0 338 (2014-08-01) Modules: VTRPT1 ASSEMBLE

VS550197 VMARC 10/07/14 14:37:12 * Baseless addressing phase 5

Update VS550197 applies to VSSI installation builds through 5520 Symptom: * Baseless addressing phase 5 Problem: Several remaining EXECUTE instructions are not unbased; e.g: . BCTR R3,R0 (OK) . BrU *+10 (OK) . MVC STRUCT1,SOMEVAR (Problem; BASED target) . EX R3,*-6 (Problem; BASED instruc.) Resolution: Changed EXECUTE instructions to conform to unbased semantics; e.g: . BCTR R3,R0 . EX R3,MYLABEL . ... ... . ... ... . HCPDATA MAIN,CONTINUE,DATA . MYLABEL MVC STRUCT1,SOMEVAR . HCPDATA MAIN,CONTINUE,CODE BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VSMODID COPY RVSCFG ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55197

VP550196 VMARC 09/24/14 15:11:03 * CCW IDAW Processing Errors (Phase 2)

Update VP550196 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 2) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. . I/O operations may fail to complete in RVxCCW in FORCE or LOGOFF modes. Resolution: Amended RVxCCW to always issue the required ASYNC tasks (CPEBKs) to free the RDEV lock even if in LOGOFF/FORCE status. 64-bit IDAW updates will be covered in a subsequent PTF. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPQY3 ASSEMBLE

VP550195 VMARC 09/24/14 15:07:26 * CCW IDAW Processing Errors (Phase 2)

Update VP550195 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 2) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. . I/O operations may fail to complete in RVxCCW in FORCE or LOGOFF modes. Resolution: Additional IDAW tracking fields added for 64-bit IDAWs. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VP55MAC $EXEC VPCHCCW COPY VPDCSBK COPY VP1WRKBK COPY

VS550195 VMARC 09/24/14 15:08:59 * CCW IDAW Processing Errors (Phase 2)

Update VS550195 applies to VSSI installation builds through 5520 Symptom: * CCW IDAW Processing Errors (Phase 2) Problem: This update addresses the following issues: . 64-bit IDAWs are incorrectly copied in RVxCSP for the following CCW OPcodes: . x'5E' - Read Multiple Count/Key/Data . x'DE' - Read Track . x'A5' - Write Track Data . x'A6' - Read Track Data The second or subsequent IDAW has an address of 0x0, which causes the CCW to be rejected by VPARS/VDISK. This issue affects ShadowDisk/Z only; VPARS TPF machines do not issue the above CCWs. . I/O operations may fail to complete in RVxCCW in FORCE or LOGOFF modes. Resolution: Additional IDAW tracking fields added for 64-bit IDAWs. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VS55MAC $EXEC VSCLSTOR MACRO VSMVSTOR MACRO RVSSTD ASSEMBLE

VS550194 VMARC 09/05/14 14:39:02 * Bump to Build 5520

Update VS550194 applies to VSSI installation builds through 5520 Symptom: * Bump to Build 5520 Problem: Bump to Build 5520. Resolution: Made the following changes: . License expiration code amendded to issue expiration messages to OPERATOR console only; message frequency reduced to once per hour. . Deprecated LOCK macros (VSLCKxx and friends) removed. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VSMODID COPY RVSSTL LAS55194

PTFs below apply to Packages at 5518 and lower

VP550193 VMARC 08/30/14 18:16:05 * CCW IDAW Processing Errors (Phase 1)

Update VP550193 applies to VSSI installation builds through 5518 Symptom: * CCW IDAW Processing Errors (Phase 1) Problem: 64-bit IDAWs are incorrectly copied in RVxCSP. The first IDAW has an address of 0x00000000, which causes the CCW to be rejected by VPARS/VDISK. Resolution: VSSI modules amended to support redefined VPCHCCW/VSIDAWD fields. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE VPCPYASM ASSEMBLE

VT550193 VMARC 08/30/14 18:16:26 * CCW IDAW Processing Errors (Phase 1)

Update VT550193 applies to VSSI installation builds through 5518 Symptom: * CCW IDAW Processing Errors (Phase 1) Problem: 64-bit IDAWs are incorrectly copied in RVxCSP. The first IDAW has an address of 0x00000000, which causes the CCW to be rejected by VPARS/VDISK. Resolution: VSSI modules amended to print redefined VPCHCCW/VSIDAWD fields. BUILD_Reqd: *None* Toolmin: 1.0 338 (2014-08-01) Modules: VTCPYASM ASSEMBLE

VP550192 VMARC 08/29/14 16:01:04 * CCW IDAW Processing Errors

Update VP550192 applies to VSSI installation builds through 5518 Symptom: * CCW IDAW Processing Errors Problem: 64-bit IDAWs are incorrectly copied in RVxCSP. The first IDAW has an address of 0x00000000, which causes the CCW to be rejected by VPARS/VDISK. Resolution: Made the following changes: . VPCHCCW macro updated for further IDAW tracking. . VSIDAWD macro updated to conform to naming standards. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VPCHCCW COPY

VS550192 VMARC 08/29/14 16:00:04 * CCW IDAW Processing Errors

Update VS550192 applies to VSSI installation builds through 5518 Symptom: * CCW IDAW Processing Errors Problem: 64-bit IDAWs are incorrectly copied in RVxCSP. The first IDAW has an address of 0x00000000, which causes the CCW to be rejected by VPARS/VDISK. Resolution: Made the following changes: . VPCHCCW macro updated for further IDAW tracking. . VSIDAWD macro updated to conform to naming standards. . RVSSTB amended to support RDEV/VDEV lock calls; will be completed via a subsequent update. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VS55MAC $EXEC VSIDAWD COPY VSLCKDEV MACRO RVSSTB ASSEMBLE

VP550191 VMARC 08/26/14 13:13:31 * Hung user with SYNC in progress

Update VP550191 applies to VSSI installation builds through 5518 Symptom: * Hung user with SYNC in progress Problem: Customer had links to R/O databases in DB concatenation at VxOPEN time. The R/O databases were open R/W by another virtual machine. This condition caused the database OPEN to fail; installation automation routines then attempted to issue a VxFCLOSE command to the R/O user (i.e., to force-close the database). This command called VxCLOSE, which then called VxRESET. The VxRESET code hung waiting for SYNC flags to be reset. Resolution: Code amended to zero out the SYNC flags and to continue the RESET if the SYNC is unresponsive. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPRCC ASSEMBLE

VS550190 VMARC 08/30/14 17:34:12 * Baseless Addressing phase 4

Update VS550190 applies to VSSI installation builds through 5518 Symptom: * Baseless Addressing phase 4 Problem: Many VSSI modules use EXECUTE instructions whose target instruction may exceed base register constraints. Resolution: Modules amended to relocate target instructions via HCPDATA directives. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VSMODID COPY RVSCMD ASSEMBLE RVSSTD ASSEMBLE RVSSTN ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55190

VT550189 VMARC 08/30/14 17:33:58 * Baseless Addressing phase 3

Update VT550189 applies to VSSI installation builds through 5518 Symptom: * Baseless Addressing phase 3 Problem: Many VSSI modules use EXECUTE instructions whose target instruction may exceed base register constraints. Resolution: Modules amended to relocate target instructions via HCPDATA directives. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTLD1 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE

VP550188 VMARC 08/20/14 17:09:07 * Hung user with Timer stopped at SYNC time

Update VP550188 applies to VSSI installation builds through 5518 Symptom: * Hung user with Timer stopped at SYNC time Problem: Customer had links to R/O databases in DB concatenation at VxOPEN time. The R/O databases were open R/W by another virtual machine. This condition caused the database OPEN to fail; installation automation routines then attempted to issue a VPSET CHECKPOINT command to the R/W user (i.e., to write all changed records to the database via an internal SYNC process). The VPSET CHECKPOINT command then hung the userid, requiring an IPL to free (i.e., FORCE/LOGOFF PENDING). During dump inspection, it was determined that no database timer was running on the R/W user. Since VPSET requires a SYNC, and since no timer was running to perform that SYNC, the VPSET command for the R/W user was hung waiting for a SYNC completion which never came. Apparently, the failed OPEN (for the R/O user) inadvertently stopped the timer for the R/W user. Resolution: Code amended to only stop timers for the primary database only, and to ignore resets for all linked R/O databases. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPRCC ASSEMBLE

VP550187 VMARC 08/18/14 12:46:33 * Symbolic Lock Consolidation

Update VP550187 applies to VSSI installation builds through 5518 Symptom: * Symbolic Lock Consolidation Problem: A significant number of VSSI modules use symbolic locks. Symbolic lock diagnosis is difficult due the number of modules using these lock types. Resolution: All VPARS modules now use the VSLCKSYM macro instead of direct calls to HCPLOC entry points. This approach consolidates all symbolic lock operations in a single VSSI service module (RVSSTB). This update should be applied concurrently with update 550186; e.g.: vsptf 186-187 BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPRCC ASSEMBLE RVPSV2 ASSEMBLE

VT550187 VMARC 08/18/14 12:46:55 * Symbolic Lock Consolidation

Update VT550187 applies to VSSI installation builds through 5518 Symptom: * Symbolic Lock Consolidation Problem: A significant number of VSSI modules use symbolic locks. Symbolic lock diagnosis is difficult due the number of modules using these lock types. Resolution: All VTAPE modules now use the VSLCKSYM macro instead of direct calls to HCPLOC entry points. This approach consolidates all symbolic lock operations in a single VSSI service module (RVSSTB). This update should be applied concurrently with update 550186; e.g.: vsptf 186-187 BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST1 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE

VS550186 VMARC 08/18/14 12:40:23 * Symbolic Lock Consolidation

Update VS550186 applies to VSSI installation builds through 5518 Symptom: * Symbolic Lock Consolidation Problem: A significant number of VSSI modules use symbolic locks. Symbolic lock diagnosis is difficult due the number of modules using these lock types. Resolution: VSLCKSYM macro added for all symbolic lock operations. This approach consolidates all symbolic lock operations in a single VSSI service module (RVSSTB). This update should be applied concurrently with update 550187; e.g.: vsptf 186-187 BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: VS55MAC $EXEC VSLCKSYM MACRO RVSSTB ASSEMBLE

VP550185 VMARC 08/13/14 12:03:00 * Baseless Addressing phase 2

Update VP550185 applies to VSSI installation builds through 5518 Symptom: * Baseless Addressing phase 2 Problem: Many VSSI modules use EXECUTE instructions whose target instruction may exceed base register constraints. Resolution: Modules amended to relocate target instructions via HCPDATA directives. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSV2 ASSEMBLE

VP550184 VMARC 08/12/14 15:25:57 * Hung users at LOGOFF/FORCE time

Update VP550184 applies to VSSI installation builds through 5518 Symptom: * Hung users at LOGOFF/FORCE time Problem: Customer experienced several hangs at LOGOFF/FORCE time. The hangs were timing-related and difficult to duplicate. Symptoms were one or more of the following: . LOGOFF/FORCE PENDING on the userid . Hung database if the user was successfully logged off and immediately re-IPLed (CMS, TPF, or ShadowDisk/Z). The VPCLOSE process emits several async tasks (CPEBKs), which were colliding with each other on faster CPUs (z196, zEC12, etc). Resolution: Made the following changes: . RVxRCC amended to: . force symbolic lock release regardless of FORCE/LOGOFF status. Continued lock retention was holding up FORCE (and sometimes LOGOFF) . wait for timing-related events (pacing - e.g., active I/O, Console Function Mode) until the event clears, or for a max of 2 seconds (whichever occurs first). BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVPRCC ASSEMBLE

VT550184 VMARC 08/12/14 15:27:31 * Hung users at LOGOFF/FORCE time

Update VT550184 applies to VSSI installation builds through 5518 Symptom: * Hung users at LOGOFF/FORCE time Problem: Customer experienced several hangs at LOGOFF/FORCE time. The hangs were timing-related and difficult to duplicate. Symptoms were one or more of the following: . LOGOFF/FORCE PENDING on the userid . Hung database if the user was successfully logged off and immediately re-IPLed (CMS, TPF, or ShadowDisk/Z). The VPCLOSE process emits several async tasks (CPEBKs), which were colliding with each other on faster CPUs (z196, zEC12, etc). Resolution: Made the following changes: . Several VTAPE modules amended to use VSLCKOP instead of HCPLCKcc. This approach centralizes lock management in VSSI code (RVSSTB). BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTIOR ASSEMBLE RVTRST ASSEMBLE RVTSUM ASSEMBLE

VS550183 VMARC 08/12/14 15:07:10 * Hung users at LOGOFF/FORCE time

Update VS550183 applies to VSSI installation builds through 5518 Symptom: * Hung users at LOGOFF/FORCE time Problem: Customer experienced several hangs at LOGOFF/FORCE time. Resolution: Diagnostic functions enhanced to support verbose lock reporting. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE

VP550182 VMARC 08/12/14 12:34:13 * CCW IDAW Processing Errors

Update VP550182 applies to VSSI installation builds through 5518 Symptom: * CCW IDAW Processing Errors Problem: 64-bit IDAWs are incorrectly copied in RVxCSP. The first IDAW has an address of 0x00000000, which causes the CCW to be rejected by VPARS/VDISK. Resolution: VPCHCCW amended to support additional IDAW tracking fields. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VPCHCCW COPY

VT550181 VMARC 08/06/14 15:28:03 * VTSALIB Cleanup

Update VT550181 applies to VSSI installation builds through 5518 Symptom: * VTSALIB Cleanup Problem: The VTSALIB structure used to manage VTAPE libraries is near its size limit (1 page). This is preventing use of the standard LOCK generation macros (VSLCKDEF and friends) which should be used in the VTSCTLBK structure. Resolution: VTSCTLBK has been updated to use the standard VSLCKDEF macros to generate the locks contained in this structure. This is now possible because the VTSCTLBK size was expanded via update 550179 from 1 to 2 pages. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTSV2 ASSEMBLE

VT550180 VMARC 08/06/14 15:26:42 * VTSALIB Cleanup

Update VT550180 applies to VSSI installation builds through 5518 Symptom: * VTSALIB Cleanup Problem: The VTSALIB structure used to manage VTAPE libraries is near its size limit (1 page). This is preventing use of the standard LOCK generation macros (VSLCKDEF and friends) which should be used in the VTSCTLBK structure. Resolution: Inner lock management macros updated to treat VTSCTLBK locks as standard VSSI locks. This is now possible because the VTSCTLBK size was expanded via update 550179 from 1 to 2 pages. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VTSCTLBK COPY

VS550180 VMARC 08/06/14 15:25:40 * VTSALIB Cleanup

Update VS550180 applies to VSSI installation builds through 5518 Symptom: * VTSALIB Cleanup Problem: The VTSALIB structure used to manage VTAPE libraries is near its size limit (1 page). This is preventing use of the standard LOCK generation macros (VSLCKDEF and friends) which should be used in the VTSCTLBK structure. Resolution: Inner lock management macros updated to treat VTSCTLBK locks as standard VSSI locks. This is now possible because the VTSCTLBK size was expanded via update 550179 from 1 to 2 pages. Additionally, the VSCKDEV macro has been updated to allow VPARS I/O (i.e., in HCPIOS) during all phases of VxOPEN processing. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 338 (2014-08-01) Modules: VSCKVDEV MACRO VSLCKXMO MACRO

VT550179 VMARC 08/01/14 14:02:02 * VTSALIB Cleanup

Update VT550179 applies to VSSI installation builds through 5518 Symptom: * VTSALIB Cleanup Problem: Cleanup required for the following code errors: 1. The VTSALIB structure used to manage VTAPE libraries is near its size limit (1 page). This is preventing use of the standard LOCK generation macros (VSLCKDEF and friends) which should be used in the VTSCTLBK structure. 2. A storage release function in RVTSV2LB is erroneously coded, as follows: . VSCPSTOR RELEASE,BLOCK=(R6),ID=VTSCTLBK The ID parameter gives the mistaken impression that the VTSCTLBK is being released. In reality, the VTSCTLBK is allocated at IPL time and is NEVER released. R6 in this case points to a Query Lib block, and NOT the VTSCTLBK. Resolution: Made the following changes: 1. VTSALIB (i.e., VTSCTLBK) allocation amended to request PAGES=2, instead of a DWORD count. This structure is allocated at IPL, and is never released. 2. The ID parameter has been removed from the VSCPSTOR RELEASE call in RVTSV2LB. No functionality is changed in RVTSV2. BUILD_Reqd: VSSICP Toolmin: 1.0 338 (2014-08-01) Modules: RVTSV2 ASSEMBLE

VS550178 VMARC 07/31/14 14:45:12 * LOCK Macro cleanup

Update VS550178 applies to VSSI installation builds through 5518 Symptom: * LOCK Macro cleanup Problem: Removal of deprecated LOCK macros. Resolution: Deprecated macros removed from usage. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 337 (2014-07-31) Modules: VS55MAC $EXEC VSREJCMD MACRO

VP550177 VMARC 07/30/14 03:54:00 * Diagnostic Lock Management updates

Update VP550177 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Made the following changes: . All lock operations now use a single macro (VSLCKOP) instead of the various VSLCKcc macros. This macro serves to consolidate all lock operations into entry points in RVSSTB. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE

VT550177 VMARC 07/30/14 03:54:10 * Diagnostic Lock Management updates

Update VT550177 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Made the following changes: . All lock operations now use a single macro (VSLCKOP) instead of the various VSLCKcc macros. This macro serves to consolidate all lock operations into entry points in RVSSTB. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTLD1 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VS550176 VMARC 07/30/14 03:51:06 * Diagnostic Lock Management updates

Update VS550176 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Made the following changes: . RVSSTB and RVSSTD code amended to perform all lock operations and report any errors. . New TRACE variable LOCKERR added to trace lock conflicts. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: VS55MAC $EXEC VSLCKXST COPY VSLCKOP MACRO VSLCKXMO MACRO RVSSTB ASSEMBLE RVSSTD ASSEMBLE

VP550175 VMARC 07/29/14 09:43:41 * Console Function mode conflicts

Update VP550175 applies to VSSI installation builds through 5518 Symptom: * Console Function mode conflicts Problem: Several VSSI functions require command stacking via Console Function Mode (CFM) in order to complete command processing for the current and/or other users (e.g., a VTAPE mount issued by userA on behalf of userB). A command collision is possible if the stack target is the current user, and that user is already in CF mode (i.e., the "double CF stack" problem). Such a condition can hang the user; a subsequent FORCE of that user will show LOGOFF/FORCE PENDING status. Resolution: Guard code added to ensure that the current user is not in CF mode before issuing another CF stack request to itself. The added CFWAIT code will wait until one of the following events occur: . User is no longer in CF mode; . The 5-second max timer interval expires (in order to avoid endless waits) BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPBUF ASSEMBLE RVPSET ASSEMBLE

VT550175 VMARC 07/29/14 09:43:53 * Console Function mode conflicts

Update VT550175 applies to VSSI installation builds through 5518 Symptom: * Console Function mode conflicts Problem: Several VSSI functions require command stacking via Console Function Mode (CFM) in order to complete command processing for the current and/or other users (e.g., a VTAPE mount issued by userA on behalf of userB). A command collision is possible if the stack target is the current user, and that user is already in CF mode (i.e., the "double CF stack" problem). Such a condition can hang the user; a subsequent FORCE of that user will show LOGOFF/FORCE PENDING status. Resolution: Guard code added to ensure that the current user is not in CF mode before issuing another CF stack request to itself. The added CFWAIT code will wait until one of the following events occur: . User is no longer in CF mode; . The 5-second max timer interval expires (in order to avoid endless waits) BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE

VP550174 VMARC 07/26/14 20:08:05 * Console Function mode conflicts

Update VP550174 applies to VSSI installation builds through 5518 Symptom: * Console Function mode conflicts Problem: In a Secondary Console Operator (SCIF) environment, console commands can collide due the rapidity of message delivery. The following commands are particularly vulnerable: . VxSET followed immediately by VxCLOSE or VxFCLOSE Resolution: RVxRCC amended to wait until the machine is not in CF mode before proceeding with the VXCLOSE (max wait = 5 seconds). BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE

VT550174 VMARC 07/26/14 20:07:29 * Console Function mode conflicts

Update VT550174 applies to VSSI installation builds through 5518 Symptom: * Console Function mode conflicts Problem: In a Secondary Console Operator (SCIF) environment, console commands can collide due the rapidity of message delivery. The following commands are particularly vulnerable: . VxSET followed immediately by VxCLOSE or VxFCLOSE Resolution: RVxRCC amended to wait until the machine is not in CF mode before proceeding with the VXCLOSE (max wait = 5 seconds). BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE

VP550173 VMARC 07/26/14 20:03:24 * Diagnostic Lock Management updates

Update VP550173 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Lock management MACROs and messages added; will be function in a later update. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPDBM ASSEMBLE RVPOPS ASSEMBLE RVPSV1 ASSEMBLE

VT550173 VMARC 07/26/14 20:03:39 * Diagnostic Lock Management updates

Update VT550173 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Lock management MACROs and messages added; will be function in a later update. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVTADD ASSEMBLE RVTDEF ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTSV2 ASSEMBLE

VP550172 VMARC 07/26/14 19:52:08 * Diagnostic Lock Management updates

Update VP550172 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Lock management MACROs and messages added; will be functional in a later update. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 335 (2014-07-14) Modules: VPCTLBK COPY VPIOTBK COPY

VT550172 VMARC 07/26/14 19:53:50 * Diagnostic Lock Management updates

Update VT550172 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Lock management MACROs and messages added; will be functional in a later update. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 335 (2014-07-14) Modules: VTACTBK COPY VTEXTBK COPY VTIOTBK COPY VTMDSKBK COPY VTSCTLBK COPY VT5ANCH MACRO VT6ANCH MACRO

VS550172 VMARC 07/26/14 19:47:47 * Diagnostic Lock Management updates

Update VS550172 applies to VSSI installation builds through 5518 Symptom: * Diagnostic Lock Management updates Problem: As presently coded, lock conflicts are difficult to detect and diagnose. Resolution: Lock management MACROs and messages added; will be functional in a later update. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 335 (2014-07-14) Modules: VS55MAC $EXEC RVSVDUBK COPY RVSVPUBK COPY RVSVTUBK COPY VSLCKDEF MACRO VSLCKOP MACRO VSLCKXMO MACRO VS6ANCH MACRO RVSSTQ ASSEMBLE

VP550171 VMARC 07/25/14 03:31:32 * Hung user during VDEV reset

Update VP550171 applies to VSSI installation builds through 5518 Symptom: * Hung user during VDEV reset Problem: User IPLed several VDISK guest machines normally. User then issued VDSET CHECKPOINT, which caused the code to enter console function mode. At this time, a VDISK I/O was also in progress. HCPRES was called to reset the VDEVs, which invoked RVxSV2RS to wait for device reset, and waited forever ("i.e., a "chicken-or-egg" issue). Resolution: RVxSV2 amended to abandon VDEV wait after 1.5 seconds, and to return to HCPRES. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPSV2 ASSEMBLE

VT550171 VMARC 07/25/14 03:30:47 * Hung user during VDEV reset

Update VT550171 applies to VSSI installation builds through 5518 Symptom: * Hung user during VDEV reset Problem: User issued a VTSCR command, which caused the code to enter console function mode. At this time, a VPARS I/O was also in progress. HCPSCT was called to reset the VDEVs, which invoked RVTSV2RS to wait for device reset, and waited forever ("i.e., a "chicken-or-egg" issue). Resolution: RVTSV2 amended to abandon VDEV wait after 1.5 seconds, and to return to HCPSCT. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVTSV2 ASSEMBLE

VP550170 VMARC 07/23/14 14:34:01 * Hung user during VDEV reset

Update VP550170 applies to VSSI installation builds through 5518 Symptom: * Hung user during VDEV reset Problem: User IPLed several VPARS guest machines normally. User then issued VPSET CHECKPOINT, which caused the code to enter console function mode. At this time, a VPARS I/O was also in progress. HCPRES was called to reset the VDEVs, which invoked RVxSV2RS to wait for device reset, and waited forever ("i.e., a "chicken-or-egg" issue). Resolution: RVxSV2 amended to abandon VDEV wait after 5 seconds, and to return to HCPRES. BUILD_Reqd: VSSICP Toolmin: 1.0 335 (2014-07-14) Modules: RVPSV2 ASSEMBLE

VS550169 VMARC 07/14/14 07:37:57 * HyperPAV Prep, Misc. VPARS/VDISK Issues

Update VS550169 applies to VSSI installation builds through 5518 Symptom: * HyperPAV Prep, Misc. VPARS/VDISK Issues Problem: This update addresses the following issues: . Many VPARS/VDISK modules obtain the virtual device number via direct interrogation of VDEVDEV (VDEV) or RDEVDEV (RDEV). This will yield incorrect results in a HyperPAV environment. . Customer issued a VxLINK command, followed by VxBKUP. VxLINK marked the linked VDEVs as "VPARS|VDISK-owned", Upon execution of VxBKUP, no database was open (i.e., no VxOPEN had been issued). Because of this, the VSSI code hook in HCPIOS received control against the linked VDEVs and passed control to RVxCCW, which promptly ABENDed (soft CCW001) because no database was open. This sequence of events hung the user; an IPL was required to recover. . VPARS/VDISK database disks show up in QUERY VIRTUAL vdev as VPARS/VDISK-intercepted devices. Only BASE devices should be marked as intercepted devices. Resolution: Made the following changes: . Macros added to return the correct base and alias device numbers and device addresses regardless if the interroated VDEV/RDEV is a HyperPav alias or not. . VSCKVDEV macro amended to bypass VPARS/VDISK calls to RVxCCW if no database is open. . HCPQVC amended to bypass VPARS/VDISK message insertion if the interrogated VDEV is part of a VPARS/VDISK database or pool. BUILD_Reqd: VSSIPL VSSMMAC Toolmin: 1.0 334 (2014-07-11) Modules: VS55MAC $EXEC VSCKVDEV MACRO VSDVADD MACRO VSDVNUM MACRO

VP550168 VMARC 07/08/14 12:40:14 * COMMAND-REJECT print reduction

Update VP550168 applies to VSSI installation builds through 5518 Symptom: * COMMAND-REJECT print reduction Problem: During error reporting for a given CCW chain (CMDREJ, UNSUPP, etc), the sense data is always printed, even if it contains no valid data. Resolution: RVxDBS amended to suppress Sense Data print if: . the Sense data is all 0s . the Sense data was set by VPARS/VDISK code. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVPDBS ASSEMBLE

VP550167 VMARC 07/08/14 08:14:08 * Additional TRACE points for COMMAND-REJECT

Update VP550167 applies to VSSI installation builds through 5518 Symptom: * Additional TRACE points for COMMAND-REJECT Problem: VPARS and VDISK do not adequately explain why a CCW was rejected. Resolution: Diagnostic message generation added for: . COMMAND-REJECT . UNSUPPORTED-CCW . BAD-LOCK BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPMSG ASSEMBLE

VP550166 VMARC 07/08/14 08:06:12 * Additional TRACE points for COMMAND-REJECT

Update VP550166 applies to VSSI installation builds through 5518 Symptom: * Additional TRACE points for COMMAND-REJECT Problem: VPARS and VDISK do not adequately explain why a CCW was rejected. Resolution: MACRO flags added to control COMMAND-REJECT and NON-VP error message generation. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 331 (2014-06-18) Modules: VP1WRKBK COPY

VS550166 VMARC 07/08/14 08:06:52 * Additional TRACE points for COMMAND-REJECT

Update VS550166 applies to VSSI installation builds through 5518 Symptom: * Additional TRACE points for COMMAND-REJECT Problem: VPARS and VDISK do not adequately explain why a CCW was rejected. Resolution: MACRO flags added to control COMMAND-REJECT and NON-VP error message generation. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 1.0 331 (2014-06-18) Modules: VS55MAC $EXEC VSREJCMD MACRO

VT550165 VMARC 07/02/14 11:46:38 * VTSCRTCH Support - invalid-format tapes

Update VT550165 applies to VSSI installation builds through 5518 Symptom: * VTSCRTCH Support - invalid-format tapes Problem: If an invalid tape (i.e., any tape created between application of PTFs VT550144 and VT550161) is detected via the VTQUERY LIB ALL command, the command aborts, and the owner ID is not printed. Resolution: RVTQLB amended to print the owner ID after the volser. All tapes in the library will be reported on if the user specifies VTQUERY LIB ALL. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVTCCW ASSEMBLE RVTMSG ASSEMBLE RVTQLB ASSEMBLE RVTSV2 ASSEMBLE

VT550164 VMARC 07/02/14 11:44:44 * VTSCRTCH Support - invalid-format tapes

Update VT550164 applies to VSSI installation builds through 5518 Symptom: * VTSCRTCH Support - invalid-format tapes Problem: VTAPE Descriptor block does not track the following: . Tape Record Format (Fixed or Variable) . Tape maximum BLKSIZE Resolution: Above fields added to VTVDSCBK. BUILD_Reqd: VSSICP VSSICMS VSSMMAC Toolmin: 1.0 331 (2014-06-18) Modules: VTACTBK COPY VTVDSCBK COPY

VT550163 VMARC 06/25/14 14:29:39 * VTSCRTCH Support - invalid-format tapes

Update VT550163 applies to VSSI installation builds through 5518 Symptom: * VTSCRTCH Support - invalid-format tapes Problem: Application of VT550144 incorrectly changed the format of the VTAPE Descriptor Block (VTVDSCBK). Since this block is also disk-resident (i.e, present in the metadata header for all VTAPE tape media), older tape headers on disk no longer matched the new struct offsets, effectively invalidating all tapes created prior to the update. No actual VTAPE database disk data was modified. Update VT550161 restored the VTVDSCBK offsets, so that all tapes prior to VT550144 are once again seen as valid tapes. This leaves us with the problem of handling all tapes created between application of VT550144 and VT550161, i.e.: . VTAPE code after appication of VT550144, and prior to application of VT550161, will see any tapes created in this interval as valid, and will see any older tapes as invalid. . VTAPE code after appication of VT550161 will see any tapes created in the VT550144-VT550161 interval as invalid, and will once again see all pre-VT550144 tapes as valid. Tapes created after VT550161 will also (obviously) be seen as valid. We need to provide the customer with the ability to scratch all tapes created during the VT550144-VT550161 code update interval. Resolution: RVTSCR modified to successfully scratch any specified tape generated between application of VT550144 and VT550161. You can determine if such tapes exist by running the following command: . VTQ LIB ALL Invalid tapes will display the following message: . RVTSV2094E First block for 12345 is invalid . RVTQLB039E Library l disk n minidisk vdev block xxxxxxxx cchhr cccchhhhrr is not a data block These tapes cannot be converted to valid format; they must be deleted via the VTSCRTCH command, i.e.: . vtscr vol_ser purge owner * The (OWNer *) keyword and value is a special parameter which allows authorized users (i.e., with one of the privilege classes specified in the VTSYSTEM DEFAULTS SCRATCH_OTHERS statement) to scratch a tape regardless of the tape owner ID. The PURGE keyword is also required in this case. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVTSCR ASSEMBLE VTCPYASM ASSEMBLE

VT550162 VMARC 06/24/14 08:47:03 * Misc. ABENDs during VTAPE DETACH/Unload (HIPER)

Update VT550162 applies to VSSI installation builds through 5518 Symptom: * Misc. ABENDs during VTAPE DETACH/Unload (HIPER) Problem: Two customers encountered the following issues during VTAPE processing: . Invalid tapes in VTAPE library after VT550144. Application of update VT550144 modified the Tape Descriptor Block, but did not take into account that this structure is also disk-resident (i.e., resides in all tape header metadata in the VTAPE database). After application, old tapes appeared invalid to VTAPE (due to VTVDSCBK mismatch between in-memory and disk structures). . PRG004 ABENDs during tape DETACH. VSSI DETACH code in RVTSV2RS was incorrectly determining the calling module ID (in this case, HCPDTD), and exiting early if HCPDTD was not detected (the caller was in fact HCPDTD). The tape VDEV was left in an unstable state (i.e., not fully detached/reset). Later code in HCPDTD attempted final cleanup, which resulted in a PRG004 ABEND. . HPC001 ABENDs if Unit Check received on current tape. VTAPE (correctly) returns a Unit Check to the requesting application if no more space exists on the VTAPE database. However, the intermediate work block used by VTAPE to do tape compression was left in a locked state (i.e., was not freed by RVTCCW) if a Unit Check (i.e., MD Full) was detected. Subsequent unload operations attempted to deallocate the work buffer which was locked (fixed in storage), resulting in an HPC001 ABEND. Resolution: Made the following changes: . RVTSCR will be modified to successfully scratch all tapes generated after application of VT550144. You can determine if such tapes exist by running the following command: . VTQ LIB ALL Invalid tapes will display the following message: . RVTSV2094E First block for 12345 is invalid . RVTQLB039E Library l disk n minidisk vdev block xxxxxxxx cchhr cccchhhhrr is not a data block These tapes cannot be converted to valid format; they must be deleted via the VTSCR command; i.e.: . vtscr vol_ser purge The required support in VTSCRTCH will be available in a few days in a seperate update. . RVTSV2RS CallerID code check removed; no longer required. Code now uses VDEVAFLG.VDEVDTCH to determine if the function was called via HCPDTD (bit ON) or not (bit OFF). . RVTCCW Unit Check routine amended to unlock Intermediate Work Block (IWA) if the block was fixed via Translate And Lock (HCPPTFLK), allowing subsequent Unload operations to successfully deallocate the page frame. This update should be applied concurrently with update 550161; i.e.: vsptf 161-162 BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVTCCW ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSV2 ASSEMBLE

VT550161 VMARC 06/23/14 22:33:22 * Incorrect tape descriptor struct

Update VT550161 applies to VSSI installation builds through 5518 Symptom: * Incorrect tape descriptor struct Problem: PTF 550143 changed the structure of the VTAPE Descriptor Block (VTVDSCBK). This change did not take into account that this structure is also disk-resident on the VTAPE database. After application of 550143, current VTAPE tapes were no longer recognized as valid tapes (due to offset changes in VTVDSCBK). Tape libraries formatted after the above updates all show valid tapes. Resolution: VTVDSCBK modified to add additional fields/flags in areas formerly marked as reserved. Descriptor offsets are now the same as prior to 550143; current tape entries are now seen as valid tapes. All tapes created after application of 550143 will now be seen as invalid tapes (i.e., invalid VTVDSCBK field offset). These tapes will require deletion via VTSCRTCH. This update should be applied concurrently with update 550162; i.e.: vsptf 161-162 BUILD_Reqd: VSSICP VSSICMS VSSMMAC Toolmin: 1.0 331 (2014-06-18) Modules: VTACTBK COPY VTVDSCBK COPY

VP550160 VMARC 06/20/14 08:43:08 * General cleanup

Update VP550160 applies to VSSI installation builds through 5518 Symptom: * General cleanup Problem: Lock-related code has new lock macros (VSLCKcc), followed by the old code in comments. Resolution: Old commented code removed. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVPBUF ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPIFC ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPSV2 ASSEMBLE

VT550160 VMARC 06/20/14 08:43:15 * General cleanup

Update VT550160 applies to VSSI installation builds through 5518 Symptom: * General cleanup Problem: Lock-related code has new lock macros (VSLCKcc), followed by the old code in comments. Resolution: Old commented code removed. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTDEF ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VP550158 VMARC 06/17/14 13:29:36 * HTT001 ABEND in timer routine RVxCCWTM

Update VP550158 applies to VSSI installation builds through 5518 Symptom: * HTT001 ABEND in timer routine RVxCCWTM Problem: Customer experienced HTT001 ABEND in database timer routine while the routine was attempting to access the VPCTLBK address loaded from the timer TRQBK. The address was non-zero but invalid (i.e., already destroyed). Resolution: RVxCCW amended to check VPCTLBK address validity (via TPROT) prior to accessing VPCTLBK fields. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVPCCW ASSEMBLE

VT550157 VMARC 06/17/14 10:27:05 * Disallow invalid VTSET LIMIT values

Update VT550157 applies to VSSI installation builds through 5518 Symptom: * Disallow invalid VTSET LIMIT values Problem: VTSET LIMIT value is not properly evaluated. Proper values for the LIMIT keyword should be as follows: . LIMIT 0 (no record limit set) . LIMIT n (n >= 4; a value of 4 allows for 3 label records (VOL1|HDR1|HDR2) plus at least 1 data block) Resolution: RVTST1 amended to evaluate and (if necessary) alter the VTSET LIMIT value specified by the user. If LIMIT = 1|2|3 is specified, the value will automatically be converted to the minimum non-zero value (4). BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVTST1 ASSEMBLE

VP550156 VMARC 06/26/14 11:00:39 * Invalid KEYPOINT record if ECHO ON at IPL time

Update VP550156 applies to VSSI installation builds through 5518 Symptom: * Invalid KEYPOINT record if ECHO ON at IPL time Problem: Customer turned ECHO ON during the early stages of IPLing a Request-Online TPF system. After the IPL image was located, the customer received the following error: IPLB0007I IPL STARTED on DEV 1600 VOL FD0100+ IPLB0086E VOLUME FD0100 ON 1600 - 00CA000001 - ID 0000 FOUND IN KEYPOINT + IPLB0055T UNABLE TO READ BSS KEYPOINT RECORDS. IPL TERMINATED+ HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 000003FF In this case, the TPF system received an invalid keypoint record from VPARS (i.e., 1st 2 buffer bytes are not 'CK'). The corresponding record on the VPARS database contains all zeros (as per VPUTIL). This leaves one of the following possibilities: . A zero record was returned via Request Online; . ECHO processing inadvertly cleared the record after the record was received, but before it was rewritten to the database. Resolution: Additional TRACE probes added to triage this issue. BUILD_Reqd: VSSICP Toolmin: 1.0 331 (2014-06-18) Modules: RVPDBM ASSEMBLE

VT550155 VMARC 06/16/14 15:30:45 * Missing block at EOV

Update VT550155 applies to VSSI installation builds through 5518 Symptom: * Missing block at EOV Problem: z/OS customer experienced 237-0C ABENDs while writing a multiple-volume tape. Prior to running the batch job, the customer had set the following VTAPE options: . VTSET VDEV 590 AUTO (automatic scratch mounts) . VTSET VDEV 590 LIM 15 (15 blocks per tape) The MVS batch job ABENDed during EOV processing for the first tape, with the following error message: . IEC537I BLOCK COUNTS: DEVICE=12 DCB=13 The message indicates that the tape device (i.e., the virtual device simulated via VTAPE) had a data block write count of 12 blocks, while the MVS application DCB (in this case, in the IEBGENER utility) had an internal data block write count of 13 (i.e., devcount+1). Apparently, RVTCCW determined that a Unit Exception be sent during the write of data block 13 (correct), but did not write the block (incorrect). These actions violate IBM tape semantics, which assume that the block which triggered the UE was in fact written. Resolution: RVTCCW amended to write the block to the VTAPE database even if that block triggers a Unit Exception (assuming that no other error conditions exist). BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVTCCW ASSEMBLE

VP550154 VMARC 06/11/14 11:09:14 * LCK001 ABEND while forcing user

Update VP550154 applies to VSSI installation builds through 5518 Symptom: * LCK001 ABEND while forcing user Problem: Customer had hung userids while performing a NOBASE database restore. FORCE was issued against these IDs, which then caused a LCK001 ABEND. Inspection of the VPSVPCLK showed that the lock had been properly destroyed by the first userid. The second user attempted to issue a destroy command (HCPLCKDX) against the same lock, which is invalid and which caused the ABEND. Resolution: RVxRCC amended to check for a destroyed lock prior to HCPLCKDX invocation, and to bypass HCPLCKDX if the lock is already destroyed. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVPRCC ASSEMBLE

VP550153 VMARC 06/10/14 13:28:06 * TRACE fixups

Update VP550153 applies to VSSI installation builds through 5518 Symptom: * TRACE fixups Problem: Several VSCPTRC macro calls are using incorrect SAVBK register specifications. Resolution: Modules updated. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVPIOR ASSEMBLE RVPRCC ASSEMBLE

VT550153 VMARC 06/10/14 13:28:14 * TRACE fixups

Update VT550153 applies to VSSI installation builds through 5518 Symptom: * TRACE fixups Problem: Several VSCPTRC macro calls are using incorrect SAVBK register specifications. Resolution: Modules updated. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVTCCW ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE

VT550152 VMARC 06/10/14 12:08:34 * VTAPE TRACE probes

Update VT550152 applies to VSSI installation builds through 5518 Symptom: * VTAPE TRACE probes Problem: Addition TRACE probes required to debug VTAPE errors. Resolution: Added VTITRWK1 TRACE save area to VTIOTBK. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 330 (2014-06-05) Modules: VTIOTBK COPY

VS550152 VMARC 06/10/14 12:07:19 * VTAPE TRACE probes

Update VS550152 applies to VSSI installation builds through 5518 Symptom: * VTAPE TRACE probes Problem: Addition TRACE probes required to debug VTAPE errors. Resolution: Updated VSCPTRC macro to support additional VTAPE calls. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 330 (2014-06-05) Modules: VSCPTRC MACRO

VS550151 VMARC 06/10/14 12:10:54 * MACRO/COPY Updates

Update VS550151 applies to VSSI installation builds through 5518 Symptom: * MACRO/COPY Updates Problem: Updates to several key MACRO/COPY files. Resolution: HCPVDEV amended to force VTAPE tape specification area to exactly 40 bytes. BUILD_Reqd: VSSMMAC Toolmin: 1.0 330 (2014-06-05) Modules: VSMODID COPY

VT550150 VMARC 06/09/14 09:36:23 * Incomplete VTAPE metadata

Update VT550150 applies to VSSI installation builds through 5518 Symptom: * Incomplete VTAPE metadata Problem: Customer VTAPE data contains incomplete VTAPE metadata used to chain data blocks together. This condition occurs when a previou EB IOT has already been written out; the last chaining operation fails to re-write the previous EB block. This is a race condition. Resolution: RVTDBM amended to check if the previous EB is paged-in, and to page it in if not (i.e., if already written). The block is then updated, marked as modified, and re-written. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVTDBM ASSEMBLE RVTMNT ASSEMBLE

VP550149 VMARC 06/06/14 12:58:08 * Invalid end CCHH calculation in VPBXPLTB

Update VP550149 applies to VSSI installation builds through 5518 Symptom: * Invalid end CCHH calculation in VPBXPLTB Problem: VPBXPLTB is generating incorrect end-CCHH values (i.e., OPMTBL has start CCHH and record number). Resolution: Added logic in VPBXPLTB to account for PRIME/DUP pairing in end-CCHH and BaseRel calculations. BUILD_Reqd: VSSICMS Toolmin: 1.0 330 (2014-06-05) Modules: VPBXPLTB ASSEMBLE

VP550148 VMARC 06/12/14 18:29:52 * Invalid KEYPOINT record if ECHO ON at IPL time

Update VP550148 applies to VSSI installation builds through 5518 Symptom: * Invalid KEYPOINT record if ECHO ON at IPL time Problem: Customer turned ECHO ON during the early stages of IPLing a Request-Online TPF system. After the IPL image was located, the customer received the following error: IPLB0007I IPL STARTED on DEV 1600 VOL FD0100+ IPLB0086E VOLUME FD0100 ON 1600 - 00CA000001 - ID 0000 FOUND IN KEYPOINT + IPLB0055T UNABLE TO READ BSS KEYPOINT RECORDS. IPL TERMINATED+ HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 000003FF In this case, the TPF system received an invalid keypoint record from VPARS (i.e., 1st 2 buffer bytes are not 'CK'). The corresponding record on the VPARS database appears valid (i.e., 'CK' found). Resolution: Additional TRACE probes added to triage this issue. BUILD_Reqd: VSSICP Toolmin: 1.0 330 (2014-06-05) Modules: RVPDBS ASSEMBLE

VP550147 VMARC 06/05/14 10:32:21 * Baseless addressing cleanups

Update VP550147 applies to VSSI installation builds through 5518 Symptom: * Baseless addressing cleanups Problem: Several GOTO routine pointers are not baseless (i.e., using LA Rx,rtnaddr). Resolution: Address pointers changed to: LARL Rx,rtnaddr. BUILD_Reqd: VSSICP Toolmin: 1.0 329 (2014-06-04) Modules: RVPCLR ASSEMBLE RVPIOR ASSEMBLE RVPOPS ASSEMBLE RVPSYN ASSEMBLE

VT550147 VMARC 06/05/14 10:32:48 * Baseless addressing cleanups

Update VT550147 applies to VSSI installation builds through 5518 Symptom: * Baseless addressing cleanups Problem: Several GOTO routine pointers are not baseless (i.e., using LA Rx,rtnaddr). Resolution: Address pointers changed to: LARL Rx,rtnaddr. BUILD_Reqd: VSSICP Toolmin: 1.0 329 (2014-06-04) Modules: RVTADD ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTOPN ASSEMBLE RVTSPX ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE

VS550146 VMARC 06/04/14 15:40:39 * EXEC Cleanup

Update VS550146 applies to VSSI installation builds through 5518 Symptom: * EXEC Cleanup Problem: This update removes several unused EXECs. No changes to VSSI code are performed by this update (i.e., housekeeping-only). Resolution: EXECs to be deleted after application of this update: Name Reason VSPTF0 Superceded by VSPTF VXSN64B z/VM 5.2-era 32-/64-bit NUC build VXSPREQ superceded by VSPTFREQ VXSTK superceded by VSPTFREQ BUILD_Reqd: VSSMMAC Toolmin: 1.0 329 (2014-06-04) Modules: VSMODID COPY

VT550145 VMARC 06/03/14 14:51:21 * VTINIT soft ABEND RST101 at first attempt

Update VT550145 applies to VSSI installation builds through 5518 Symptom: * VTINIT soft ABEND RST101 at first attempt Problem: After application of update VT550140, the first invocation of VTINIT generates a soft ABEND of RST101. Subsequent invocations work fine. Upon closer inspection, it was discovered that the first invocation was in fact successful; however, the logic to generate an ABEND in the case of a (not-yet-initialized) CMPBK had been inadvertently changed by 550140 (i.e., a BO instruction was changed to BrNO (incorrect) instead of BrO (correct)). Resolution: Logic changed back to former correct status (i.e., BrNO changed back to BrO). BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVTRST ASSEMBLE

VP550144 VMARC 06/02/14 15:50:47 * Miscellaneous MACRO updates

Update VP550144 applies to VSSI installation builds through 5518 Symptom: * Miscellaneous MACRO updates Problem: MACRO flag updates added to support: . enhanced VTAPE EB tracking; . enhanced VPARS/VDISK read record origin tracking. Resolution: Requisite module FLAG references updated. This update should be applied concurrently with update 550143; e.g., vsptf 143-144 BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPIOR ASSEMBLE

VT550144 VMARC 06/02/14 15:50:56 * Miscellaneous MACRO updates

Update VT550144 applies to VSSI installation builds through 5518 Symptom: * Miscellaneous MACRO updates Problem: MACRO flag updates added to support: . enhanced VTAPE EB tracking; . enhanced VPARS/VDISK read record origin tracking. Resolution: Requisite module FLAG references updated. This update should be applied concurrently with update 550143; e.g., vsptf 143-144 BUILD_Reqd: VSSMMAC Toolmin: 327 (2014-05-25) Modules: VTMODID COPY

VP550143 VMARC 06/02/14 15:47:10 * Miscellaneous MACRO updates

Update VP550143 applies to VSSI installation builds through 5518 Symptom: * Miscellaneous MACRO updates Problem: MACRO flag updates added to support: . enhanced VTAPE EB tracking; . enhanced VPARS/VDISK read record origin tracking. Resolution: Requisite macros updated. This update should be applied concurrently with update 550144; e.g., vsptf 143-144 BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 327 (2014-05-25) Modules: VP1WRKBK COPY

VT550143 VMARC 06/02/14 15:47:50 * Miscellaneous MACRO updates

Update VT550143 applies to VSSI installation builds through 5518 Symptom: * Miscellaneous MACRO updates Problem: MACRO flag updates added to support: . enhanced VTAPE EB tracking; . enhanced VPARS/VDISK read record origin tracking. Resolution: Requisite macros updated. This update should be applied concurrently with update 550144; e.g., vsptf 143-144 BUILD_Reqd: VSSICP VSSICMS VSSMMAC Toolmin: 327 (2014-05-25) Modules: VTMODID COPY VTVDSCBK COPY

VS550143 VMARC 06/02/14 15:47:02 * Miscellaneous MACRO updates

Update VS550143 applies to VSSI installation builds through 5518 Symptom: * Miscellaneous MACRO updates Problem: MACRO flag updates added to support: . enhanced VTAPE EB tracking; . enhanced VPARS/VDISK read record origin tracking. Resolution: Requisite macros updated. This update should be applied concurrently with update 550144; e.g., vsptf 143-144 BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 327 (2014-05-25) Modules: VSMODID COPY RVSSTD ASSEMBLE VSTRCDIF LAS55143

VP550142 VMARC 05/27/14 15:38:43 * CMS preparation for baseless addressing

Update VP550142 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions . VPBXPLTB and VPBXLTP modified to account for PRIME/DUP module pairing. BUILD_Reqd: VSSICMS Toolmin: 327 (2014-05-25) Modules: VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXLTP ASSEMBLE VPBXPLTB ASSEMBLE VPBXREF ASSEMBLE VPBXREST ASSEMBLE VPBXRES2 ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPLOADO ASSEMBLE VPREST ASSEMBLE VPRESTO ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE

VT550142 VMARC 05/27/14 15:38:28 * CMS preparation for baseless addressing

Update VT550142 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSICMS Toolmin: 327 (2014-05-25) Modules: VTMODID COPY COPYTAPE ASSEMBLE TAPSENSE ASSEMBLE TBROWSE ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE VTSCR1 ASSEMBLE

VS550142 VMARC 05/27/14 15:38:50 * CMS preparation for baseless addressing

Update VS550142 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSICMS Toolmin: 327 (2014-05-25) Modules: VSMODID COPY VSTRCDIF LAS55142

VD550141 VMARC 05/27/14 15:35:21 * CMS preparation for baseless addressing

Update VD550141 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSMMAC Toolmin: 327 (2014-05-25) Modules: VDMODID COPY

VP550141 VMARC 05/27/14 15:35:34 * CMS preparation for baseless addressing

Update VP550141 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSMMAC Toolmin: 327 (2014-05-25) Modules: VPMODID COPY

VT550141 VMARC 05/27/14 15:35:42 * CMS preparation for baseless addressing

Update VT550141 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSMMAC Toolmin: 327 (2014-05-25) Modules: VTMODID COPY

VS550141 VMARC 05/27/14 15:35:06 * CMS preparation for baseless addressing

Update VS550141 applies to VSSI installation builds through 5518 Symptom: * CMS preparation for baseless addressing Problem: Multiple VSSI CMS modules are base-register constrained. Resolution: Made the following changes: . all BRANCHes (i.e., instructions without an index register) converted to BRANCH-RELATIVE instructions BUILD_Reqd: VSSICMS Toolmin: 327 (2014-05-25) Modules: VSMODID COPY DISKPRT ASSEMBLE DISKZAP ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSSTRC ASSEMBLE VSSUBDT ASSEMBLE VSTRCDIF LAS55141

VP550140 VMARC 05/27/14 15:32:11 * Eliminate multiple base registers

Update VP550140 applies to VSSI installation builds through 5518 Symptom: * Eliminate multiple base registers Problem: Many VSSI modules use multiple base registers. Due to baseless addressing instructions and techniques, this approach is now obsolete. Resolution: Code amended as follows: . All VSSI code modified to use BASE=(R12) only. . All VSSI code modified to use branch-relative notation. . HCPDATA macros used where necessary to force data variables into the dafault data LOCTR areas. BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIOR ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE

VT550140 VMARC 05/27/14 15:32:03 * Eliminate multiple base registers

Update VT550140 applies to VSSI installation builds through 5518 Symptom: * Eliminate multiple base registers Problem: Many VSSI modules use multiple base registers. Due to baseless addressing instructions and techniques, this approach is now obsolete. Resolution: Code amended as follows: . All VSSI code modified to use BASE=(R12) only. . All VSSI code modified to use branch-relative notation. . HCPDATA macros used where necessary to force data variables into the dafault data LOCTR areas. BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTOCT ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTRST ASSEMBLE RVTSTS ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE

VS550140 VMARC 05/27/14 15:32:17 * Eliminate multiple base registers

Update VS550140 applies to VSSI installation builds through 5518 Symptom: * Eliminate multiple base registers Problem: Many VSSI modules use multiple base registers. Due to baseless addressing instructions and techniques, this approach is now obsolete. Resolution: Code amended as follows: . All VSSI code modified to use BASE=(R12) only. . All VSSI code modified to use branch-relative notation. . HCPDATA macros used where necessary to force data variables into the dafault data LOCTR areas. BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVSUTL ASSEMBLE

VP550139 VMARC 05/27/14 15:18:31 * Move global structs out of CPXLOADed modules

Update VP550139 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550138; e.g.: vsptf 138-139 BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE VPCPYASM ASSEMBLE

VT550139 VMARC 05/27/14 15:18:39 * Move global structs out of CPXLOADed modules

Update VT550139 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550138; e.g.: vsptf 138-139 BUILD_Reqd: VSSICP Toolmin: 327 (2014-05-25) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTTBL ASSEMBLE VTCPYASM ASSEMBLE

VD550138 VMARC 05/20/14 08:52:29 * Move global structs out of CPXLOADed modules

Update VD550138 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550139; e.g.: vsptf 138-139 BUILD_Reqd: VSSMMAC Toolmin: 325 (2014-05-19) Modules: VD55MAC $EXEC

VP550138 VMARC 05/20/14 08:52:56 * Move global structs out of CPXLOADed modules

Update VP550138 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550139; e.g.: vsptf 138-139 BUILD_Reqd: VSSMMAC Toolmin: 325 (2014-05-19) Modules: VP55MAC $EXEC

VT550138 VMARC 05/20/14 08:53:05 * Move global structs out of CPXLOADed modules

Update VT550138 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550139; e.g.: vsptf 138-139 BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 325 (2014-05-19) Modules: VT55MAC $EXEC VT5ANCH MACRO VT6ANCH MACRO

VS550138 VMARC 05/20/14 08:46:12 * Move global structs out of CPXLOADed modules

Update VS550138 applies to VSSI installation builds through 5518 Symptom: * Move global structs out of CPXLOADed modules Problem: Several key global structures reside in VSSI modules subject to CPXUNLOAD/CPXLOAD activity. Because the modules containing these structures are subject to imminent unload, the current code forces all databases to close, detaches all virtual tape devices, and CPU-resets all active users, before the CPXUNLOAD operation is allowed to proceed. Resolution: Made the following changes: . All global structures moved to new stub module RVSSTA. In the near future, this will allow us to quiesce/resume user activity between CPXUNLOAD/CPXLOAD instead of the current method of force-closing all databases on the system. . All LTORG declarations removed from VSSI CP code; added HCPDATA statements as necessary. This action was taken to permanently resolve base register constraints. This update should be applied concurrently with update 550139; e.g.: vsptf 138-139 BUILD_Reqd: VSSIPL VSSICP Toolmin: 325 (2014-05-19) Modules: VS55MAC $EXEC VSMODID COPY RVSMDLAT MACRO RVSMDLAX MACRO VSILX MACRO VSLCKAS MACRO VSLCKAX MACRO VSLCKCS MACRO VSLCKCX MACRO VSLCKDX MACRO VSLCKRS MACRO VSLCKRX MACRO VSLCKSX MACRO VSLCKXS MACRO VS5ANCH MACRO VS6ANCH MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTD ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE RVSSTL LAS55138

VP550137 VMARC 05/15/14 09:52:32 * Hung user(s) if CPXUNLOAD issued

Update VP550137 applies to VSSI installation builds through 5518 Symptom: * Hung user(s) if CPXUNLOAD issued Problem: Customer issued a CPXUNLOAD command via the VSSI VSCPX exec. This command drives the VSSI common code to call RVxSHU, which loops thru and shuts down all open VPARS/VDISK databases. However, the timer routine code in RVxCCW interprets this event as a system-wide shutdown (i.e., it assumes that CP will cleanup any outstanding timers/CPEBKs). The cleanup routines in RVxRCC are left waiting for a STOP-TIMER signal (via CPEBK) that never arrives, thus preventing them from properly closing the database. The result is one or more hung-users (causing FORCE PENDING if the operator attempts to force the user(s) off the system). In a related issue, a customer experienced FRF002 ABENDs (i.e., SXS storage exhausted) after continuous VPARS/VDISK usage. The timer scheduling code in RVxCCW was prematurely clearing the VPCTLBK timer pointer under some conditions, causing the timer scheduling routine to allocate a new TRQBK without freeing the previous one. Resolution: Made the following changes: . RVxSHU amended to force synchronous console writes. . RVxCCW amended to distinguish between CPXUNLOAD and system-wide shutdown, and to take the proper actions in each case. . RVxCCW amended to eliminate excessive TRQBK storage allocations. This update should be concurrently applied with update 550136; e.g.: vsptf 136-137. 550136 introduces assembly errors which are resolved by 550137. BUILD_Reqd: VSSICP Toolmin: 324 (2014-05-15) Modules: RVPCCW ASSEMBLE RVPOPN ASSEMBLE RVPRCC ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE

VT550137 VMARC 05/15/14 09:52:57 * Hung user(s) if CPXUNLOAD issued

Update VT550137 applies to VSSI installation builds through 5518 Symptom: * Hung user(s) if CPXUNLOAD issued Problem: Customer issued a CPXUNLOAD command via the VSSI VSCPX exec. This command drives the VSSI common code to call RVxSHU, which loops thru and shuts down all open VPARS/VDISK databases. However, the timer routine code in RVxCCW interprets this event as a system-wide shutdown (i.e., it assumes that CP will cleanup any outstanding timers/CPEBKs). The cleanup routines in RVxRCC are left waiting for a STOP-TIMER signal (via CPEBK) that never arrives, thus preventing them from properly closing the database. The result is one or more hung-users (causing FORCE PENDING if the operator attempts to force the user(s) off the system). Resolution: Made the following changes: . RVTSHU amended to force synchronous console writes. . Timer scheduling code moved to RVTSV1; duplicate code in RVTDBM and RVTOCT removed. This update should be concurrently applied with update 550136; e.g.: vsptf 136-137. 550136 introduces assembly errors which are resolved by 550137. BUILD_Reqd: VSSICP Toolmin: 324 (2014-05-15) Modules: RVTCCW ASSEMBLE RVTDBM ASSEMBLE RVTOCT ASSEMBLE RVTSHU ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE

VP550136 VMARC 05/15/14 10:25:26 * Hung user(s) if CPXUNLOAD issued

Update VP550136 applies to VSSI installation builds through 5518 Symptom: * Hung user(s) if CPXUNLOAD issued Problem: Customer issued a CPXUNLOAD command via the VSSI VSCPX exec. This command drives the VSSI common code to call RVxSHU, which loops thru and shuts down all open VPARS/VDISK databases. However, the timer routine code in RVxCCW interprets this event as a system-wide shutdown (i.e., it assumes that CP will cleanup any outstanding timers/CPEBKs). The cleanup routines in RVxRCC are left waiting for a STOP-TIMER signal (via CPEBK) that never arrives, thus preventing them from properly closing the database. The result is one or more hung-users (causing FORCE PENDING if the operator attempts to force the user(s) off the system). Resolution: Several macros modified to support CPXUNLOAD/CPXLOAD. This update should be concurrently applied with update 550137; e.g.: vsptf 136-137. 550136 introduces assembly errors which are resolved by 550137. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 324 (2014-05-15) Modules: VPCTLBK COPY VPTCCTBK COPY

VS550136 VMARC 05/15/14 10:24:25 * Hung user(s) if CPXUNLOAD issued

Update VS550136 applies to VSSI installation builds through 5518 Symptom: * Hung user(s) if CPXUNLOAD issued Problem: Customer issued a CPXUNLOAD command via the VSSI VSCPX exec. This command drives the VSSI common code to call RVxSHU, which loops thru and shuts down all open VPARS/VDISK databases. However, the timer routine code in RVxCCW interprets this event as a system-wide shutdown (i.e., it assumes that CP will cleanup any outstanding timers/CPEBKs). The cleanup routines in RVxRCC are left waiting for a STOP-TIMER signal (via CPEBK) that never arrives, thus preventing them from properly closing the database. The result is one or more hung-users (causing FORCE PENDING if the operator attempts to force the user(s) off the system). Resolution: Made the following changes: . RVxSHU amended to force synchronous console writes. . RVxCCW amended to distinguish between CPXUNLOAD and system-wide shutdown, and to take the proper actions in each case. This update should be concurrently applied with update 550137; e.g.: vsptf 136-137. 550136 introduces assembly errors which are resolved by 550137. BUILD_Reqd: VSSIPL VSSICP Toolmin: 324 (2014-05-15) Modules: VS55MAC $EXEC VSSIEQU COPY VSEXL MACRO RVSSTB ASSEMBLE

VT550135 VMARC 05/02/14 14:16:19 * VTAPE RVTMNT assembly fails after VT550133

Update VT550135 applies to VSSI installation builds through 5518 Symptom: * VTAPE RVTMNT assembly fails after VT550133 Problem: Base register exceeded after application of VT550133. This condition affects the RVTMNT assembly on z/VM 5.4; other z/VM releases are unaffected. Resolution: Moved message generation code (VSMSGH calls) below the LTORG; these calls do not require literals or a base register. BUILD_Reqd: VSSICP Toolmin: 319 (2014-04-24) Modules: RVTMNT ASSEMBLE

VT550134 VMARC 04/26/14 17:00:53 * PRG004 in RVTDBM during I/O buffer allocation

Update VT550134 applies to VSSI installation builds through 5518 Symptom: * PRG004 in RVTDBM during I/O buffer allocation Problem: VTAPE allocated a new EB (tape metadata) IOT and buffer. The code attempted to update the EB block chain pointers via loading of the old and current EB addresses. The new EB address pointers were fine; the old EB address was 0xFFFFFFFF, indicating that the old EB has already been written (asynchronously) to the VTAPE database and released. However, the chaining routine at RVTDBM label WC014 did not check for this condition, and attempted to update the forward-chain pointer of the old EB at (invalid) address 0xFFFFFFFF+4, resulting in a PRG004 ABEND. This is almost certainly a race condition between the asynchronous database write routines (in RVTIOR) and the EB chaining routine (in RVTDBM). Possible causes: system was migrated to a faster CPU, or a CPU with more engines available for VTAPE use. Resolution: Code amended to validity-check the previous EB address (VTIREALA) before attempting to chain the EBs. BUILD_Reqd: VSSICP Toolmin: 319 (2014-04-24) Modules: RVTDBM ASSEMBLE RVTIOR ASSEMBLE

VT550133 VMARC 04/26/14 09:11:09 * DSP001 at shared TAPE REWIND/UNLOAD time

Update VT550133 applies to VSSI installation builds through 5518 Symptom: * DSP001 at shared TAPE REWIND/UNLOAD time Problem: Customer was using shared tape. At unload time, the shared tape code enters the routine at RVTREW label NRN000 to stack unsolicted interrupts to all VMDBKs owning the shared device. NRN000 saves the contents of R2-R11 at entry, and restores them at exit (label NRN098). However, the loop does VMDBK switching internally; the last contents of R11 (i.e., the current VMDBK pointer) are thus overlaid by the restore (LM R2-R11) at label NRN098, resulting in a DSP001 ABEND. Resolution: Code amended to exclude R11 from save/restore at loop routine entry/exit; R11 should be modified ONLY by calls to HCPDSBSW. BUILD_Reqd: VSSICP Toolmin: 319 (2014-04-24) Modules: RVTCON ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTST2 ASSEMBLE RVTSV2 ASSEMBLE

VP550132 VMARC 05/08/14 10:50:19 * Misc. CMS and static NUC fixups

Update VP550132 applies to VSSI installation builds through 5518 Symptom: * Misc. CMS and static NUC fixups Problem: Static NUC builds need refactoring to avoid base register constraints. Resolution: Made the following changes: . Added new modules VPBXRES2 and VPBXRCF (refactored VPBXREST replacements) . Modiified current VPBXREST to use consolidated VTSDMMDR macro. This update should be applied concurrently with update 550131 (e.g., vsptf 131-132). Standalone application of 550131 will cause assembly errors fixed by 550132. BUILD_Reqd: VSSICMS Toolmin: 323 (2014-05-08) Modules: VPBXPLTB ASSEMBLE VPBXRCTL ASSEMBLE VPBXREST ASSEMBLE VPBXRES2 ASSEMBLE

VT550132 VMARC 05/08/14 10:49:46 * Misc. CMS and static NUC fixups

Update VT550132 applies to VSSI installation builds through 5518 Symptom: * Misc. CMS and static NUC fixups Problem: Static NUC builds need refactoring to avoid base register constraints. Resolution: Modified VTBKVOL to use consolidated VTSDMMDR macro. This update should be applied concurrently with update 550131 (e.g., vsptf 131-132). Standalone application of 550131 will cause assembly errors fixed by 550132. BUILD_Reqd: VSSICP VSSICMS Toolmin: 323 (2014-05-08) Modules: RVTSV1 ASSEMBLE RVTSV5 ASSEMBLE VTBKVOL ASSEMBLE

VP550131 VMARC 05/08/14 10:47:20 * Misc. CMS and static NUC fixups

Update VP550131 applies to VSSI installation builds through 5518 Symptom: * Misc. CMS and static NUC fixups Problem: Static NUC builds need refactoring to avoid base register constraints. Resolution: Added several fields to VPBXRCF macro for common use between VPBXREST and auxilary CMS modules. This update should be applied concurrently with update 550132 (e.g., vsptf 131-132). Standalone application of 550131 will cause assembly errors fixed by 550132. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 323 (2014-05-08) Modules: VPBXRCF COPY VPBXRPL COPY

VT550131 VMARC 05/08/14 10:48:35 * Misc. CMS and static NUC fixups

Update VT550131 applies to VSSI installation builds through 5518 Symptom: * Misc. CMS and static NUC fixups Problem: Static NUC builds need refactoring to avoid base register constraints. Resolution: VTSDMMDR macro (called via VPBXREST) modified to include new MDR fields. This update should be applied concurrently with update 550132 (e.g., vsptf 131-132). Standalone application of 550131 will cause assembly errors fixed by 550132. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 323 (2014-05-08) Modules: VTSDMMDR MACRO

VS550131 VMARC 05/08/14 10:46:34 * Misc. CMS and static NUC fixups

Update VS550131 applies to VSSI installation builds through 5518 Symptom: * Misc. CMS and static NUC fixups Problem: Static NUC builds need refactoring to avoid base register constraints. Resolution: Made the following changes: . Added VSSPROLG macro to several CMS modules. . Added CMS message equates. . Updated IBM HCPUSO and several VSSI modules to avoid base register constraints (via HCPDATA). . Added several message to CMS message repository (VPBXREST usage). This update should be applied concurrently with update 550132 (e.g., vsptf 131-132). Standalone application of 550131 will cause assembly errors fixed by 550132. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 323 (2014-05-08) Modules: VSSUME $REPOS VSMEQU COPY VSMODID COPY RVSSTD ASSEMBLE RVSUTL ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSSUBDT ASSEMBLE VSSUBR ASSEMBLE

VP550130 VMARC 05/23/14 11:18:05 * REQONLINE TRACE messages

Update VP550130 applies to VSSI installation builds through 5518 Symptom: * REQONLINE TRACE messages Problem: REQONLINE system is not returning valid CHKPOINT records. Resolution: Messages added. BUILD_Reqd: VSSICP Toolmin: 325 (2014-05-19) Modules: RVPDBS ASSEMBLE

VP550129 VMARC 04/21/14 09:36:54 * HTT001 ABENDs if CCW rejected by VPARS/VDISK

Update VP550129 applies to VSSI installation builds through 5518 Symptom: * HTT001 ABENDs if CCW rejected by VPARS/VDISK Problem: Customer received an HTT001 ABEND during VPARS/VDISK processing. The dump showed a COMMAND-REJECT code in the VP1WRKBK; the code was attempting to issue the relevent error message when the HTT001 occurred. Upon closer inspection, it was determined that RVxDBS was using register 5 (R5) to setup variables for the message processor. Since R5 is also used as a base register for RVxDBS, reuse of R5, along with additional code inserted by update 550120, caused RVxDBS to lose addressability, resulting in the HTT001. Resolution: Made the following changes: . RVxDBS amended to use another register for message variable setup. . RVxCCW amended to bypass timer TRQ and sync CPEBK launches if other timer pops are pending. This approach avoids flooding the system with unsatisfied asynchronous tasks in the event that a COMMAND REJECT causes I/O queuing to back up for one or more VPARS/VDISK-controlled virtual devices. BUILD_Reqd: VSSICP Toolmin: 316 (2014-04-15) Modules: RVPCCW ASSEMBLE RVPDBS ASSEMBLE RVPRCC ASSEMBLE

VP550128 VMARC 04/21/14 08:41:53 * HTT001 ABENDs if CCW rejected by VPARS/VDISK

Update VP550128 applies to VSSI installation builds through 5518 Symptom: * HTT001 ABENDs if CCW rejected by VPARS/VDISK Problem: Customer received an HTT001 ABEND during VPARS processing. The dump showed a COMMAND-REJECT code in the VP1WRKBK; the code was attempting to issue the relevent error message when the HTT001 occurred. Upon closer inspection, it was determined that RVxDBS was using register 5 (R5) to setup variables for the message processor. Since R5 is also used as a base register for RVxDBS, reuse of R5, along with additional code inserted by update 550120, caused RVxDBS to lose addressability, resulting in the HTT001. Resolution: Timer queue counter added to VPCTLBK for support of timer TRQ and sync CPEBK pacing. This approach avoids flooding the system with unsatisfied asynchronous tasks in the event that a COMMAND REJECT causes I/O queuing to back up for one or more VPARS/VDISK-controlled virtual devices. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 316 (2014-04-15) Modules: VPCTLBK COPY

VS550127 VMARC 04/18/14 09:00:07 * Fix incorrect TRACE messages

Update VS550127 applies to VSSI installation builds through 5518 Symptom: * Fix incorrect TRACE messages Problem: TRACE messages for SIGREGS events print R0 and R2 contents, instead of the expected R0 and R1 contents, if the value in R0 exceeds 4000. Resolution: RVSSTD modified to use the contents of R0 and R2 only if invoked from RVxCCW, since R1 in RVxCCW is used to hold a CCW address across TRACE calls (and therefore must not be modified by a TRACE invocation). BUILD_Reqd: VSSIPL VSSICP Toolmin: 316 (2014-04-15) Modules: RVSSTD ASSEMBLE

VP550126 VMARC 04/17/14 10:15:42 * Fix DIVIDE exception in VPBXLTP

Update VP550126 applies to VSSI installation builds through 5518 Symptom: * Fix DIVIDE exception in VPBXLTP Problem: VPBXREST ABENDs with a DIVIDE exception during the BXA Capture Tape restore. Resolution: Fixed the offending instruction in VPBXLTP. BUILD_Reqd: VSSICMS Toolmin: 316 (2014-04-15) Modules: VPBXLTP ASSEMBLE

VP550125 VMARC 04/09/14 21:07:54 * Fix register save/restore conventions (CMS)

Update VP550125 applies to VSSI installation builds through 5518 Symptom: * Fix register save/restore conventions (CMS) Problem: Several CMS source code bits have inconsistent register save/restore linkage. Resolution: Introduced a new macro, VPBXRCF. This macro contains common structs for use between VPBXREST and auxiliary modules. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 315 (2014-03-07) Modules: VP55MAC $EXEC VPBXRCF COPY

VS550125 VMARC 04/09/14 21:10:22 * Fix register save/restore conventions (CMS)

Update VS550125 applies to VSSI installation builds through 5518 Symptom: * Fix register save/restore conventions (CMS) Problem: Several CMS source code bits have inconsistent register save/restore linkage. Resolution: Made the following changes: . Introduced a new macro, VSSPROLG. The macro will eventually front-end all CMS code. . Added CMS awareness to VSLRL and VSSTL macros. These macros are used by both CMS and CP code. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 315 (2014-03-07) Modules: VS55MAC $EXEC VSMODID COPY VSLRL MACRO VSSPROLG MACRO VSSTL MACRO VSSUBR ASSEMBLE

VP550124 VMARC 04/09/14 19:49:15 * IPL UNIT Error detected for REQONLINE

Update VP550124 applies to VSSI installation builds through 5518 Symptom: * IPL UNIT Error detected for REQONLINE Problem: TRACE messages added for IPL UNIT error. Resolution: Messages added. BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVPDBM ASSEMBLE RVPDBS ASSEMBLE

PTFs below apply to Packages at 5516 and lower

VP550123 VMARC 04/01/14 16:43:24 * RVxDBM LOCK Changes, TRACE additions

Update VP550123 applies to VSSI installation builds through 5516 Symptom: * RVxDBM LOCK Changes, TRACE additions Problem: Final HCPLCK -> VSLCK conversions. Resolution: All HCPLCK function calls converted to VSLCK equivalents. BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIOR ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSV1 ASSEMBLE

VP550122 VMARC 04/03/14 10:33:51 * Routine removal

Update VP550122 applies to VSSI installation builds through 5516 Symptom: * Routine removal Problem: Routine RVPDBTUL is no longer used. Resolution: Removed RVPDBTUL call from RVPDBM and function code from RVPDBT. This update should be applied concurrently with update VP550121; e.g.: . vsptf 121-122 BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVPDBM ASSEMBLE RVPDBT ASSEMBLE

VT550122 VMARC 04/03/14 10:34:20 * Routine removal

Update VT550122 applies to VSSI installation builds through 5516 Symptom: * Routine removal Problem: Customer experienced HTT001 ABENDs when multiple concurrent VTMOUNT commands were issued. The code was attempting to access a VTXSHRLK lock (used to test TAPE PATH ASSIGN code). This lock is never used by any customers other than IBM; consequently, an invalid address was passsed to the code used to release the lock, with a resulting HTT001 ABEND. Resolution: VTAPE code modified to check for a shared drive prior to attempting to access any shared-lock structures. BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTSV2 ASSEMBLE

VD550121 VMARC 04/01/14 18:06:49 * MDLAT Cleanup

Update VD550121 applies to VSSI installation builds through 5516 Symptom: * MDLAT Cleanup Problem: Routine RVDDBTUL is no longer used. Resolution: Removed RVDDBTUL entry from RVDMDLAT. This update should be concurrently applied with update VD550122; e.g.: . vsptf 121-122 BUILD_Reqd: VSSICP VSSMMAC Toolmin: 315 (2014-03-07) Modules: RVDMDLAT MACRO

VP550121 VMARC 04/01/14 18:07:20 * MDLAT Cleanup

Update VP550121 applies to VSSI installation builds through 5516 Symptom: * MDLAT Cleanup Problem: Routine RVPDBTUL is no longer used. Resolution: Removed RVPDBTUL entry from RVPMDLAT. This update should be concurrently applied with update VP550122; e.g.: . vsptf 121-122 BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 315 (2014-03-07) Modules: VPCTLBK COPY RVPMDLAT MACRO

VS550121 VMARC 04/01/14 18:08:15 * MDLAT Cleanup

Update VS550121 applies to VSSI installation builds through 5516 Symptom: * MDLAT Cleanup Problem: Final macros required to convert all HCPLCK macro calls to VSLCK macro calls. Resolution: New macros VSLCKSX and VSLCLXS added. BUILD_Reqd: VSSIPL VSSICP Toolmin: 315 (2014-03-07) Modules: VS55MAC $EXEC VSLCKAS MACRO VSLCKAX MACRO VSLCKCS MACRO VSLCKCX MACRO VSLCKDX MACRO VSLCKRS MACRO VSLCKRX MACRO VSLCKSX MACRO VSLCKXS MACRO RVSSTB ASSEMBLE RVSSTD ASSEMBLE

VP550120 VMARC 03/20/14 03:20:53 * Hung user if LCP and forced-logoff

Update VP550120 applies to VSSI installation builds through 5516 Symptom: * Hung user if LCP and forced-logoff Problem: Customer was running in a Loosely-Coupled Processing (LCP) environment with 2 userids. A FORCE of userid1 was successful; the FORCE for userid2 hung indefinitely. The DB timer routine was being entered with the wrong VPCTL block; the original base VPCTL (marked for timer stop) was never seen by the timer routine. The timer was never stopped, and the CPEBK launched by RVxRCC was thus never invoked, causing RVxRCC to wait indefinitely for a (non-existent) timer stop. Resolution: Made the following changes: . RVxRCC amended to scan all owned VPCTL blocks when the last user is ready to close the LCP DB. All blocks are now marked as "disallow further timer requests"; when all timer activity is quiesced, the last timer routine is driven. This ensures that the last (i.e., base) VPCTL is seen and processed by the timer routine. . RVxCCW amended to clear the timer TRQBK pointer in the VPCTL block after each timer invocation. BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVPCCW ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIOR ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE

VS550120 VMARC 03/20/14 03:21:09 * Hung user if LCP and forced-logoff

Update VS550120 applies to VSSI installation builds through 5516 Symptom: * Hung user if LCP and forced-logoff Problem: Customer was running in a Loosely-Coupled Processing (LCP) environment with 2 userids. A FORCE of userid1 was successful; the FORCE for userid2 hung indefinitely. The DB timer routine was being entered with the wrong VPCTL block; the original base VPCTL (marked for timer stop) was never seen by the timer routine. The timer was never stopped, and the CPEBK launched by RVxRCC was thus never invoked, causing RVxRCC to wait indefinitely for a (non-existent) timer stop. Resolution: Made the following changes: . RVSSTD amended to properly print TRACE statements at FORCED-LOGOFF time. BUILD_Reqd: VSSIPL VSSICP Toolmin: 315 (2014-03-07) Modules: RVSSTD ASSEMBLE

VP550119 VMARC 04/03/14 13:13:04 * VPXPLTB Updates

Update VP550119 applies to VSSI installation builds through 5516 Symptom: * VPXPLTB Updates Problem: VPBXPLTB is generating an incorrect Pool Section Map. Resolution: Made the following changes: . VPBXPLTB corrected. . Added a new module to generate an XREF of the VPBXRMAP file generated by VPBXPLTB, as follows: . vpbxref fn fm Where fn is the filename of the VPBXRMAP previously created by VPBXPLTB fm is the optional VPBXRMAP filemode (default: *) The program will generate XREF on the caller's A-disk. BUILD_Reqd: VSSICMS Toolmin: 315 (2014-03-07) Modules: VPBXPLTB ASSEMBLE VPBXREF ASSEMBLE

VP550118 VMARC 04/03/14 12:09:15 * VPXPLTB Updates

Update VP550118 applies to VSSI installation builds through 5516 Symptom: * VPXPLTB Updates Problem: VPBXPLTB is generating an incorrect Pool Section Map. Resolution: Made the following changes: . VPBXPLTB corrected. . Added a new module to generate a Cross-Refenence listing of the VPBXRMAP file generated by VPBXPLTB, via the following command: . vpbxref fn ft fm Where fn is the filename of the VPBXRMAP previously created by VPBXPLTB ft is the optional VPBXRMAP filetype (default: VPBXRMAP) fm is the optional VPBXRMAP filemode (default: *) The program will generate XREF on the caller's A-disk. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 315 (2014-03-07) Modules: VP55MAC $EXEC VPBXPOOL COPY

VS550118 VMARC 04/03/14 12:09:52 * VPXPLTB Updates

Update VS550118 applies to VSSI installation builds through 5516 Symptom: * VPXPLTB Updates Problem: VPBXPLTB is generating an incorrect Pool Section Map. Resolution: Added VPBXPLTB-related messages to CMS message message repository. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 315 (2014-03-07) Modules: VSSUME $REPOS VSMEQU COPY

VT550117 VMARC 03/04/14 13:13:10 * TRACE LOCK Macro Enhancements

Update VT550117 applies to VSSI installation builds through 5516 Symptom: * TRACE LOCK Macro Enhancements Problem: Prep work for VTAPE LOCK TRACE macro calls. Resolution: All VTAPE calls to HCPLCKxx converted to VSLCKxx macro calls. BUILD_Reqd: VSSICP Toolmin: 314 (2014-03-01) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTLD1 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE

VS550116 VMARC 03/04/14 09:18:26 * TRACE LOCK Macro Enhancements

Update VS550116 applies to VSSI installation builds through 5516 Symptom: * TRACE LOCK Macro Enhancements Problem: Prep work for VTAPE LOCK TRACE macro calls. Resolution: All VSLCKxx macros enhanced to account for VTAPE invocations. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 314 (2014-03-01) Modules: VSLCKAS MACRO VSLCKAX MACRO VSLCKCS MACRO VSLCKCX MACRO VSLCKDX MACRO VSLCKRS MACRO VSLCKRX MACRO

VP550115 VMARC 03/04/14 09:18:06 * I/O TRACE additions - Step 3

Update VP550115 applies to VSSI installation builds through 5516 Symptom: * I/O TRACE additions - Step 3 Problem: Lock acquire/release code requires tracing to detect "lock leakage" (i.e., attempting to release a lock which is not held, or failing to release locks that are held). Resolution: All direct calls to HCPLCK have been converted to VSLCKxx macro calls. This approach allows us to trap and (optionally) diagnose the calls for "lock leakage" conditions. BUILD_Reqd: VSSICP Toolmin: 314 (2014-03-01) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE

VT550114 VMARC 03/01/14 18:43:16 * Fix non-CPXLOAD build errors

Update VT550114 applies to VSSI installation builds through 5516 Symptom: * Fix non-CPXLOAD build errors Problem: Static NUC (i.e., non-CPXLOAD) builds fail at several points, due to regression caused by many PTFs since the start of the Version 55 series. Resolution: RVTCCW modified to emit an HCPEXTRN for symbol RVTCCWSM in a static NUC environment. BUILD_Reqd: VSSICP Toolmin: 313 (2014-02-17) Modules: RVTCCW ASSEMBLE

VS550113 VMARC 02/26/14 14:54:43 * Fix non-CPXLOAD build errors

Update VS550113 applies to VSSI installation builds through 5516 Symptom: * Fix non-CPXLOAD build errors Problem: Static NUC (i.e., non-CPXLOAD) builds fail at several points, due to regression caused by many PTFs since the start of the Version 55 series. Resolution: Made the following changes: . Modified VSCPXIT macro to handle non-CPXLOAD environments for several VTAPE modules which are called with calltype(CALL) in a CPXLOAD environment, but need to be called with calltype(GOTO) in a static NUC environment. Application of the update will force all VSSI-hooked HCP modules to be rebuilt, as well as several VSSI CP modules. . Replaced HCPXSERV calls in RVSSTB with VSSRV calls (new macro code included in this update). The VSSRV macro is CPXLOAD/non-CPXLOAD-aware; HCPXSERV TEST|CALL is (obviously) not. BUILD_Reqd: VSSIPL VSSICP Toolmin: 313 (2014-02-17) Modules: VS55MAC $EXEC VSCPXIT MACRO VSSRV MACRO RVSSTB ASSEMBLE

VP550112 VMARC 03/20/14 15:27:47 * Multiple Write Count/Key/Data reqs in error

Update VP550112 applies to VSSI installation builds through 5516 Symptom: * Multiple Write Count/Key/Data reqs in error Problem: A customer detected invalid IPL records when attempting to IPL a NOBASE system. The customer has ECHO ON in order to generate the NOBASE database. In this case, Write CKD (CCW x'1D') requests are improperly written to the database (i.e., not using the length in the count field). A subsequent IPL request in a NOBASE environment returns a truncated or garbled IPL2 record (IPL1 and VOL1 appear OK). This problem was introduced by PTF Vx550068. Resolution: RVxDBM modified to always use record and key lengths indicated in the record count field. BUILD_Reqd: VSSICP Toolmin: 315 (2014-03-07) Modules: RVPDBM ASSEMBLE

VP550111 VMARC 02/25/14 12:06:06 * I/O TRACE additions - Step 2

Update VP550111 applies to VSSI installation builds through 5516 Symptom: * I/O TRACE additions - Step 2 Problem: VSCPTRC macro does not support modules whose HCPENTER calling sequence is not SAVE=DYNAMIC. This deficiency needs to be fixed in order to provide comprehensive I/O tracing support. Resolution: Made the following changes: . RVxOPN and RVxRCC modified to allocate and release VP1WRKBK tables (address VPTWRKAP in VPTCCTBK) for debugging purposes. . RVxRCC modified to stop printing "Reset Slalled" messages after 5 attempts. Previously, if base system I/O was stalled and the user was in LOGOFF or FORCE mode, the DB reset was stalled indefinitely, resulting in a hang userid which could not be forced off the system. Notes: This update should be applied together with 550110, e.g.: . vsptf 110-111 BUILD_Reqd: VSSICP Toolmin: 313 (2014-02-17) Modules: RVPOPN ASSEMBLE RVPRCC ASSEMBLE

VP550110 VMARC 02/25/14 15:02:57 * I/O TRACE additions - Step 1

Update VP550110 applies to VSSI installation builds through 5516 Symptom: * I/O TRACE additions - Step 1 Problem: VSCPTRC macro does not support modules whose HCPENTER calling sequence is not SAVE=DYNAMIC. This deficiency needs to be fixed in order to provide comprehensive I/O tracing support. Resolution: Made the following changes: . VPTWRKAP field added to VPTCCTBK in order to find the current VP1WRKBK for debugging purposes. . VP1WRKBK expanded for provision of additional TRACE fields. . VPIOTBK expanded for provision of additional TRACE fields. Notes: This update should be applied together with 550111, e.g.: . vsptf 110-111 Any assembly errors incurred by 550110 will be corrected by 550111. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 313 (2014-02-17) Modules: VPIOTBK COPY VPTCCTBK COPY VP1WRKBK COPY

VT550110 VMARC 02/25/14 15:04:17 * I/O TRACE additions - Step 1

Update VT550110 applies to VSSI installation builds through 5516 Symptom: * I/O TRACE additions - Step 1 Problem: VTIOTBK COPY has several EQUates whose names are identical with VPIOTBK COPY. Resolution: VPI-prefix EQUates changed to VTI-prefix symbols. Notes: This update should be applied together with 550111, e.g.: . vsptf 110-111 Any assembly errors incurred by 550110 will be corrected by 550111. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 313 (2014-02-17) Modules: VTIOTBK COPY

VS550110 VMARC 02/25/14 14:58:51 * I/O TRACE additions - Step 1

Update VS550110 applies to VSSI installation builds through 5516 Symptom: * I/O TRACE additions - Step 1 Problem: VSCPTRC macro does not support modules whose HCPENTER calling sequence is not SAVE=DYNAMIC. This deficiency needs to be fixed in order to provide comprehensive I/O tracing support. Resolution: Made the following changes: . VSCPTRC amended to support calls from SAVE=savearea_name and GOTO modules. . VSSI RVSST* modules updated to support new TRACE function via the VSTRACE exec. . VSSI Lock management macros . VSLCKAS/AX/CS/CX/DX/RS/RX added; all product calls to HCPLCK will eventually be converted to use these macros. . VTAPE MDLAT added to HCPUSP for support in a static (i.e., non-CPXLOAD) environment. Notes: This update should be applied together with 550111, e.g.: . vsptf 110-111 Any assembly errors incurred by 550110 will be corrected by 550111. BUILD_Reqd: VSSIPL VSSICP Toolmin: 313 (2014-02-17) Modules: VS55MAC $EXEC VSCPTRCI COPY VSCPTRC MACRO VSLCKAS MACRO VSLCKAX MACRO VSLCKCS MACRO VSLCKCX MACRO VSLCKDX MACRO VSLCKRS MACRO VSLCKRX MACRO RVSMSG ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTG ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE

VS550109 VMARC 02/17/14 17:29:40 * Add HCPPAV to module tracking list

Update VS550109 applies to VSSI installation builds through 5516 Symptom: * Add HCPPAV to module tracking list Problem: Updated HCP update entries required. Resolution: The attached VSSI HCPMODS file: . adds HCPPAV to the tracked module list; . removes support for z/VM 6.1. BUILD_Reqd: VSSMMAC Toolmin: 313 (2014-02-17) Modules: VSMODID COPY

VP550108 VMARC 02/17/14 18:41:34 * Miscellaneous VPARS message updates (2)

Update VP550108 applies to VSSI installation builds through 5516 Symptom: * Miscellaneous VPARS message updates (2) Problem: Additional I/O TRACE messages required. Resolution: Message strings added. BUILD_Reqd: VSSICP Toolmin: 313 (2014-02-17) Modules: RVPMSG ASSEMBLE

VS550106 VMARC 01/01/14 17:31:42 * Fix standalone ShadowDisk/Z install errors

Update VS550106 applies to VSSI installation builds through 5516 Symptom: * Fix standalone ShadowDisk/Z install errors Problem: Miscellaneous build errors occurring at product install time when the ShadowDisk/Z product is installed standalone (i.e., on an Install disk without a previous install of VPARS or VTAPE). Resolution: Guard code has been placed in RVSSTB and HCPDVT modules to suppress CPXLOAD calls to VTAPE modules if VTAPE is not installed. BUILD_Reqd: VSSIPL VSSICP Toolmin: 301 (2014-01-01) Modules: VSMODID COPY RVSSTB ASSEMBLE

VS550105 VMARC 12/19/13 15:10:44 * HCP Module PTF ID Tags

Update VS550105 applies to VSSI installation builds through 5516 Symptom: * HCP Module PTF ID Tags Problem: New function. Resolution: PTF ID tags added to all HCP modules modified by VSSI. BUILD_Reqd: VSSMMAC Toolmin: 296 (2013-12-13) Modules: VSMODID COPY

VP550104 VMARC 12/14/13 09:26:50 * Hung users when LOGOFF issued

Update VP550104 applies to VSSI installation builds through 5516 Symptom: * Hung users when LOGOFF issued Problem: A zVM 5.4 customer had hung users after issuing LOGOFF without a previous VxCLOSE. The subsequent SNAPDUMP showed the last command as LOGOFF, but VMDCFLAG.VMDLOGOF was 0. The user was hanging in RVPRCC (timer routine), waiting for the database SYNC to complete, but the timer had alreaady been stopped (i.e., SYNC impossible). Resolution: RVxRCC amended to: . Check for LOGOFF as the last command, as well as VMDCFLAG.VMDLOGOF and VMDOSTAT.VMDFORCE+VMDUFORC. . Set the "DIsallow new I/O" bits after the timer is stopped (and not before as was the case). BUILD_Reqd: VSSICP Toolmin: 296 (2013-12-13) Modules: RVPRCC ASSEMBLE

VP550103 VMARC 02/13/14 00:29:42 * More VPBXPLTB Changes

Update VP550103 applies to VSSI installation builds through 5516 Symptom: * More VPBXPLTB Changes Problem: The VPBXPLTB build process is buggy. Resolution: Made the following changes: . Updated VPBXPLTB exec in VSTOOLS to: . Accomodate multiple OSMACLIB, CP, and CMS statements; . Support a new VMMACLIB statement; . Use the default CMS CNTRL file if no CNTRL statement specified in the VPBXPLTB OPTIONS file. . Updated VPBXPLTB source code to: . load non-fullword-aligned variables NBRRCC and LENRCC; . print internal diagnostic error codes during OPMAAA validation. . fix previous update errors introduced by VP550061. BUILD_Reqd: VSSICMS Toolmin: 310 (2014-02-05) Modules: VPBXPLTB ASSEMBLE

VS550102 VMARC 11/18/13 13:53:58 * HTT001 ABENDs when untracking VTAPE user

Update VS550102 applies to VSSI installation builds through 5516 Symptom: * HTT001 ABENDs when untracking VTAPE user Problem: The above ABEND occurred during one of the following commands: . VxCLOSE . LOGOFF . FORCE The HCP exit code calls RVTRSTXF, which in turn calls RVSSTQMQ with R0 = RVT_DELUSER (i.e., delete the userid from the VTAPE tracking table). RVSSTQMQ correctly deletes the user entry from the VTAPE USER table, but then (incorrectly) attempts to delete the user's virtual device entries from the same USER table, instead of from the appropriate DEVICE table. Resolution: Code amended to insert the DEVICE table address in R9 prior to device deletion, instead of using the former (and now incorrect) USER table address. BUILD_Reqd: VSSIPL VSSICP Toolmin: 290 (2013-11-12) Modules: RVSSTQ ASSEMBLE

VP550101 VMARC 11/07/13 22:29:01 * SVC002 ABENDs at shutdown time

Update VP550101 applies to VSSI installation builds through 5516 Symptom: * SVC002 ABENDs at shutdown time Problem: Customer experienced an SVC002 ABEND while attempting to shutdown the system. VSSI module RVxSHU was attempting to reference a VPARS/VDISK user ID that had been previously forced off the system. Resolution: Made the following changes: . RVxSHU amended to bypass invalid VMDBKs if the VMDBK is not dispatchable. BUILD_Reqd: VSSICP Toolmin: 289 (2013-11-07) Modules: RVPRCC ASSEMBLE RVPSHU ASSEMBLE

VS550101 VMARC 11/07/13 22:29:24 * SVC002 ABENDs at shutdown time

Update VS550101 applies to VSSI installation builds through 5516 Symptom: * SVC002 ABENDs at shutdown time Problem: Customer experienced an SVC002 ABEND while attempting to shutdown the system. VSSI module RVxSHU was attempting to reference a VPARS/VDISK user ID that had been previously forced off the system. Resolution: Made the following changes: . RVSSTDDB amended to properly dump storage if called. BUILD_Reqd: VSSIPL VSSICP Toolmin: 289 (2013-11-07) Modules: RVSSTD ASSEMBLE

VP550100 VMARC 11/07/13 22:25:44 * Misc. macro changes

Update VP550100 applies to VSSI installation builds through 5516 Symptom: * Misc. macro changes Problem: Miscellaneous MACRO changes. Resolution: Made the following changes: . VPINDXBK expanded to hold up to 256 page entry ptrs per index entry. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 289 (2013-11-07) Modules: VPINDXBK COPY

VS550099 VMARC 10/25/13 10:13:51 * Add PTF ID tags to all modules

Update VS550099 applies to VSSI installation builds through 5516 Symptom: * Add PTF ID tags to all modules Problem: PTF ID tags needed for effective DUMP debugging. Resolution: This update adds a new 8-character PTF ID tag immediate after the module PROLOG. This tag is visible in CP dumps (via VMDUMPTL), and makes it easy to determine if the customer is running the correct update level for any VSSI modules. Additionally, the COPYRIGHT character strings in all modules have been updated to reflect the current date. BUILD_Reqd: VSSIPL VSSICP Toolmin: 287 (2013-10-23) Modules: VSMODID COPY RVSSTL LAS55099

VP550098 VMARC 10/25/13 10:12:22 * Add PTF ID tags to all modules

Update VP550098 applies to VSSI installation builds through 5516 Symptom: * Add PTF ID tags to all modules Problem: PTF ID tags needed for effective DUMP debugging. Resolution: This update adds a new 8-character PTF ID tag immediate after the module PROLOG. This tag is visible in CP dumps (via VMDUMPTL), and makes it easy to determine if the customer is running the correct update level for any VSSI modules. Additionally, the COPYRIGHT character strings in all modules have been updated to reflect the current date. BUILD_Reqd: VSSICP Toolmin: 287 (2013-10-23) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPL00 ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE

VT550098 VMARC 10/25/13 10:12:37 * Add PTF ID tags to all modules

Update VT550098 applies to VSSI installation builds through 5516 Symptom: * Add PTF ID tags to all modules Problem: PTF ID tags needed for effective DUMP debugging. Resolution: This update adds a new 8-character PTF ID tag immediate after the module PROLOG. This tag is visible in CP dumps (via VMDUMPTL), and makes it easy to determine if the customer is running the correct update level for any VSSI modules. Additionally, the COPYRIGHT character strings in all modules have been updated to reflect the current date. BUILD_Reqd: VSSICP Toolmin: 287 (2013-10-23) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTL00 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE RVTTBL ASSEMBLE

VS550098 VMARC 10/25/13 10:12:29 * Add PTF ID tags to all modules

Update VS550098 applies to VSSI installation builds through 5516 Symptom: * Add PTF ID tags to all modules Problem: PTF ID tags needed for effective DUMP debugging. Resolution: This update adds a new 8-character PTF ID tag immediate after the module PROLOG. This tag is visible in CP dumps (via VMDUMPTL), and makes it easy to determine if the customer is running the correct update level for any VSSI modules. Additionally, the COPYRIGHT character strings in all modules have been updated to reflect the current date. BUILD_Reqd: VSSIPL VSSICP Toolmin: 287 (2013-10-23) Modules: RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSL00 ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE

VP550097 VMARC 10/30/13 09:31:38 * VPARS/VDISK Timer Entry Points

Update VP550097 applies to VSSI installation builds through 5516 Symptom: * VPARS/VDISK Timer Entry Points Problem: Database timer routine RVxCCWTM is not always stopped at database RESET time, causing miscellaneous HTT001/STK017 ABENDs. This issue was reported by customers running multiple-level databases (i.e., concatenated PMRs). Resolution: Made the following changes: . Entry point RVxRCCST added to RVxRCC. This function will start a CPEBK to halt the running database timer. BUILD_Reqd: VSSICP Toolmin: 287 (2013-10-23) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE

VD550096 VMARC 10/23/13 09:35:20 * VPARS/VDISK Timer Entry Points

Update VD550096 applies to VSSI installation builds through 5516 Symptom: * VPARS/VDISK Timer Entry Points Problem: Database timer routine RVxCCWTM is not always stopped at database RESET time, causing miscellaneous HTT001/STK017 ABENDs. This issue was reported by customers running multiple-level databases (i.e., concatenated PMRs). Resolution: Made the following changes: . Entry point RVxRCCST added to RVxMDLAT. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 287 (2013-10-23) Modules: RVDMDLAT MACRO

VP550096 VMARC 10/23/13 09:35:51 * VPARS/VDISK Timer Entry Points

Update VP550096 applies to VSSI installation builds through 5516 Symptom: * VPARS/VDISK Timer Entry Points Problem: Database timer routine RVxCCWTM is not always stopped at database RESET time, causing miscellaneous HTT001/STK017 ABENDs. This issue was reported by customers running multiple-level databases (i.e., concatenated PMRs). Resolution: Made the following changes: . Entry point RVxRCCST added to RVxMDLAT. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 287 (2013-10-23) Modules: RVPMDLAT MACRO

VS550096 VMARC 10/23/13 09:36:46 * VPARS/VDISK Timer Entry Points

Update VS550096 applies to VSSI installation builds through 5516 Symptom: * VPARS/VDISK Timer Entry Points Problem: Database timer routine RVxCCWTM is not always stopped at database RESET time, causing miscellaneous HTT001/STK017 ABENDs. Resolution: Made the following changes: . VSIPROLG macro modified so that module offsets generated under z/VM 5.4 and 6.2 are identical to z/VM 6.3 offsets. . New macros VSCPTRC and VSCPTRCI added. . TRACE entry points inserted into the following HCP modules: . HCPUSO . HCPUSP . HCPWRP BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 287 (2013-10-23) Modules: VS55MAC $EXEC VSCPTRCI COPY VSCPTRC MACRO

VP550095 VMARC 10/22/13 13:33:28 * Database OPEN hangs after VxOPEN CLEAR

Update VP550095 applies to VSSI installation builds through 5516 Symptom: * Database OPEN hangs after VxOPEN CLEAR Problem: Customer experienced database hangs when VxOPEN CLEAR NORESET issued. Further analysis indicated that the database is OPENed OK, but hangs on the CLEAR. This problem is caused by a race condition between the database sync timer started by RVxOPN, and an additional timer started by RVxCLR. The added complexity (start TRQ, CPEBK to stop TRQ, restart TRQ) is unnecessary, and may cause race conditions on single-engine z/VM images. Multiple-engine images (first- or second-level) do not appear to suffer this condition. Resolution: Made the following changes: . RVxOPN is now the ONLY place where the database timer is started. . Database timer start code removed from RVxCLR, since CLEAR only works if the database has been successfully OPENed (i.e., timer already running). BUILD_Reqd: VSSICP Toolmin: 286 (2013-10-15) Modules: RVPCCW ASSEMBLE RVPCLR ASSEMBLE RVPOPN ASSEMBLE

VP550094 VMARC 10/22/13 13:31:55 * Block not written if originating from ONLINE

Update VP550094 applies to VSSI installation builds through 5516 Symptom: * Block not written if originating from ONLINE Problem: PTF 530092 made NOBASE and ECHO mutually exclusive; if VxSET NOBASE was issued, the ECHO flag was turned off. This approach did not consider the effects on VPARS/VDISK ONLINE configurations (i.e., via VxSET REQONline). An ONLINE system (i.e., supporting code property of HP) is a NOBASE system where records are supplied from a remote online TPF system (i.e., not from a local BASE and not from records already in the VPARS database). ONLINE systems require ECHO ON in order to write the remote records to the VPARS/VDISK database. Resolution: Code modified to check for NOBASE and ECHO conflicts only if REQONLINE is not also indicated via VxSET. Note that the REQONLINE environment will NOT write records to the VPARS/VDISK database if ECHO is not also turned ON. The VPARS and VDISK User's Guides discuss this issue in the VPSET/VDSET documentation. BUILD_Reqd: VSSICP Toolmin: 286 (2013-10-15) Modules: RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPSET ASSEMBLE

VT550093 VMARC 10/04/13 10:42:25 * Broken VTAPE Metadata (EB) Block Chains

Update VT550093 applies to VSSI installation builds through 5516-17 Symptom: * Broken VTAPE Metadata (EB) Block Chains Problem: Customer generated VTAPE tapes which received I/O errors when the tape was next read. Upon closer inspection (thanks, KLM!!), it was determined that all data (DB) blocks were sucessfully written to the VTAPE library. However, the metadata (EB) blocks, which are used to point to the data blocks, had broken chains. This event occurs when the current VTAPE MDISK is near or at full (e.g., 98+%). The MDISK space check code is spread over several VTAPE modules, and generates inconsistent results (e.g., whether to return a Unit Exception (low on space) or a Unit Check (out of space) to the writing application). Resolution: Made the following changes: . All MDISK capacity-checking code is consolidated into RVTCCW, and removed from other VTAPE modules. If VTAPE determines that it is running low on space, a Unit Exception will be returned to the caller, and the current block will not be written. This gives the caller a chance to write an ending TapeMark and trailer labels, for which sufficient space will exist (approx. 2 VTAPE blocks per tape). If VTAPE determines that the MDISK is out of space, a Unit Check will be returned to the caller, and the current block will not be written. This conforms to normal tape I/O semantics. . The VTACTBK and VTMDISK blocks have been cleaned up, and modified to support the enhanced space checks (via PTF VT550091). Notes: For VTAPE users, this PTF MUST be applied immediately after VT550092. BUILD_Reqd: VSSICP Toolmin: 279 (2013-10-03) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE

VT550092 VMARC 10/03/13 15:53:50 * Expanded VSSI MACRO/COPYBOOK Expansion

Update VT550092 applies to VSSI installation builds through 5516-17 Symptom: * Expanded VSSI MACRO/COPYBOOK Expansion Problem: Miscellaneous VTAPE errors require additional VTAPE control block modification and enhanced diagnostic capability. Resolution: . Applicable MACRO/COPYBOOK structures updated . New diagnostic MACROs added. Notes: This update will bypass all assemblies. For VTAPE users, this update MUST be followed by the immediate application of VT550093, which assembles the relevant modules. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 279 (2013-10-03) Modules: VTACTBK COPY VTMDSKBK COPY

VS550092 VMARC 10/03/13 15:53:43 * Expanded VSSI MACRO/COPYBOOK Expansion

Update VS550092 applies to VSSI installation builds through 5516 Symptom: * Expanded VSSI MACRO/COPYBOOK Expansion Problem: Miscellaneous VTAPE errors require additional VTAPE control block modification and enhanced diagnostic capability. Resolution: . Applicable MACRO/COPYBOOK structures updated . New diagnostic MACROs added. . RVSTRACE area in RVSSTD expanded to 32 bytes. BUILD_Reqd: VSSIPL VSSICP Toolmin: 279 (2013-10-03) Modules: RVSSTD ASSEMBLE

VP550091 VMARC 10/02/13 15:47:03 * VMDBK switch results in STK017

Update VP550091 applies to VSSI installation builds through 5516 Symptom: * VMDBK switch results in STK017 Problem: During detection of FORCED-LOGOFF, the VSSI timer routine in RVxCCW attempts to dispatch the database reset code under the VMDBK of the target user. This action causes a race condition with HCPCFM, resulting in intermittent STK017 ABENDs. This issue does not occur if the FORCE or LOGOFF commands are used; only manual testing or setting of VMDOSTAT.VMDFORCE is vulnerable to this condition. Resolution: RVxCCW timer code amended to remove all checks for VMDBK flag bits, since the VMDBK may not exist. The normal routines in HCPCFM will drive the logoff code in HCPUSO, which will in turn drive RVxRCC database reset. BUILD_Reqd: VSSICP Toolmin: 276 (2013-09-30) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE RVPSV2 ASSEMBLE

VS550091 VMARC 10/02/13 15:47:10 * VMDBK switch results in STK017

Update VS550091 applies to VSSI installation builds through 5516 Symptom: * VMDBK switch results in STK017 Problem: During detection of FORCED-LOGOFF, the VSSI timer routine in RVxCCW attempts to dispatch the database reset code under the VMDBK of the target user. This action causes a race condition with HCPCFM, resulting in intermittent STK017 ABENDs. This issue does not occur if the FORCE or LOGOFF commands are used; only manual testing or setting of VMDOSTAT.VMDFORCE is vulnerable to this condition. Resolution: RVxCCW timer code amended to remove all checks for VMDBK flag bits, since the VMDBK may not exist. The normal routines in HCPCFM will drive the logoff code in HCPUSO, which will in turn drive RVxRCC database reset. Additionally, this update adds several diagnostic functions to VSSI stub code. BUILD_Reqd: VSSIPL VSSICP Toolmin: 276 (2013-09-30) Modules: RVSSTD ASSEMBLE RVSSTQ ASSEMBLE

VP550090 VMARC 10/02/13 15:41:27 * Database indices exhausted after 32K entries

Update VP550090 applies to VSSI installation builds through 5516 Symptom: * Database indices exhausted after 32K entries Problem: Customer is using a very large VPARS database. However, the current database indices only allow for 64 page entries per index (i.e., 32K record pointers per HI, II, DI, or RD index). The customer attempted to exceed 32K HI index entries, resulting in a HTT001 ABEND. This event occurs only if the VPARS or VDISK database is significantly larger than at most sites (e.g. > 800M records). Resolution: Made the following changes: . RVxDBT amended to force soft ABENDs for queue management errors instead of the former hard ABENDs. Additionally, guard code has been added to disallow any attempts to fit more than the maximum entries in queue index pages. . Multiple modules amended to enforce condition code checking after issuing calls to RVxDBT routines. BUILD_Reqd: VSSICP Toolmin: 276 (2013-09-30) Modules: RVPBUF ASSEMBLE RVPCLR ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPMSG ASSEMBLE RVPOPS ASSEMBLE VPCPYASM ASSEMBLE

VD550089 VMARC 10/02/13 15:26:40 * Database indices exhausted after 32K entries

Update VD550089 applies to VSSI installation builds through 5516 Symptom: * Database indices exhausted after 32K entries Problem: Customer is using a very large VPARS database. However, the current database indices only allow for 64 page entries per index (i.e., 32K record pointers per HI, II, DI, or RD index). The customer attempted to exceed 32K HI index entries, resulting in a HTT001 ABEND. This event occurs only if the VPARS or VDISK database is significantly larger than at most sites (e.g. > 800M records). Resolution: Made the following changes: . VPINDXBK amended to double the index page pointers from 64 to 128 (i.e., 65536 entries per index) . RVxMDLAT macro amended to remove obsolete entry point RVxRCCST; no longer used. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 276 (2013-09-30) Modules: RVDMDLAT MACRO

VP550089 VMARC 10/02/13 15:27:43 * Database indices exhausted after 32K entries

Update VP550089 applies to VSSI installation builds through 5516 Symptom: * Database indices exhausted after 32K entries Problem: Customer is using a very large VPARS database. However, the current database indices only allow for 64 page entries per index (i.e., 32K record pointers per HI, II, DI, or RD index). The customer attempted to exceed 32K HI index entries, resulting in a HTT001 ABEND. This event occurs only if the VPARS or VDISK database is significantly larger than at most sites (e.g. > 800M records). Resolution: Made the following changes: . VPINDXBK amended to double the index page pointers from 64 to 128 (i.e., 65536 entries per index) . RVxMDLAT macro amended to remove obsolete entry point RVxRCCST; no longer used. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 276 (2013-09-30) Modules: VPINDXBK COPY RVPMDLAT MACRO

PTFs below apply to Packages at 5514 and lower

VP550088 VMARC 09/02/13 16:57:22 * Logoff-Pending after FORCE

Update VP550088 applies to VSSI installation builds through 5514 Symptom: * Logoff-Pending after FORCE Problem: VSSI database reset code not being called in all cases. Resolution: Made the following changes for proper handling of database resets if the user is in FORCED-LOGOFF status: . RVxCCW amended to bypass CCW002 soft ABEND if CCT table ptr not found in VMBDK. . RVxCSP amended to bypass CSP001 soft ABEND if CCT table ptr not found in VMBDK. . RVxIOR amended to bypass further CPEBK stacking. . RVxRCC amended to: . Use origin VMDBK for status checking. . Bypass all waits for pending I/O. . Turn off SIE bits in VMDRSTAT to avoid later hangs in HCPUSP. . RVxSV2 amended to bypass SV2002 soft ABEBDs if device DETACH has errors. BUILD_Reqd: VSSICP Toolmin: 265 (2013-08-21) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPIOR ASSEMBLE RVPRCC ASSEMBLE RVPSV2 ASSEMBLE

VS550088 VMARC 09/02/13 16:57:31 * Logoff-Pending after FORCE

Update VS550088 applies to VSSI installation builds through 5514 Symptom: * Logoff-Pending after FORCE Problem: VSSI database reset code not being called in all cases. Resolution: Made the following changes for proper handling of database resets if the user is in FORCED-LOGOFF status: . HCPUSO amended to call DB reset code from multiple locations. . Reinstated database reset code in HCPUSP. . Diagnostic support functions added to RVSSTD. . Diagnostic support functions added to RVSSTQ. BUILD_Reqd: VSSIPL VSSICP Toolmin: 265 (2013-08-21) Modules: RVSSTD ASSEMBLE RVSSTQ ASSEMBLE

VS550087 VMARC 09/02/13 17:21:58 * Logoff-Pending after FORCE

Update VS550087 applies to VSSI installation builds through 5514 Symptom: * Logoff-Pending after FORCE Problem: VSSI database reset code not being called in all cases. Resolution: Made the following changes for proper handling of database resets if the user is in FORCED-LOGOFF status: . Serialization lock added to RVSVPUBK. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 265 (2013-08-21) Modules: RVSVPUBK COPY

VP550086 VMARC 08/16/13 12:19:13 * CP Exit Cleanup

Update VP550086 applies to VSSI installation builds through 5514 Symptom: * CP Exit Cleanup Problem: New function. Resolution: This update updates the VSSIVP PRODUCT file to support the CP exit changes made in VS550086. BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVPSV2 ASSEMBLE

VS550086 VMARC 08/16/13 12:19:19 * CP Exit Cleanup

Update VS550086 applies to VSSI installation builds through 5514 Symptom: * CP Exit Cleanup Problem: New function. Resolution: This update does as follows: . Removes the VSSI exit point in IBM module HCPUSP. All VSSI VPARS/VDISK database reset code in user LOGOFF and FORCED-LOGOFF scenarios is now invoked via HCPUSO; HCPUSP is no longer needed. . Adds a new VSSI exit point in IBM module HCPPAV. This exit point begins VSSI support of PAV and HyperPAV aliases. The current exit point is an effective NO-OP (i.e., no modifications made to PAV VDEVs), and will be modified in a future PTF. BUILD_Reqd: VSSMMAC Toolmin: 260 (2013-07-12) Modules: VSMODID COPY

VS550085 VMARC 08/16/13 07:33:37 * CP Exit Cleanup

Update VS550085 applies to VSSI installation builds through 5514 Symptom: * CP Exit Cleanup Problem: New function. Resolution: This update adds a new macro, VSXRL, for architecture- dependent EXECUTE instruction generation (EX for HLASM versions less than 1.6 or z/VM releases older than 6.1, EXRL otherwise). BUILD_Reqd: VSSMMAC Toolmin: 260 (2013-07-12) Modules: VS55MAC $EXEC VSXRL MACRO

VS550084 VMARC 08/15/13 07:33:07 * STK017 ABENDs in forced-logoff (4)

Update VS550084 applies to VSSI installation builds through 5514 Symptom: * STK017 ABENDs in forced-logoff (4) Problem: Customer code sets VMDOSTAT.VMDFORCE to force a VPARS/VDISK user off the system. CP eventually calls entry point HCPUSOPR, which does not call the VSSI database reset code. The VSSI database timer thus continues to run, which causes a STK017 ABEND once the user has been logged off. Resolution: HCPUSO amended to invoke VSSI exit point RVxRCCXL from within entry point HCPUSOPR, which is common to: . the LOGOFF command processor . the FORCE command processor . manual setting of VMDOSTAT.VMDFORCE BUILD_Reqd: VSSIPL VSSMMAC Toolmin: 260 (2013-07-12) Modules: VSMODID COPY

VS550083 VMARC 08/14/13 08:54:46 * Extended-relative instructions invalid for Z9

Update VS550083 applies to VSSI installation builds through 5514 Symptom: * Extended-relative instructions invalid for Z9 Problem: Customers running on the processors older than Z10 cannot use the following extended-relative instructions: . LRL . STRL . EXRL The VSLRL and VSSTL macros emit instructions based on the HL/ASM level (versions < 1.6 do not support the above instructions); no provision was made for the hardware architecture. Resolution: The VSLRL and VSSTL macros have been amended to check for the z/VM release as well as the HL/ASM version (i.e., z/VM 5.4 was the last release capable of running on processors older than Z10). BUILD_Reqd: VSSIPL VSSICP Toolmin: 260 (2013-07-12) Modules: VSMODID COPY VSLRL MACRO VSSTL MACRO RVSSTL LAS55083

VS550082 VMARC 08/10/13 09:44:56 * Extended-relative instructions invalid for Z9

Update VS550082 applies to VSSI installation builds through 5514 Symptom: * Extended-relative instructions invalid for Z9 Problem: Customers running on the processors older than Z10 cannot use the following extended-relative instructions: . LRL . STRL . EXRL The VSLRL and VSSTL macros emit instructions based on the HL/ASM level (versions < 1.6 do not support the above instructions); no provision was made for the hardware architecture. Resolution: The VSLRL and VSSTL macros have been amended to check for the z/VM release as well as the HL/ASM version (i.e., z/VM 5.4 was the last release capable of running on processors older than Z10). BUILD_Reqd: VSSIPL VSSICP Toolmin: 260 (2013-07-12) Modules: VSMODID COPY RVSSTL LAS55082

VS550081 VMARC 08/10/13 09:41:37 * Extended-relative instructions invalid for Z9

Update VS550081 applies to VSSI installation builds through 5514 Symptom: * Extended-relative instructions invalid for Z9 Problem: Customers running on the processors older than Z10 cannot use the following extended-relative instructions: . LRL . STRL . EXRL The VSLRL and VSSTL macros emit instructions based on the HL/ASM level (versions < 1.6 do not support the above instructions); no provision was made for the hardware architecture. Resolution: The VSLRL and VSSTL macros have been amended to check for the z/VM release as well as the HL/ASM version (i.e., z/VM 5.4 was the last release capable of running on processors older than Z10). BUILD_Reqd: VSSIPL VSSICP Toolmin: 260 (2013-07-12) Modules: VSHCPV MACRO VSLRL MACRO VSSTL MACRO RVSSTB ASSEMBLE RVSSTQ ASSEMBLE

VP550080 VMARC 08/09/13 08:36:44 * Logoff-pending for forced VPARS/VDISK user

Update VP550080 applies to VSSI installation builds through 5514 Symptom: * Logoff-pending for forced VPARS/VDISK user Problem: Customer initiated force-logoff for a VPARS/VDISK user via setting VMDOSTAT.VMDFORCE. This user had I/O requests pending, which were not restarted due to the FORCE request. Entry point RVxRCCRR entered a loop waiting for the I/O to complete, which caused a FORCE-PENDING status for the user (i.e., the wait loop never completed). Resolution: RVxRCCRR amended to bypass pending I/O requests in the event that FORCE-LOGOFF is detected. Pending I/O requests will be lost, but the ID should not be hung in FORCE-PENDING status. BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVPRCC ASSEMBLE

VT550079 VMARC 08/06/13 10:43:46 * VSSTL macro does not accept R14 as input

Update VT550079 applies to VSSI installation builds through 5514-15 Symptom: * VSSTL macro does not accept R14 as input Problem: VSSTL macro dows not accept R14 as input under HLASM V5. Resolution: Code amended to use another register. BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVTCON ASSEMBLE

VP550078 VMARC 08/01/13 13:25:09 * Additional STK017 ABENDS at forced-LOGOFF

Update VP550078 applies to VSSI installation builds through 5514 Symptom: * Additional STK017 ABENDS at forced-LOGOFF Problem: Continuing STK017 ABENDs at forced-logoff. Resolution: Additional force-logoff checks added in RVxCCW (to avoid CPEBK launch). BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVPCCW ASSEMBLE

VT550077 VMARC 08/01/13 07:52:50 * EXRL instruction invalid with HLASM V5

Update VT550077 applies to VSSI installation builds through 5514-15 Symptom: * EXRL instruction invalid with HLASM V5 Problem: HLASM5 does not support the EXRL instruction. Resolution: Code amended to use EX instead of EXRL. VSSI support for HLASM5 will eventually be withdrawn in future releases; customers are STRONGLY recommended to upgrade to HLASM V6 or higher. BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVTCON ASSEMBLE RVTDEF ASSEMBLE

VS550077 VMARC 08/01/13 07:52:42 * EXRL instruction invalid with HLASM V5

Update VS550077 applies to VSSI installation builds through 5514 Symptom: * EXRL instruction invalid with HLASM V5 Problem: HLASM5 does not support the EXRL instruction. Resolution: Code amended to use EX instead of EXRL. VSSI support for HLASM5 will eventually be withdrawn in future releases; customers are STRONGLY recommended to upgrade to HLASM V6 or higher. BUILD_Reqd: VSSIPL VSSICP Toolmin: 260 (2013-07-12) Modules: RVSCFG ASSEMBLE RVSSTD ASSEMBLE RVSSTQ ASSEMBLE

VS550076 VMARC 07/31/13 08:36:18 * Handle FORCED-LOGOFF caused via user code

Update VS550076 applies to VSSI installation builds through 5514 Symptom: * Handle FORCED-LOGOFF caused via user code Problem: Customer supports a user modification to CP which generates a forced-logoff for specific VM userids via setting VMDOSTAT.VMDFORCE. Since the above bit was set in user code, and not via the FORCE command, the VSSI database reset code in HCPUSOFL (FORCE command) and HCPUSOLG (LOGOFF command) was not driven, resulting in STK017 ABENDs when database timers attempted to process after the userid was already logged off. Resolution: HCPUSO amended to capture FORCE-LOGOFF indication in entry point HCPUSORF (involuntary FORCE-LOGOFF) and invoke database reset routine. Notes: After application of this PTF, the customer must rebuild the CP NUC; e.g.: . vssetup . vssiprep . vsbldnuc . vscopy nuc cf1 (force (if z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if z/VM >= 6.2) BUILD_Reqd: VSSIPL VSSMMAC Toolmin: 260 (2013-07-12) Modules: VSMODID COPY

VP550075 VMARC 07/26/13 12:06:28 * Incorrect counter decrement for open DB count

Update VP550075 applies to VSSI installation builds through 5514 Symptom: * Incorrect counter decrement for open DB count Problem: Several VPARS/VDISK counters have invalid values: . VP6MAXRW . VP6MAXRO Several VPARS/VDISK counters are being decremented incorrectly (i.e., < 0): . VP6OPNRW . VP6OPNRO Resolution: Logic amended to set correct counter values. BUILD_Reqd: VSSICP Toolmin: 260 (2013-07-12) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE

VD550074 VMARC 07/26/13 12:04:24 * Incorrect counter decrement for open DB count

Update VD550074 applies to VSSI installation builds through 5514 Symptom: * Incorrect counter decrement for open DB count Problem: Several VPARS/VDISK counters have invalid values: . VP6MAXRW . VP6MAXRO Several VPARS/VDISK counters are being decremented incorrectly (i.e., < 0): . VP6OPNRW . VP6OPNRO Resolution: Logic amended to set correct counter values. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 260 (2013-07-12) Modules: VD6CNTRL MACRO

VP550074 VMARC 07/26/13 12:04:58 * Incorrect counter decrement for open DB count

Update VP550074 applies to VSSI installation builds through 5514 Symptom: * Incorrect counter decrement for open DB count Problem: Several VPARS/VDISK counters have invalid values: . VP6MAXRW . VP6MAXRO Several VPARS/VDISK counters are being decremented incorrectly (i.e., < 0): . VP6OPNRW . VP6OPNRO Resolution: Logic amended to set correct counter values. BUILD_Reqd: VSSICP VSSICMS VSSMMAC Toolmin: 260 (2013-07-12) Modules: VPCTLBK COPY VP6CNTRL MACRO

VP550073 VMARC 07/17/13 09:16:01 * STK017 timer queue ABENDs (3)

Update VP550073 applies to VSSI installation builds through 5514 Symptom: * STK017 timer queue ABENDs (3) Problem: More race conditions found in async timer routine. Resolution: RVxCCWTM amended fo check VMDBK queue flags prior to dispatching the next CPEBK. BUILD_Reqd: VSSICP Toolmin: 259 (2013-07-08) Modules: RVPCCW ASSEMBLE

VS550072 VMARC 07/17/13 16:59:04 * New function - dump memory block

Update VS550072 applies to VSSI installation builds through 5514 Symptom: * New function - dump memory block Problem: New Dump Memory function. Resolution: VSSUBR now supports a new API (VSPRTMEM) to dump arbitrary blocks of memory from 1 to 16M bytes. BUILD_Reqd: VSSICMS Toolmin: 259 (2013-07-08) Modules: VSSUBR ASSEMBLE

VS550071 VMARC 07/10/13 13:18:06 * CMS linkage macro enhancements

Update VS550071 applies to VSSI installation builds through 5514 Symptom: * CMS linkage macro enhancements Problem: CMS linkage macros do not use baseless addressing. Resolution: MACROs modified to use baseless addressing. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 259 (2013-07-08) Modules: VSXCALL MACRO VSXENTR MACRO VSXEXIT MACRO

VP550070 VMARC 07/09/13 08:59:32 * Expanded message lengths

Update VP550070 applies to VSSI installation builds through 5514 Symptom: * Expanded message lengths Problem: Message print enhancement. Resolution: Made the following changes: . Message sizes for all stub code message have been increased to 72 bytes from 60 bytes. . Enhancements made to Print Memory Block routine to make the output look more CP-like. BUILD_Reqd: VSSICP Toolmin: 259 (2013-07-08) Modules: RVPRST ASSEMBLE RVPSHU ASSEMBLE

VT550070 VMARC 07/09/13 08:59:48 * Expanded message lengths

Update VT550070 applies to VSSI installation builds through 5514-15 Symptom: * Expanded message lengths Problem: Message print enhancement. Resolution: Made the following changes: . Message sizes for all stub code message have been increased to 72 bytes from 60 bytes. . Enhancements made to Print Memory Block routine to make the output look more CP-like. BUILD_Reqd: VSSICP Toolmin: 259 (2013-07-08) Modules: RVTCON ASSEMBLE RVTRST ASSEMBLE RVTSHU ASSEMBLE RVTSV2 ASSEMBLE

VS550070 VMARC 07/09/13 08:59:40 * Expanded message lengths

Update VS550070 applies to VSSI installation builds through 5514 Symptom: * Expanded message lengths Problem: Message print enhancement. Resolution: Made the following changes: . Message sizes for all stub code message have been increased to 72 bytes from 60 bytes. . Enhancements made to Print Memory Block routine to make the output look more CP-like. BUILD_Reqd: VSSIPL VSSICP Toolmin: 259 (2013-07-08) Modules: VSMODID COPY RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTG ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSSTL LAS55070

VP550069 VMARC 07/05/13 13:11:06 * STK017 timer queue ABENDS (2)

Update VP550069 applies to VSSI installation builds through 5514 Symptom: * STK017 timer queue ABENDS (2) Problem: User experienced STK017 ABEND with PTF Vx550067 applied. Although the previous update drastically reduced these occurrences, it did not entirely eliminate race conditions between RVxRCCCL (entered during database close) and RVcCCWTM (async timer statistics routine). Resolution: RVxRCC amended to force 3-second wait for timer expiration if user is in LOGOFF or FORCE-LOGOFF status. BUILD_Reqd: VSSICP Toolmin: 253 (2013-06-19) Modules: RVPRCC ASSEMBLE

VP550068 VMARC 07/03/13 13:24:44 * IPL2 expanded record write truncated

Update VP550068 applies to VSSI installation builds through 5514 Symptom: * IPL2 expanded record write truncated Problem: Cylinder 0, track 0 I/O uses Read Count/Key/Data (x'1E') and Write Count/Key/Data (x'1D') to read and write the IPL1, IPL2, VOL1, and IPLA records on track 0. If one of the above records exist on the VPARS/VDISK database, and the user subsequently attempts to write larger records, the record size is truncated to the current size on the database, and the truncated record is written. This action causes incorrect record lengths when used by subsequent operations (such as IPL). Resolution: RVxDBM has been modified to erase the existing VPARS/VDISK record on track 0 prior to the write of the new record to the database. The record size of any Track 0 record is thus always set by the last write operation. BUILD_Reqd: VSSICP Toolmin: 253 (2013-06-19) Modules: RVPDBM ASSEMBLE

VP550067 VMARC 06/25/13 11:12:41 * STK017 ABENDs in forced-LOGOFF

Update VP550067 applies to VSSI installation builds through 5514 Symptom: * STK017 ABENDs in forced-LOGOFF Problem: Customer experienced a STK017 ABEND in RVxCCWTM (timer management routine) after forced-LOGOFF. This is a race condition; the logoff command executed while the timer routine was running. Resolution: RVxCCW amended to add an extra check just before a new CPEBK is launched. If the user no longer exists, the CPEBK launch is bypassed. BUILD_Reqd: VSSICP Toolmin: 253 (2013-06-19) Modules: RVPCCW ASSEMBLE

VP550066 VMARC 06/17/13 14:11:10 * HTT001 ABENDs in VPARS/VDISK TRQ handler

Update VP550066 applies to VSSI installation builds through 5514 Symptom: * HTT001 ABENDs in VPARS/VDISK TRQ handler Problem: Customer received HTT001 ABENDs while attempting to force-logoff VPARS/VDISK users. This ABEND was partially addressed by PTF 550064, but failed to address the case where the user VMDBK has already been destroyed by CP. Resolution: Made the following changes: . RVSSTQ amended to save and validate the user's TRQBLOK address. At database CLOSE time (called via user VPCLOSE|VDCLOSE command, LOGOFF, or forced-LOGOFF), the saved address is destroyed. . RVxCCWTM amended to validate the TRQBLOK address via a call to RVSSTQ, and to bypass TRQ processing if the address is no longer valid. Application of this PTF requires the immediate application of the 550066 PTF9s). After all 550065 and 550066 PTFs are applied, you must do the following to install all service elements: . vssetup . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (if target z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if target z/VM >= 6.2) BUILD_Reqd: VSSICP Toolmin: 249 (2013-05-23) Modules: RVPCCW ASSEMBLE RVPIFC ASSEMBLE RVPOPN ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSV1 ASSEMBLE

VT550066 VMARC 06/17/13 14:11:17 * HTT001 ABENDs in VPARS/VDISK TRQ handler

Update VT550066 applies to VSSI installation builds through 5514-15 Symptom: * HTT001 ABENDs in VPARS/VDISK TRQ handler Problem: Customer received HTT001 ABENDs while attempting to force-logoff VPARS/VDISK users. This ABEND was partially addressed by PTF 550064, but failed to address the case where the user VMDBK has already been destroyed by CP. Resolution: Made the following changes: . RVSSTQ amended to save and validate the user's TRQBLOK address. At database CLOSE time (called via user VPCLOSE|VDCLOSE command, LOGOFF, or forced-LOGOFF), the saved address is destroyed. . RVxCCWTM amended to validate the TRQBLOK address via a call to RVSSTQ, and to bypass TRQ processing if the address is no longer valid. Application of this PTF requires the immediate application of the 550066 PTF9s). After all 550065 and 550066 PTFs are applied, you must do the following to install all service elements: . vssetup . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (if target z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if target z/VM >= 6.2) BUILD_Reqd: VSSICP Toolmin: 249 (2013-05-23) Modules: RVTDEF ASSEMBLE RVTRST ASSEMBLE

VS550066 VMARC 06/17/13 14:11:37 * HTT001 ABENDs in VPARS/VDISK TRQ handler

Update VS550066 applies to VSSI installation builds through 5514 Symptom: * HTT001 ABENDs in VPARS/VDISK TRQ handler Problem: Customer received HTT001 ABENDs while attempting to force-logoff VPARS/VDISK users. This ABEND was partially addressed by PTF 550064, but failed to address the case where the user VMDBK has already been destroyed by CP. Resolution: Made the following changes: . RVSSTQ amended to save and validate the user's TRQBLOK address. At database CLOSE time (called via user VPCLOSE|VDCLOSE command, LOGOFF, or forced-LOGOFF), the saved address is destroyed. . RVxCCWTM amended to validate the TRQBLOK address via a call to RVSSTQ, and to bypass TRQ processing if the address is no longer valid. Application of this PTF requires the immediate application of the 550066 PTF9s). After all 550065 and 550066 PTFs are applied, you must do the following to install all service elements: . vssetup . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (if target z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if target z/VM >= 6.2) BUILD_Reqd: VSSMMAC Toolmin: 249 (2013-05-23) Modules: VSMODID COPY

VS550065 VMARC 06/17/13 14:02:51 * HTT001 ABENDs in VPARS/VDISK TRQ handler

Update VS550065 applies to VSSI installation builds through 5514 Symptom: * HTT001 ABENDs in VPARS/VDISK TRQ handler Problem: Customer received HTT001 ABENDs while attempting to force-logoff VPARS/VDISK users. This ABEND was partially addressed by PTF 550064, but failed to address the case where the user VMDBK has already been destroyed by CP. Resolution: Made the following changes: . RVSSTQ amended to save and validate the user's TRQBLOK address. At database CLOSE time (called via user VPCLOSE|VDCLOSE command, LOGOFF, or forced-LOGOFF), the saved address is destroyed. . RVxCCWTM amended to validate the TRQBLOK address via a call to RVSSTQ, and to bypass TRQ processing if the address is no longer valid. Application of this PTF requires the immediate application of the 550066 PTF9s). After all 550065 and 550066 PTFs are applied, you must do the following to install all service elements: . vssetup . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (if target z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if target z/VM >= 6.2) BUILD_Reqd: VSSIPL VSSICP Toolmin: 249 (2013-05-23) Modules: RVSVDUBK COPY RVSVPUBK COPY VSCPXRM MACRO RVSSTQ ASSEMBLE

PTFs below apply to Packages at 5512 and lower

VP550064 VMARC 06/08/13 08:12:29 * Convert all HCPGETST|RELST to VSCPSTOR calls

Update VP550064 applies to VSSI installation builds through 5512 Symptom: * Convert all HCPGETST|RELST to VSCPSTOR calls Problem: Mix of HCP and VSSI storage management calls in VSSI code. Additionally, an error in RVxCCW was causing timer interrupts to be handled even if the user was in LOGOFF/FORCE status, causing HTT001 ABENDs in this case. Resolution: The following changes were made: . ALL HCPGETST/HCPRELST macro calls converted to VSCPSTOR macro calls. This change provides a single module, RVSSTG, used for all VSSI storage management calls. The new code also supports additional TRACE support not available previously. . RVxCCW has been modified to bypass statistics timer processing if the user is in LOGOFF or FORCE status. This PTF is a COREQ to 550063, and must be applied if 550063 is applied. After 550063 and 550064 are applied, the user MUST rebuild the VSSI code, as follows: . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (z/VM < 6.2) . vscopy nuc cf1 cf0 (force (z/VM >= 6.2) BUILD_Reqd: VSSICP Toolmin: 249 (2013-05-23) Modules: RVPCCW ASSEMBLE RVPPRC ASSEMBLE

VS550064 VMARC 06/08/13 08:12:37 * Convert all HCPGETST|RELST to VSCPSTOR calls

Update VS550064 applies to VSSI installation builds through 5512 Symptom: * Convert all HCPGETST|RELST to VSCPSTOR calls Problem: Mix of HCP and VSSI storage management calls in VSSI code. Additionally, an error in RVxCCW was causing timer interrupts to be handled even if the user was in LOGOFF/FORCE status, causing HTT001 ABENDs in this case. Resolution: The following changes were made: . ALL HCPGETST/HCPRELST macro calls converted to VSCPSTOR macro calls. This change provides a single module, RVSSTG, used for all VSSI storage management calls. The new code also supports additional TRACE support not available previously. . RVxCCW has been modified to bypass statistics timer processing if the user is in LOGOFF or FORCE status. This PTF is a COREQ to 550063, and must be applied if 550063 is applied. After 550063 and 550064 are applied, the user MUST rebuild the VSSI code, as follows: . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (z/VM < 6.2) . vscopy nuc cf1 cf0 (force (z/VM >= 6.2) BUILD_Reqd: VSSIPL VSSICP Toolmin: 249 (2013-05-23) Modules: VSMODID COPY RVSSTB ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSSTL LAS55064

VP550063 VMARC 06/08/13 07:59:04 * VPARS/VDISK database close at force-logoff

Update VP550063 applies to VSSI installation builds through 5512 Symptom: * VPARS/VDISK database close at force-logoff Problem: Customer attempted to force-logoff several VPARS/VDISK userids; the following errors were reported based on the state of the VM at the time: ABEND Status Reason SV2002 Soft attempt to detach database MDISK STK017 Soft Invalid I/O interrupt HTT001 Hard Invalid reference to VxCCTBK in timer handler routine RVxCCWTM The above errors are caused by the fact that the code is in the process of releasing the relevant control blocks when the ASYNC interrupts occur. While triaging the above, several memory leaks were discovered in module RVSSTB. Resolution: The following changes have been made: . Additional code added to RVxRCC to skip unnecessary processing in LOGOFF/FORCE states . Memory FREE/FRET processing moved to a new stub module (RVSSTG) from RVSSTB; memory leaks fixed . VSCPSTOR and associated macros/copybooks amended to support memory trace events (i.e., console msgs). The TRACE events are actived in the VSSI Lab, and are not turned on at the customer site. Application of PTF update(s) 550063 MUST be accompanied by application of PTF update(s) 550064. When 550063 and 550064 are both applied, the user MUST rebuild the VSSI code, as follows: . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (z/VM < 6.2) . vscopy nuc cf1 cf0 (force (z/VM >= 6.2) BUILD_Reqd: VSSICP Toolmin: 249 (2013-05-23) Modules: RVPRCC ASSEMBLE

VS550063 VMARC 06/08/13 07:59:14 * VPARS/VDISK database close at force-logoff

Update VS550063 applies to VSSI installation builds through 5512 Symptom: * VPARS/VDISK database close at force-logoff Problem: Customer attempted to force-logoff several VPARS/VDISK userids; the following errors were reported based on the state of the VM at the time: ABEND Status Reason SV2002 Soft attempt to detach database MDISK STK017 Soft Invalid I/O interrupt HTT001 Hard Invalid reference to VxCCTBK in timer handler routine RVxCCWTM The above errors are caused by the fact that the code is in the process of releasing the relevant control blocks when the ASYNC interrupts occur. While triaging the above, several memory leaks were discovered in module RVSSTB. Resolution: The following changes have been made: . Additional code added to RVxRCC to skip unnecessary processing in LOGOFF/FORCE states . Memory FREE/FRET processing moved to a new stub module (RVSSTG) from RVSSTB; memory leaks fixed . VSCPSTOR and associated macros/copybooks amended to support memory trace events (i.e., console msgs). The TRACE events are actived in the VSSI Lab, and are not turned on at the customer site. Application of PTF update(s) 550063 MUST be accompanied by application of PTF update(s) 550064. When 550063 and 550064 are both applied, the user MUST rebuild the VSSI code, as follows: . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 (force (z/VM < 6.2) . vscopy nuc cf1 cf0 (force (z/VM >= 6.2) BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 249 (2013-05-23) Modules: VS55MAC $EXEC VSXCREG COPY VSXHREG COPY RVSMDLAT MACRO RVSMDLAX MACRO VSCPSTOR MACRO VSSTOR MACRO VSXHID MACRO VSXRID MACRO RVSSTD ASSEMBLE RVSSTG ASSEMBLE

VP550062 VMARC 05/21/13 09:48:44 * Move HCP entries to VS55MAC loadlist

Update VP550062 applies to VSSI installation builds through 5512 Symptom: * Move HCP entries to VS55MAC loadlist Problem: HCP COPY mods currently exist in the VP55MAC and VT55MAC macro loadlists. Resolution: All HCP MACRO/COPY mods moved to VS55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VP55MAC $EXEC

VT550062 VMARC 05/21/13 09:48:17 * Move HCP entries to VS55MAC loadlist

Update VT550062 applies to VSSI installation builds through 5512-13 Symptom: * Move HCP entries to VS55MAC loadlist Problem: HCP COPY mods currently exist in the VP55MAC and VT55MAC macro loadlists. Resolution: All HCP MACRO/COPY mods moved to VS55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VT55MAC $EXEC

VS550062 VMARC 05/21/13 09:49:10 * Move HCP entries to VS55MAC loadlist

Update VS550062 applies to VSSI installation builds through 5512 Symptom: * Move HCP entries to VS55MAC loadlist Problem: HCP COPY mods currently exist in the VP55MAC and VT55MAC macro loadlists. Resolution: All HCP MACRO/COPY mods moved to VS55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VS55MAC $EXEC

VP550061 VMARC 05/28/13 06:57:57 * Support pool 4D6, Prime/DUP non-sequential

Update VP550061 applies to VSSI installation builds through 5512 Symptom: * Support pool 4D6, Prime/DUP non-sequential Problem: The current VPBXPLTB does not support the TPF 4D6 pools or Prime/DUP non-sequential records. Resolution: Support added. Application of this PTF will generate an assembly error for module VPBXPLTB. This is OK, since the supported generation method uses the VPBXPTLB exec. BUILD_Reqd: VSSICMS Toolmin: 248 (2013-05-20) Modules: VPBXBMAP ASSEMBLE VPBXLTP ASSEMBLE VPBXPLTB ASSEMBLE VPBXREST ASSEMBLE

VP550060 VMARC 05/20/13 16:41:01 * Support pool 4D6, Prime/DUP non-sequential

Update VP550060 applies to VSSI installation builds through 5512 Symptom: * Support pool 4D6, Prime/DUP non-sequential Problem: The current VPBXPLTB does not support the TPF 4D6 pools or Prime/DUP non-sequential records. Resolution: Support added. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 248 (2013-05-20) Modules: VPBXPOOL COPY

VP550059 VMARC 05/06/13 11:20:56 * Excessive DBM005 ABENDs

Update VP550059 applies to VSSI installation builds through 5512 Symptom: * Excessive DBM005 ABENDs Problem: A customer experienced excessive DBM005 soft ABENDs. These ABENDs are caused by READ DIRECTORY scan errors, which were almost all satified by a subsequent rescan in RVPDBM. Resolution: RVPDBM amended to delay the DBM005 soft ABEND if the first directory scan fails, and the rescan succeeds. The ABEND will only be issued if the rescan fails. BUILD_Reqd: VSSICP Toolmin: 246 (2013-05-04) Modules: RVPDBM ASSEMBLE

VP550058 VMARC 05/08/13 08:50:15 * Add user fields to VP1WRKBK

Update VP550058 applies to VSSI installation builds through 5512 Symptom: * Add user fields to VP1WRKBK Problem: This update adds the following: . VP1WRKBK modified to add 4 user dwords for customer use only. The contents of these fields are not referenced by VSSI code. Resolution: Fields VP1USER1 thru VP1USER4 (dwords) added to VP1WRKBK. After application of this update, the user MUST reassemble ALL VPARS and/or ShadowDisk/Z modules (e.g., via VSASMALL) BUILD_Reqd: VSSICP VSSMMAC Toolmin: 246 (2013-05-04) Modules: VP1WRKBK COPY

VP550057 VMARC 05/04/13 10:23:04 * Duplicate macro LOADLIST definition

Update VP550057 applies to VSSI installation builds through 5512 Symptom: * Duplicate macro LOADLIST definition Problem: HCPIORBK COPY is defined in multiple macro LOADLIST entries (VPARS VP55MAC and VTAPE VT55MAC). Resolution: HCPIORBK COPY moved to VS55MAC, deleted from VP55MAC and VT55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VP55MAC $EXEC

VT550057 VMARC 05/04/13 10:21:55 * Duplicate macro LOADLIST definition

Update VT550057 applies to VSSI installation builds through 5512-13 Symptom: * Duplicate macro LOADLIST definition Problem: HCPIORBK COPY is defined in multiple macro LOADLIST entries (VPARS VP55MAC and VTAPE VT55MAC). Resolution: HCPIORBK COPY moved to VS55MAC, deleted from VP55MAC and VT55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VT55MAC $EXEC

VS550057 VMARC 05/04/13 10:22:35 * Duplicate macro LOADLIST definition

Update VS550057 applies to VSSI installation builds through 5512 Symptom: * Duplicate macro LOADLIST definition Problem: HCPIORBK COPY is defined in multiple macro LOADLIST entries (VPARS VP55MAC and VTAPE VT55MAC). Resolution: HCPIORBK COPY moved to VS55MAC, deleted from VP55MAC and VT55MAC. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VS55MAC $EXEC

VS550056 VMARC 05/04/13 10:39:12 * User-defined default VTAPE model numbers

Update VS550056 applies to VSSI installation builds through 5512 Symptom: * User-defined default VTAPE model numbers Problem: VTAPE currently defaults to the following virtual tape model numbers if a DEFINE command is specified without a model number suffix for 3480 and 3490 devices: Command Default Model DEFINE V3480 B22 DEFINE V3490 B04 (in 3480 compatibility mode) These defaults are hard-coded in module HCPDFN. There is currently no way (other than a local USERMOD to HCPDFN) to change these defaults. Resolution: Code has been added to allow users to change the 3480 and 3490 defaults via additional tags in VSSINSTL DEFAULTS. At VSSI BUILD time, these tags are used to generate a new macro, VTMDEF, containing the defaults enumerated by the tags in VSSINSTL DEFAULTS. HCPDFN is now updated to invoke the VTMDEF macro in order to generate the default 3480 and 3490 definitions. Application of this PTF will force re-assembly of IBM CP module HCPDFN in order to incorporate the support. After this PTF has been applied, you can modify your default 3480/3490 model numbers as follows: 1. Add or modify the following tag lines in VSSINSTL DEFAULTS: :VTMD3480 mdlid (where mdlid is B22 or B11) :VTMD3490 mdlid (where mdlid is B04 or B40) 2. Rebuild the CP NUC: . vssetup . vssiprep . vsuasm hcpdfn . vsbldnuc . vscopy nuc CF1 CF0 (force 3. Re-IPL the system. BUILD_Reqd: VSSMMAC Toolmin: 246 (2013-05-04) Modules: VSMODID COPY

VP550055 VMARC 04/30/13 20:35:02 * RVPDBS checks wrong CCW offset for CP-flags

Update VP550055 applies to VSSI installation builds through 5512 Symptom: * RVPDBS checks wrong CCW offset for CP-flags Problem: The customer had the following CCW chain presented by CP to module RVPDBS: Opcode CCW-Desc 0x63 Define Extent 0x08 Transfer in Channel (TIC) 0x47 Locate Record 0x06 Read Data 0x08 Transfer in Channel (TIC) 0x00 Unknown/invalid OPCODE RVPDBS is designed to bypass CCW validation for those OPCODEs that do not contain a usable data address (in this case, the 0x63 and 0x47 OPCODEs above). However, the CCW with OPCODE 0x00 was (correctly) flagged as invalid. The validation code at label VALCCW then went to check the CP-set bits in the CCW address field using an incorrect offset of CCW+0x00 instead of the correct offset of CCW+0x04, resulting in a VSSI-enforced (and incorrect) CCW data protection check. Resolution: RVPDBS has been modified to: . Point to the correct CCW offset (+0x00 for FORMAT0 CCWs, +0x04 for FORMAT1 CCWs) for CCW address validation. . CCWs with invalid OPCODEs will still be flagged as invalid. BUILD_Reqd: VSSICP Toolmin: 243 (2013-04-23) Modules: RVPDBS ASSEMBLE

VP550054 VMARC 04/13/13 08:16:40 * Force-Logoff pending for VPARS userids

Update VP550054 applies to VSSI installation builds through 5512 Symptom: * Force-Logoff pending for VPARS userids Problem: A customer attempted to force-logoff several VPARS userids. The VMs entered into an infinite loop; a subsequent PSW restart indicated a high number of threads looping at RVPCCW+0xDB2.The indicated code is called via the statistics timer routine to update buffer usage info. Resolution: RVPCCW amended to check for forced-logoff conditions as well as currently-checked LOGOF indicators. Forced-logoffs are now treated the same as normal logoff conditions, and appropriate actions are now taken for either condition. This check has been extended to all modules checking for LOGOFF indicators in the VMDBK. BUILD_Reqd: VSSICP Toolmin: 216 (2013-02-01) Modules: RVPCCW ASSEMBLE RVPRCC ASSEMBLE RVPSHU ASSEMBLE

VP550053 VMARC 04/03/13 13:42:29 * VPQuery message(s) showing internal msg IDs

Update VP550053 applies to VSSI installation builds through 5512 Symptom: * VPQuery message(s) showing internal msg IDs Problem: The response to a VPQUERY CCT cctname was incorrectly shown as: . VP Config VP Database . RVPQY2130E cctname 0900-09FF The proper message text should be: . VP Config VP Database . cctname 0900-09FF Resolution: Internal message number now marked as INFO(I), not ERROR(E). INFO message text now suppresses the internal message number for this message, as expected. BUILD_Reqd: VSSICP Toolmin: 216 (2013-02-01) Modules: RVPMSG ASSEMBLE RVPQY2 ASSEMBLE

VT550052 VMARC 03/25/13 11:18:29 * RVTCON refactoring

Update VT550052 applies to VSSI installation builds through 5512-13 Symptom: * RVTCON refactoring Problem: The size of RVTCON exceeds the base register if assembled via HL/ASM Version 5. Consequently, several LTORG symbols are not referenced. This problem does not occur for HL/ASM Version 6 users. Resolution: Several instructions converted to baseless addressing. This update, as well as VT550051, provide storage constraint relief for this module. Use of HL/ASM V6 will provide the maximum constraint relief. BUILD_Reqd: VSSICP Toolmin: 216 (2013-02-01) Modules: RVTCON ASSEMBLE

VT550051 VMARC 03/01/13 08:51:36 * HCPCONSL consolidation

Update VT550051 applies to VSSI installation builds through 5512-13 Symptom: * HCPCONSL consolidation Problem: HCPCONSL macro usage is spread over several modules. Resolution: This update consolidates HCPCONSL usage by invoking RVSSTBHU and RVSSTBHS. BUILD_Reqd: VSSICP Toolmin: 216 (2013-02-01) Modules: RVTCON ASSEMBLE RVTSV2 ASSEMBLE

VS550051 VMARC 03/01/13 08:51:28 * HCPCONSL consolidation

Update VS550051 applies to VSSI installation builds through 5512 Symptom: * HCPCONSL consolidation Problem: HCPCONSL macro usage is spread over several modules. Additionally, license expiration messages can flood OPERATOR logs during heavy usage. Resolution: This update consolidates HCPCONSL usage by invoking RVSSTBHU and RVSSTBHS. Additionally, license expiration messages to the OPERATOR console are limited to once per day. BUILD_Reqd: VSSIPL VSSICP Toolmin: 216 (2013-02-01) Modules: VSMODID COPY RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSSTB ASSEMBLE RVSSTN ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55051

VD550049 VMARC 01/31/13 12:44:33 * VTFREST first bits

Update VD550049 applies to VSSI installation builds through 5512 Symptom: * VTFREST first bits Problem: New function. Resolution: VTFREST macros and copybooks. BUILD_Reqd: VSSMMAC Toolmin: 213 (2013-01-14) Modules: VD55MAC $EXEC

VT550049 VMARC 01/31/13 12:49:00 * VTFREST first bits

Update VT550049 applies to VSSI installation builds through 5512-13 Symptom: * VTFREST first bits Problem: New function. Resolution: VTFREST macros and copybooks. BUILD_Reqd: VSSICP VSSICMS VSSMMAC Toolmin: 213 (2013-01-14) Modules: VT55MAC $EXEC VTFWRK COPY VTCMPD MACRO VTENT MACRO VTRET MACRO VTSIMCA MACRO

VS550049 VMARC 01/31/13 12:44:45 * VTFREST first bits

Update VS550049 applies to VSSI installation builds through 5512 Symptom: * VTFREST first bits Problem: New function. Resolution: VTFREST macros and copybooks. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 213 (2013-01-14) Modules: VS55MAC $EXEC VSDTIW COPY VSPIPPL COPY VSSIOBK COPY VSCLOSE MACRO VSENT2 MACRO VSG2H MACRO VSIEDB MACRO VSIEZIOB MACRO VSOPEN MACRO VSREN MACRO VSREX MACRO VSWAITD MACRO

VS550048 VMARC 01/06/13 11:17:39 * VSSET DELIMITER accepts any delimiter char

Update VS550048 applies to VSSI installation builds through 5512 Symptom: * VSSET DELIMITER accepts any delimiter char Problem: The VSSET DELIMITER command currently accepts any character as a date filed delimiter. If the user sets a delimiter (e.g., 'A'), all VSSI date fields will print out as mmAddAyyyy, which is probably not what the user intended. Resolution: Date delimiters are now limited to the following characters: Char Name / forward slash - dash _ underscore | vertical bar : colon If the user enters any character other than the above, a warning message is issued, and the date delimiter is not altered. BUILD_Reqd: VSSICP Toolmin: 207 (2012-12-25) Modules: RVSCMD ASSEMBLE

VS550047 VMARC 01/05/13 09:09:36 * ShadowDisk/Z HELPMSG additions

Update VS550047 applies to VSSI installation builds through 5512 Symptom: * ShadowDisk/Z HELPMSG additions Problem: ShadowDisk/Z HELPSMSG files missing from package 5512. Resolution: Files are added via this PTF. BUILD_Reqd: VSSIPL VSSICP Toolmin: 211 (2013-01-05) Modules: RVSMSG ASSEMBLE RVSSTB ASSEMBLE

PTFs below apply to Packages at 5510 and lower

VP550045 VMARC 12/26/12 13:06:08 * ShadowDisk/Z base code - non-MACRO|COPY

Update VP550045 applies to VSSI installation builds through 5510 Symptom: * ShadowDisk/Z base code - non-MACRO|COPY Problem: ShadowDisk/Z base code. Resolution: This PTF renames several VPARS CPEXIT entry point names in order to support ShadowDisk/Z coexistence. BUILD_Reqd: VSSICP Toolmin: 207 (2012-12-25) Modules: RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPSET ASSEMBLE RVPSYN ASSEMBLE

VT550045 VMARC 12/26/12 13:07:30 * ShadowDisk/Z base code - non-MACRO|COPY

Update VT550045 applies to VSSI installation builds through 5510-11 Symptom: * ShadowDisk/Z base code - non-MACRO|COPY Problem: ShadowDisk/Z base code. Resolution: This PTF adds the ShadowDisk/Z product to the VSSI product suite.Additionally, several VTAPE CPEXIT entry point names are changed to enforce VSSI component name standardization. BUILD_Reqd: VSSICP Toolmin: 207 (2012-12-25) Modules: RVTSV2 ASSEMBLE

VS550045 VMARC 12/26/12 13:06:17 * ShadowDisk/Z base code - non-MACRO|COPY

Update VS550045 applies to VSSI installation builds through 5510 Symptom: * ShadowDisk/Z base code - non-MACRO|COPY Problem: ShadowDisk/Z base code. Resolution: This PTF adds the ShadowDisk/Z product to the VSSI product suite. Additionally, several CPEXIT entry points are renamed in RVSCFG in order to enforce CPEXIT name standardization across VSSI product components. This update includes reworked VTAPE CP hooks. Guard code has been added to each HCP hook in order to avoid assembly errors if the invoked component is not available (i.e., not licensed to the installation). For z/VM 5.4 users, the IBM PTF VM64843 against module HCPDTD (i.e., HCPDTD K64843HP) is REQUIRED in order to apply this PTF. The IBM PTF was included in RSU 1101; if you have this RSU applied, then this update may also be applied. The IBM HCPDTD update is already included in z/VM 6.1 and higher. BUILD_Reqd: VSSIPL VSSICP Toolmin: 207 (2012-12-25) Modules: VSCFGBK COPY VSMODID COPY VSCPXRM MACRO RVSCFG ASSEMBLE RVSMSG ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSVDY ASSEMBLE RVSSTL LAS55045

VP550044 VMARC 12/19/12 14:21:08 * ShadowDisk/Z base code - non-MACRO|COPY

Update VP550044 applies to VSSI installation builds through 5510 Symptom: * ShadowDisk/Z base code - non-MACRO|COPY Problem: New function. Resolution: This updates adds code to stamp the VPTCCTBK as either owned by VPARS or VDISK. BUILD_Reqd: VSSICP Toolmin: 203 (2012-12-02) Modules: RVPOPN ASSEMBLE

VD550043 VMARC 12/05/12 15:23:55 * Level-Set MACRO|COPY co-existence changes

Update VD550043 applies to VSSI installation builds through 5510 Symptom: * Level-Set MACRO|COPY co-existence changes Problem: This update resolves the following product co-existence issues: . VD5CNTRL contains an HCPENTRY for RVPIORCT which conflicts with the same-named entry in VP5CNTRL (VPARS). . VDEV contains no VDISK flags. . HCP modifications do not include CPEXIT calls to VDISK routines. Resolution: Addressed: 1. VD5CNTRL label changed to RVDIORCT. 2. HCPVDEV modified to support ShadowDisk/Z; VTAPE flags moved by 1 byte. 3. HCP hooks modified to detect VPARS/VDISK devices and invoke the appropriate CPEXIT routines. Notes: This update is a required PREREQ for ALL future product updates against VSSI packages 5510 and above. Please see the Notes in VS550043 for the proper procedure to use to apply this PTF. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 203 (2012-12-02) Modules: VD5CNTRL MACRO

VP550043 VMARC 12/05/12 15:24:23 * Level-Set MACRO|COPY co-existence changes

Update VP550043 applies to VSSI installation builds through 5510 Symptom: * Level-Set MACRO|COPY co-existence changes Problem: This update resolves the following product co-existence issues: . VD5CNTRL contains an HCPENTRY for RVPIORCT which conflicts with the same-named entry in VP5CNTRL (VPARS). . VDEV contains no VDISK flags. . HCP modifications do not include CPEXIT calls to VDISK routines. Resolution: Addressed: 1. VD5CNTRL label changed to RVDIORCT. 2. HCPVDEV modified to support ShadowDisk/Z; VTAPE flags moved by 1 byte. 3. HCP hooks modified to detect VPARS/VDISK devices and invoke the appropriate CPEXIT routines. Notes: This update is a required PREREQ for ALL future product updates against VSSI packages 5510 and above. Please see the Notes in VS550043 for the proper procedure to use to apply this PTF. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 203 (2012-12-02) Modules: VPTCCTBK COPY

VS550043 VMARC 12/05/12 15:22:49 * Level-Set MACRO|COPY co-existence changes

Update VS550043 applies to VSSI installation builds through 5510 Symptom: * Level-Set MACRO|COPY co-existence changes Problem: This update resolves the following product co-existence issues: . VD5CNTRL contains an HCPENTRY for RVPIORCT which conflicts with the same-named entry in VP5CNTRL (VPARS). . VDEV contains no VDISK flags. . HCP modifications do not include CPEXIT calls to VDISK routines. Resolution: Addressed: 1. VD5CNTRL label changed to RVDIORCT. 2. HCPVDEV modified to support ShadowDisk/Z; VTAPE flags moved by 1 byte. 3. HCP hooks modified to detect VPARS/VDISK devices and invoke the appropriate CPEXIT routines. Notes: This update is a required PREREQ for ALL future product updates against VSSI packages 5510 and above. This update makes significant changes to all VSSI HCP hooks; the PTFs listed below must be applied concurrently, as follows: 1. Download the following VMARC files from the VSSI FTP site (URL ftp.vsoftsys.com, your VSSI-supplied userid and password, your 193 disk, BINary mode). . VSTOOLS (all users) . VS550043 (all users) . VD550043 (all users) . VP550043 (VPARS users) . VP550044 (VPARS users) 2. Backup your VSSI Install disk prior to attempting to apply these updates. 3. vmarc unpk vstools vmarc * = = G (assuming G is the filemode of the VSSI Install disk) 4. vsptf vs550043 (apply this PTF) 5. vsptf vd550043 (apply this PTF) 6. vsptf vp550043 (apply this PTF) 7. erase vssiasm log g (e.g., VSSI Install disk filemode G) 8. vsuasm (assemble all VSSI HCP hooks) 9. Check the contents of VSSIASM LOG to ensure that all assemblies completed without error (rc = 0). If any errors occurred: . Run VSCPSRC against all failed HCP modules (e.g., vscpsrc hcpdtd) . FTP all generated HCPSRC files (e.g., hcpdtd hcpsrc *) to VSSI (URL ftp.vsoftsys.com, user VSSIDUMP, password VSS$DUMP, BINary mode) . Restore your Install disk 10. If all assemblies are OK: . vsptf vp550044 (VPARS users) . vsasmall (compile all modsules) . vsbldnuc (build the CP NUC) . vscopy nuc cf1 (force (if z/VM < 6.2) . vscopy nuc cf1 cf0 (force (if z/VM >= 6.2) BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 203 (2012-12-02) Modules: VS55MAC $EXEC RVSCMPBK COPY VSCKVDEV MACRO VSCKVMD MACRO

PTFs below apply to Packages at 5508 and lower

VD550042 VMARC 11/20/12 12:03:30 * ShadowDisk/Z base code - MACRO|COPY

Update VD550042 applies to VSSI installation builds through 5508 Symptom: * ShadowDisk/Z base code - MACRO|COPY Problem: ShadowDisk/Z base code. Resolution: This PTF adds the ShadowDisk/Z product to the VSSI product suite. BUILD_Reqd: VSSICP VSSMMAC Toolmin: 188 (2012-11-15) Modules: VD55MAC $EXEC RVDMDLAT MACRO VD5CNTRL MACRO VD6CNTRL MACRO

VP550041 VMARC 11/14/12 20:06:36 * Code refactoring - make room for ShadowDisk/Z

Update VP550041 applies to VSSI installation builds through 5508 Symptom: * Code refactoring - make room for ShadowDisk/Z Problem: Naming standards for the VQ6CNTRL macro are inconsistent between VPARS and ShadowDisk/Z products. Resolution: This PTF changes several VPARS modules to conform to updated naming standards introduced via PTF VS550040. BUILD_Reqd: VSSICP Toolmin: 184 (2012-10-26) Modules: RVPCQY ASSEMBLE RVPIOR ASSEMBLE RVPSV1 ASSEMBLE VPCPYASM ASSEMBLE

VT550041 VMARC 11/14/12 20:07:01 * Code refactoring - make room for ShadowDisk/Z

Update VT550041 applies to VSSI installation builds through 5508-09 Symptom: * Code refactoring - make room for ShadowDisk/Z Problem: Naming standards for the VQ6CNTRL macro are inconsistent between VPARS and ShadowDisk/Z products. Resolution: This PTF changes several VPARS modules to conform to updated naming standards introduced via PTF VS550040. Some of these macros are included in the VTCPYASM program. BUILD_Reqd: *None* Toolmin: 184 (2012-10-26) Modules: VTCPYASM ASSEMBLE

VS550041 VMARC 11/14/12 20:06:51 * Code refactoring - make room for ShadowDisk/Z

Update VS550041 applies to VSSI installation builds through 5508 Symptom: * Code refactoring - make room for ShadowDisk/Z Problem: RVSCFG uses VSOPTNS macro symbols which are no longer valid for multiple-product detection. Resolution: RVSCFG code changed to use the new per-product macro variables contained in the VSOPTNS macro vis PTF VS550040. BUILD_Reqd: VSSIPL VSSICP Toolmin: 184 (2012-10-26) Modules: RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE

VP550040 VMARC 11/02/12 12:18:13 * Modify VSOPTNS product ID semantics

Update VP550040 applies to VSSI installation builds through 5508 Symptom: * Modify VSOPTNS product ID semantics Problem: ShadowDisk/Z HCP modifications conflict with existing VPARS HCP modifications. The current VSOPTNS macro is also insufficient for both VPARS and ShadowDisk/Z usage. Resolution: 1. All HCP modifications are renamed to VS equivalents. 2. The VSOPTNS macro is modified to support more than two VSSI products (VPARS, VTAPE, and now ShadowDisk/Z). BUILD_Reqd: VSSICP Toolmin: 184 (2012-10-26) Modules: VP55MAC $EXEC RVPSYSBK COPY VP5CNTRL MACRO

VS550040 VMARC 11/02/12 12:19:53 * Modify VSOPTNS product ID semantics

Update VS550040 applies to VSSI installation builds through 5508 Symptom: * Modify VSOPTNS product ID semantics Problem: ShadowDisk/Z HCP modifications conflict with existing VPARS HCP modifications. The current VSOPTNS macro is also insufficient for both VPARS and ShadowDisk/Z usage. Resolution: 1. All HCP modifications are renamed to VS equivalents. 2. The VSOPTNS macro is modified to support more than two VSSI products (VPARS, VTAPE, and now ShadowDisk/Z). BUILD_Reqd: VSSIPL VSSICP Toolmin: 184 (2012-10-26) Modules: VS55MAC $EXEC RVSCMPBK COPY RVSUHDBK COPY VSMODID COPY RVSMDLAT MACRO VSCPXGT MACRO VSCPXRM MACRO

VS550039 VMARC 11/02/12 08:55:20 * CFR001/PRG006 ABENDs during License messages

Update VS550039 applies to VSSI installation builds through 5508 Symptom: * CFR001/PRG006 ABENDs during License messages Problem: RVSSTL issues informational and warning messages when the VSSI license is within 30 days of expiration. In a Secondary Console Facility (SCIF) environment, the message PLIST is built incorrectly, resulting in CFR001 and/or PRG006 ABENDs in HCPCSL. Resolution: HCPCONSL macro generation logic moved out of RVSSTL (an OCO module), and into RVSSTB, which will get assembled and generate the correct PLIST for the z/VM version. BUILD_Reqd: VSSIPL VSSICP Toolmin: 167 (2012-07-24) Modules: VSMODID COPY RVSSTB ASSEMBLE RVSSTL LAS55039

VP550038 VMARC 09/04/12 10:54:19 * Fix invalid characters in msg generation

Update VP550038 applies to VSSI installation builds through 5508 Symptom: * Fix invalid characters in msg generation Problem: Reported negative numbers for TPF record count if DB was cleared prior to running VPCHKDIR. Resolution: Branch around subtacting records if record count was zero. BUILD_Reqd: VSSICMS Toolmin: 167 (2012-07-24) Modules: VPCHKDIR ASSEMBLE

VP550037 VMARC 08/29/12 12:34:18 * Fix vpchkdir i/o errors

Update VP550037 applies to VSSI installation builds through 5508 Symptom: * Fix vpchkdir i/o errors Problem: The CCW command code for an internal TIC (Transfer In Channel) command was cleared and never reset, resulting in an invalid CCW chain. Resolution: Set TIC command code correctly. BUILD_Reqd: VSSICMS Toolmin: 167 (2012-07-24) Modules: VPCHKDIR ASSEMBLE

PTFs below apply to Packages at 5506 and lower

VP550036 VMARC 08/20/12 14:45:53 * VPOPEN ignores CLEAR parameter

Update VP550036 applies to VSSI installation builds through 5506 Symptom: * VPOPEN ignores CLEAR parameter Problem: VPOPEN ignores the CLEAR parameter after application of PTF VP550027. This PTF added code to establish a VPARS users queue for connection cleanup during user LOGOFF. However, the added code modified R10 (the VPOPEN pointer) without saving and restoring the contents. The CLEAR flag was therefore lost, and VPOPEN processing continues as if CLEAR was not specified. Resolution: The contents of R10 are now saved and restored across queue management calls. BUILD_Reqd: VSSICP Toolmin: 167 (2012-07-24) Modules: RVPIFC ASSEMBLE

VT550035 VMARC 08/20/12 09:40:50 * Infinite loop in RVTIOR

Update VT550035 applies to VSSI installation builds through 5506-07 Symptom: * Infinite loop in RVTIOR Problem: RVTIOR contains a COMPARE-AND-SWAP (CS) loop used to serialize access to the database write I/O queue. Under certain conditions, the queue word does not get properly reset, and an infinite loop results. This is a Severity Level 1 issue. This problem has been reported only on more recent CPUs (z196, z114). Resolution: Convert the CS loop to a single VM lock (via HCPLCK). The CP lock code takes advantage of the OILL and NILL instructions used by the advanced architecture. BUILD_Reqd: VSSICP Toolmin: 167 (2012-07-24) Modules: RVTIOR ASSEMBLE

VT550033 VMARC 07/31/12 15:46:13 * HTT001 abend in RVTMET+x'2F6' (4-digit VDEV)

Update VT550033 applies to VSSI installation builds through 5506-07 Symptom: * HTT001 abend in RVTMET+x'2F6' (4-digit VDEV) Problem: A customer changed the VTAPE minidisk numbers to 4 digits (i.e., from F20 for 16 to E200 for 16). The device number offset of the MDISK containing the mounted tape is determined by subtracting the contents of VTAMDSK (a halfword value containing the current VDEV address) from the base MDISK VDEV address for the library. VSSI module RVTMET uses LH and STH instructions to load, store, and perform offset calculation on this field, which results in incorrect values if the hi-order bit is on in the halfword (e.g., x'E200' instead of x'0F20 for VDEV). The incorrectly calculated address caused a hard CP ABEND HTT001. Resolution: RVTMET and RVTSV3 changed to use ICM and STCM instructions for VTAMDSK access. These instructions do not perform hi-order bit sign propagation like LH does. BUILD_Reqd: VSSICP Toolmin: 167 (2012-07-24) Modules: RVTMET ASSEMBLE RVTSV3 ASSEMBLE

VP550032 VMARC 07/24/12 10:44:54 * Infinite loop at RVPIOR+x'51E'

Update VP550032 applies to VSSI installation builds through 5506 Symptom: * Infinite loop at RVPIOR+x'51E' Problem: RVPIOR contains a COMPARE-AND-SWAP (CS) loop used to serialize access to the database write I/O queue. Under certain conditions, the queue word does not get properly reset, and an infinite loop results. This is a Severity Level 1 issue. This problem has been reported only on more recent CPUs (z196, z114). Resolution: Convert the CS loop to a single VM lock (via HCPLCK). The CP lock code takes advantage of the OILL and NILL instructions used by the advanced architecture. BUILD_Reqd: VSSICP Toolmin: 167 (2012-07-24) Modules: RVPIOR ASSEMBLE

VS550030 VMARC 11/02/12 09:02:39 * Enhance IFL checking

Update VS550030 applies to VSSI installation builds through 5506 Symptom: * Enhance IFL checking Problem: IFL checking requires license enhancements. Resolution: 1. VSSI license generation code changed to populate IFL fields in license text 2. License code added to check IFL counts if: . the product is a Linux product; . Valid IFL values exist in the license BUILD_Reqd: VSSIPL VSSICP Toolmin: 167 (2012-07-24) Modules: VSMODID COPY RVSSTL LAS55030

VT550029 VMARC 06/20/12 21:16:53 * COPYTAPE issues error messages if EOT used

Update VT550029 applies to VSSI installation builds through 5506-07 Symptom: * COPYTAPE issues error messages if EOT used Problem: Customer used COPYTAPE with the EOT option. The following error messages were issued: VSSCOP2020S I/O error on 181 Block=1, Rcode=03, CPA=07EDB000 VSSCOP2020S CASC=07EDB008 0E408000, Sense=08428031 07EDB000 CCW 02A08000 07EB8000 DATA 00000000 00000000 07EDB008 CCW 02A08000 07EC0000 DATA 00000000 00000000 07EDB010 CCW 02200008 07EC8000 DATA 00000000 00000000 The above messages appear on VTAPE builds with PTF VT530114 applied. This PTF changed the meaning of the EOT option, as follows: . If the input tape is a Reel device (342x|343x), EOT causes reading of a multiple-file tape to stop when 2 contiguous tape marks are detected; . Otherwise, EOT causes reading of a multiple-file tape to stop when a Unit Check is reflected by CP. In all cases, all actual tape data is correctly copied. In the VTAPE case, the Unit Check error messages are not being suppressed (since the UC is expected and is OK if EOT was specified). Resolution: Code has been changed to suppress the Unit Check error messages if the EOT option was specified with a VTAPE input device. In this case, the Unit Check is in fact expected due to the specification of the EOT option. BUILD_Reqd: VSSICMS Toolmin: 164 (2012-06-12) Modules: COPYTAPE ASSEMBLE

VP550028 VMARC 06/20/12 19:56:28 * CPUID check uses virtual CPU, not real CPU

Update VP550028 applies to VSSI installation builds through 5506 Symptom: * CPUID check uses virtual CPU, not real CPU Problem: The current license code checks the CPU ID via the prefix page in memory. If the VM is second-level, the virtual CPUID is checked, which may cause problems for customers whose virtual CPUIDs do not match the underlying real CPUID. Resolution: 1. CPUID now obtained via STSI instead of prefix page scan. 2. IFL count now obtained via prefix page scan. 3. Product files modified to accurately reflect HCP COPY and MACRO files modified by VSSI. BUILD_Reqd: *None* Toolmin: 164 (2012-06-12) Modules: VPMODID COPY

VS550028 VMARC 06/20/12 19:56:21 * CPUID check uses virtual CPU, not real CPU

Update VS550028 applies to VSSI installation builds through 5506 Symptom: * CPUID check uses virtual CPU, not real CPU Problem: The current license code checks the CPU ID via the prefix page in memory. If the VM is second-level, the virtual CPUID is checked, which may cause problems for customers whose virtual CPUIDs do not match the underlying real CPUID. Resolution: 1. CPUID now obtained via STSI instead of prefix page scan. 2. IFL count now obtained via prefix page scan. 3. Product files modified to accurately reflect HCP COPY and MACRO files modified by VSSI. BUILD_Reqd: VSSIPL VSSICP Toolmin: 164 (2012-06-12) Modules: VSMODID COPY RVSSTL LAS55028

PTFs below apply to Packages at 5504 and lower

VP550027 VMARC 06/14/12 08:40:19 * Implement HCPUSO|HCPRLI CP Hooks

Update VP550027 applies to VSSI installation builds through 5504 Symptom: * Implement HCPUSO|HCPRLI CP Hooks Problem: VTAPE sharing sometimes fails if under heavy load. This issue was reported by IBM Poughkeepsie (thanks, Mark Gardiner), and exposed a design flaw in VTAPE support of tape sharing (via ASSIGN|UNASSIGN). Resolution: 1. New HCPUSO|HCPRLI hooks added to allow VPARS and VTAPE to cleanup user and device entries in the event that: . A VPARS or VTAPE guest logs off or is forced . A VMRELOcate is issued against a Linux guest using either VPARS or VTAPE 2. The bulk of VTAPE shared device management code has been relocated into a new VSSI CP stub module, RVSSTQ. 3. A more formal internal VTAPE API has been created to allow the code to query shared VTAPE devices. BUILD_Reqd: VSSICP Toolmin: 164 (2012-06-12) Modules: VP55MAC $EXEC RVPIFC ASSEMBLE RVPQY3 ASSEMBLE RVPRST ASSEMBLE

VT550027 VMARC 06/14/12 08:43:41 * Implement HCPUSO|HCPRLI CP Hooks

Update VT550027 applies to VSSI installation builds through 5504-05 Symptom: * Implement HCPUSO|HCPRLI CP Hooks Problem: VTAPE sharing sometimes fails if under heavy load. This issue was reported by IBM Poughkeepsie (thanks, Mark Gardiner), and exposed a design flaw in VTAPE support of tape sharing (via ASSIGN|UNASSIGN). Resolution: 1. New HCPUSO|HCPRLI hooks added to allow VPARS and VTAPE to cleanup user and device entries in the event that: . A VPARS or VTAPE guest logs off or is forced . A VMRELOcate is issued against a Linux guest using either VPARS or VTAPE 2. The bulk of VTAPE shared device management code has been relocated into a new VSSI CP stub module, RVSSTQ. 3. A more formal internal VTAPE API has been created to allow the code to query shared VTAPE devices. BUILD_Reqd: VSSICP Toolmin: 164 (2012-06-12) Modules: VT55MAC $EXEC RVTCON ASSEMBLE RVTDEF ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTST2 ASSEMBLE RVTSV2 ASSEMBLE

VS550027 VMARC 06/14/12 08:40:32 * Implement HCPUSO|HCPRLI CP Hooks

Update VS550027 applies to VSSI installation builds through 5504 Symptom: * Implement HCPUSO|HCPRLI CP Hooks Problem: VTAPE sharing sometimes fails if under heavy load. This issue was reported by IBM Poughkeepsie (thanks, Mark Gardiner), and exposed a design flaw in VTAPE support of tape sharing (via ASSIGN|UNASSIGN). Resolution: 1. New HCPUSO|HCPRLI hooks added to allow VPARS and VTAPE to cleanup user and device entries in the event that: . A VPARS or VTAPE guest logs off or is forced . A VMRELOcate is issued against a Linux guest using either VPARS or VTAPE 2. The bulk of VTAPE shared device management code has been relocated into a new VSSI CP stub module, RVSSTQ. 3. A more formal internal VTAPE API has been created to allow the code to query shared VTAPE devices. 4. VSSI HCPVDEV updates for VPARS and VTAPE have been merged into a single PTF. Installation of this PTF will delete the older PTFs. BUILD_Reqd: VSSIPL VSSICP Toolmin: 164 (2012-06-12) Modules: VS55MAC $EXEC RVSCMPBK COPY RVSUHDBK COPY RVSVPUBK COPY RVSVTDBK COPY RVSVTUBK COPY RVSMDLAT MACRO RVSMDLAX MACRO VSCALL0 MACRO VSCALL1 MACRO VSCALL2 MACRO RVSSTN ASSEMBLE RVSSTQ ASSEMBLE

VS550026 VMARC 05/28/12 07:27:06 * New CPEXIT calls for VSSI cleanup

Update VS550026 applies to VSSI installation builds through 5504 Symptom: * New CPEXIT calls for VSSI cleanup Problem: New CP hooks are required for: . better cleanup if a user if logs off or is forced; . proper error messages if a VMRELOcate fails against a Linux guest due to VPARS activity Resolution: The added CP HOOK entry points are as follows: EntryPoint CP_Module Usage RVPRSTXL HCPUSO Clean up VPARS user queues during LOGOFF RVTRSTXL HCPUSO Clean up VTAPE user queues during LOGOFF RVPRSTXM HCPRLI Issue message if VMRELOcate attempted for a Linux machine which has VPARS active (z/VM >= 6.2) RVTRSTXM HCPRLI Issue message if VMRELOcate attempted for a Linux machine which has VTAPE active (z/VM >= 6.2) Currently, these exits are effective NO-OPs; enabling code will be added in a subsequent PTF. BUILD_Reqd: VSSIPL Toolmin: 163 (2012-05-28) Modules: VSMODID COPY

VP550025 VMARC 05/28/12 07:22:25 * Product preparation for new CP hooks

Update VP550025 applies to VSSI installation builds through 5504 Symptom: * Product preparation for new CP hooks Problem: New CP hooks are required for: . better cleanup if a user logs off or is forced; . proper error messages if a VMRELOcate fails against a Linux guest due to VPARS activity Resolution: Updated source objects added to support new CP hook application via subsequent PTFs: . VSSI PRODUCT files have been updated to include the new CPEXIT entry points . The z/VM modifications to the VDEV USER fields (contained in HCPVDEV N55001VP) have been reworked and included in this package to avoid conflicts in the event that any PTFs (IBM or VSSI) are applied against HCPRLI ASSEMBLE (z/VM 6.2 and higher; potential issue discovered in Lab testing). BUILD_Reqd: VSSICP Toolmin: 163 (2012-05-28) Modules: RVPRST ASSEMBLE

VT550025 VMARC 05/28/12 07:22:40 * Product preparation for new CP hooks

Update VT550025 applies to VSSI installation builds through 5504-05 Symptom: * Product preparation for new CP hooks Problem: New CP hooks are required for: . better cleanup if a user logs off or is forced; . proper error messages if a VMRELOcate fails against a Linux guest due to VTAPE activity Resolution: Updated source objects added to support new CP hook application via subsequent PTFs: . VSSI PRODUCT files have been updated to include the new CPEXIT entry points BUILD_Reqd: VSSICP Toolmin: 163 (2012-05-28) Modules: RVTRST ASSEMBLE

VS550025 VMARC 05/28/12 07:22:52 * Product preparation for new CP hooks

Update VS550025 applies to VSSI installation builds through 5504 Symptom: * Product preparation for new CP hooks Problem: New CP hooks are required for: . better cleanup if a user logs off or is forced; . proper error messages if a VMRELOcate fails against a Linux guest due to VPARS activity Resolution: Updated source objects added to support new CP hook application via subsequent PTFs: . VSSI PRODUCT files have been updated to include the new CPEXIT entry points . VSSI HCPMODS has been reworked to support multiple CP HOOK z/VM releases in a single file BUILD_Reqd: VSSIPL VSSICP Toolmin: 163 (2012-05-28) Modules: VSCPXRM MACRO

VP550024 VMARC 05/30/12 09:41:56 * CMPBK Field Additions

Update VP550024 applies to VSSI installation builds through 5504 Symptom: * CMPBK Field Additions Problem: If virtual tape devices are defined as shared, several ABENDs may occur if one of the shared users has logged off while the shared queue is being updated. This is because the VDEVs pointed to by the queue may no longer exist, especially under heavy system load. This is a race condition that this PTF takes the first step in rectifying; the race condition will be fixed in a subsequent PTF. Resolution: VPARS and VTAPE need additional persistent storage to better manage virtual devices across user machines. This storage must be accessible even if the user and/or device being tracked has already logged off. To this end, several CMPBK fields have been added to: 1. Improve queue mechanisms for shared devices 2. Remove the RVSCMPBK dependency on IBM CMPBK structure (required for Linux prep also) BUILD_Reqd: VSSIPL VSSICP Toolmin: 163 (2012-05-28) Modules: RVPCMPBK COPY RVPCFG ASSEMBLE RVPPRC ASSEMBLE RVPRST ASSEMBLE

VT550024 VMARC 05/30/12 09:42:56 * CMPBK Field Additions

Update VT550024 applies to VSSI installation builds through 5504-05 Symptom: * CMPBK Field Additions Problem: If virtual tape devices are defined as shared, several ABENDs may occur if one of the shared users has logged off while the shared queue is being updated. This is because the VDEVs pointed to by the queue may no longer exist, especially under heavy system load. This is a race condition that this PTF takes the first step in rectifying; the race condition will be fixed in a subsequent PTF. Resolution: VPARS and VTAPE need additional persistent storage to better manage virtual devices across user machines. This storage must be accessible even if the user and/or device being tracked has already logged off. To this end, several CMPBK fields have been added to: 1. Improve queue mechanisms for shared devices 2. Remove the RVSCMPBK dependency on IBM CMPBK structure (required for Linux prep also) BUILD_Reqd: VSSIPL VSSICP Toolmin: 163 (2012-05-28) Modules: RVTCMPBK COPY RVTPRC ASSEMBLE RVTRST ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE

VS550024 VMARC 05/30/12 09:42:30 * CMPBK Field Additions

Update VS550024 applies to VSSI installation builds through 5504 Symptom: * CMPBK Field Additions Problem: If virtual tape devices are defined as shared, several ABENDs may occur if one of the shared users has logged off while the shared queue is being updated. This is because the VDEVs pointed to by the queue may no longer exist, especially under heavy system load. This is a race condition that this PTF takes the first step in rectifying; the race condition will be fixed in a subsequent PTF. Resolution: VPARS and VTAPE need additional persistent storage to better manage virtual devices across user machines. This storage must be accessible even if the user and/or device being tracked has already logged off. To this end, several CMPBK fields have been added to: 1. Improve queue mechanisms for shared devices 2. Remove the RVSCMPBK dependency on IBM CMPBK structure (required for Linux prep also) BUILD_Reqd: VSSIPL VSSICP Toolmin: 163 (2012-05-28) Modules: RVSCMPBK COPY RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE

VP550023 VMARC 05/22/12 09:38:44 * Insufficient cleanup during CPXUNLOAD

Update VP550023 applies to VSSI installation builds through 5504 Symptom: * Insufficient cleanup during CPXUNLOAD Problem: The VSSI SHUTDOWN hook invokes product-specific cleanup code. This code was sufficient for system shutdown, but left several global variables initialized in the case of CPXUNLOAD/CPXLOAD (i.e., where shutdown is NOT indicated). Resolution: Several MACROs and source lines have been modified to support more comprehansive cleanup in the case of system shutdown or CPXUNLOAD/CPXLOAD. For VPARS users, the following messages will be issued to the user console when VPARS is CPXUNLOADed: Disabled wait entered due to VPARS unload. Please do as follows: . Logoff the user ID. . After VPARS is reloaded: . Logon this user ID . Issue VPCLOSE NORESET . Issue VPOPEN (as normal) BUILD_Reqd: VSSICP Toolmin: 159 (2012-05-12) Modules: VP6CNTRL MACRO RVPSHU ASSEMBLE RVPSV1 ASSEMBLE

VT550023 VMARC 05/22/12 09:39:06 * Insufficient cleanup during CPXUNLOAD

Update VT550023 applies to VSSI installation builds through 5504-05 Symptom: * Insufficient cleanup during CPXUNLOAD Problem: The VSSI SHUTDOWN hook invokes product-specific cleanup code. This code was sufficient for system shutdown, but left several global variables initialized in the case of CPXUNLOAD/CPXLOAD (i.e., where shutdown is NOT indicated). Resolution: Several MACROs and source lines have been modified to support more comprehansive cleanup in the case of system shutdown or CPXUNLOAD/CPXLOAD. BUILD_Reqd: VSSICP Toolmin: 159 (2012-05-12) Modules: VT6CNTRL MACRO RVTSHU ASSEMBLE RVTSV2 ASSEMBLE

VS550022 VMARC 05/16/12 21:42:40 * CPUID Check compares too many digits

Update VS550022 applies to VSSI installation builds through 5504 Symptom: * CPUID Check compares too many digits Problem: RVSSTL checks the CPUID for 10 characters. This number of characters includes the digits allocated for the processor and LPAR numbers, which may change based on the customer machine configuration. Resolution: The CPUID check has been modified to check only the last 4 digits of the serial number, and all 4 digits of the model number. These digits do not change based on processor and LPAR configuration changes, and are unique to the machine. BUILD_Reqd: VSSIPL VSSICP Toolmin: 159 (2012-05-12) Modules: VSMODID COPY RVSSTL LAS55022

PTFs below apply to Packages at 5502 and lower

VP550021 VMARC 03/28/12 12:44:55 * Message ID prettification

Update VP550021 applies to VSSI installation builds through 5502 Symptom: * Message ID prettification Problem: None. Resolution: Convert MSG=nn to MSG=0nn for all 2-digit message numbers via VSMSGH calls. Used for internal VSSI message number scan routines. BUILD_Reqd: VSSICP Toolmin: 151 (2012-03-25) Modules: RVPCQY ASSEMBLE

VT550021 VMARC 03/28/12 12:45:01 * Message ID prettification

Update VT550021 applies to VSSI installation builds through 5502-03 Symptom: * Message ID prettification Problem: None. Resolution: Convert MSG=nn to MSG=0nn for all 2-digit message numbers via VSMSGH calls. Used for internal VSSI message number scan routines. BUILD_Reqd: VSSICP Toolmin: 151 (2012-03-25) Modules: RVTCON ASSEMBLE RVTIOR ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOPN ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE

VP550020 VMARC 03/26/12 10:25:41 * Eliminate hard ABENDs if PARM disk not found

Update VP550020 applies to VSSI installation builds through 5502 Symptom: * Eliminate hard ABENDs if PARM disk not found Problem: If the VSSI code cannot find the VSSI PARM disk, hard ABENDs follow (HTT001, etc). The code is not setting the proper return codes from the PARM disk check routines. Resolution: Return code is now properly set, allowing for graceful termination (error messages, soft ABENDs, etc) in the event of VSSI PARM disk errors. BUILD_Reqd: VSSICP Toolmin: 151 (2012-03-25) Modules: RVPSV1 ASSEMBLE

VT550020 VMARC 03/26/12 10:25:47 * Eliminate hard ABENDs if PARM disk not found

Update VT550020 applies to VSSI installation builds through 5502-03 Symptom: * Eliminate hard ABENDs if PARM disk not found Problem: If the VSSI code cannot find the VSSI PARM disk, hard ABENDs follow (HTT001, etc). The code is not setting the proper return codes from the PARM disk check routines. Resolution: Return code is now properly set, allowing for graceful termination (error messages, soft ABENDs, etc) in the event of VSSI PARM disk errors. BUILD_Reqd: VSSICP Toolmin: 151 (2012-03-25) Modules: RVTSV2 ASSEMBLE

VP550019 VMARC 03/25/12 16:35:07 * VPMODID COPY Addition

Update VP550019 applies to VSSI installation builds through 5502 Symptom: * VPMODID COPY Addition Problem: New function. Resolution: This PTF adds a new file, VPMODID COPY, used to track distribution changes to non-source file objects (e.g., OCO objects, added configuration files). BUILD_Reqd: *None* Toolmin: 151 (2012-03-25) Modules: VP55MAC $EXEC VPMODID COPY

VS550019 VMARC 03/25/12 16:35:28 * IBM-VSSI PTF Conflict Resolution

Update VS550019 applies to VSSI installation builds through 5502 Symptom: * IBM-VSSI PTF Conflict Resolution Problem: New function. Resolution: This PTF adds a new file, VSSI HCPMODS, used to assist customers in resolving IBM-VSSI PTF conflicts in HCP source objects. It is STRONGLY RECOMMENDED that users apply this update; this update will be used by subsequent rework PTFs used to resolve IBM PTF conflicts. BUILD_Reqd: *None* Toolmin: 151 (2012-03-25) Modules: VSMODID COPY

VP550018 VMARC 03/23/12 20:42:20 * CMS Message ID EQUates

Update VP550018 applies to VSSI installation builds through 5502 Symptom: * CMS Message ID EQUates Problem: APPLMSG macros have hard-coded message IDs. Resolution: APPLMSG message IDs converted to symbolics; macros have been re-formatted to allow for quick scans via internal VSSI message validation utilities. BUILD_Reqd: VSSICMS Toolmin: 150 (2012-01-22) Modules: VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXLTP ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPLOADO ASSEMBLE VPREST ASSEMBLE VPRESTO ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE

VT550018 VMARC 03/23/12 20:41:56 * CMS Message ID EQUates

Update VT550018 applies to VSSI installation builds through 5502-03 Symptom: * CMS Message ID EQUates Problem: APPLMSG macros have hard-coded message IDs. Resolution: APPLMSG message IDs converted to symbolics; macros have been re-formatted to allow for quick scans via internal VSSI message validation utilities. BUILD_Reqd: VSSICMS Toolmin: 150 (2012-01-22) Modules: COPYTAPE ASSEMBLE TAPSENSE ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE VTSCR1 ASSEMBLE

VS550018 VMARC 03/23/12 20:42:03 * CMS Message ID EQUates

Update VS550018 applies to VSSI installation builds through 5502 Symptom: * CMS Message ID EQUates Problem: APPLMSG macros have hard-coded message IDs. Resolution: APPLMSG message IDs converted to symbolics; macros have been re-formatted to allow for quick scans via internal VSSI message validation utilities. BUILD_Reqd: VSSICMS Toolmin: 150 (2012-01-22) Modules: VS55MAC $EXEC VSMEQU COPY DISKPRT ASSEMBLE DISKZAP ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSSUBDT ASSEMBLE

VS550017 VMARC 02/06/12 17:34:50 * Message changes, CMS HELPMSG files

Update VS550017 applies to VSSI installation builds through 5502 Symptom: * Message changes, CMS HELPMSG files Problem: Missing CMS HELPMSG files, some garbled message text. Resolution: The following messages have been changed: OldID NewID Issuing Module(s) VSS2108E VSS2108E Mesasge text correction VSS2219I VSS2219E Set as error message (not info) VSS2329E VSS2329E Message text correction The following CMS HELPMSG files have been added: VSSI: 2028R 2039I 2058E 2072W 2027E 2108E 2122R 2145R 2146W 2161I 2204E 2209I 2219E 2225I 2226I 2227E 2228I 2263I 2264E 2265I 2266E 2267I 2268W 2329E 2330E 2332I 2334E 2335E 2337E 2338E 2339I 2340E 2401W 2402E 2403E 2404E 2405R 2406I 2407I 2408E 2410I 2411I 2412I 2459E 2500E 2501E 2502E 2503E 2504E 2505E 2506E 2507E BUILD_Reqd: VSSICMS Toolmin: 144 (2012-01-22) Modules: VSSUME $REPOS

VS550016 VMARC 02/06/12 17:53:29 * VSSI HELPMSG additions

Update VS550016 applies to VSSI installation builds through 5502 Symptom: * VSSI HELPMSG additions Problem: Several HELPMSG files are missing from the VSSI package repository. Resolution: HELPMSG files added for the following messages: VSSI: 999S 1001I 1002I 1021I 1022I 1023I 1024E 1025E 1041W 1042I 1044E 1050W 1061I 1081E 1082E 1083E 1084E 1091E 1092E 1093E VPARS: 024I 025W 042I 062I 074I 119I 128I 147I 148I 161I 182I 199I 210E 219W 220W 221W 222W 223W 224I 225W 226W 999S VTAPE: 111E 130I 137I 165I 168I 191W 192W 214I 220I 257E 999S BUILD_Reqd: *None* Toolmin: 144 (2012-01-22) Modules: VSMODID COPY

VS550015 VMARC 01/27/12 14:32:17 * VSSI user message number corrections

Update VS550015 applies to VSSI installation builds through 5502 Symptom: * VSSI user message number corrections Problem: Several messages have message IDs which do not match the VSSI online documentation. Resolution: The following message IDs have been reassigned to match current documentation: OldID NewID Issuing Module(s) RVP163I RVP163E RVPOPN, RVPSV2 RVP201E RVP201W RVPRCC RVT032E RVT032I RVTLD1 RVT049I RVT049E RVTST2, RVTSUM RVT059E RVT059W RVTST1 RVT076E RVT076W RVTOPN RVT084I RVT084E RVTOPC RVT214W RVT214I RVTOCS RVT240I RVT240E RVTADD RVS1001I RVS1001I Was RVSINI; now RVSSTN RVS1002I RVS1002I Was RVSINI; now RVSSTN RVS5001I RVS1021I RVSSTB RVS5002I RVS1022I RVSSTB RVS5003I RVS1023I RVSSTB RVS5601E RVS1024E RVSSTB RVS5602E RVS1025E RVSSTB RVS5041W RVS1041W RVSSTL RVS5041I RVS1042I RVSSTL RVS5044E RVS1044E RVSSTL RVS5050W RVS1050W RVSSTL RVS5061I RVS1061I RVSSTL RVS5801E RVS1081E RVSSTL RVS5802E RVS1082E RVSSTL RVS5803E RVS1083E RVSSTL RVS5804E RVS1084E RVSSTL RVS5901E RVS1091E RVSSTL RVS5902E RVS1092E RVSSTL RVS5903E RVS1093E RVSSTL BUILD_Reqd: VSSIPL VSSICP Toolmin: 144 (2012-01-22) Modules: VSMODID COPY RVSSTL LAS55015

VP550014 VMARC 01/27/12 14:00:56 * VSSI user message number corrections

Update VP550014 applies to VSSI installation builds through 5502 Symptom: * VSSI user message number corrections Problem: Several messages have message IDs which do not match the VSSI online documentation. Resolution: The following message IDs have been reassigned to match current documentation: OldID NewID Issuing Module(s) RVP163I RVP163E RVPOPN, RVPSV2 RVP201E RVP201W RVPRCC RVT032E RVT032I RVTLD1 RVT049I RVT049E RVTST2, RVTSUM RVT059E RVT059W RVTST1 RVT076E RVT076W RVTOPN RVT084I RVT084E RVTOPC RVT214W RVT214I RVTOCS RVT240I RVT240E RVTADD RVS1001I RVS1001I Was RVSINI; now RVSSTN RVS1002I RVS1002I Was RVSINI; now RVSSTN RVS5001I RVS1021I RVSSTB RVS5002I RVS1022I RVSSTB RVS5003I RVS1023I RVSSTB RVS5601E RVS1024E RVSSTB RVS5602E RVS1025E RVSSTB RVS5041W RVS1041W RVSSTL RVS5041I RVS1042I RVSSTL RVS5044E RVS1044E RVSSTL RVS5050W RVS1050W RVSSTL RVS5061I RVS1061I RVSSTL RVS5801E RVS1081E RVSSTL RVS5802E RVS1082E RVSSTL RVS5803E RVS1083E RVSSTL RVS5804E RVS1084E RVSSTL RVS5901E RVS1091E RVSSTL RVS5902E RVS1092E RVSSTL RVS5903E RVS1093E RVSSTL BUILD_Reqd: VSSICP Toolmin: 144 (2012-01-22) Modules: RVPMSG ASSEMBLE

VT550014 VMARC 01/27/12 14:01:16 * VSSI user message number corrections

Update VT550014 applies to VSSI installation builds through 5502-03 Symptom: * VSSI user message number corrections Problem: Several messages have message IDs which do not match the VSSI online documentation. Resolution: The following message IDs have been reassigned to match current documentation: OldID NewID Issuing Module(s) RVP163I RVP163E RVPOPN, RVPSV2 RVP201E RVP201W RVPRCC RVT032E RVT032I RVTLD1 RVT049I RVT049E RVTST2, RVTSUM RVT059E RVT059W RVTST1 RVT076E RVT076W RVTOPN RVT084I RVT084E RVTOPC RVT214W RVT214I RVTOCS RVT240I RVT240E RVTADD RVS1001I RVS1001I Was RVSINI; now RVSSTN RVS1002I RVS1002I Was RVSINI; now RVSSTN RVS5001I RVS1021I RVSSTB RVS5002I RVS1022I RVSSTB RVS5003I RVS1023I RVSSTB RVS5601E RVS1024E RVSSTB RVS5602E RVS1025E RVSSTB RVS5041W RVS1041W RVSSTL RVS5041I RVS1042I RVSSTL RVS5044E RVS1044E RVSSTL RVS5050W RVS1050W RVSSTL RVS5061I RVS1061I RVSSTL RVS5801E RVS1081E RVSSTL RVS5802E RVS1082E RVSSTL RVS5803E RVS1083E RVSSTL RVS5804E RVS1084E RVSSTL RVS5901E RVS1091E RVSSTL RVS5902E RVS1092E RVSSTL RVS5903E RVS1093E RVSSTL BUILD_Reqd: VSSICP Toolmin: 144 (2012-01-22) Modules: RVTMSG ASSEMBLE

VS550014 VMARC 01/27/12 14:01:06 * VSSI user message number corrections

Update VS550014 applies to VSSI installation builds through 5502 Symptom: * VSSI user message number corrections Problem: Several messages have message IDs which do not match the VSSI online documentation. Resolution: The following message IDs have been reassigned to match current documentation: OldID NewID Issuing Module(s) RVP163I RVP163E RVPOPN, RVPSV2 RVP201E RVP201W RVPRCC RVT032E RVT032I RVTLD1 RVT049I RVT049E RVTST2, RVTSUM RVT059E RVT059W RVTST1 RVT076E RVT076W RVTOPN RVT084I RVT084E RVTOPC RVT214W RVT214I RVTOCS RVT240I RVT240E RVTADD RVS1001I RVS1001I Was RVSINI; now RVSSTN RVS1002I RVS1002I Was RVSINI; now RVSSTN RVS5001I RVS1021I RVSSTB RVS5002I RVS1022I RVSSTB RVS5003I RVS1023I RVSSTB RVS5601E RVS1024E RVSSTB RVS5602E RVS1025E RVSSTB RVS5041W RVS1041W RVSSTL RVS5041I RVS1042I RVSSTL RVS5044E RVS1044E RVSSTL RVS5050W RVS1050W RVSSTL RVS5061I RVS1061I RVSSTL RVS5801E RVS1081E RVSSTL RVS5802E RVS1082E RVSSTL RVS5803E RVS1083E RVSSTL RVS5804E RVS1084E RVSSTL RVS5901E RVS1091E RVSSTL RVS5902E RVS1092E RVSSTL RVS5903E RVS1093E RVSSTL BUILD_Reqd: VSSIPL VSSICP Toolmin: 144 (2012-01-22) Modules: RVSMSG ASSEMBLE RVSSTB ASSEMBLE

VS550013 VMARC 01/22/12 10:56:54 * CPDISK filemode routine entry point

Update VS550013 applies to VSSI installation builds through 5502 Symptom: * CPDISK filemode routine entry point Problem: Filemode determination routines are scattered among several modules. Resolution: All modules now call RVSSTPSN in order to retrieve the VSSI CP PARM disk filemode. BUILD_Reqd: VSSIPL VSSICP Toolmin: 144 (2012-01-22) Modules: RVSSTP ASSEMBLE