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 5530 to 5532), all outstanding updates (e.g., from 5530) are rolled into the new package version (e.g., 5532). You can determine your package version by running the VSQPKG exec on your VSSI Install disk; e.g.: . vsqpkg (no parameters) To obtain updates for your package, you can do as follows: 1. Determine your package version (e.g., 5530). 2. Download the PTFCUM that corresponds to your package (e.g., VPVT5530 PTFCUM if you have VPARS/VTAPE, VT5530 PTFCUM if you have VTAPE-only, and SD5530 PTFCUM if you have ShadowDisk/Z). 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 VSPTFCUM EXEC is used to install the PTF(s) from the matching PTFCUM package that you downloaded. If specified with the normal parameters (e.g., VSPTFCUM 5530), the EXEC does as follows: . expands all contained PTFs to your A-disk; . evaluates all PTFs for APPLY inclusion; . installs any validated PTFs which are not already applied. 3. If you are at a given package level (e.g., 5530), and you wish to install subsequent updates for the next available package level (e.g., 5532) for the same z/VM release, you can do as follows: . Download the latest PTFCUM for your current package level (e.g., download VPVT5530 PTFCUM). You will not need to download 5530 in the future. . Install the PTFCUM via the VSPTFCUM exec (use the (NOASM option to save time). . Download the latest PTFCUM for the next package level (e.g., download VPVT5532 PTFCUM). You will be downloading this PTFCUM on a regular basis (e.g., until VSSI closes 5532 and generates 5534). . Install the PTFCUM via the VSPTFCUM exec (use the (NOASM option to save time). . Complete the PTF update process as follows: . vssetup . vssiprep . vsasmall . vsbldnuc . vscopy nuc cf1 cf0 (force . Reboot and test 4. The PTF summaries can be viewed on the VSSI Web site; e.g.: VPARS/VTAPE https://www.vsoftsys.com/doc/critvp55.htm VTAPE-only https://www.vsoftsys.com/doc/critvt55.htm ShadowDisk/Z https://www.vsoftsys.com/doc/critsd55.htm 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 . 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 5532 and lower
VS550492 VMARC 03/23/23 14:30:58 * Placeholder update - start 5532
Update VS550492 applies to VSSI installation builds through 5532 Symptom: * Placeholder update - start 5532 Problem: Dummy update to mark the start of Build 5532. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 497 (2023-03-09) Modules: VSMODID COPY
PTFs below apply to Packages at 5530 and lower
VS550491 VMARC 03/23/23 14:08:04 * Placeholder update - end 5530
Update VS550491 applies to VSSI installation builds through 5530 Symptom: * Placeholder update - end 5530 Problem: Dummy update to mark the end of Build 5530. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 497 (2023-03-09) Modules: VSMODID COPY
VS550490 VMARC 03/23/23 14:08:31 * VTAPE scratch errors after fix VT550479
Update VS550490 applies to VSSI installation builds through 5530 Symptom: * VTAPE scratch errors after fix VT550479 Problem: Files generated by VTRPT1 incorrect after the refactoring done by fix VT550479. This only happens if VSSI dateformat is set to SHORTDATE. Resolution: Several routines in VSSUBDT updated to clear the output buffer to blanks. BUILD_Reqd: VSSICMS Toolmin: 1.0 497 (2023-03-09) Modules: VSSUBDT ASSEMBLE
VT550489 VMARC 01/26/23 17:24:18 * VTBKVOL USING error after fix VT550485
Update VT550489 applies to VSSI installation builds through 5530 Symptom: * VTBKVOL USING error after fix VT550485 Problem: Incorrect USING usage results in a warning when assembling VTBKVOL and the incorrect base register being used. Resolution: VTBKVOL is updated to ensure the correct base register is used. Updates to additional parts with minor pending resfactoring are included. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 494 (2022-12-18) Modules: RVTADD ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTOPN ASSEMBLE RVTPAC ASSEMBLE RVTST1 ASSEMBLE VTBKVOL ASSEMBLE
VP550488 VMARC 01/25/23 14:33:54 * LCK001 possible after fix VP550464
Update VP550488 applies to VSSI installation builds through 5530 Symptom: * LCK001 possible after fix VP550464 Problem: During code review it was determined that a LCK001 ABEND could occur on a busy system after fix 464's refactoring. Resolution: RVPSV1 is updated so the requested lock is properly obtained even if not immediately available. Updates from additional parts with minor pending refactoring are included. BUILD_Reqd: VSSICP Toolmin: 1.0 494 (2022-12-18) Modules: RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPEXT ASSEMBLE RVPFCL ASSEMBLE RVPFCX ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSYN ASSEMBLE
VT550487 VMARC 12/14/22 09:54:06 * Annual resequence assembler parts
Update VT550487 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVTADD, RVTMSG, RVTSV1 and VTBKUP are resequenced. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 490 (2022-11-07) Modules: RVTADD ASSEMBLE RVTMSG ASSEMBLE RVTSV1 ASSEMBLE VTBKUP ASSEMBLE
VP550487 VMARC 12/14/22 09:53:57 * Annual resequence assembler parts
Update VP550487 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVPCLR, RVPIOR, RVPOPN, RVPQY1, RVPRCC and RVPSYN are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 490 (2022-11-07) Modules: RVPCLR ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPQY1 ASSEMBLE RVPRCC ASSEMBLE RVPSYN ASSEMBLE
VP550486 VMARC 12/14/22 09:53:35 * Annual resequence MACROs
Update VP550486 applies to VSSI installation builds through 5530 Symptom: * Annual resequence MACROs 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year VPFMTMAC is resequenced. BUILD_Reqd: VSSICMS VSSMMAC Toolmin: 1.0 490 (2022-11-07) Modules: VPFMTMAC MACRO
VS550486 VMARC 12/14/22 09:52:57 * Annual resequence assembler parts
Update VS550486 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVSCFG and RVSSTL are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 490 (2022-11-07) Modules: VSMODID COPY RVSCFG ASSEMBLE
VT550485 VMARC 12/13/22 10:45:59 * Deadlock on VTSABQLK
Update VT550485 applies to VSSI installation builds through 5530 Symptom: * Deadlock on VTSABQLK Problem: We had a deadlock situation where user A had issued a VTQUERY ACTIVE command at the exact same instant as user B did a rewind/unload I/O against a tape mounted shared. We (user A) obtained the VTSABQLK and, because we encountered a shared tape we want its VTXSHRLK. Meanwhile user B has obtained the VTXSHRLK as part of the I/O processing and wants the VTSABQLK in order to remove the tape from the chain of active tapes. Classic textbook deadlock. Resolution: RVTCONQA (VTQUERY ACTIVE) has been updated to conditionally obtain the VTXSHRLK (formerly it unconditionally obtained it). If it is not available, release the VTSQBALK, throw away any output generated up to that point and then restart the query. In this way a deadlock is avoided. This is an old bug, code has been like this for about 30 years! Additionally, a number of other parts have been updated with minor refactoring (eg: device number on message RVTREW099W was wrong (another 30 year old bug)). BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 490 (2022-11-07) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTMSG ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPAC ASSEMBLE RVTPRC ASSEMBLE RVTREW ASSEMBLE RVTSCS ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTRPT1 ASSEMBLE
VP550484 VMARC 12/14/22 10:18:31 * Concatenated database errors after fix VP550478
Update VP550484 applies to VSSI installation builds through 5530 Symptom: * Concatenated database errors after fix VP550478 Problem: The second (and subsequent) user to open a concatenated database receives message: RVPOPN163E Database disk 1F10 is in use by the database with key E946000000 The user should be able to concatenate the database. Additionally, the database key wrong in message RVPOPN163E. Resolution: Fix 478 added EAV support which resulted in the database key being expanded from 4 to 6 bytes. At its root this was a database key problem with the concatenated database being assigned the wrong key. RVPOPS has been updated to assign the correct key. A new informational message is now issued when a database is concatenated: Database with key x has been concatenated Additionally a number of other parts have had minor refactoring. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 490 (2022-11-07) Modules: RVPBUF ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCPS ASSEMBLE RVPIFC ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY2 ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPTMR ASSEMBLE VPBKUP ASSEMBLE VPCHKDIR ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VP550483 VMARC 12/12/22 12:12:03 * Common/COPY/MACRO updates in support of fix 484
Update VP550483 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 484 Problem: Changes in support of fix 484. Resolution: Changes in support of fix 484. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 490 (2022-11-07) Modules: RVPFMTBK COPY RVPKEYGN COPY RVPTPHDR COPY VPCAPFLS COPY VPCTLBK COPY VPFMTMAC MACRO
VS550483 VMARC 12/12/22 12:10:55 * Common/COPY/MACRO updates in support of fix 484
Update VS550483 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 484 Problem: Changes in support of fix 484. Resolution: Changes in support of fix 484 and minor refactoring. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 490 (2022-11-07) Modules: VSSUME $REPOS VSMDEBK COPY VSMEQU COPY VSXENTR MACRO DISKPRT ASSEMBLE DISKZAP ASSEMBLE RVSCMD ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSUTL ASSEMBLE VSSUBR02 ASSEMBLE
VP550482 VMARC 08/01/22 12:04:04 * Wild branch into page 0 after VP550478
Update VP550482 applies to VSSI installation builds through 5530 Symptom: * Wild branch into page 0 after VP550478 Problem: Wild branch into page 0 after VP550478. R14 should have contained the return address but it was also being used to hold a cylinder number. Resolution: Code in RVPCSP is updated to use R15 to hold the cylinder number, ensuring R14 always contains the return address. BUILD_Reqd: VSSICP Toolmin: 1.0 481 (2022-05-04) Modules: RVPCSP ASSEMBLE
VS550481 VMARC 07/22/22 14:21:11 * Show CPU Capicity Identifier in VSQ LICENSE
Update VS550481 applies to VSSI installation builds through 5530 Symptom: * Show CPU Capicity Identifier in VSQ LICENSE Problem: VSQuery LICense shows the host machine CPU type and model (e.g., 2964-401 for a z13). These values are internally used by the license code to validate the CPU capacity for licensing and execution purposes. Older machine types mostly had the model number and the capacity identifier as the same value, so license validation routines could use either one. Increasingly (e.g., some z13/z14, more on the z16) contain capacity identifiers which are not the same as (i.e., "genetically drifting from") each other. Resolution: Modify VSQuery LICense to display both the CPU capacity identifer as well as the CPU model number. BUILD_Reqd: VSSICP Toolmin: 1.0 481 (2022-05-04) Modules: VSMODID COPY RVSSTL LAS55481
VT550480 VMARC 06/19/22 18:21:10 * FRE016 hard abend during SPXTAPE to a VTAPE
Update VT550480 applies to VSSI installation builds through 5530 Symptom: * FRE016 hard abend during SPXTAPE to a VTAPE Problem: HCPSPY called RVTSPXCU to clean up the simulated RDEV used for SPXTAPE to a VTAPE device. RVTSPXCU assumed HCPSPY had passed it the RDEV to return in R8. In some causes R8 contained a stale RDEV pointer resulting in the FRE016 abend. Resolution: RVTSPXCU is updated to obtain the RDEV to release from the TAPBK. This is an old bug. Code has been like this for at least 15 or 20 years. BUILD_Reqd: VSSICP Toolmin: 1.0 481 (2022-05-04) Modules: RVTSPX ASSEMBLE
VT550479 VMARC 06/11/22 19:12:11 * VMDUMP on message VSSVTB2215E
Update VT550479 applies to VSSI installation builds through 5530 Symptom: * VMDUMP on message VSSVTB2215E Problem: Customer received message "VSSVTB2233I 1 tape(s) with internal structural errors", while running a VTBKUP. Resolution: There is not enough information in the console log to diagnose the problem. A VMDUMP has been temporarily added to the code where message 2233 is issued. A number of other parts reviewed while researching this have had minor refactoring updates done. This fix hits the VTAPE CMS utilities only. BUILD_Reqd: VSSICMS Toolmin: 1.0 481 (2022-05-04) Modules: VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE
VP550478 VMARC 11/04/22 12:13:53 * Minimal EAV support
Update VP550478 applies to VSSI installation builds through 5530 Symptom: * Minimal EAV support Problem: Two problems are being addressed. First, output from VPQ OPEN is incorrect after fix 468. Second, provide minimal EAV support in VPARS and ShadowDisk. Resolution: Entry point RVPQY4QO is updated to fix the 468 regression. This was found in internal testing and nit a customer reported problem. Minimal support is added to VPARS/ShadowDisk. What "minimal" means is: - only support for guest database volume on EAV devices. No support for VPARS database disks on cylinders above 65519. Support will be added via a future fix. - format tables for EAV devices need to be created using the VPFMTMAC macro. VPBLDFMT has no support for EAV devices. Support will be added via a future fix. - the VPARS database layout is not optimized for EAV guest volumes. A future fix will add a new VPARS database format optimized for larger disks, When that fix is released old VPARS database formats will be deprecated and the VPARS database will need to be re-formatted. - while there is no support for VPARS database volumes on EAV cylinders, a number of externals have been updated in preparation of that support. Most notably, the database unique key is expanded from 4 to 6 bytes in size. Formerly it was made up of two unsigned 16 bit numbers, the device number of the RDEV hosting the VPARS database base disk, the starting cylinder number. The key is now: 2 bit unsigned channel subsystem number 16 bit RDEV device number (as before) 28 bit starting cylinder number (in big-endian format) 2 bits (reserved and set to 0) Numerous commands and messages have been updated to support the larger key size. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 481 (2022-05-04) Modules: RVPADD ASSEMBLE RVPBUF ASSEMBLE RVPCFG ASSEMBLE RVPCPS ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPFCL ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPQY4 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXPLTB ASSEMBLE VPBXREF ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VT550477 VMARC 06/11/22 19:10:34 * Common/COPY/MACRO updates in support of fix 479
Update VT550477 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 479 Problem: Changes in support of fix 479. Resolution: Changes in support of fix 479. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 481 (2022-05-04) Modules: VT55MAC $EXEC RVTSALIB COPY VTFDIRBK COPY VTVDSCBK COPY VTYCYCLE COPY VT6ANCH MACRO
VP550477 VMARC 06/11/22 19:08:40 * Common/COPY/MACRO updates in support of fix 478
Update VP550477 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 478 Problem: Changes in support of fix 478. Resolution: Changes in support of fix 478. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 481 (2022-05-04) Modules: VP55MAC $EXEC RVPCFGBK COPY RVPFMTBK COPY RVPKEYGN COPY RVPSHORT COPY VPCTLBK COPY VPMDSKBK COPY VPOPENBK COPY VP1WRKBK COPY VPFMTMAC MACRO
VS550477 VMARC 06/11/22 19:06:12 * Common/COPY/MACRO updates in support of fix 478/479
Update VS550477 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 478/479 Problem: Changes in support of fixes 478 and 479. Additionally VSI_DISK statement no longer recognized after fix 429. Resolution: Changes in support of fixes 478 and 479. Customer that reported the VSI_DISK problem was not CPXLOADing the VSSI code from the SYSTEM CONFIG file, choosing instead to load it from AUTOLOG1's PROFILE EXEC. Prior to fix 429 the code supporting the VSSI config statements was always built into the CP nucleus so it was always available whether or not the VSSI had been loaded. After fix 429 only the absolute minimum code was still build into CP. The vast majority of VSSI code is CPXLOADed. As this customer found out if you haven't CPLOADed our code our config file statements are not recognized. Rather than the VSI_DISK statement, the customer needed to issue a VSSET VSIDISK command with the FORCE option. The FORCE option implies there is something wrong if you need to use it, but, as the above scenario shows, it can be a completely normal thing to have an empty VSSI CMPK. Since this is not an exceptional condition, deprecate the FORCE option on VSSET VSIDISK. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 481 (2022-05-04) Modules: VS55MAC $EXEC VSSUME $REPOS VSDEFXBK COPY VSLCKXST COPY VSLOCRBK COPY VSMDEBK COPY VSMEQU COPY VSSIDATE COPY VSTRCBK COPY VSIMSG MACRO VSSPROLG MACRO VSXENTR MACRO DISKCHK ASSEMBLE DISKLAB ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSRTP01 ASSEMBLE VSSTRC ASSEMBLE VSSUBDT ASSEMBLE VSSUBR02 ASSEMBLE
VT550476 VMARC 05/18/22 10:17:58 * PRODUCT file update
Update VT550476 applies to VSSI installation builds through 5530 Symptom: * PRODUCT file update Problem: VTAPE product file (VSSIVT PRODUCT) has 1 missing comment block. Resolution: Updated PRODUCT file attached. BUILD_Reqd: VSSMMAC Toolmin: 1.0 481 (2022-05-04) Modules: VTMODID COPY
VP550476 VMARC 05/18/22 10:17:54 * VPSCAN module removal
Update VP550476 applies to VSSI installation builds through 5530 Symptom: * VPSCAN module removal Problem: VPSCAN is deprecated and is no longer required. Resolution: The following modules were altered: Module Action VPSCAN removed The above modules are removed from the PRODUCT files; actual element erasure will happen at a later date. BUILD_Reqd: VSSMMAC Toolmin: 1.0 481 (2022-05-04) Modules: VPMODID COPY
VS550476 VMARC 05/18/22 10:17:49 * CMS module reassignment
Update VS550476 applies to VSSI installation builds through 5530 Symptom: * CMS module reassignment Problem: Several VSSI Common modules have been deprecated and are no longer necessary. Resolution: The following modules were altered: Module Action VSDBSCAN removed (originally written as a bimodal (SD|VP) replacement for VPSCAN, but was never called) VSDCHK removed; replaced by DISKCHK VSDLBL removed; replaced by DISKLAB The above modules are removed from the PRODUCT files; actual element erasure will happen at a later date. BUILD_Reqd: VSSICMS Toolmin: 1.0 481 (2022-05-04) Modules: VSMODID COPY DISKCHK ASSEMBLE DISKLAB ASSEMBLE
VP550475 VMARC 04/17/22 19:24:33 * Chained A5/A6 simulation errors
Update VP550475 applies to VSSI installation builds through 5530 Symptom: * Chained A5/A6 simulation errors Problem: Three problems are being addressed by this fix: - fcx001 hard abend if VPARS receives a transport mode channel program - final record written to track with an A5 CCW not recorded in VPARS database - track advancement incorrect when reading data with an A6 CCW. Resolution: RVPFCX is updated to soft abend and command reject a transport mode I/O. RVPCSP is updated to properly increment tracks on A6 reads and properly recognize track end on A5 writes. A number of other parts are updated with minor pending refactoring. BUILD_Reqd: VSSICP Toolmin: 1.0 477 (2022-04-11) Modules: RVPCCL ASSEMBLE RVPCCV ASSEMBLE RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPFCX ASSEMBLE
VT550474 VMARC 04/14/22 14:04:48 * Correct SEPARATE handling
Update VT550474 applies to VSSI installation builds through 5530 Symptom: * Correct SEPARATE handling Problem: Two problems are being corrected: - SEPARATE list not handled correctly in all cases on VTMOUNT and VTSET. - VTSCTLBK is larger than 4K due to having VTSALIB blocks embedded in it. Resolution: SEPARATE list handling corrected. VTSALIB blocks are now stand alone blocks rather than embedded blocks. VTSCTLBK is now less than 4K in size and can be asserted (as can the free standing VTSALIB blocks). BUILD_Reqd: VSSICP Toolmin: 1.0 477 (2022-04-11) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTINI ASSEMBLE RVTIOR ASSEMBLE RVTMET ASSEMBLE RVTMNS ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPAC ASSEMBLE RVTQLB ASSEMBLE RVTQY2 ASSEMBLE RVTRST ASSEMBLE RVTSCS ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST2 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE RVTTBL ASSEMBLE RVTTMR ASSEMBLE
VT550473 VMARC 03/31/22 23:45:14 * Common/COPY/MACRO updates in support of fix 474
Update VT550473 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 474 Problem: COPY and MACRO updates in support of fix VT550474. Resolution: Primary change is the VTSCTLBK is updated to have an array of pointers to VTSALIB blocks (one for each library) rather than having the VTSALIB blocks embedded as part of the VTSCTLBK. This makes the VTSCTLBK smaller than 4K and allows both the VTSALIB block and the VTSCTLBK to be asserted. Additionally a number of other parts have been updated with minor pending refactoring (comment corrections and so on). BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 475 (2022-02-22) Modules: RVTSALIB COPY VTEXTBK COPY VTMNTBK COPY VTSCTLBK COPY VTXDCPBK COPY
VS550473 VMARC 03/31/22 23:43:32 * Common/COPY/MACRO updates in support of fix 474
Update VS550473 applies to VSSI installation builds through 5530 Symptom: * Common/COPY/MACRO updates in support of fix 474 Problem: COPY and MACRO updates in support of fix VT550474. Resolution: For the VSCOMMON subsystem, the VSSICBID list of control blocks is updated with entries for VTSALIB and VTSCTLBK. Additionally a number of other parts have been updated with minor pending refactoring (comment corrections and so on). BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 475 (2022-02-22) Modules: VS55MAC $EXEC VSMODID COPY VSSICBID COPY VSSIMSG COPY VSIMSG MACRO VSIPROLG MACRO RVSSTP ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55473
VT550472 VMARC 01/25/22 10:37:00 * Module splits; second tranche
Update VT550472 applies to VSSI installation builds through 5530 Symptom: * Module splits; second tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: RVTSYN is moved from the permanent to the temporary CPXLOAD list in RVTCPX. The VTAPE syntax tree is changed from having a single large branch to having multiple smaller branches. BUILD_Reqd: VSSICP Toolmin: 1.0 473 (2022-01-20) Modules: RVTCPX ASSEMBLE RVTINI ASSEMBLE RVTMSG ASSEMBLE RVTSYN ASSEMBLE
VP550472 VMARC 01/25/22 10:36:56 * Module splits; second tranche
Update VP550472 applies to VSSI installation builds through 5530 Symptom: * Module splits; second tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: RVPSYN is moved from the permanent to the temporary CPXLOAD list in RVPCPX. The VPARS and ShadowDisk syntax trees are changed from having a component specific branch and a common branch to having a component specific branch and multiple common branches. BUILD_Reqd: VSSICP Toolmin: 1.0 473 (2022-01-20) Modules: RVPCPX ASSEMBLE RVPINI ASSEMBLE RVPMSG ASSEMBLE RVPSYN ASSEMBLE
VS550472 VMARC 01/25/22 10:36:46 * Module splits; second tranche
Update VS550472 applies to VSSI installation builds through 5530 Symptom: * Module splits; second tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: RVSSYN is moved from the permanent to the temporary CPXLOAD list in RVSCPX. BUILD_Reqd: VSSICP Toolmin: 1.0 473 (2022-01-20) Modules: RVSCPX ASSEMBLE RVSSYN ASSEMBLE
VT550471 VMARC 01/24/22 10:54:12 * Some tapes not scratched when expired
Update VT550471 applies to VSSI installation builds through 5530 Symptom: * Some tapes not scratched when expired Problem: When a scratch tape is created, it has VOL1, HDR1 and HDR2 records with default values. The HDR1 record has a creation and expiration date of Dec. 31 1969. If the application using the tape either does not support standard labelled tapes or does not rewind and write over the VOL1/HDR1/HDR2 records, the default values are used when determining whether or not a tape has expired. Our VTRPT1 utility was comparing 69 with 22 and concluding the tape was not expired (despite 69 representing 1969 and 22 representing 2022). Yes, this is a Y2K bug still extant 22 years on!! Resolution: VPRPT1 is updated to properly support expiration dates in HDR1 records. It seems some sites may have worked around this by adding SCRATCH_SL_OPTION LIBONLY (or EITHER) to their VTAPE configuration file. After this fix, things should work correctly with the default of BOTH for SCRATCH_SL_OPTION and installations may not require this statement. Additionally this update performs refactoring on a number of other VTAPE parts to supply pending minor revisions to comments, shutdown processing and goto entry points. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 473 (2022-01-20) Modules: RVTADD ASSEMBLE RVTCME ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTREW ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSV1 ASSEMBLE RVTTMR ASSEMBLE VTBKUP ASSEMBLE VTRPT1 ASSEMBLE
VP550471 VMARC 01/20/22 19:25:14 * Some tapes not scratched when expired
Update VP550471 applies to VSSI installation builds through 5530 Symptom: * Some tapes not scratched when expired Problem: For VPARS this update is a refactoring change to supply pending minor revisions to comments, shutdown processing and goto entry points. Resolution: For VPARS this update is a refactoring change to supply pending minor revisions to comments, shutdown processing and goto entry points. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 473 (2022-01-20) Modules: RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCHN ASSEMBLE RVPCLR ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBY ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPTMR ASSEMBLE VPBXREST ASSEMBLE
VT550470 VMARC 01/20/22 19:24:24 * Refactoring in support of fix 471
Update VT550470 applies to VSSI installation builds through 5530 Symptom: * Refactoring in support of fix 471 Problem: Tapes not scratched when expired. Resolution: Changes to support fix 471. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 473 (2022-01-20) Modules: RVTSYSBK COPY VTCLBLBK COPY RVTMDLAT MACRO
VP550470 VMARC 01/20/22 19:23:03 * Refactoring in support of fix 471
Update VP550470 applies to VSSI installation builds through 5530 Symptom: * Refactoring in support of fix 471 Problem: Tapes not scratched when expired. Resolution: Changes to support fix 471. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 473 (2022-01-20) Modules: VPCTLBK COPY RVPMDLAT MACRO
VS550470 VMARC 01/20/22 19:21:58 * Refactoring in support of fix 471
Update VS550470 applies to VSSI installation builds through 5530 Symptom: * Refactoring in support of fix 471 Problem: Tapes not scratched when expired. Resolution: Changes to support fix 471. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 473 (2022-01-20) Modules: VSQLSTAT COPY RVSCFG ASSEMBLE RVSIOS ASSEMBLE RVSUTL ASSEMBLE VSSUBDT ASSEMBLE
VT550469 VMARC 11/11/21 11:33:56 * Annual resequence assembler parts
Update VT550469 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVTCON, RVTLD1, RVTOCT, RVTPRC, RVTQY1 and RVTSV5 are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 468 (2021-11-04) Modules: RVTCON ASSEMBLE RVTLD1 ASSEMBLE RVTOCT ASSEMBLE RVTPRC ASSEMBLE RVTQY1 ASSEMBLE RVTSV5 ASSEMBLE
VP550469 VMARC 11/11/21 11:33:51 * Annual resequence assembler parts
Update VP550469 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVPBUF, RVPCCL, RVPCFG, RVPCQY, RVPQY2, RVPSET and RVPSV1 are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 468 (2021-11-04) Modules: RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCQY ASSEMBLE RVPQY2 ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE
VS550469 VMARC 11/11/21 11:33:45 * Annual resequence assembler parts
Update VS550469 applies to VSSI installation builds through 5530 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVSCMD, RVSSTP and RVSUTL are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 468 (2021-11-04) Modules: RVSCMD ASSEMBLE RVSSTP ASSEMBLE RVSUTL ASSEMBLE
VT550468 VMARC 11/20/21 14:08:44 * Module splits; first tranche
Update VT550468 applies to VSSI installation builds through 5530 Symptom: * Module splits; first tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: For VTAPE the following modules are changed: RVTCMD entry points RVTCMDBI, RVTCMDBR, RVTCMDBW, RVTCMDCD, RVTCMDMC, RVTCMDMD, RVTCMDME, RVTCMDMK, RVTCMDMO, RVTCMDMS, RVSCMDRA and RVTCMDTM moved to RVTCME (new module) RVTDBM entry points RVTDBMPK and RVTDBMUP moved to RVTPAC (new module) RVTMSG module cleverly split with itself RVTQLB module split with RVTQLC (new module) RVTSCR entry point RVTSCRSC moved to RVTSCS (new module) RVTSUM entry point RVTSUMVL moved to RVTMNS (new module) RVTSV1 entry point RVTSV1LB moved to RVTSV4 (by fix VT550431) RVTSV2 entry points RVTSV2IN, RVTSV2SI and RVTSV2TS moved to RVTINI (new module) entry points RVTSV2DT, RVTSV2SH and RVTSV2VQ moved to RVTCPS (new module); (as well entry points RVTSV5DR, RVTSV5D1 and RVTSV5D4 were moved from RVTSV5 to RVTCPS (although RVTSV5 was not over 4K in size, it made sense to logically group those routines together with the ones moved from RVTSV2)) This leaves RVTCCW still to be split. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 470 (2021-11-12) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCFG ASSEMBLE RVTCMD ASSEMBLE RVTCME ASSEMBLE RVTCON ASSEMBLE RVTCPS ASSEMBLE RVTCPX ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTINI ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTLGR ASSEMBLE RVTMET ASSEMBLE RVTMNS ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPAC ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQLC ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSCS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE RVTSYN ASSEMBLE RVTTMR ASSEMBLE VTSCR1 ASSEMBLE
VP550468 VMARC 11/20/21 14:07:04 * Module splits; first tranche
Update VP550468 applies to VSSI installation builds through 5530 Symptom: * Module splits; first tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: For VPARS the following modules are changed: RVPCON was not over 4K but it was close so entry points RVPCONFM and RVPCONFP were moved to RVPSV2. RVPDBS entry point RVPDBSVC moved to RVPCCV (new module) RVPMSG module cleverly split with itself RVPQY1 entry points RVPQY1QK and RVPQY1QO moved to RVPQY4 (new module) RVPSET entry point RVPSETFC moved to RVPFCL (new module) RVPSV1 although it was under 4K, to be consistent with VTAPE, RVPINI was created and entry points RVPSV1IN and RVPSV1SI were moved to it. RVPSV2 was also under 4K, and again to be consistent with VTAPE, RVPCPS was created and entry points RVPSV2DR, RVPSV2DT, RVPSV2DV, RVPSV2RD This leaves RVPCSP and RVPDBM still to be split. BUILD_Reqd: VSSICP Toolmin: 1.0 470 (2021-11-12) Modules: RVPADD ASSEMBLE RVPBUF ASSEMBLE RVPCCV ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCHN ASSEMBLE RVPCON ASSEMBLE RVPCPS ASSEMBLE RVPCPX ASSEMBLE RVPCQY ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPEXT ASSEMBLE RVPFCL ASSEMBLE RVPIFC ASSEMBLE RVPINI ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPQY4 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE RVPTMR ASSEMBLE
VT550467 VMARC 11/16/21 15:42:03 * Module splits; first tranche
Update VT550467 applies to VSSI installation builds through 5530 Symptom: * Module splits; first tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: Changes to VTAPE COPY/MACRO parts in support of fix VT550468. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 470 (2021-11-12) Modules: VT55MAC $EXEC RVTCMPBK COPY RVTEQUAT COPY RVTSAVBK COPY VTQRYBK COPY RVTMDLAT MACRO VTREST ASSEMBLE
VP550467 VMARC 11/16/21 15:35:29 * Module splits; first tranche
Update VP550467 applies to VSSI installation builds through 5530 Symptom: * Module splits; first tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: Changes to VPARS COPY/MACRO parts in support of fix VP550468. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 470 (2021-11-12) Modules: RVPCMPBK COPY RVPEQUAT COPY VPCTLBK COPY VPOPENBK COPY VP1WRKBK COPY RVPMDLAT MACRO
VS550467 VMARC 11/16/21 14:06:34 * Module splits; first tranche
Update VS550467 applies to VSSI installation builds through 5530 Symptom: * Module splits; first tranche Problem: VSSI would like any part loaded with the temporary attribute to be smaller than 4K in size. Resolution: For the VSCOMMON component all temporary parts were already under 4K. These changes are in support of the changes to VPARS and VTAPE. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 470 (2021-11-12) Modules: VS55MAC $EXEC RVSCHKPR COPY RVSEQUAT COPY VSMODID COPY VSSICBID COPY VSSICMP COPY VSSIDATE COPY VSSIEQU COPY RVSMDLAT MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOR ASSEMBLE RVSIOS ASSEMBLE RVSMSG ASSEMBLE RVSPER ASSEMBLE RVSPRM ASSEMBLE RVSUTL ASSEMBLE VSLABSL ASSEMBLE VSSUBDT ASSEMBLE
VP550466 VMARC 11/14/21 11:44:10 * More ShadowDisk errors
Update VP550466 applies to VSSI installation builds through 5530 Symptom: * More ShadowDisk errors Problem: Two problems are being corrected: - Sense Path Group ID CCWs are being rejected. CP's CCW translation was translating CCW x34 (Sense Path Group ID) to CCW x70 (which is invalid). VPARS saw the x70 and command rejected the CCW as invalid. In fact CP untranslation recognizes the x70 as a translated x34 so we need to allow it out to the device and thence through to CP's CCW untranslation. - some multitrack reads receive incorrect data, or result in soft or hard abends (ccw006, csp007, dbs001, FUN001 and PRG005 have been seen). Resolution: RVPCCW and RVPDBS are updated to recognize CCW x70 and valid and allow the IO out to the device and thence to CP's untranslation. RVPCSP is updated to properly advance tracks on multitrack reads. BUILD_Reqd: VSSICP Toolmin: 1.0 470 (2021-11-12) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE
VP550465 VMARC 10/25/21 15:50:11 * ShadowDisk errors
Update VP550465 applies to VSSI installation builds through 5530 Symptom: * ShadowDisk errors Problem: A number of ShadowDisk problems are being corrected. - A second SDOPEN with an already open database results in a FRE016 abend. - VPQuery/SDQuery not distinguishing between VPARS and ShadowDisk databases for some queries (eg: status and checkpoint). - SDQuery not recognizing the correct file types (eg: SDQuery DEVTBL NAMEs (and FMTTBL and so on) would show VPARS rather than ShadowDisk files). Resolution: RVPIFC is updated to correct the FRE016. RVPCQY is updated to limit queries to matching databases. RVPCFG is updated to match file types with command type. BUILD_Reqd: VSSICP Toolmin: 1.0 466 (2021-09-28) Modules: RVPCFG ASSEMBLE RVPCQY ASSEMBLE RVPIFC ASSEMBLE
VT550464 VMARC 10/25/21 15:49:58 * Refactoring (timer/shutdown)
Update VT550464 applies to VSSI installation builds through 5530 Symptom: * Refactoring (timer/shutdown) Problem: Preparatory refactoring changes for future changes. Resolution: The logic to force close output VTAPE libraries at shutdown time is revised. Numerous other parts have had code restructuring/refactoring performed. BUILD_Reqd: VSSICP Toolmin: 1.0 466 (2021-09-28) Modules: RVTCCW ASSEMBLE RVTCON ASSEMBLE RVTCPX ASSEMBLE RVTMSG ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTSHU ASSEMBLE RVTST3 ASSEMBLE RVTSV1 ASSEMBLE RVTSYN ASSEMBLE
VP550464 VMARC 10/25/21 15:49:17 * Refactoring (timer/shutdown)
Update VP550464 applies to VSSI installation builds through 5530 Symptom: * Refactoring (timer/shutdown) Problem: Preparatory refactoring changes for future changes. Resolution: The logic to synchronize VPARS databases at shutdown time is simplified. The logic related to the VPARS synchronization timer is revised. Numerous other parts have had code restructuring/refactoring performed. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 466 (2021-09-28) Modules: RVPADD ASSEMBLE RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCPX ASSEMBLE RVPCQY ASSEMBLE RVPDBM ASSEMBLE RVPDBY ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPER ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE RVPTMR ASSEMBLE VPFMT ASSEMBLE
VT550463 VMARC 10/25/21 15:44:23 * Preparatory refactoring changes
Update VT550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550464 Resolution: MACRO/COPY updates for 550464 BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 466 (2021-09-28) Modules: RVTTRACE COPY VTCLBLBK COPY VTEXTBK COPY VTOPRMBK COPY VTQRPTS COPY
PTFs below apply to Packages at 5532 and lower
VT550463 VMARC 03/23/23 17:56:02 * Preparatory refactoring changes
Update VT550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550464 Resolution: MACRO/COPY updates for 550464 BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 466 (2021-09-28) Modules: RVTTRACE COPY VTCLBLBK COPY VTEXTBK COPY VTOPRMBK COPY VTQRPTS COPY
PTFs below apply to Packages at 5530 and lower
VP550463 VMARC 10/25/21 15:37:52 * Preparatory refactoring changes
Update VP550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550464 Resolution: MACRO/COPY updates for 550464 BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 466 (2021-09-28) Modules: RVPDEVBK COPY RVPEQUAT COPY RVPTRACE COPY VPCTLBK COPY VPMDSKBK COPY VPMDTBL COPY VPTCCTBK COPY
PTFs below apply to Packages at 5532 and lower
VP550463 VMARC 03/23/23 17:54:33 * Preparatory refactoring changes
Update VP550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550464 Resolution: MACRO/COPY updates for 550464 BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 466 (2021-09-28) Modules: RVPDEVBK COPY RVPEQUAT COPY RVPTRACE COPY VPCTLBK COPY VPMDSKBK COPY VPMDTBL COPY VPTCCTBK COPY
PTFs below apply to Packages at 5530 and lower
VS550463 VMARC 10/25/21 15:27:17 * Preparatory refactoring changes
Update VS550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550453 Resolution: In addition to the MACRO/COPY changes the following additional changes are done to the VSCOMMON subsystem: - the current fix level shown in the response to VSQuery LEVel (nee VSQuery VSLevel) is now dynamically determined at load time from the just loaded code. Formerly this was a static value determined at build time. The command output is unchanged. vsq lev VSSI Level 5500 Build 5530 Fix 550464 on 26 Sep 2021 for Z/VM 7.2.0 Ready; T=0.01/0.01 02:53:55 - a new VSQuery COMPonents command will show the highest fix level for each subsystem that is loaded and where the subsystem was loaded from. eg: vsquery components VSCOMMON fixlevel VS550463 loaded from VSCOMM72 TXTLIB dated 2021-09-26 21:18:44 VTAPE fixlevel VT550464 loaded from VTAPE72 TXTLIB dated 2021-09-26 20:03:50 VPARS fixlevel VP550464 loaded from VPARS72 TXTLIB dated 2021-09-27 00:37:37 Ready; T=0.01/0.01 02:54:46 BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 466 (2021-09-28) Modules: VS55MAC $EXEC RVSCHKPR COPY RVSTRACE COPY RVSYNTAX COPY VSDATEFM COPY VSMDEBK COPY VSMODID COPY VSSICFG COPY VSSIEQU COPY VSSIMSG COPY VSIMSG MACRO VSIPROLG MACRO VSLCKOP MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOS ASSEMBLE RVSLCK ASSEMBLE RVSMSG ASSEMBLE RVSPER ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE VSSUBDT ASSEMBLE VSSUBR02 ASSEMBLE RVSSTL LAS55463
PTFs below apply to Packages at 5532 and lower
VS550463 VMARC 03/23/23 17:53:01 * Preparatory refactoring changes
Update VS550463 applies to VSSI installation builds through 5530 Symptom: * Preparatory refactoring changes Problem: MACRO/COPY updates for 550453 Resolution: In addition to the MACRO/COPY changes the following additional changes are done to the VSCOMMON subsystem: - the current fix level shown in the response to VSQuery LEVel (nee VSQuery VSLevel) is now dynamically determined at load time from the just loaded code. Formerly this was a static value determined at build time. The command output is unchanged. vsq lev VSSI Level 5500 Build 5530 Fix 550464 on 26 Sep 2021 for Z/VM 7.2.0 Ready; T=0.01/0.01 02:53:55 - a new VSQuery COMPonents command will show the highest fix level for each subsystem that is loaded and where the subsystem was loaded from. eg: vsquery components VSCOMMON fixlevel VS550463 loaded from VSCOMM72 TXTLIB dated 2021-09-26 21:18:44 VTAPE fixlevel VT550464 loaded from VTAPE72 TXTLIB dated 2021-09-26 20:03:50 VPARS fixlevel VP550464 loaded from VPARS72 TXTLIB dated 2021-09-27 00:37:37 Ready; T=0.01/0.01 02:54:46 BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 466 (2021-09-28) Modules: VS55MAC $EXEC RVSCHKPR COPY RVSTRACE COPY RVSYNTAX COPY VSDATEFM COPY VSMDEBK COPY VSMODID COPY VSSICFG COPY VSSIEQU COPY VSSIMSG COPY VSIMSG MACRO VSIPROLG MACRO VSLCKOP MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOS ASSEMBLE RVSLCK ASSEMBLE RVSMSG ASSEMBLE RVSPER ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE VSSUBDT ASSEMBLE VSSUBR02 ASSEMBLE RVSSTL LAS55463
PTFs below apply to Packages at 5530 and lower
VS550462 VMARC 09/26/21 10:03:36 * Placeholder update - start 5530
Update VS550462 applies to VSSI installation builds through 5530 Symptom: * Placeholder update - start 5530 Problem: Dummy update to mark the start of Build 5530. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 464 (2021-09-24) Modules: VSMODID COPY
PTFs below apply to Packages at 5528 and lower
VS550461 VMARC 09/26/21 09:54:00 * Placeholder update - end 5528
Update VS550461 applies to VSSI installation builds through 5528 Symptom: * Placeholder update - end 5528 Problem: Dummy update to mark the end of Build 5528. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 464 (2021-09-24) Modules: VSMODID COPY
VP550460 VMARC 09/26/21 09:01:23 * Revert fix 350's CFM requirement
Update VP550460 applies to VSSI installation builds through 5528 Symptom: * Revert fix 350's CFM requirement Problem: To ensure consistent results when doing a VPQUERY of another users open VPARS database, fix VP550350 annexed console function mode (CFM) serialization on the target user. Requiring CFM on the target has subsequently proven to be too onerous a requirement. Resolution: CFM annexing has been reverted. Alternate forms of serialization are used to ensure consistent results. BUILD_Reqd: VSSICP Toolmin: 1.0 464 (2021-09-24) Modules: RVPCQY ASSEMBLE RVPDBM ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPSV1 ASSEMBLE
VP550459 VMARC 09/21/21 15:58:24 * Storage alignment unfavorable warnings
Update VP550459 applies to VSSI installation builds through 5528 Symptom: * Storage alignment unfavorable warnings Problem: VPREST receives an ASMA033I Storage alignment unfavorable warning for QKEYDVNM. Resolution: ST QKEYDVNM has been changed to STCM QKEYDVNM in VPBKUP, VPREST and VPUNLD. A number of other parts have had comments corrected. BUILD_Reqd: VSSICMS Toolmin: 1.0 463 (2021-08-05) Modules: VPBKUP ASSEMBLE VPCHKDIR ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VP550458 VMARC 09/06/21 17:06:48 * VPADDing too many disks
Update VP550458 applies to VSSI installation builds through 5528 Symptom: * VPADDing too many disks Problem: Issuing a VPADD for more disks than are available results in the VPARS database minidisk table having the last valid entry removed. This can result in various soft abends (eg: ccw006, csp007, dbt008, sv1001) and/or hard abends (eg: PRG006, HTT001 have been seen). VPADD ALL does not have this problem, only VPADDing when a count of disks has been specified. Resolution: RVPADD is updated to properly back out a partially added minidisk if an error occurs during a VPADD. RVPCON is updated to properly pass back the databases key on an error. These are very old bugs. The code has been like this for 25 or 30 years. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVPADD ASSEMBLE RVPCON ASSEMBLE
VP550457 VMARC 08/30/21 22:20:14 * sv1001 soft abend after a dbt002 or dbt008 soft abend
Update VP550457 applies to VSSI installation builds through 5528 Symptom: * sv1001 soft abend after a dbt002 or dbt008 soft abend Problem: Fix VP550090 updated several entry points in RVPDBT to soft abend and return an error indication via the CC, rather than hard abend. Calls to those entry points were then updated to check the CC on return. One of the calls in RVPDBM was taking an error exit but leaving a buffer locked. Subsequently, when the buffer is released, RVPSV1 determines it is still in use and takes an sv1001 soft abend. Resolution: RVPDBM is updated to unlock the RD buffer if it receives an error back from an RVPDBTQA call. As well additional data is provided for future ccw006 soft abends. RVPSV1 is updated to include more information in the sv1001 soft abend. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVPDBM ASSEMBLE RVPSV1 ASSEMBLE
VP550456 VMARC 08/30/21 21:52:57 * Buffer address wrong after call to RVPEXTOL
Update VP550456 applies to VSSI installation builds through 5528 Symptom: * Buffer address wrong after call to RVPEXTOL Problem: Fix 435 updated our use of HCPTRANS to accommodate IBM's changes to it. As part of that fix an HCPTRANS in RVPDBM was eliminated. R2 was used to hold the translated address and it no longer had the buffer address after 435's change. Resolution: RVPDBM has been updated so R2 again has the buffer address. RVPDBS has been updated to clarify some comments. RVPDBS text decks compare before and after. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVPDBM ASSEMBLE RVPDBS ASSEMBLE
VP550455 VMARC 08/11/21 13:06:11 * dbt008/ccw006 soft abends
Update VP550455 applies to VSSI installation builds through 5528 Symptom: * dbt008/ccw006 soft abends Problem: After doing a VPADD to expand a guest's VPARS database there are many dbt008/ccw006 soft abends and the guest's I/Os are failed. Resolution: There are two problems being fixed: - the dbt008 is because a VPARS block validation failed. RVPDBM was calling RVPSV1OA to obtain one or more blocks in the VPARS database. RVPSV1OA failed the request and returned X'FFFFFFFF' as the block id. Not all calls to RVPSV1OA in RVPDBM were checking that they were successful and thus we carried on and tried to use the invalid block id. The ccw006 is another variant of this problem. RVPDBM is updated to check whether or not each call to RVPSV1OA was successful. - the reason RVPSV1OA failed the request was due to the order in which VPADD updated fields relating to the number of minidisk that make up the VPARS database. There was a ~100 instruction window where the count of database minidisks did not match the number database minidisk descriptors. Updating the count later closes this window. Both these are very old bugs. The code has been like this for 25 or 30 years. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVPADD ASSEMBLE RVPDBM ASSEMBLE RVPSV1 ASSEMBLE
VS550454 VMARC 08/11/21 13:06:01 * ALS rollback
Update VS550454 applies to VSSI installation builds through 5528 Symptom: * ALS rollback Problem: RVSUTL uses instructions that not all customer machines have. Resolution: RVSUTL is updated to rollback the new instructions and use older instructions. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVSUTL ASSEMBLE
VT550453 VMARC 08/11/21 13:05:50 * Blank missing after REC on VTAPE query response
Update VT550453 applies to VSSI installation builds through 5528 Symptom: * Blank missing after REC on VTAPE query response Problem: Q V xxx for a VTAPE device, with a mounted tape that has been partially read, is missing the space between the constant REC and the record number. eg: q v 181 TAPE 0181 V349E H00023 3490 R/W S0041 AT REC15 Ready; T=0.01/0.01 13:15:39 that should be REC 15 not REC15. Resolution: This bug was introduced by fix VT550331 which did code clean up in RVTSV2VQ. It was no longer accounting for a trailing blank after the constant REC. Code has been updated to once again account for the trailing blank after REC. BUILD_Reqd: VSSICP Toolmin: 1.0 463 (2021-08-05) Modules: RVTSV2 ASSEMBLE
VS550452 VMARC 08/11/21 13:05:40 * Deprecated update - revised PTFCUM
Update VS550452 applies to VSSI installation builds through 5528 Symptom: * Deprecated update - revised PTFCUM Problem: This is a dummy update formerly used to mark the end of PTFCUM 5528. VSSI has since decided to add additional PTFs to 5528; therefore, this is no longer an end-of-CUM placeholder. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 463 (2021-08-05) Modules: VSMODID COPY
VT550451 VMARC 07/12/21 11:48:56 * Tape must be older than retention to scratch
Update VT550451 applies to VSSI installation builds through 5528 Symptom: * Tape must be older than retention to scratch Problem: Tapes must be one day older than their retention period in order to be scratched without the PURGE option. For example, tapes A1 and A2 are more than 24 hours old and should be sratchable with a keep of 1 day but they can not be scratched until they are 48 hours old: q t TIME IS 11:52:26 PDT SATURDAY 07/10/21 CONNECT= 14:48:57 VIRTCPU= 000:00.30 TOTCPU= 000:00.99 Ready; T=0.01/0.01 11:52:13 vtq lib a Volume Owner Created Keep Records %Full ... A00001 PRUITER 07/09/2021 04:25:40 1 195 4 ... A00002 PRUITER 07/09/2021 04:26:50 1 5 1 ... 2 tapes selected from library A Ready; T=0.01/0.01 11:52:20 vtscr a1 RVTSCR033E A00001 has not expired Ready(00033); T=0.01/0.01 11:52:25 Resolution: The problem is in RVTSCR. Fix VT530073 changed the expiration calculation to handle cases with a long retention period that resulted in a TOD value beyond 2042. After that change the tape had to be older than the retention period in order to be scratched. RVTSCR is updated so tapes that are equal in age to their retention period can also be scratched (as was the case prior to VT530073). This can also be seen when using the VTRPT1 and VTSCR1 utilities (as was the case with the reporting customer, where one or more RVTSCR033E $1 has not expired messages were received when running VTSCR1 with a list of expired tapes generated by VTRPT1). Additionally a number of other parts reviewed while researching this problem, have had minor refactoring done. In most cases text decks compare before and after. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 460 (2021-07-02) Modules: RVTCPX ASSEMBLE RVTDEF ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSYN ASSEMBLE RVTTBL ASSEMBLE RVTTMR ASSEMBLE VTRPT1 ASSEMBLE VTSCR1 ASSEMBLE
VT550450 VMARC 06/25/21 13:07:27 * VTREST ABENDs due to invalid base registers
Update VT550450 applies to VSSI installation builds through 5528 Symptom: * VTREST ABENDs due to invalid base registers Problem: A regression in module VTREST caused the base registers to be setup as follows: LARL R11,VTREST First base register 00794970 LARL R12,VTREST+4096 Second base register 00795960 LARL R12,VTREST+8192 Third base register 00797960 USING VTREST,R11,R12,R13 SET UP ADDRESSABILITY 00809990 Since R12 was set twice, and R13 was never set, the module experienced miscellaneous program ABENDs in short order. Resolution: Base register setup amended to properly load R10, R11, R12 (in that order). BUILD_Reqd: VSSICMS Toolmin: 1.0 459 (2021-06-24) Modules: VTREST ASSEMBLE
VT550449 VMARC 06/23/21 16:17:19 * VTQ DEF LIB x includes spurious output
Update VT550449 applies to VSSI installation builds through 5528 Symptom: * VTQ DEF LIB x includes spurious output Problem: VTQuery DEfaults LIbrary x includes a final line that was intended only to be included on user queries. Resolution: RVTQY2 is updated so the "volumes in use" line is only included with when VTQ DEF USER x is issued. This bug was introduced by fix 530106. Additionally, updates to a number of other VTAPE parts with pending minor refactoring are included with this fix. In most cases, text decks compare before and after the update. BUILD_Reqd: VSSICP Toolmin: 1.0 458 (2021-06-18) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTCPX ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTPRC 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 RVTTMR ASSEMBLE
VS550448 VMARC 06/18/21 12:28:56 * VSQ LICENSE output bypasses DIAG 8 buffer
Update VS550448 applies to VSSI installation builds through 5528 Symptom: * VSQ LICENSE output bypasses DIAG 8 buffer Problem: Customer issues: PIPE CP VSQ LICENSE | > VSSI OUT A and expects the command output to be captured and written to the file. Instead the command output is displayed on the screen. This worked prior to fix 550420. The command output was captured. Resolution: In preparation for future changes (that were eventually delivered in fix 429) fix 420 moved the entry points used by the license code to write output to the screen from RVSSTB to RVSSTP. At the same time two HCPCONSL macros were combined into one and the DESTINATION= operand was used to direct the output. When DESTINATION= is in use, the DIAG 8 buffer is bypassed. Entry points RVSSTPHS and RVSSTPHU are updated to again each have their own HCPCONSL rather than sharing one that uses DESTINATION=. Additionally a number of other parts with pending minor refactoring are included with this fix. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 458 (2021-06-18) Modules: RVSCHKPR COPY VSMODID COPY VSIPROLG MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSMSG ASSEMBLE RVSPRC ASSEMBLE RVSSTP ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55448
VS550447 VMARC 05/31/21 17:08:05 * VPTEST succeeds when it should have failed
Update VS550447 applies to VSSI installation builds through 5528 Symptom: * VPTEST succeeds when it should have failed Problem: VPTEST of a device intercept list (file type VPTPFDEV) with more than 505 device ranges should result in message RVPCFG041E Test failed but instead gets Test successful message. Resolution: Fix 550429 reworked the logic in RVSCFGRD and resulted in RVSCFGRD sometimes returning with return code 0 when it should have been return code 4. RVSCFG is updated to correct. Additionally, updates to a number of other VSCOMMON parts with minor pending refactoring are included. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 457 (2021-04-18) Modules: VSSICBID COPY RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSSTP ASSEMBLE
VT550446 VMARC 05/31/21 21:26:15 * Refactoring (renames)
Update VT550446 applies to VSSI installation builds through 5528 Symptom: * Refactoring (renames) Problem: Rename a number of parts to better reflect how they are used. Resolution: Update VPARS code base to use the new names for the parts mentioned in 550445. A number of other parts with minor pending refactoring are included. This fix should cause no functional change. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 457 (2021-04-18) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCFG ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTCPX ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTLGR ASSEMBLE RVTLVL ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPER 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 RVTSYN ASSEMBLE RVTTMR ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTCPYASM ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE
VP550446 VMARC 05/31/21 21:05:13 * Refactoring (renames)
Update VP550446 applies to VSSI installation builds through 5528 Symptom: * Refactoring (renames) Problem: Rename a number of parts to better reflect how they are used. Resolution: Update VPARS code base to use the new names for the parts mentioned in 550445. A number of other parts with minor pending refactoring are included. This fix should cause no functional change. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 457 (2021-04-18) Modules: RVPADD ASSEMBLE RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCHN ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCPX ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPDBY ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPLGR ASSEMBLE RVPLVL ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPER ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE VPBXREST ASSEMBLE VPCPYASM ASSEMBLE VPREST ASSEMBLE
VT550445 VMARC 05/31/21 20:42:47 * Refactoring (renames)
Update VT550445 applies to VSSI installation builds through 5528 Symptom: * Refactoring (renames) Problem: Rename a number of parts to better reflect how they are used. Resolution: VSMSGH MACRO and VSMSGPBK COPY are renamed to VSIMSG MACRO and VSSIMSG COPY to better reflect that they are used across the entire code base. RVSCMPBK COPY is renamed to VSSICMP COPY to again better reflect that its use is not restricted only to RVSxxx parts. VSSITRAC COPY has been split into RVPTRACE COPY, RVSTRACE COPY and RVTTRACE COPY to better reflect that information relating to private trace tables only needs to be known by each subsystem and not code base wide. A number of other parts with minor pending refactoring are included. This fix should cause no functional change. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 457 (2021-04-18) Modules: VT55MAC $EXEC RVTCMPBK COPY RVTEQUAT COPY RVTTRACE COPY
VP550445 VMARC 05/31/21 20:35:52 * Refactoring (renames)
Update VP550445 applies to VSSI installation builds through 5528 Symptom: * Refactoring (renames) Problem: Rename a number of parts to better reflect how they are used. Resolution: VSMSGH MACRO and VSMSGPBK COPY are renamed to VSIMSG MACRO and VSSIMSG COPY to better reflect that they are used across the entire code base. RVSCMPBK COPY is renamed to VSSICMP COPY to again better reflect that its use is not restricted only to RVSxxx parts. VSSITRAC COPY has been split into RVPTRACE COPY, RVSTRACE COPY and RVTTRACE COPY to better reflect that information relating to private trace tables only needs to be known by each subsystem and not code base wide. A number of other parts with minor pending refactoring are included. This fix should cause no functional change. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 457 (2021-04-18) Modules: VP55MAC $EXEC RVPCMPBK COPY RVPEQUAT COPY RVPSHORT COPY RVPTRACE COPY VPCTLBK COPY
VS550445 VMARC 05/31/21 20:24:55 * Refactoring (renames)
Update VS550445 applies to VSSI installation builds through 5528 Symptom: * Refactoring (renames) Problem: Rename a number of parts to better reflect how they are used. Resolution: VSMSGH MACRO and VSMSGPBK COPY are renamed to VSIMSG MACRO and VSSIMSG COPY to better reflect that they are used across the entire code base. RVSCMPBK COPY is renamed to VSSICMP COPY to again better reflect that its use is not restricted only to RVSxxx parts. VSSITRAC COPY has been split into RVPTRACE COPY, RVSTRACE COPY and RVTTRACE COPY to better reflect that information relating to private trace tables only needs to be known by each subsystem and not code base wide. A number of other parts with minor pending refactoring are included. This fix should cause no functional change. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 457 (2021-04-18) Modules: VS55MAC $EXEC RVSEQUAT COPY RVSTRACE COPY RVSYNTAX COPY VSMODID COPY VSSICBID COPY VSSICMP COPY VSSIMSG COPY VSIMSG MACRO VSIPROLG MACRO VSMSGHE MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSLVL ASSEMBLE RVSPER ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSTP ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55445
VP550444 VMARC 05/04/21 12:54:35 * Wild branch from RVPCCWCD possible after fix VP550430
Update VP550444 applies to VSSI installation builds through 5528 Symptom: * Wild branch from RVPCCWCD possible after fix VP550430 Problem: During further code development it was noticed that a wild branch was possible from RVPCCWCD after update VP550430. This is a rarely used entry point and no customer outage occurred due to the code defect. Resolution: RVPCCW has been updated to eliminate entry point RVPCCWCD; this logic has been moved to RVPDBM. RVPDBS has been updated to eliminate entry point RVPDBSNV; this logic has been moved to RVPCCW. RVPCPS has minor pending refeactoring done. BUILD_Reqd: VSSICP Toolmin: 1.0 457 (2021-04-18) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE
VP550443 VMARC 04/18/21 13:13:31 * Fix 430/432 regressions
Update VP550443 applies to VSSI installation builds through 5528 Symptom: * Fix 430/432 regressions Problem: Several regressions crept into the VPARS code base during the ShadowDisk merge. They are: - VPUNLD and VPBKUP no longer includes the userid as part of the HDR1 record of the output tape. - VPLOAD and VPREST no longer ignores the userid in the HDR1 record of the input tape. - the file name of the NCONTROL file created by VPUNLD is wrong. - the VPARS database is corrupt after being restored by VPREST. - VPCHKDIR sometimes abends with message: DMSFRR161E Invalid free storage release call - message 026 (issued by the VPCLEAR command) has a spurious trailing C in the second token of the message. Resolution: RVPMSG is updated to correct message 026. VPUNLD is updated to correct the file name on the NCONTROL file. VPUNLD and VPBKUP are updated to again include the userid as part of the data set name in the HDR1 record. VPLOAD and VPREST are updated to again cause the userid to be ignored in the data set name in the HDR1 record. The corrupt database after a VPREST is an old problem where a halfword was mistakenly referenced as a fullword. The VPCHKDIR problem is an old bug not a recent regression. VPCHKDIR was referencing fret'ed storage for a value. It has been updated to release storage in the correct order so there is no longer a reference to fret'ed storage. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 456 (2021-04-07) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBT ASSEMBLE RVPMSG ASSEMBLE VPBKUP ASSEMBLE VPBXBMAP ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VP550442 VMARC 04/18/21 13:12:52 * COPY updates in support of fix 550443
Update VP550442 applies to VSSI installation builds through 5528 Symptom: * COPY updates in support of fix 550443 Problem: Several CMS VPARS utilities have regressions after fixes 430, 432 and 439. Resolution: Update VPARS COPY members in support of fix 550443. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 456 (2021-04-07) Modules: VP55MAC $EXEC RVPSHORT COPY RVPTPHDR COPY VPIOTBK COPY
VS550442 VMARC 04/18/21 13:05:59 * COPY updates in support of fix 550443
Update VS550442 applies to VSSI installation builds through 5528 Symptom: * COPY updates in support of fix 550443 Problem: Several CMS VPARS utilities have regressions after fixes 430, 432 and 439. Resolution: The VSCOMMON parts updated are primarily refactoring changes. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 456 (2021-04-07) Modules: VS55MAC $EXEC VSSUME $REPOS RVSYNTAX COPY VSLPRMBK COPY VSSIMSG COPY VSIMSG MACRO DISKPRT ASSEMBLE DISKZAP ASSEMBLE RVSSTB ASSEMBLE RVSSTP ASSEMBLE VSLABSL ASSEMBLE VSSTRC ASSEMBLE
VT550441 VMARC 03/28/21 15:50:09 * Append updated product file + objects
Update VT550441 applies to VSSI installation builds through 5528 Symptom: * Append updated product file + objects Problem: From time to time, we need to append non-source VTAPE files as part of a propsed fix (i.e., without changing any underlying product code). Resolution: VTMODID COPY created as a dummy COPY file. This file is used to generated dummy PTFs against which non-source objects (e.e., amended PRODUCT files) can be appended. BUILD_Reqd: VSSMMAC Toolmin: 1.0 453 (2021-03-21) Modules: VT55MAC $EXEC VTMODID COPY
VP550441 VMARC 03/28/21 15:50:01 * Append updated product file + objects
Update VP550441 applies to VSSI installation builds through 5528 Symptom: * Append updated product file + objects Problem: From time to time, we need to append non-source VPARS | ShadowDiskZ files as part of a propsed fix (i.e., without changing any underlying product code). Resolution: VPMODID COPY created as a dummy COPY file. This file is used to generated dummy PTFs against which non-source objects (e.e., amended PRODUCT files) can be appended. BUILD_Reqd: VSSMMAC Toolmin: 1.0 453 (2021-03-21) Modules: VP55MAC $EXEC VPMODID COPY
VS550441 VMARC 03/28/21 15:49:57 * Append updated product file + objects
Update VS550441 applies to VSSI installation builds through 5528 Symptom: * Append updated product file + objects Problem: The following modules were missing elements: . DISKPRT . DISKZAP Resolution: Missing elements appended in update 550440; this PTF is used to force assembly and link of the affected parts. BUILD_Reqd: VSSMMAC Toolmin: 1.0 453 (2021-03-21) Modules: VSMODID COPY
VT550440 VMARC 03/25/21 21:06:09 * VTBKUP hangs
Update VT550440 applies to VSSI installation builds through 5528 Symptom: * VTBKUP hangs Problem: VTBKVOL (called by VTBKUP) issues a SSCH. The next interrupt is an attention interrupt with alert and status pending in the status control. VTBKVOL ignores the attention interrupt and continues to wait for an interrupt that indicates the I/O has completed. It is never coming since the I/O was never initiated due to the pending status. As a result VTBKUP processing hangs. This is a very old bug. The code has been like this for decades. Resolution: VTBKVOL is updated to recognize there is status pending, drain the status and re-issue the SSCH. As a bypass, issuing READY against the tape drive will kick start the process and recover from the hang. Additionally, updates to a number of other VTAPE parts with minor pending refactoring are included. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 453 (2021-03-21) Modules: RVTCCW ASSEMBLE RVTCPX ASSEMBLE RVTIOR ASSEMBLE RVTLVL ASSEMBLE RVTMNT ASSEMBLE RVTSUM ASSEMBLE RVTSV5 ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTREST ASSEMBLE VTSTRC ASSEMBLE
VT550439 VMARC 03/25/21 21:05:47 * VTCPYASM updates required after VS550438
Update VT550439 applies to VSSI installation builds through 5528 Symptom: * VTCPYASM updates required after VS550438 Problem: Fix 438 deleted a copy member that VTCPYASM was including resulting in an assembly error. Resolution: Delete copy member from VTCPYASM. Fixes 438 and 439 must be applied concurrently. BUILD_Reqd: *None* Toolmin: 1.0 453 (2021-03-21) Modules: VTCPYASM ASSEMBLE
VP550439 VMARC 03/25/21 21:05:36 * VPBXLTP updates required after VS550438
Update VP550439 applies to VSSI installation builds through 5528 Symptom: * VPBXLTP updates required after VS550438 Problem: Fix 550438 updated the common VSIOPARM to require the INTBLOK also be copied into any part including it. VPBXLTP did not include INTBLOK resulting in an assembly error. Resolution: Since 3390 is the only supported DASD type and VPBXLTP only referenced VSIOPARM to determine the DASD type, references to VSIOPARM has been removed DASD type now defaults to 3390. Additionally, updates to a number of other VPARS parts with minor pending refactoring are included. Fixes 438 and 439 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 453 (2021-03-21) Modules: RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCPX ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBY ASSEMBLE RVPEXT ASSEMBLE RVPIFC ASSEMBLE RVPLVL ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPTMR ASSEMBLE VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXLTP ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPCPYASM ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VT550438 VMARC 03/25/21 21:04:39 * HCPIST update no longer fits after VM66173
Update VT550438 applies to VSSI installation builds through 5528 Symptom: * HCPIST update no longer fits after VM66173 Problem: Our update to HCPIST no longer fits after the PTF for VM66173 is applied. Resolution: Revise our HCPIST update so it fits whether or not VM66173's PTF is applied. Additionally, updates to a number of other parts with minor pending refactoring are included. Fixes 438 and 439 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 453 (2021-03-21) Modules: VT55MAC $EXEC RVTEQUAT COPY VTACTBK COPY VTSTTRC COPY VTSTLABL MACRO
VP550438 VMARC 03/25/21 20:54:51 * HCPIST update no longer fits after VM66173
Update VP550438 applies to VSSI installation builds through 5528 Symptom: * HCPIST update no longer fits after VM66173 Problem: Our update to HCPIST no longer fits after the PTF for VM66173 is applied. Resolution: Revise our HCPIST update so it fits whether or not VM66173's PTF is applied. Additionally, updates to a number of other parts with minor pending refactoring are included. Fixes 438 and 439 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 453 (2021-03-21) Modules: VP55MAC $EXEC VPCTLBK COPY VPINDXBK COPY VPIOTBK COPY VP1WRKBK COPY
VS550438 VMARC 03/25/21 20:32:42 * HCPIST update no longer fits after VM66173
Update VS550438 applies to VSSI installation builds through 5528 Symptom: * HCPIST update no longer fits after VM66173 Problem: Our update to HCPIST no longer fits after the PTF for VM66173 is applied. Resolution: Revise our HCPIST update so it fits whether or not VM66173's PTF is applied. Additionally, updates to a number of other parts with minor pending refactoring are included. Fixes 438 and 439 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 453 (2021-03-21) Modules: VSIOPARM COPY VSQIOBK COPY VSSICBID COPY VSWCCWXA COPY RVSMDLAT MACRO VS6ANCH MACRO DISKPRT ASSEMBLE DISKZAP ASSEMBLE RVSCBI ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSLVL ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSSUBR02 ASSEMBLE
VT550437 VMARC 02/19/21 10:20:52 * VTBKUP may fail after fix 550418
Update VT550437 applies to VSSI installation builds through 5528 Symptom: * VTBKUP may fail after fix 550418 Problem: After fix 550418 VTBKUP will receive I/O errors while reading library minidisks. Resolution: VTBKVOL is updated to properly initialize CCWs. A number of other VTAPE parts with pending refactoring are also updated. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 448 (2020-01-25) Modules: VTSENT MACRO VTSRET MACRO VTSTLABL MACRO RVTCPX ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT5 ASSEMBLE VTSCR1 ASSEMBLE VTSTRC ASSEMBLE
VT550436 VMARC 01/25/21 18:12:01 * User's maximum volume limit wrong
Update VT550436 applies to VSSI installation builds through 5528 Symptom: * User's maximum volume limit wrong Problem: User issues VTMOUNT 181 SCRATCH and receives message: RVTSV3057E Maximum volumes in VTAPE library system for user xxxx In fact the user not only isn't at their limit, they have no tapes at all in the library! Additionally, the maximum volume count shown on VTQUERY DEFAULTS is wrong. Resolution: Fix 550431 warned that once it was applied volume limits would be properly enforced, so naturally it was initially thought this was due to fix 431, but this is unrelated to fix 431. This is very old bug, at least 20 years. The reporting customer has multiple Volume_Class records in their VTSYSTEM DEFAULTS file, eg: VOLUME_CLASS AB 30 VOLUME_CLASS EG 20 VOLUME_CLASS TV 50 If there are multiple Volume_Class records AND the user issuing the mount has multiple privilge classes such that they match more than a single Volume_Class record, then the value returned is wrong (it is 0, rather than the maximum number of volumes they are entitled to). RVTSV5CS is updated to properly determine the maximum value from a group. As well a number of other VTAPE parts are updated with pending minor refactoring. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 448 (2020-01-25) Modules: RVTCON ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTST2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV5 ASSEMBLE RVTTMR ASSEMBLE VTBKUP ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE VTRPT2 ASSEMBLE VTRPT3 ASSEMBLE VTRPT4 ASSEMBLE VTRPT5 ASSEMBLE VTRPT6 ASSEMBLE VTSCR1 ASSEMBLE
VS550436 VMARC 01/25/21 18:11:46 * License code cleanup
Update VS550436 applies to VSSI installation builds through 5528 Symptom: * License code cleanup Problem: Several code paths in RVSSTL have deprecated code blocks and/or variables. Resolution: Redundant code paths removed. BUILD_Reqd: VSSICP Toolmin: 1.0 448 (2020-01-25) Modules: VSMODID COPY RVSSTL LAS55436
VT550435 VMARC 01/25/21 18:14:47 * Support upcoming HCPTRANS changes
Update VT550435 applies to VSSI installation builds through 5528 Symptom: * Support upcoming HCPTRANS changes Problem: IBM is changing the supported actions on the LOCK= operand of HCPTRANS. Resolution: All affected HCPTRANS are updated to expand using the new actions if assembled on z/VM V7. Assemblies on zVM V6 are unchanged. This update must be applied prior to applying VM66173 when it becomes available. BUILD_Reqd: VSSICP Toolmin: 1.0 448 (2020-01-25) Modules: RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTIOR ASSEMBLE
VP550435 VMARC 01/25/21 18:14:39 * Support upcoming HCPTRANS changes
Update VP550435 applies to VSSI installation builds through 5528 Symptom: * Support upcoming HCPTRANS changes Problem: IBM is changing the supported actions on the LOCK= operand of HCPTRANS. Resolution: All affected HCPTRANS are updated to expand using the new actions if assembled on z/VM V7. Assemblies on zVM V6 are unchanged. This update must be applied prior to applying VM66173 when it becomes available. BUILD_Reqd: VSSICP Toolmin: 1.0 448 (2020-01-25) Modules: RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPIOR ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE
VS550435 VMARC 01/25/21 18:14:25 * Support upcoming HCPTRANS changes
Update VS550435 applies to VSSI installation builds through 5528 Symptom: * Support upcoming HCPTRANS changes Problem: IBM is changing the supported actions on the LOCK= operand of HCPTRANS. Resolution: All affected HCPTRANS are updated to expand using the new actions if assembled on z/VM V7. Assemblies on zVM V6 are unchanged. This update must be applied prior to applying VM66173 when it becomes available. Additionally the DISKZAP utility has had refactoring work and a NOPROMPT option added. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 448 (2020-01-25) Modules: DISKZAP ASSEMBLE RVSIOS ASSEMBLE RVSUTL ASSEMBLE
VS550434 VMARC 12/19/20 15:41:29 * Deprecated module cleanup
Update VS550434 applies to VSSI installation builds through 5528 Symptom: * Deprecated module cleanup Problem: Deprecated ShadowDisk modules may reside on disk after the VPARS-ShadowDisk code merge. Resolution: Clean up deprecated entries. BUILD_Reqd: VSSMMAC Toolmin: 1.0 446 (2020-12-18) Modules: VSMODID COPY
VT550433 VMARC 01/06/21 13:59:21 * Annual resequence VTAPE assembler parts
Update VT550433 applies to VSSI installation builds through 5528 Symptom: * Annual resequence VTAPE assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVTCCW, RVTCMD, RVTLD2, RVTMET, RVTMNT, RVTOPC, RVTQLB, RVTQY2, RVTREW, RVTST1, RVTST2, RVTSUM, RVTSV3 and RVTSV4 BUILD_Reqd: VSSICP Toolmin: 1.0 447 (2020-12-28) Modules: RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOPC ASSEMBLE RVTQLB ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSUM ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE
VP550433 VMARC 01/06/21 13:58:56 * Annual resequence VPARS assembler parts
Update VP550433 applies to VSSI installation builds through 5528 Symptom: * Annual resequence VPARS assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVPCON, RVPCSP, RVPDBM, RVPDBT, RVPOPS, RVPSV2 and RVPSV3 are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 447 (2020-12-28) Modules: RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPOPS ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE
VP550432 VMARC 12/13/20 20:53:40 * csp007 soft abends possible after VP550419
Update VP550432 applies to VSSI installation builds through 5528 Symptom: * csp007 soft abends possible after VP550419 Problem: It was assumed that a channel program would only contain a single Perform Subsystem Function Read Subsystem Data pair. In some cases a channel program will consist of multiple PSF/RSD pairs. Resolution: RVPCSP and RVPDBS are updated to support multiple command chained PSF/RSD pairs. Additionally the CMS based VPARS utilities have been updated to be bimodal and support a ShadowDisk environment. This completes the ShadowDisk merge work started with VP550430. Fix level 550432 is our minimum recommended level for customers migrating to z/VM 7.2.0. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 442 (2020-12-08) Modules: RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPSHU ASSEMBLE RVPSV2 ASSEMBLE VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VT550431 VMARC 11/27/20 16:11:34 * VTAPE maximum volume limit not properly enforced
Update VT550431 applies to VSSI installation builds through 5528 Symptom: * VTAPE maximum volume limit not properly enforced Problem: If an installation has more than one library opened for output, each user's volume count only includes the volumes in the last library opened rather than (the intended) total volumes across all libraries. Often this results in a user's volume count being less than the number of volumes they own and, as a result, the user is allowed to create more tapes than their limit permits. For example: vtq defaults user xyz XYZ Defaults Libr Size-Max Keep-Max Bufs-Max Maxvols B 10 200 3 120 20 50 25 25 volumes in use by XYZ Max=25 Ready; T=0.01/0.01 04:33:11 vtq lib owner xyz count 138 tapes selected from library B Ready; T=0.01/0.01 04:36:33 User XYZ had zero tapes in the last library opened for output. Thus they were allowed to create 25 tapes in library B despite already exceeding their limit by a large number of volumes. This is a very old bug, going back probably 25 or 30 years. Resolution: Formerly, code related to user volume counts/limits was spread across several disparate parts with logic duplicated in some areas. This has all been gathered together and redesigned into a number of new entry points in RVTSV4. Duplicated code is eliminated. Overloaded interfaces are eliminated. A user's volume limit is now correctly enforced. NOTE WELL - installations should be aware that once this fix is applied, users that were operating over limit with impunity will now be appropriately limited. Some users' limits may need to be raised to allow them to operate as they did before this fix was applied. BUILD_Reqd: VSSICP Toolmin: 1.0 440 (2020-10-22) Modules: RVTEQUAT COPY RVTSALIB COPY VTEXTBK COPY VTLSTBK COPY VTSCTLBK COPY RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTST1 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE
VT550430 VMARC 12/11/20 09:21:02 * CP exit elimination; phase 2
Update VT550430 applies to VSSI installation builds through 5528 Symptom: * CP exit elimination; phase 2 Problem: The following issues are addressed by this update: - volumes formatted by VTFMT not valid after VT550428 - indirect calls replace exits to invoke VSSI code from HCPxxx parts Resolution: VTFMT is updated to address the format regression. Any needed changes to support indirect calls rather than exits have been done (indirect call entry points must be SAVE=DYNAMIC for instance). Fixes 429 and 430 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 444 (2020-12-11) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCFG ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTCPX ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTLGR ASSEMBLE RVTLVL ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTPER 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 RVTSYN ASSEMBLE RVTTBL ASSEMBLE RVTTMR ASSEMBLE VTFMT ASSEMBLE
VP550430 VMARC 12/11/20 09:21:09 * CP exit elimination; phase 2
Update VP550430 applies to VSSI installation builds through 5528 Symptom: * CP exit elimination; phase 2 Problem: The following issues are addressed by this update: - various abends if a bit map is used with trackset mode I/Os after fix VP550395 - PRG019 in RVPCSP after fix VP550424 - csp007 soft abend on some I/Os after fix VP550424 - LCK001 on read of >4K from VPARS database - indirect calls replace exits to invoke VSSI code from HCPxxx parts - merge ShadowDisk and VPARS code base Resolution: RVPCSP is updated to address the three regressions noted in the above Problem: section. The LCK001 was a very old problem. At least 25 years. A write of >4K would be correctly added to the VPARS database but an attempt to read it back would fail when trying to read the second page of data. RVPDBM is updated to re-acquire the DBQ lock prior to starting a second (or subsequent) read. The entire VPARS code base has been updated to include VSSIOPTS (new in fix 550423) and have had module size verification added. Any needed changes to support indirect calls rather than exits have been done (indirect call entry points must be SAVE=DYNAMIC for instance). Fixes 429 and 430 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 444 (2020-12-11) Modules: RVPADD ASSEMBLE RVPBUF ASSEMBLE RVPCCL ASSEMBLE RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCHN ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCPX ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPDBY ASSEMBLE RVPEXT ASSEMBLE RVPFCX ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPKEY ASSEMBLE RVPLGR ASSEMBLE RVPLVL ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPER 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 RVPTMR ASSEMBLE VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VT550429 VMARC 12/11/20 09:20:55 * Macro/Copy updates for 550430
Update VT550429 applies to VSSI installation builds through 5528 Symptom: * Macro/Copy updates for 550430 Problem: Macro/Copy updates for VT550430 Resolution: Macro/Copy updates for VT550430 Fixes 429 and 430 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 444 (2020-12-11) Modules: RVTCMPBK COPY RVTEQUAT COPY VTACTBK COPY VTSCTLBK COPY RVTMDLAT MACRO VT5ANCH MACRO VT6ANCH MACRO VTCPYASM ASSEMBLE
VP550429 VMARC 10/21/21 12:37:18 * Macro/Copy updates for 550430
Update VP550429 applies to VSSI installation builds through 5528 Symptom: * Macro/Copy updates for 550430 Problem: Macro/Copy updates for VP550430 Resolution: Macro/Copy updates for VP550430 Fixes 429 and 430 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 444 (2020-12-11) Modules: RVPCCTBK COPY RVPCFGBK COPY RVPCMPBK COPY RVPDEVBK COPY RVPEQUAT COPY RVPFMTBK COPY RVPSYSBK COPY VPCHCCW COPY VPCTLBK COPY VPOPENBK COPY VPSETBK COPY VPTCCTBK COPY VPTPFKEY COPY VP1WRKBK COPY RVPMDLAT MACRO VPCPYASM ASSEMBLE
VS550429 VMARC 12/11/20 09:20:40 * Macro/Copy updates for 550430
Update VS550429 applies to VSSI installation builds through 5528 Symptom: * Macro/Copy updates for 550430 Problem: Macro/Copy updates for VS550430 Resolution: Exits have been replaced with indirect calls in HCPxxx parts. RVSxxx parts and macros and copy members are updated to support fix VS550430. Fixes 429 and 430 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 444 (2020-12-11) Modules: VS55MAC $EXEC VSSUME $REPOS RVSCMPBK COPY RVSEQUAT COPY RVSYNTAX COPY VSMODID COPY VSSICBID COPY VSSICFG COPY VSSIEQU COPY VSSIIOC COPY VSSIIOT COPY VSSILVL COPY VSSITRAC COPY RVSMDLAT MACRO VSCMDCHK MACRO VSCPSTOR MACRO VSCPXGT MACRO VSIABEND MACRO VSICALL MACRO VSIGOTO MACRO VSILTICL MACRO VSILX MACRO VSIPROLG MACRO VSMSGHE MACRO VS5ANCH MACRO VS6ANCH MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOR ASSEMBLE RVSIOS ASSEMBLE RVSLCK ASSEMBLE RVSLVL ASSEMBLE RVSMSG ASSEMBLE RVSPER ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE VSDBSCAN ASSEMBLE VSSUBR02 ASSEMBLE RVSSTL LAS55429
VT550428 VMARC 07/29/20 14:30:00 * VTAPE SCRATCH performance improvements
Update VT550428 applies to VSSI installation builds through 5528 Symptom: * VTAPE SCRATCH performance improvements Problem: Fix VT550416 increased the allowable size for a VTAPE. As so often happens, once one bottleneck is removed another appears. It turns out scratching VTAPEs was very inefficient and scratching multiple large tapes could monopolize the system for several minutes. This was exacerbated by the fact that the scratch processing had to run on the master processor. Resolution: RVTSV1SC has been updated to eliminate, as much as possible, divide instructions. RVTSV5CB has been updated to eliminate translate and test instructions. Both D and TRT are very expensive. As well, use of the EXecute instruction in both modules is minimized. Our testing shows these changes improved scratch performance by more than an order of magnitude. Additionally the VTAPE code base has been converted to use the common VSIOCBK channel program work area. Text decks compared before and after this change. VPARS was switched via fix VP550415. The goal is to eventually have a common database I/O backend used by both VPARS and VTAPE rather than each have their own duplicated code. Lastly a number of other parts were updated with refactoring and preparatory changes for future updates. Fixes 427 and 428 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 433 (2020-06-05) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCFG 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 RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE RVTSYN ASSEMBLE RVTTBL ASSEMBLE VTBKUP ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTRPT1 ASSEMBLE
VT550427 VMARC 07/29/20 02:05:00 * COPY updates for VT550428
Update VT550427 applies to VSSI installation builds through 5528 Symptom: * COPY updates for VT550428 Problem: VTSCRATCH has poor performance and hogs the master processor. Resolution: COMMON, COPY and MACRO updates in support of fix VT550428. Fixes 427 and 428 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 433 (2020-06-05) Modules: RVTEQUAT COPY RVTEXCBK COPY RVTSALIB COPY RVTSYSBK COPY VTACTBK COPY VTBMAPBK COPY VTCLBLBK COPY VTENTBK COPY VTFDIRBK COPY VTFENTBK COPY VTLSTBK COPY VTMNTBK COPY VTQRYBK COPY VTRELBK COPY VTSCTLBK COPY VTVDSCBK COPY VTXRELBK COPY RVTSCFBK MACRO VT6ANCH MACRO
VS550427 VMARC 07/29/20 01:18:11 * COPY updates for VT550428
Update VS550427 applies to VSSI installation builds through 5528 Symptom: * COPY updates for VT550428 Problem: VTSCRATCH has poor performance and hogs the master processor. Resolution: COMMON, COPY and MACRO updates in support of fix VT550428. Fixes 427 and 428 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 433 (2020-06-05) Modules: VSMODID COPY VSSIEQU COPY VSCPXIT MACRO RVSUTL ASSEMBLE RVSVTY ASSEMBLE RVSSTL LAS55427
VS550426 VMARC 05/31/20 17:19:58 * Placeholder update - start 5528
Update VS550426 applies to VSSI installation builds through 5528 Symptom: * Placeholder update - start 5528 Problem: Dummy update to mark the start of Build 5528. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 431 (2019-05-30) Modules: VSMODID COPY
PTFs below apply to Packages at 5526 and lower
VS550425 VMARC 05/31/20 17:15:38 * Placeholder update - end 5526
Update VS550425 applies to VSSI installation builds through 5526 Symptom: * Placeholder update - end 5526 Problem: Dummy update to mark the end of Build 5526. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 431 (2019-05-30) Modules: VSMODID COPY
VT550424 VMARC 05/19/20 12:41:03 * Nucleus TXTLIB mismatch results in 9026 wait state
Update VT550424 applies to VSSI installation builds through 5526 Symptom: * Nucleus TXTLIB mismatch results in 9026 wait state Problem: Typically part of the VSSI code base is built into the nucleus and part of it is CPXLOADed by statements in the SYSTEM CONFIG file. Obviously there is an opportunity for the two parts to get out of synch (eg: attempting to CPXLOAD code assembled on 6.4 onto a 7.1 system). Our CPXLOAD control routine verifies that the nucleus resident code matches the CPXLOADed code and if there is any discrepancy it ABENDs. However, since we are still processing the SYSTEM CONFIG file, the SPOOLing environment is not yet active and thus an ABEND dump can not be written. An ABEND this early in system initialization is turned into a 9026 wait state and a stand along dump is required to diagnose what the problem is. Taking a stand alone dump is an onerous task for an installation. It should be easier to diagnose a simple a configuration error. Resolution: All ABENDs that could occur during system initialization have been changed to issue an error message and load a wait state by calling HCPOPRDM. This should allow the installation to diagnose the problem without resorting to a stand alone dump. For the VTAPE subsystem, ABENDs in RVTCPX have been changed to wait states. Additionally all VTAPE parts have been updated to include VSSIOPTS (new in fix 550343) and have module size validation included. In most cases text decks compare before and after. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 429 (2019-03-30) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCFG ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTCPX ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTLGR 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 RVTSYN ASSEMBLE RVTTBL ASSEMBLE RVTTMR ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE
VP550424 VMARC 08/24/20 02:46:26 * Nucleus TXTLIB mismatch results in 9026 wait state
Update VP550424 applies to VSSI installation builds through 5526 Symptom: * Nucleus TXTLIB mismatch results in 9026 wait state Problem: Typically part of the VSSI code base is built into the nucleus and part of it is CPXLOADed by statements in the SYSTEM CONFIG file. Obviously there is an opportunity for the two parts to get out of synch (eg: attempting to CPXLOAD code assembled on 6.4 onto a 7.1 system). Our CPXLOAD control routine verifies that the nucleus resident code matches the CPXLOADed code and if there is any discrepancy it ABENDs. However, since we are still processing the SYSTEM CONFIG file, the SPOOLing environment is not yet active and thus an ABEND dump can not be written. An ABEND this early in system initialization is turned into a 9026 wait state and a stand along dump is required to diagnose what the problem is. Taking a stand alone dump is an onerous task for an installation. It should be easier to diagnose a simple configuration error. Resolution: All ABENDs that could occur during system initialization have been changed to issue an error message and load a wait state by calling HCPOPRDM. This should allow the installation to diagnose the problem without resorting to a stand alone dump. For the VPARS subsystem, ABENDs in RVPCPX have been changed to wait states. Two other VPARS problems are being addressed by this fix. First, I/O to PAV or HyperPAV base devices is now tolerated. Prior to fix VP550395 these I/Os were tolerated. VP550395 enhanced the validation of the Prefix CCW and resulted in those I/Os being command rejected. Some installations have their base systems backed on HyperPAV capable DASD (although HyperPAV was not in use). RVPCCW and RVPCSP are updated to again tolerate that environment. I/O to an alias device will continue to be command rejected. Second, if the base system disks are defined as DEVNO minidisks, in an SSI environment with users of the base system spread across multiple systems then the re-link of the disks by VPOPEN fails. VPOPEN was specifying the start and end extents in the link block (LKBK) it was populating, but for a DEVNO minidisk SSI's shared disk support requires the DEVNO flag to be set as well. RVPSV3 is updated to set the LKXDVFP flag. Finally a number of other VPARS parts have had minor refactoring. BUILD_Reqd: VSSICP Toolmin: 1.0 437 (2020-08-23) Modules: RVPCCW ASSEMBLE RVPCPX ASSEMBLE RVPCSP ASSEMBLE RVPMSG ASSEMBLE RVPSV3 ASSEMBLE
VS550424 VMARC 05/19/20 12:39:37 * Nucleus TXTLIB mismatch results in 9026 wait state
Update VS550424 applies to VSSI installation builds through 5526 Symptom: * Nucleus TXTLIB mismatch results in 9026 wait state Problem: Typically part of the VSSI code base is built into the nucleus and part of it is CPXLOADed by statements in the SYSTEM CONFIG file. Obviously there is an opportunity for the two parts to get out of synch (eg: attempting to CPXLOAD code assembled on 6.4 onto a 7.1 system). Our CPXLOAD control routine verifies that the nucleus resident code matches the CPXLOADed code and if there is any discrepancy it ABENDs. However, since we are still processing the SYSTEM CONFIG file, the SPOOLing environment is not yet active and thus an ABEND dump can not be written. An ABEND this early in system initialization is turned into a 9026 wait state and a stand along dump is required to diagnose what the problem is. Taking a stand alone dump is an onerous task for an installation. It should be easier to diagnose a simple a configuration error. Resolution: All ABENDs that could occur during system initialization have been changed to issue an error message and load a wait state by calling HCPOPRDM. This should allow the customer to diagnose the problem without resorting to a stand alone dump. For the VSCOMMON subsystem, ABENDs in RVSCPX and RVPPRC have been changed to wait states. Additionally a number of other VSCOMMON parts have had minor refactoring. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 429 (2019-03-30) Modules: RVSCBI ASSEMBLE RVSCPX ASSEMBLE RVSMSG ASSEMBLE RVSPRC ASSEMBLE VSDBSCAN ASSEMBLE
VS550423 VMARC 05/08/20 09:07:57 * Add new VSSIOPTS COPY member
Update VS550423 applies to VSSI installation builds through 5526 Symptom: * Add new VSSIOPTS COPY member Problem: Create new VSSIOPTS COPY member to define set symbols for VSSI configuration values (which components an installation has licensed and whether they are CPXLOADed or built into the nucleus). Resolution: Formerly these values were defined in VSOPTNS MACRO. That macro also defines an EQUate value which starts an unnamed section. Upcoming changes will mean our text decks can not start with an unnamed section and thus the values are moved out of VSOPTNS MACRO and into VSSIOPTS COPY. Now the first section will be the one defined by the VISPROLG macro that starts each module. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: VS55MAC $EXEC VSMODID COPY VSCPXGT MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOR ASSEMBLE RVSIOS ASSEMBLE RVSLCK ASSEMBLE RVSMSG ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTF ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE RVSSTL LAS55423
VT550422 VMARC 05/06/20 14:05:03 * Annual resequence assembler parts
Update VT550422 applies to VSSI installation builds through 5526 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVTDBM, RVTOCS, RVTSV2 and RVTSCR are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: RVTDBM ASSEMBLE RVTOCS ASSEMBLE RVTSCR ASSEMBLE RVTSV2 ASSEMBLE
VP550422 VMARC 05/06/20 14:04:53 * Annual resequence assembler parts
Update VP550422 applies to VSSI installation builds through 5526 Symptom: * Annual resequence assembler 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 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. The sequence number range is 00000000-99999999 and to minimize future resequences we attempt to pick a new gap that best exploits the full range. This year RVPCCW, RVPDBS and RVPFCX are resequenced. BUILD_Reqd: VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: RVPCCW ASSEMBLE RVPDBS ASSEMBLE RVPFCX ASSEMBLE
VT550421 VMARC 05/06/20 14:15:03 * Code refactoring tasks
Update VT550421 applies to VSSI installation builds through 5526 Symptom: * Code refactoring tasks Problem: For VTAPE there is no functional change. Resolution: CPXLoad related code is moved from RVSSTB to RVTCPX, the VTAPE-related syntax definitions are moved from RVSVTY to RVTSYN, the LGR related error handling is moved from RVTRST to RVTLGR, and RVTCFG is gathering together the configration file handling from numerous parts. Fixes 550420 and 550421 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: RVTCFG ASSEMBLE RVTCPX ASSEMBLE RVTLGR ASSEMBLE RVTSYN ASSEMBLE
VP550421 VMARC 05/06/20 14:14:51 * Code refactoring tasks
Update VP550421 applies to VSSI installation builds through 5526 Symptom: * Code refactoring tasks Problem: For VPARS there is no functional change. Resolution: CPXLoad related code is moved from RVSSTB to RVPCPX, the database synch code is moved from RVPSYN to RVPDBY, and LGR related error handling is moved from RVPRST to RVPLGR. Fixes 550420 and 550421 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: RVPCPX ASSEMBLE RVPDBY ASSEMBLE RVPLGR ASSEMBLE
VT550420 VMARC 05/06/20 14:04:16 * CPSYNTAX flags VSSI statements after VS550404
Update VT550420 applies to VSSI installation builds through 5526 Symptom: * CPSYNTAX flags VSSI statements after VS550404 Problem: For VTAPE there is no functional change. Resolution: CPXLoad related code is moved from RVSSTB to RVTCPX and the syntax tree for VTAPE config file statements is moved from RVSVTY to RVTSYN. Stub routine RVTCFG is added. It will be expanded in the future with VTAPE config file processing logic. These new parts are shipped via fix 550421. Fixes 550420 and 550421 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 429 (2019-03-30) Modules: RVTCMPBK COPY RVTEQUAT COPY VTACTBK COPY VTXRELBK COPY RVTMDLAT MACRO
VP550420 VMARC 05/06/20 13:49:41 * CPSYNTAX flags VSSI statements after VS550404
Update VP550420 applies to VSSI installation builds through 5526 Symptom: * CPSYNTAX flags VSSI statements after VS550404 Problem: For VPARS there is no functional change. Resolution: CPXLoad related code is moved from RVSSTB to RVPCPX and the database synch code is moved from RVPSYN to RVPDBY. These new parts are shipped via fix 550421. Finally, COPY members RVPDEVBK and VPCTLBK are resequenced. Fixes 550420 and 550421 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 429 (2019-03-30) Modules: RVPCFGBK COPY RVPCMPBK COPY RVPDEVBK COPY RVPEQUAT COPY VPCTLBK COPY RVPMDLAT MACRO RVPSCFBK MACRO
VS550420 VMARC 05/06/20 13:30:34 * CPSYNTAX flags VSSI statements after VS550404
Update VS550420 applies to VSSI installation builds through 5526 Symptom: * CPSYNTAX flags VSSI statements after VS550404 Problem: It looked like our update to HCPZSC was dead code so fix 55404 removed it. While, in the normal course of events it was dead code, there was one specific instance where it was being used. That was when HCPZSC was included in the CMS module CPSYNCHK that is used by CPSYNTAX. Without our statements defined in HCPZSC, CPSYNTAX no longer recognizes our statements and flags them. Resolution: HCPZSC has been updated to (re)include the syntax tree entries for our SYSTEM CONFIG file statements (and had commentary added to explain its reason before being there). Additionally the processing of VSSI config file statements has been overhauled. Three new modules have been added. RVSSYN contains the branch of the syntax tree for VSSI SYSTEM CONFIG statements, RVSPRC contains the post processing logic for those statements. Formerly these two were in module RVSSTN. Lastly all CPXLOAD related code has been moved from RVSSTB to RVSCPX and VSMODID is resequenced. Fixes 550420 and 550421 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 429 (2019-03-30) Modules: VS55MAC $EXEC RVSCMPBK COPY RVSEQUAT COPY RVSYNTAX COPY VSLCKXST COPY VSMODID COPY VSSICBID COPY VSSICFG COPY VSSIEQU COPY VSSIIOC COPY VSSIIOT COPY RVSMDLAT MACRO RVSMDLAX MACRO VSCPXGT MACRO VSMSGH MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSCPX ASSEMBLE RVSIOR ASSEMBLE RVSIOS ASSEMBLE RVSLCK ASSEMBLE RVSMSG ASSEMBLE RVSPRC ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTF ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSSYN ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE RVSSTL LAS55420
VP550419 VMARC 03/28/20 11:16:09 * Block zHPF indication for base volumes
Update VP550419 applies to VSSI installation builds through 5526 Symptom: * Block zHPF indication for base volumes Problem: VPARS does not (yet) support transport mode channel programs. Now that VM's support for guest use of zHPF devices has matured TPF development would like to start using transport mode channel programs when running as a guest of VM. Resolution: TPF determines whether or not a device supports transport mode channel programs by issuing a (command mode) channel program consisting of a Perform Subsystem Function with a Read Subsystem Data chained to it. In the past VPARS has ignored these two CCWs. We now intercept these CCWs and update the response to indicate the device does not support transport mode channel programs. This allows TPF to use transport mode channel programs without having to make a special case for a VPARS environment. Additionally three new (stub) parts are added. RVPCHN, RVPFCX and RVPKEY. They will be developed further in the future. A number of other parts have had minor refactoring. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCHN ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPFCX ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPKEY ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE
VT550418 VMARC 03/03/20 12:55:03 * Macro/Copy updates for 550419
Update VT550418 applies to VSSI installation builds through 5526 Symptom: * Macro/Copy updates for 550419 Problem: Macro/Copy updates for 550419 Resolution: For the VTAPE part this is a refactoring change only. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 428 (2019-10-24) Modules: VTSETWK COPY
VP550418 VMARC 03/03/20 12:52:40 * Macro/Copy updates for 550419
Update VP550418 applies to VSSI installation builds through 5526 Symptom: * Macro/Copy updates for 550419 Problem: Macro/Copy updates for 550419 Resolution: For VPARS two new COPY members are defined. RVPPSFBK COPY maps the plist for Perform Subsystem Function and RVPRSDBK COPY maps the reply structure for Read Subsystem Data. RVPMDLAT has been updated with three new parts being added by 419. RVPCHN, RVPFCX and RVPKEY. Additionally RVPSV3 is moved to the MP section of the load list from the master only section. Finally, a number of other parts have had refactoring changes. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 428 (2019-10-24) Modules: VP55MAC $EXEC RVPEQUAT COPY RVPPSFBK COPY RVPRSDBK COPY VPCHCCW COPY VPMDSKBK COPY VPOPENBK COPY VPTCCTBK COPY VP1WRKBK COPY RVPMDLAT MACRO
VS550418 VMARC 03/03/20 12:31:10 * Macro/Copy updates for 550419
Update VS550418 applies to VSSI installation builds through 5526 Symptom: * Macro/Copy updates for 550419 Problem: Macro/Copy updates for 550419 Resolution: For the VSCOMMON parts these are refactoring changes only. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 428 (2019-10-24) Modules: VSICCWS COPY VSMODID COPY VSCPXCL MACRO VSLCKOP MACRO VSMSGHE MACRO VSSRV MACRO RVSSTL LAS55418
VP550417 VMARC 02/17/20 13:37:11 * HTT001 during write to CCHH of 0000 0000
Update VP550417 applies to VSSI installation builds through 5526 Symptom: * HTT001 during write to CCHH of 0000 0000 Problem: Two problems are being addressed by this fix: - infinite loop on the master processor if a user has an FFFF device and issues VPCLOSE - HTT001 during write to CCHH of 0000 0000 Resolution: RVPSV3 is updated to properly handle an FFFF disk. This bug was introduced by fix VP550392. The HTT001 looks to be due to corruption on a VPARS database disk. We could trivially avoid the abend by having RVPDBTBS return CC2 when an entry is not found in the index page being searched. RVPDBMVR is updated to check for CC2 being returned and will issue a command reject back to the guest's I/O rather than abend. A number of other parts that were studied while researching the above have had minor refactoring performed (eg: clarifying comments added, &.). BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPCLR ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPOPS ASSEMBLE RVPSV3 ASSEMBLE
VT550416 VMARC 01/30/20 09:14:47 * Increase maximum tape size
Update VT550416 applies to VSSI installation builds through 5526 Symptom: * Increase maximum tape size Problem: For decades the maximum VTAPE size has been 9999 megabytes. That is an arbitrary and archaic limit that should be raised given that VTAPE libraries contain 3390 model 54 minidisks. Resolution: The limit is increased to 65535 megabytes. This is larger than a single tape can be on a model 54 library minidisk. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVTCMD ASSEMBLE RVTMET ASSEMBLE RVTMSG ASSEMBLE RVTPRC ASSEMBLE RVTQY2 ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSV3 ASSEMBLE
VP550416 VMARC 01/30/20 09:14:38 * Increase maximum tape size
Update VP550416 applies to VSSI installation builds through 5526 Symptom: * Increase maximum tape size Problem: For decades the maximum VTAPE size has been 9999 megabytes. That is an arbitrary and archaic limit that should be raised given that VTAPE libraries contain 3390 model 54 minidisks. Resolution: For VPARS this is a housekeeping change only. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPIOR ASSEMBLE
VS550416 VMARC 01/30/20 09:14:32 * Increase maximum tape size
Update VS550416 applies to VSSI installation builds through 5526 Symptom: * Increase maximum tape size Problem: For decades the maximum VTAPE size has been 9999 megabytes. That is an arbitrary and archaic limit that should be raised given that VTAPE libraries contain 3390 model 54 minidisks. Resolution: The limit is increased to 65535 megabytes. This is larger than a single tape can be on a model 54 library minidisk. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVSVTY ASSEMBLE
VP550415 VMARC 11/19/19 11:56:52 * Message RVPSV1029W issued inappropriately
Update VP550415 applies to VSSI installation builds through 5526 Symptom: * Message RVPSV1029W issued inappropriately Problem: Two message related issues are being addressed: - RVPSV1029W is sometimes issued when it should not be and also sometimes not issued when it should be - VPQUERY DEFAULTS should have blank lines as part of its output, but instead there is message text from an unrelated message Resolution: RVPDBM, RVPMSG and RVPQY2 are updated to correct VPQUERY DEFAULT's missing blank line(s). This bug was introduced by fix 550008. RVPSV1 is updated to correct the message 029 issue. This bug was introduced by fix 550392. RVPCSP, RVPIOR, RVPOPN, RVPSV1, RVPSV2 are updated to convert to the common VSIOCBK channel program work area. Text decks compare before and after this change. Additionally, RVPCFG, RVPCQY and RVPPRC have had minor refactoring performed. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPCFG ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPIOR ASSEMBLE RVPMSG ASSEMBLE RVPOPN ASSEMBLE RVPPRC ASSEMBLE RVPQY2 ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE
VT550414 VMARC 11/15/19 12:07:14 * PRG001 on VTQUERY RESTRICTED or DEFAULTS
Update VT550414 applies to VSSI installation builds through 5526 Symptom: * PRG001 on VTQUERY RESTRICTED or DEFAULTS Problem: Customer upgrade to 7.1.0 and our fix level 403. After issuing VTQ DEF USER the system crashed with a PRG001 abend in module RVTQY2. Resolution: Fix VT550387 added two block HCPASERTs to RVTQY2. One to entry point RVTQY2DF, the other to entry point RVTQY2RS. Both HCPASERT blocks contained a coding error. The HCPASERTs have been corrected. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVTQY2 ASSEMBLE RVTTMR ASSEMBLE
VP550413 VMARC 11/12/19 13:20:27 * Message RVSCFG011E after fix 409
Update VP550413 applies to VSSI installation builds through 5526 Symptom: * Message RVSCFG011E after fix 409 Problem: Customer has local mods to VPARS and after applying the latest service receives message RVSCFG011E. Resolution: The call interface to RVPCFGRD was changed as part of 409's changes. The customer was assisted with revising their modifications to RVPCFGRD's new expectations. While researching this (before we knew it was due to a local mod) we found a number of areas that could be improved. This update delivers those improvements. Additionally RVPPRC is restructured for better clarity. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPCCL ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPIFC ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE
VT550412 VMARC 11/06/19 11:07:19 * EB block corrupted on heavily loaded system
Update VT550412 applies to VSSI installation builds through 5526 Symptom: * EB block corrupted on heavily loaded system Problem: In some rare instances an EB block (VTAPE metadata) is missing its final update and thus the tape is unreadable beyond the point of the bad EB block. Resolution: This has been a long standing bug going back decades. We would like to thank Paula Duijneveld, our customer's Systems Programmer, for diligently helping us research and understand this problem. Several previous attempts to fix it were unsuccessful (eg: fixes 550093, 5500134, 5500143 and 550150) but we are confident we have finally gotten to the bottom of it and fixed it once and for all. Entry point RVTDBMWC is updated to unconditionally do a a write of the previous EB block whenever a new EB block is allocated. Formerly the code would conditionally do the write and if delivery of the completion interrupt from the previous write was delayed, we would wrongly conclude the previous write was still outstanding and expect that it would write the updated data out when in fact its write had already completed and thus the final updates on the prior EB page would never be written out, resulting in the corrupt tape. Additionally, all the VTAPE timing related code has been gathered together from various other parts into the new RVTTMR stub module that fix VT550404 added for this purpose. Lastly, a number of other parts have had comments and/or SIDcodes corrected. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOCT ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQY2 ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE RVTTMR ASSEMBLE
VP550411 VMARC 10/24/19 10:53:43 * FRE016 hard abend possible after fix 409
Update VP550411 applies to VSSI installation builds through 5526 Symptom: * FRE016 hard abend possible after fix 409 Problem: FRE016 after fix VP550409. Resolution: Fix VP550409 revised the handling of the device I/O intercept list (VPTPFDEV file). Depending on the number of format tables referenced and the order they were referenced in a FRE016 abend is possible. RVPIFC is updated to correct this. A number of other parts have had comments and/or USINGs corrected/clarified. BUILD_Reqd: VSSICP Toolmin: 1.0 428 (2019-10-24) Modules: RVPCCW ASSEMBLE RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPSET ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE
VP550410 VMARC 10/18/19 16:00:44 * ASR001 when maximum VPARS users reached
Update VP550410 applies to VSSI installation builds through 5526 Symptom: * ASR001 when maximum VPARS users reached Problem: Customer was running their test system with: SET CPCHECKING ON This activates the HCPASERT facility and they (eventually) received an ASR001 abend on the following assert: HCPASERT SYMLOCK,LOCK=VPSYMKEY,QUEUE=0(R6) in entry point RVPRCCCO (close VPARS database after an open error). The assert failed because the lock wasn't held. In fact the lock was held however, the error was so early in open processing that the VPCTLBK (where VPSYMKEY is defined) had not been allocated yet and lock key was still in the VPOPENBK. As an aside, the source of the error was maximum R/W databases open (the customer was running with an artificially low limit of 5 databases). Resolution: RVPIFC is update with some clarifying comments. RVPOPN was missed in 550406's branch mnemonic overhaul, so that is completed here. As well it has comments to clarify that is is passing the VPOPENBK to RVPRCCCO (it always was, this just formalizes the interface). RVPRCCCO is updated to assert that the lock is held, using the lock in the VPOPENBK rather than the VPCTLBK. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVPIFC ASSEMBLE RVPOPN ASSEMBLE RVPRCC ASSEMBLE
VP550409 VMARC 10/18/19 16:00:17 * Support >252 ranges in the device I/O intercept list
Update VP550409 applies to VSSI installation builds through 5526 Symptom: * Support >252 ranges in the device I/O intercept list Problem: Three problems are being addressed by this fix: - there is a limit of 252 device ranges when indicating which DASD are to have their I/Os intercepted. This has been a long-standing (multi-decade) limit. Some customers are now bumping into it. - when a file with more than 252 device ranges fails a a VPTEST its file name is missing from the message: RVPCFG041E Test failed for ........ This bug was introduced by fix VP550008. - when a VPTEST command fails, the command still completes with return code zero. Resolution: The limit has been increased to 505 device ranges. Message 041 now contains the file name that failed the test. Failed tests now result in a non-zero return code. Fixes 408 and 409 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPIFC ASSEMBLE RVPMSG ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSV1 ASSEMBLE RVPSV3 ASSEMBLE
VT550408 VMARC 10/18/19 15:59:12 * Support >252 ranges in the device I/O intercept list
Update VT550408 applies to VSSI installation builds through 5526 Symptom: * Support >252 ranges in the device I/O intercept list Problem: The limit of 252 device ranges is being bumped into. Raise the limit to 505 device ranges. Resolution: Fix 550408 contains the COPY member changes required by fix 550409. Fixes 408 and 409 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: RVTCMPBK COPY
VP550408 VMARC 10/18/19 15:56:38 * Support >252 ranges in the device I/O intercept list
Update VP550408 applies to VSSI installation builds through 5526 Symptom: * Support >252 ranges in the device I/O intercept list Problem: The limit of 252 device ranges is being bumped into. Raise the limit to 505 device ranges. Resolution: Fix 550408 contains the COPY member changes required by fix 550409. Fixes 408 and 409 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: RVPDEVBK COPY RVPEQUAT COPY RVPFMTBK COPY RVPSCFBK MACRO
VS550408 VMARC 10/18/19 15:44:53 * Support >252 ranges in the device I/O intercept list
Update VS550408 applies to VSSI installation builds through 5526 Symptom: * Support >252 ranges in the device I/O intercept list Problem: The limit of 252 device ranges is being bumped into. Raise the limit to 505 device ranges. Resolution: Fix 550408 contains the COPY member changes required by fix 550409. Fixes 408 and 409 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: RVSCMPBK COPY VSSICBID COPY
VT550407 VMARC 10/18/19 15:20:16 * CP exit elimination; phase 1
Update VT550407 applies to VSSI installation builds through 5526 Symptom: * CP exit elimination; phase 1 Problem: The vast majority of VSSI's product code is CPXLOADed. The code is loaded with the TEMP option which means external symbols are not resolved between subsystems (that is code not loaded on the same CPXLOAD command). Initially the way approach around this was to use CPEXITs for the cross subsystem calls. However, this adds overhead. Fix 550257 was an initial attempt to reduce this overhead. Subsequently fix 550354 enhanced CPXLOAD to allow external symbols to be resolved between code that was not loaded on the same CPXLOAD command. This allows for direct HCPCALLs to be used. Resolution: We now exploit 550354's enhancement and HCPCALL replaces the use of CPEXITs for cross subsystem calls. CPEXITs remain in use for calls between the CP nucleus and CPXLOADed code. A future update will address those. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVTADD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMET ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTQLB ASSEMBLE RVTQY2 ASSEMBLE RVTSUM ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE
VP550407 VMARC 10/18/19 15:19:32 * CP exit elimination; phase 1
Update VP550407 applies to VSSI installation builds through 5526 Symptom: * CP exit elimination; phase 1 Problem: The vast majority of VSSI's product code is CPXLOADed. The code is loaded with the TEMP option which means external symbols are not resolved between subsystems (that is code not loaded on the same CPXLOAD command). Initially the way approach around this was to use CPEXITs for the cross subsystem calls. However, this adds overhead. Fix 550257 was an initial attempt to reduce this overhead. Subsequently fix 550354 enhanced CPXLOAD to allow external symbols to be resolved between code that was not loaded on the same CPXLOAD command. This allows for direct HCPCALLs to be used. Resolution: We now exploit 550354's enhancement and HCPCALL replaces the use of CPEXITs for cross subsystem calls. CPEXITs remain in use for calls between the CP nucleus and CPXLOADed code. A future update will address those. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCSP ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE
VS550407 VMARC 10/18/19 15:18:54 * CP exit elimination; phase 1
Update VS550407 applies to VSSI installation builds through 5526 Symptom: * CP exit elimination; phase 1 Problem: The vast majority of VSSI's product code is CPXLOADed. The code is loaded with the TEMP option which means external symbols are not resolved between subsystems (that is code not loaded on the same CPXLOAD command). Initially the way approach around this was to use CPEXITs for the cross subsystem calls. However, this adds overhead. Fix 550257 was an initial attempt to reduce this overhead. Subsequently fix 550354 enhanced CPXLOAD to allow external symbols to be resolved between code that was not loaded on the same CPXLOAD command. This allows for direct HCPCALLs to be used. Resolution: We now exploit 550354's enhancement and HCPCALL replaces the use of CPEXITs for cross subsystem calls. CPEXITs remain in use for calls between the CP nucleus and CPXLOADed code. A future update will address those. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVSCFG ASSEMBLE RVSUTL ASSEMBLE
VT550406 VMARC 10/18/19 15:17:10 * Refactoring - comments and branch mnemonics
Update VT550406 applies to VSSI installation builds through 5526 Symptom: * Refactoring - comments and branch mnemonics Problem: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. Resolution: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) 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
VP550406 VMARC 10/18/19 15:14:27 * Refactoring - comments and branch mnemonics
Update VP550406 applies to VSSI installation builds through 5526 Symptom: * Refactoring - comments and branch mnemonics Problem: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. Resolution: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) 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 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
VS550406 VMARC 10/18/19 15:12:56 * Refactoring - comments and branch mnemonics
Update VS550406 applies to VSSI installation builds through 5526 Symptom: * Refactoring - comments and branch mnemonics Problem: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. Resolution: Reformatting comments and revising branch mnemonics. Refactoring only. No code change. Text decks compare before and after. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSPRM ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSUTL ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE
VT550405 VMARC 10/18/19 15:11:55 * Preparatory refactoring changes (VTAPE)
Update VT550405 applies to VSSI installation builds through 5526 Symptom: * Preparatory refactoring changes (VTAPE) Problem: Update to accomodate changes by 550404. Resolution: Update to accomodate changes by 550404. Updates 550404 and 550405 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 425 (2019-07-09) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM 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 RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTST3 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE VTBKUP ASSEMBLE VTBKVOL ASSEMBLE VTCPYASM ASSEMBLE VTDIRC ASSEMBLE VTFMT ASSEMBLE VTMDSCR ASSEMBLE VTREST ASSEMBLE VTRPT1 ASSEMBLE
VP550405 VMARC 10/18/19 15:07:38 * Preparatory refactoring changes (VPARS)
Update VP550405 applies to VSSI installation builds through 5526 Symptom: * Preparatory refactoring changes (VPARS) Problem: Update to accomodate changes by 550404. Resolution: Update to accomodate changes by 550404. Updates 550404 and 550405 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 425 (2019-07-09) 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 RVPOPN ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPCPYASM ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPLOADO ASSEMBLE VPREST ASSEMBLE VPRESTO ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL ASSEMBLE
VT550404 VMARC 10/18/19 15:04:57 * Preparatory refactoring changes (VTAPE COPY/MACROs)
Update VT550404 applies to VSSI installation builds through 5526 Symptom: * Preparatory refactoring changes (VTAPE COPY/MACROs) Problem: Prepare the COPY and MACRO parts for future fixes and updates. Resolution: Prepare the COPY and MACRO parts for future fixes and updates. Part RVPTMR ASSEMBLE is created. Currently it is just a stub but a future fix will gather the VPARS timer management code together which is currently spread across a number of disparate parts. Updates VT550404 and VT550405 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 425 (2019-07-09) Modules: RVTEQUAT COPY RVTEXCBK COPY RVTSALIB COPY RVTSYSBK COPY VTACTBK COPY VTBMAPBK COPY VTCLBLBK COPY VTDATABK COPY VTENTBK COPY VTFDIRBK COPY VTFENTBK COPY VTIOCBK COPY VTIOTBK COPY VTLDRBK COPY VTLSTBK COPY VTLWRKBK COPY VTMDSKBK COPY VTMNTBK COPY VTPACKBK COPY VTSCRBK COPY VTSETWK COPY VTVDSCBK COPY VTXDCPBK COPY RVTMDLAT MACRO VT5ANCH MACRO VT6ANCH MACRO RVTTMR ASSEMBLE
VP550404 VMARC 10/18/19 14:04:04 * Preparatory refactoring changes (VPARS COPY/MACROs)
Update VP550404 applies to VSSI installation builds through 5526 Symptom: * Preparatory refactoring changes (VPARS COPY/MACROs) Problem: Prepare the COPY and MACRO parts for future fixes and updates. Resolution: Prepare the COPY and MACRO parts for future fixes and updates. Part RVPTMR ASSEMBLE is created. Currently it is just a stub but a future fix will gather the VPARS timer management code together which is currently spread across a number of disparate parts. Updates VP550404 and VP550405 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 425 (2019-07-09) Modules: RVPCCTBK COPY RVPCFGBK COPY RVPCMPBK COPY RVPDEVBK COPY RVPEQUAT COPY RVPFMTBK COPY RVPSYSBK COPY VPBXIOWK COPY VPBXPOOL COPY VPBXRCF COPY VPBXRPL COPY VPCTLBK COPY VPINDXBK COPY VPIOCBK COPY VPIOTBK COPY VPOPENBK COPY VPPOOLBK COPY VPSETBK COPY VPTCCTBK COPY VPTPFKEY COPY RVPMDLAT MACRO RVPSCFBK MACRO RVPTMR ASSEMBLE
VS550404 VMARC 10/18/19 12:06:02 * Preparatory refactoring changes (Common/COPY/MACROs)
Update VS550404 applies to VSSI installation builds through 5526 Symptom: * Preparatory refactoring changes (Common/COPY/MACROs) Problem: Prepare the COPY, MACRO and common code for future fixes and updates. Resolution: Prepare the COPY, MACRO and common code for future fixes and updates. Additionally the update to CP part HCPZSC is deprecated by this fix and the update to HCPIOV is revised. Part RVSLCK ASSEMBLE is created and VSSI's lock management code is moved to it from RVSSTB. Eventually RVSSTB will be re-purposed. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 425 (2019-07-09) Modules: VS55MAC $EXEC RVSCMPBK COPY RVSIOCBK COPY VSCFGBK COPY VSICCWS COPY VSLCKXST COPY VSMODID COPY VSSICBID COPY RVSMDLAT MACRO VSLCKDEF MACRO VSLCKOP MACRO VSMSGH MACRO RVSCBI ASSEMBLE RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSLCK ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE RVSSTA ASSEMBLE RVSSTB ASSEMBLE RVSSTD ASSEMBLE RVSSTF ASSEMBLE RVSSTG ASSEMBLE RVSSTN ASSEMBLE RVSSTP ASSEMBLE RVSSTQ ASSEMBLE RVSUTL ASSEMBLE RVSVDY ASSEMBLE RVSVPY ASSEMBLE RVSVTY ASSEMBLE VSDBSCAN ASSEMBLE VSDCHK ASSEMBLE VSDLBL ASSEMBLE VSFSERR ASSEMBLE VSLABSL ASSEMBLE VSRTP01 ASSEMBLE RVSSTL LAS55404
VT550403 VMARC 09/20/19 14:12:39 * Add dummy VTAPE part for file appends
Update VT550403 applies to VSSI installation builds through 5526 Symptom: * Add dummy VTAPE part for file appends Problem: From time to time, it is necessary to modify and ship non-SES VTAPE parts (e.g., HELP files). Resolution: Dummy part VTAPPEND COPY as been created. This part is a comment-only file; updates against this part will be used to append non-SES parts to the UPDATE file. Accordingly, part VTMODID COPY is no longer needed and is removed by this update. BUILD_Reqd: VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: VT55MAC $EXEC VTAPPEND COPY
VP550403 VMARC 09/20/19 14:12:33 * Add dummy VPARS part for file appends
Update VP550403 applies to VSSI installation builds through 5526 Symptom: * Add dummy VPARS part for file appends Problem: From time to time, it is necessary to modify and ship non-SES VPARS parts (e.g., HELP files). Resolution: Dummy part VPAPPEND COPY as been created. This part is a comment-only file; updates against this part will be used to append non-SES parts to the UPDATE file. Accordingly, part VPMODID COPY is no longer needed and is removed by this update. BUILD_Reqd: VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: VP55MAC $EXEC VPAPPEND COPY
VS550403 VMARC 09/20/19 14:12:26 * Add missing HELP files
Update VS550403 applies to VSSI installation builds through 5526 Symptom: * Add missing HELP files Problem: The z/VM 7.1 packages are missing several HELP files. Resolution: HELP files appended to this update for dummy part VSAPPEND COPY. BUILD_Reqd: VSSMMAC Toolmin: 1.0 425 (2019-07-09) Modules: VS55MAC $EXEC VSAPPEND COPY
VP550402 VMARC 09/20/19 14:25:02 * Loop in RVPSV3 during VPOPEN after fix VP550392
Update VP550402 applies to VSSI installation builds through 5526 Symptom: * Loop in RVPSV3 during VPOPEN after fix VP550392 Problem: Customer has a device intercept list (for VPARS this is filetype VPTPFDEV) that contains device FFFF. Fix VP550392 did refactoring work in RVPSV3 to add code that purged the minidisk cache for devices who will be having their I/Os intercepted or devices that will form part of the VPARS database. As a result of this overhaul, the boundary condition of device number FFFF was no longer handled properly. Resolution: RVPSV3 is updated to properly handle the entire device number range. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVPSV3 ASSEMBLE
VT550401 VMARC 09/06/19 09:37:30 * Fix several minor old VTAPE bugs
Update VT550401 applies to VSSI installation builds through 5526 Symptom: * Fix several minor old VTAPE bugs Problem: Four very old (several decades) minor VTAPE bugs are being addressed by this fix. We discovered these while researching another problem. - when an error occurs opening a VTAPE library for output, the library is not opened. However, the internal count of open output libraries counts the failed open. - z architecture changed the format of the CPUID returned by the STIDP (Store CPU ID) instruction. It no longer contains a logical CP address. VTAPE checks the CPU ID when opening an output library that wasn't properly closed (eg: due to a crash) to verify it is being opened by the same system as last had it open. - if a library being opened for output encounters an error, and if the VTOPEN command was issued by the system operator userid, then the VTOPEN is successful when it should not be. This is due to a bug in an IBM support routine we call. Eg: -------------------------------------------------- VTOPEN LIB A OUT A DEF A 00:50:29 HCPLNM104E $VTAPE$ 1101 not linked; R/O by MAINT at PERRY1 Library A has been opened by OPERATOR Libraries: Input=None Output=A Default=A Defined=A VTAPE library open complete Ready; T=0.01/0.01 00:51:10 -------------------------------------------------- - some tokens are missing from error messages. Eg: -------------------------------------------------- vtq lib * RVTQY1071E Library was not found in system definition Ready VSS31 at VMA (00071); T=0.01/0.01 04:01:40 -------------------------------------------------- Resolution: - RVTOPN is updated to decrement the count of open output libraries when a open for output fails. The internal count of open output libraries is decremented so it now accurately reflects the number of libraries actually open. - RVTOPN is updated to correctly use z architecture CPU ids - RVTOCS is updated to bypass the IBM defect. Should IBM decide to fix HCPLNMSG this bypass will be removed. Libraries are no longer opened when they shouldn't be. - the coding technique that resulted in missing tokens in some message, was found in several modules. All of them have been updated to supply the correct token for the message. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVTCON ASSEMBLE RVTMSG ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTST3 ASSEMBLE RVTSV2 ASSEMBLE
VT550400 VMARC 08/26/19 10:54:41 * Excessive CPEBKs for RVTDBMTM
Update VT550400 applies to VSSI installation builds through 5526 Symptom: * Excessive CPEBKs for RVTDBMTM Problem: CPEBKs pointing to RVTDBMTM are being orphaned. Resolution: RVTSV1 is updated to indicate to CP's TRQBK handler that control should be passed to RVTDBMTM via HCPGOTO rather than HCPCALL. This bug was introduced by fix VT550393. BUILD_Reqd: VSSICP Toolmin: 1.0 425 (2019-07-09) Modules: RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTDBM ASSEMBLE RVTIOR ASSEMBLE RVTOCS ASSEMBLE RVTREW ASSEMBLE RVTSCR ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE
VT550399 VMARC 06/28/19 09:55:35 * Tapes partially unreadable after VP550393
Update VT550399 applies to VSSI installation builds through 5526 Symptom: * Tapes partially unreadable after VP550393 Problem: SR instructions were converted to SLR when working with addresses (where logical arithmetic is appropriate). One SR that was not dealing with an address was mistakenly converted to SLR. Since SR and SLR have different condition code meanings, this caused the code following the mistakenly changed SLR to behave incorrectly. Resolution: RVTDBM is updated to revert the SLR to an SR. RVTOCT and RVTST1 have had comments corrected. VSSI fix level 550399 is the recommended minimum level for our customers migrating to z/VM 7.1.0. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVTDBM ASSEMBLE RVTOCT ASSEMBLE RVTST1 ASSEMBLE
VP550399 VMARC 06/28/19 09:55:07 * TPF guest unable to enter NORM state after VP550392
Update VP550399 applies to VSSI installation builds through 5526 Symptom: * TPF guest unable to enter NORM state after VP550392 Problem: Two problems after the code refactoring done by VP550392: - Specification except at RVPSV1+B9C instr CSY - Operation except at xxxxx000 instr 0000 Resolution: RVPSV1 is updated to correct the regression. RVPSYN is updated to avoid the wild branch. VSSI fix level 550399 is the recommended minimum level for our customers migrating to z/VM 7.1.0. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSYN ASSEMBLE
VS550398 VMARC 06/26/19 11:03:36 * Placeholder update - start 5526
Update VS550398 applies to VSSI installation builds through 5526 Symptom: * Placeholder update - start 5526 Problem: Dummy update to mark the start of Build 5526. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: VSMODID COPY
PTFs below apply to Packages at 5524 and lower
VS550397 VMARC 06/18/19 16:33:16 * Placeholder update - end 5524
Update VS550397 applies to VSSI installation builds through 5524 Symptom: * Placeholder update - end 5524 Problem: Dummy update to mark the end of Build 5524. Resolution: n/a. BUILD_Reqd: VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: VSMODID COPY
VS550396 VMARC 06/17/19 16:19:51 * Remove Deprecated VSXRL macro
Update VS550396 applies to VSSI installation builds through 5524 Symptom: * Remove Deprecated VSXRL macro Problem: The VSXRL macro was used to generate the proper EX instruction for older machine types: Machine Generated Instruction <= Z10 EX Rx,addr >= Z12 EXRL Rx,addr Since z/VM is no longer supported on older hardware, all current machines have the Extended Instruction Set Feature. Therefore, the possible use of EXRL in VSSI code is no longer an issue, and the macro can thus be removed. Resolution: Application of the PTF will remove all references to the VSXRL macro. BUILD_Reqd: VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: VS55MAC $EXEC
VP550395 VMARC 06/17/19 16:11:50 * MultiTrack I/O Operation updates
Update VP550395 applies to VSSI installation builds through 5524 Symptom: * MultiTrack I/O Operation updates Problem: Shadowdisk/Z QA testing has identified the following issues on SLES15 which did not exist in SLES12; i.e.: . Missing support for Prefix Read (0xEA) opcode . Missing support for Prefix operations which specify the Read Trackset, Update Tracket, or Prestage Trackset extended operation codes . Incomplete support for the Write Track Data (0xA5) and Read Track Data (0xA6) CCWs Resolution: The following updates were added to RVPCSP: . Support added for Locate Record Extended Read (0x4A) CCW opcode. . Correct tracking for MultiTrack CCWs based on Locate Record Extended parameters (i.e., Trackset Mode vs. Normal mode). . If A5|A6 CCws are runing in Trackset mode, CCW operation is considered compete after the last record in each indicated track has been processed; otherwise, the CCW COUNT field is used to determine the number of records to be included in the current operation. . additional validation of Prefix, Define Extent and Locate Record (Extended) parameters in order to better detect channel program errors. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVPCCW ASSEMBLE RVPCSP ASSEMBLE RVPDBS ASSEMBLE
VT550394 VMARC 06/17/19 14:44:49 * MultiTrack I/O Operation updates
Update VT550394 applies to VSSI installation builds through 5524 Symptom: * MultiTrack I/O Operation updates Problem: Update VTIOTBK and RVTMDLAT in preperation for future changes. Resolution: Update VTIOTBK and RVTMDLAT in preperation for future changes. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: VTIOTBK COPY RVTMDLAT MACRO
VP550394 VMARC 06/17/19 11:26:59 * MultiTrack I/O Operation updates
Update VP550394 applies to VSSI installation builds through 5524 Symptom: * MultiTrack I/O Operation updates Problem: Shadowdisk/Z QA testing has identified the following issues on SLES15 which did not exist in SLES12; i.e.: . Missing support for Prefix Read (0xEA) opcode . Missing support for Prefix operations which specify the Read Trackset, Update Tracket, or Prestage Trackset extended operation codes . Incomplete support for the Write Track Data (0xA5) and Read Track Data (0xA6) CCWs Resolution: This update adds additional support bits/fields/values to the RVPEQUAT, VPCHCCW, VPIOTBK and VP1WRKBK copy members required by updated multi-track processing code in update 550395. Additionally, several deprecated fields have been removed from the VP1WRKBK and clarifying comments have been added to RVPFMTBK. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: RVPEQUAT COPY RVPFMTBK COPY VPCHCCW COPY VPIOTBK COPY VPTCCTBK COPY VP1WRKBK COPY RVPMDLAT MACRO
VS550394 VMARC 06/17/19 10:37:45 * MultiTrack I/O Operation updates
Update VS550394 applies to VSSI installation builds through 5524 Symptom: * MultiTrack I/O Operation updates Problem: Shadowdisk/Z QA testing has identified the following issues on SLES15 which did not exist in SLES12; i.e.: . Missing support for Prefix Read (0xEA) opcode . Missing support for Prefix operations which specify the Read Trackset, Update Tracket, or Prestage Trackset extended operation codes . Incomplete support for the Write Track Data (0xA5) and Read Track Data (0xA6) CCWs Resolution: This update add equates that are used across the VSSI code base to RVSEQUAT COPY. Our HCPDFN update results in assembly errors after VM66249 is applied and our HCPPAV update no longer fits after VM66237 is applied. Revised updates for HCPDFN and HCPPAV are included. As is a revised HCPVDEV update. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: RVSEQUAT COPY VSMODID COPY RVSMDLAT MACRO
VT550393 VMARC 06/15/19 09:10:06 * PRG004 in RVTCCW on UNASSIGN CCW
Update VT550393 applies to VSSI installation builds through 5524 Symptom: * PRG004 in RVTCCW on UNASSIGN CCW Problem: Several problems are being addressed via this fix: - PRG004 on UNASSIGN CCW after fix 550387 - HTT001 on mount of a scratch volume from a restricted volume range when the range is full after fix 550378 - VTAPE is incorrectly determining whether I/Os are subject to timestamping - incorrect pointer usage after fix 550139 Resolution: RVTCCW is updated to properly simulate an unassign CCW. RVTSV3 is updated to properly support a restricted volume range. RVTIOR is updated to properly support I/O timestamping. RVTCCW is updated to properly set up the VTSCTL pointer. Several other parts have had refactoring work done in preperation for upcoming fixes. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVTADD ASSEMBLE RVTCCW ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTDBM ASSEMBLE RVTDEF ASSEMBLE RVTIOR 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 RVTST1 ASSEMBLE RVTST2 ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE RVTSV5 ASSEMBLE
VP550392 VMARC 06/17/19 10:27:33 * dbm004 soft abend possible after applying VP550391
Update VP550392 applies to VSSI installation builds through 5524 Symptom: * dbm004 soft abend possible after applying VP550391 Problem: dbm004 or ccw006 soft abends possible after fix 550391. Incorrectly determining success after HCPTRANS. Resolution: RVPDBM is updated to correct the 391 regression. RVPIOR is updated to check the return code in R15 after invoking HCPTRANS rather than relying on the CC. Additional validation is done when CP presents an I/O interrupt to us after a system has lost timing synchronization. This is to try and catch what seems to be an IBM bug. Numerous other parts have had refactoring done in preperation for future updates. Fixes 550392, 550393, 550394 and 550395 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVPBUF ASSEMBLE RVPCFG ASSEMBLE RVPCLR ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPDBM ASSEMBLE RVPDBT 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
VP550391 VMARC 02/15/19 10:49:37 * Deprecate HCPHTS modification
Update VP550391 applies to VSSI installation builds through 5524 Symptom: * Deprecate HCPHTS modification Problem: Three problems are being addressed. VSSI's update to HCPHTS is being deprecated for VM 7.1.0. Timestamp support is being determined incorrectly. Prefix Read CCW is not supported. Resolution: RVPCQY is updated to source the value formerly computed by the HCPHTS update from a CP maintained value. RVPIOR is updated to properly determine whether timestamp support is required on I/O. RVPCSP is updated to support Prefix Read. Additionally a number of other VPARS parts are updated with minor pending refactoring. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 423 (2019-02-01) Modules: RVPBUF ASSEMBLE RVPCCW ASSEMBLE RVPCLR 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 RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE RVPSYN ASSEMBLE VPBLDFMT ASSEMBLE
VT550390 VMARC 02/06/19 08:03:34 * Annual re-sequence VTAPE parts
Update VT550390 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. The sequence number range is 00000000-99999999 and to minimize future re-sequences we attempt to pick a new gap that best exploits the full range. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVTIOR ASSEMBLE RVTOPN ASSEMBLE RVTPRC ASSEMBLE RVTSTS ASSEMBLE
VP550390 VMARC 02/06/19 08:03:25 * Annual re-sequence VPARS parts
Update VP550390 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. The sequence number range is 00000000-99999999 and to minimize future re-sequences we attempt to pick a new gap that best exploits the full range. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVPCSP ASSEMBLE RVPIFC ASSEMBLE RVPPRC ASSEMBLE RVPQY3 ASSEMBLE
VS550390 VMARC 02/06/19 08:03:14 * Annual re-sequence VS common parts
Update VS550390 applies to VSSI installation builds through 5524 Symptom: * Annual re-sequence VS common 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. The sequence number range is 00000000-99999999 and to minimize future re-sequences we attempt to pick a new gap that best exploits the full range. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 423 (2019-02-01) Modules: RVSSTA ASSEMBLE
VT550389 VMARC 02/05/19 11:54:07 * Annual re-sequence COPY members
Update VT550389 applies to VSSI installation builds through 5524 Symptom: * Annual re-sequence COPY members 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. The sequence number range is 00000000-99999999 and to minimize future re-sequences we attempt to pick a new gap that best exploits the full range. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: RVTEQUAT COPY
VT550388 VMARC 02/05/19 11:50:19 * csp007 soft abend on read of x'FFFF' bytes
Update VT550388 applies to VSSI installation builds through 5524 Symptom: * csp007 soft abend on read of x'FFFF' bytes Problem: Guest I/O contains an Read multiple CKD CCW (x'5E') that has 33 IDAWs to satisify the length specified (2K IDAWs and the first does not start on a 2K boundary). VPARS only supports 32 IDAWs so the I/O is rejected with a csp007 soft abend. Resolution: This is simply a refactoring change for the VTAPE parts. Fixes 550387 and 550388 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: RVTEQUAT COPY RVTEXCBK COPY VTACTBK COPY VTEXTBK COPY VTIOTBK COPY VTLDRBK COPY VTLWRKBK COPY VTMDSKBK COPY VTOPRMBK COPY VTPACKBK COPY VTQRYBK COPY VTRELBK COPY VTSCTLBK COPY VTSETWK COPY VT6ANCH MACRO
VP550388 VMARC 02/05/19 10:50:45 * csp007 soft abend on read of x'FFFF' bytes
Update VP550388 applies to VSSI installation builds through 5524 Symptom: * csp007 soft abend on read of x'FFFF' bytes Problem: Guest I/O contains an Read multiple CKD CCW (x'5E') that has 33 IDAWs to satisify the length specified (2K IDAWs and the first does not start on a 2K boundary). VPARS only supports 32 IDAWs so the I/O is rejected with a csp007 soft abend. Resolution: VPCHCCW is updated to support 33 IDAWs. A number of other VPARS copy members have had minor refactoring performed. Fixes 550387 and 550388 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSICMS VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: RVPCMPBK COPY RVPEQUAT COPY RVPEXCBK COPY VPCHCCW COPY VPCTLBK COPY VPDCSBK COPY VPINDXBK COPY VPIOCBK COPY VPMDSKBK COPY VPMDTBL COPY VPOPENBK COPY VPTCCTBK COPY VPTPFKEY COPY VPUSERBK COPY VP1WRKBK COPY
VS550388 VMARC 02/05/19 09:38:30 * csp007 soft abend on read of x'FFFF' bytes
Update VS550388 applies to VSSI installation builds through 5524 Symptom: * csp007 soft abend on read of x'FFFF' bytes Problem: Guest I/O contains an Read multiple CKD CCW (x'5E') that has 33 IDAWs to satisfy the length specified (2K IDAWs and the first does not start on a 2K boundary). VPARS only supports 32 IDAWs so the I/O is rejected with a csp007 soft abend. Resolution: This is simply a refactoring change for the VS common parts. Fixes 550387 and 550388 must be applied concurrently. BUILD_Reqd: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 423 (2019-02-01) Modules: VSIDAWD COPY VSMSGPBK COPY VSSITRAC COPY VSCKVMD MACRO VSMSGH MACRO
VT550387 VMARC 02/05/19 09:20:56 * VTAPE's end of volume simulation incorrect
Update VT550387 applies to VSSI installation builds through 5524 Symptom: * VTAPE's end of volume simulation incorrect Problem: VTAPE is not always reflecting a unit exception to CCWs after end of volume has been reached. Some I/Os complete normally when they should have received a unit exception. Resolution: Fix VT550093 performed a significant update to VTAPE to correct metadata issues. One of the changes was to how tape limits were determined. The updated code did not hue strictly to the hardware architecture of the device(s) we are emulating, thereby allowing a virtual tape drive to behave in a manner that a real tape drive never would. Those portions of fix 93 relating to end of tape unit exception reflection have been reverted to their pre 93 logic and unit exceptions are now presented as defined by the hardware architecture. Additiontally, the VTAPE code base has had code modernization/rationalization performed. Fixes 550387 and 550388 must be applied concurrently. BUILD_Reqd: VSSICP Toolmin: 1.0 423 (2019-02-01) 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 VTCPYASM ASSEMBLE
VP550387 VMARC 02/05/19 09:19:04 * csp007 soft abend on read of x'FFFF' bytes
Update VP550387 applies to VSSI installation builds through 5524 Symptom: * csp007 soft abend on read of x'FFFF' bytes Problem: Guest I/O contains a Read multiple CKD CCW (x'5E') that has 33 IDAWs to satisify the length specified (2K IDAWs and the first does not start on a 2K boundary). VPARS only supports 32 IDAWs so the I/O is rejected with a csp007 soft abend. Resolution: RVPCSP and RVPDBS are updated to support 33 IDAWs. Fixes 550387 and 550388 must be applied concurrently. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 423 (2019-02-01) Modules: RVPCSP ASSEMBLE RVPDBS ASSEMBLE VPFMT ASSEMBLE
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:06 * 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
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
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
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:38 * 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
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
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
VS550370 VMARC 10/08/18 10:36:38 * 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 VP550342
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
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
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
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
VT550361 VMARC 06/11/18 12:35:33 * 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
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
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
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
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
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
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
VS550358 VMARC 06/08/18 13:29:59 * 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
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
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
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:08 * 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:36 * 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
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
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
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:08 * 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:06 * 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
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
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
VS550341 VMARC 03/15/18 13:11:31 * 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
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
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
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:28 * 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 database
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 database
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:44 * 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:27 * 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:07 * 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:11 * 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/08/17 09:05:06 * 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
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
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
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
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
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
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:33:17 * 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
VT550304 VMARC 12/01/16 04:20:32 * RAS changes to improve dump readability (VPARS/VTAPE)
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
VP550304 VMARC 12/01/16 04:20:26 * RAS changes to improve dump readability (VPARS/VTAPE)
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
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
VT550302 VMARC 11/26/16 01:01:11 * RAS changes to improve dump readability (macros/copy)
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
VP550302 VMARC 11/26/16 01:01:19 * RAS changes to improve dump readability (macros/copy)
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
VS550302 VMARC 11/26/16 01:01:35 * RAS changes to improve dump readability (macros/copy)
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
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
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
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
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
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
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/23/16 10:22:47 * 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
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 08/06/16 13:37:01 * 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 . IPLThe 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:44 * 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
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
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
VS550265 VMARC 08/19/15 07:49:52 * 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:17:15 * 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:47:03 * 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:46 * 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:51 * 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
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
VP550257 VMARC 06/22/15 11:29:04 * 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
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
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
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
VS550254 VMARC 05/20/15 17:38:53 * 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:14:06 * 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:18:00 * 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
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
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
VS550248 VMARC 04/28/15 18:15:16 * 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:19 * 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
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
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
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:27 * 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
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
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
VS550236 VMARC 02/11/15 13:21:30 * 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:33:12 * 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:38:58 * 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 initialization.
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:47 * 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
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
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
VS550216 VMARC 12/16/14 18:35:26 * 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
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
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
VS550214 VMARC 12/11/14 04:25:47 * 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
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
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
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:57 * 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:20 * 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:38 * 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:08:03 * 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:30:50 * 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:48 * 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:04:11 * 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
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
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
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:08:46 * 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:09:49 * 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
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
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
VP550192 VMARC 08/29/14 16:01:30 * 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:55 * 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
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
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
VS550186 VMARC 08/18/14 12:40:54 * 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
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
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
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:40 * 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:27:08 * 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:26:34 * 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:40 * 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
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
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
VS550176 VMARC 07/30/14 03:52:26 * 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
VT550175 VMARC 07/29/14 09:43:54 * 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
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
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
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
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
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
VT550172 VMARC 07/27/14 04:38:43 * 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
VP550172 VMARC 07/27/14 04:37:14 * 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
VS550172 VMARC 07/27/14 04:38:25 * 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
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
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
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:39:19 * 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:41 * 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:07:19 * 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:45:37 * 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:34:13 * 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
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
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
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
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
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
VT550152 VMARC 06/10/14 12:09:02 * 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:44 * 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
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
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
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
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
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
VT550143 VMARC 06/02/14 15:48:16 * 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
VP550143 VMARC 06/02/14 15:47:36 * 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
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
VT550142 VMARC 06/02/14 15:26:54 * 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
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
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
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
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
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
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
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
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
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
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
VT550138 VMARC 05/20/14 08:53:55 * 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
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
VS550138 VMARC 05/20/14 08:52:13 * 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
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
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
VP550136 VMARC 05/15/14 10:26:17 * 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:25:16 * 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
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
VP550132 VMARC 05/08/14 10:50:20 * 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
VT550131 VMARC 05/08/14 10:48:59 * 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
VP550131 VMARC 05/08/14 10:48:09 * 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
VS550131 VMARC 05/21/14 09:51:45 * 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:42:17 * 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 15:20:59 * 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:16:23 * 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:12:53 * 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
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
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
VP550121 VMARC 04/01/14 18:08:07 * 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:11:44 * 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 generateXREF 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:41 * 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 generateXREF 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:10:16 * 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:21:13 * 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:44:08 * 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:55:31 * 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
VT550110 VMARC 02/25/14 15:04:41 * 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
VP550110 VMARC 02/25/14 15:04:08 * 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
VS550110 VMARC 02/25/14 15:02:45 * 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:26:08 * 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
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
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
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
VP550096 VMARC 10/23/13 09:36:19 * 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:37:35 * 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/06/13 14:32:20 * 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/06/13 14:31:30 * 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:43 * 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
VP550089 VMARC 10/02/13 19:35:55 * 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:58:50 * 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:59:19 * 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:22:21 * 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:34:02 * 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:23 * 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:55:47 * 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:43:13 * 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:38 * 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
VP550074 VMARC 07/26/13 12:05:44 * 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:19:15 * 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
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
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
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
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
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
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:04:02 * 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 09: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 09:12:21 * 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 09:12:52 * 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/12/13 08:29:34 * 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
VT550062 VMARC 05/21/13 09:49:55 * 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
VP550062 VMARC 05/21/13 09:49:45 * 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
VS550062 VMARC 05/21/13 09:49:29 * 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:59:58 * 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:43:49 * 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:36 * 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
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
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
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 10/04/13 09:02:36 * 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 05/20/13 16:34:01 * 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
VT550049 VMARC 01/31/13 12:50:33 * 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:48:06 * 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:18:23 * 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/06/13 07:57:33 * 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
VT550045 VMARC 12/26/12 13:06:17 * ShadowDisk/Z base code - non-MACRO|COPY
Update VT550045 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 VTAPE CPEXIT entry point names are changed to enforce VSSI component name standardization. BUILD_Reqd: VSSICP Toolmin: 1.0 207 (2012-12-25) Modules: RVTSV2 ASSEMBLE
VP550045 VMARC 12/26/12 13:06:17 * 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: 1.0 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
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: 1.0 207 (2012-12-25) Modules: VSCFGBK COPY VSMODID COPY RVSCFG ASSEMBLE RVSMSG ASSEMBLE RVSSTB ASSEMBLE RVSSTP 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: 1.0 203 (2012-12-02) Modules: RVPOPN ASSEMBLE
VP550043 VMARC 12/05/12 15:22:49 * 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 VSSICMS VSSMMAC Toolmin: 1.0 203 (2012-12-02) Modules: VPTCCTBK COPY
VS550043 VMARC 12/05/12 15:24:23 * 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: VSSMMAC Toolmin: 1.0 203 (2012-12-02) Modules: VS55MAC $EXEC
PTFs below apply to Packages at 5508 and lower
VT550041 VMARC 11/14/12 20:06:51 * Code refactoring - make room for ShadowDisk/Z
Update VT550041 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. Some of these macros are included in the VTCPYASM program. BUILD_Reqd: *None* Toolmin: 1.0 184 (2012-10-26) Modules: VTCPYASM ASSEMBLE
VP550041 VMARC 11/14/12 20:06:51 * 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: 1.0 184 (2012-10-26) Modules: RVPCQY ASSEMBLE RVPIOR ASSEMBLE RVPSV1 ASSEMBLE VPCPYASM 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: 1.0 184 (2012-10-26) Modules: RVSCFG ASSEMBLE RVSSTB ASSEMBLE RVSUTL ASSEMBLE
VP550040 VMARC 11/02/12 12:19:53 * 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: VSSIPL VSSICP VSSMMAC Toolmin: 1.0 184 (2012-10-26) Modules: VP55MAC $EXEC RVPSYSBK COPY
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 VSSMMAC Toolmin: 1.0 184 (2012-10-26) Modules: VS55MAC $EXEC VSMODID COPY RVSMDLAT MACRO RVSSTL LAS55040
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: 1.0 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: 1.0 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: 1.0 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: 1.0 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 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: 1.0 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 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: 1.0 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: 1.0 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: VSSICP Toolmin: 1.0 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 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: 1.0 164 (2012-06-12) Modules: COPYTAPE ASSEMBLE
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: VSSICP Toolmin: 1.0 164 (2012-06-12) Modules: VSMODID COPY RVSSTL LAS55028
PTFs below apply to Packages at 5504 and lower
VT550027 VMARC 06/14/12 08:40:32 * Implement HCPUSO|HCPRLI CP Hooks
Update VT550027 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: 1.0 164 (2012-06-12) Modules: VT55MAC $EXEC RVTCON ASSEMBLE RVTDEF ASSEMBLE RVTMNT ASSEMBLE RVTREW ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTST2 ASSEMBLE RVTSV2 ASSEMBLE VTCPYASM ASSEMBLE
VP550027 VMARC 06/14/12 08:40:32 * 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: 1.0 164 (2012-06-12) Modules: VP55MAC $EXEC RVPIFC ASSEMBLE RVPQY3 ASSEMBLE RVPRST ASSEMBLE VPCPYASM 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 VSSMMAC Toolmin: 1.0 164 (2012-06-12) Modules: VS55MAC $EXEC RVSMDLAT MACRO RVSSTL LAS55027
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: VSSMMAC Toolmin: 1.0 163 (2012-05-28) Modules: VSMODID COPY
VT550025 VMARC 05/28/12 07:22:52 * Product preparation for new CP hooks
Update VT550025 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 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: 1.0 163 (2012-05-28) Modules: RVTRST ASSEMBLE
VP550025 VMARC 05/28/12 07:22:52 * 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: 1.0 163 (2012-05-28) Modules: RVPRST ASSEMBLE
VT550024 VMARC 05/30/12 09:42:30 * CMPBK Field Additions
Update VT550024 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: 1.0 163 (2012-05-28) Modules: RVTCMPBK COPY RVTPRC ASSEMBLE RVTRST ASSEMBLE RVTSV2 ASSEMBLE RVTSV5 ASSEMBLE VTCPYASM ASSEMBLE
VP550024 VMARC 05/30/12 09:42:30 * 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: 1.0 163 (2012-05-28) Modules: RVPCMPBK COPY RVPCFG ASSEMBLE RVPPRC ASSEMBLE RVPRST ASSEMBLE VPCPYASM 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: VSSICP Toolmin: 1.0 163 (2012-05-28) Modules: RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSSTP ASSEMBLE
VT550023 VMARC 05/22/12 09:39:06 * Insufficient cleanup during CPXUNLOAD
Update VT550023 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. BUILD_Reqd: VSSICP Toolmin: 1.0 159 (2012-05-12) Modules: RVTSHU ASSEMBLE RVTSV2 ASSEMBLE
VP550023 VMARC 05/22/12 09:39:06 * 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: 1.0 159 (2012-05-12) Modules: RVPSHU ASSEMBLE RVPSV1 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: VSSICP Toolmin: 1.0 159 (2012-05-12) Modules: VSMODID COPY RVSSTL LAS55022
PTFs below apply to Packages at 5502 and lower
VT550021 VMARC 03/28/12 12:45:01 * Message ID prettification
Update VT550021 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: 1.0 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
VP550021 VMARC 03/28/12 12:45:01 * 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: 1.0 151 (2012-03-25) Modules: RVPCQY 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 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: 1.0 151 (2012-03-25) Modules: RVTSV2 ASSEMBLE
VP550020 VMARC 03/26/12 10:25:47 * 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: 1.0 151 (2012-03-25) Modules: RVPSV1 ASSEMBLE
VP550019 VMARC 03/25/12 16:35:28 * 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: VSSMMAC Toolmin: 1.0 151 (2012-03-25) Modules: VP55MAC $EXEC
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: VSSMMAC Toolmin: 1.0 151 (2012-03-25) Modules: VSMODID COPY
VT550018 VMARC 03/23/12 20:42:03 * CMS Message ID EQUates
Update VT550018 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: 1.0 150 (2012-03-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
VP550018 VMARC 03/23/12 20:42:03 * 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: 1.0 144 (2012-01-22) Modules: VPBKUP ASSEMBLE VPBLDFMT ASSEMBLE VPBXBMAP ASSEMBLE VPBXLTP ASSEMBLE VPBXREST ASSEMBLE VPCHKDIR ASSEMBLE VPFMT ASSEMBLE VPLOAD ASSEMBLE VPREST ASSEMBLE VPSCAN ASSEMBLE VPUNLD ASSEMBLE VPUTIL 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: 1.0 144 (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 VSSMMAC Toolmin: 1.0 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: VSSMMAC Toolmin: 1.0 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: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: VSMODID COPY RVSSTL LAS55015
VT550014 VMARC 01/27/12 14:01:06 * VSSI user message number corrections
Update VT550014 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: 1.0 144 (2012-01-22) Modules: RVTMSG ASSEMBLE
VP550014 VMARC 01/27/12 14:01:06 * 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: 1.0 144 (2012-01-22) Modules: RVPMSG 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: 1.0 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: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVSSTP ASSEMBLE
VP550012 VMARC 01/15/12 11:43:12 * Handle IOT double-dequeue
Update VP550012 applies to VSSI installation builds through 5502 Symptom: * Handle IOT double-dequeue Problem: A VPARS IOT was dequeued twice. The existing code checks for a valid buffer address at VTIREALA and ABENDs if an invalid address was found. The customer dump indicated a VTIREALA address of x'FFFFFFFF', indicating that the IOT was already dequeued (probably by another virtual machine using the same IOT). Resolution: Added logic to check for an invalid VTIREALA address and bypass the dequeue operation instead of generating a hard ABEND. BUILD_Reqd: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVPDBM ASSEMBLE RVPIOR ASSEMBLE
VT550011 VMARC 01/15/12 11:43:12 * Internal calibration modules
Update VT550011 applies to VSSI installation builds through 5502 Symptom: * Internal calibration modules Problem: Parsing code scatted over 3 separate modules. Resolution: Moved several parsing routines to new module RVSSTP. BUILD_Reqd: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVTSV2 ASSEMBLE
VP550011 VMARC 01/15/12 11:43:12 * Internal calibration modules
Update VP550011 applies to VSSI installation builds through 5502 Symptom: * Internal calibration modules Problem: Parsing code scatted over 3 separate modules. Resolution: Moved several parsing routines to new module RVSSTP. BUILD_Reqd: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVPSV1 ASSEMBLE
VS550011 VMARC 01/15/12 11:43:12 * Internal calibration modules
Update VS550011 applies to VSSI installation builds through 5502 Symptom: * Internal calibration modules Problem: Parsing code scatted over 3 separate modules. Resolution: Moved several parsing routines to new module RVSSTP. BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 144 (2012-01-22) Modules: VS55MAC $EXEC VSCFGBK COPY VSMODID COPY VSXCREG COPY RVSMDLAT MACRO RVSSTP ASSEMBLE RVSSTL LAS55011
VT550010 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VT550010 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: This update inserts the storage macros into all applicable modules. BUILD_Reqd: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVTADD ASSEMBLE RVTCMD ASSEMBLE RVTCON ASSEMBLE RVTIOR ASSEMBLE RVTLD1 ASSEMBLE RVTLD2 ASSEMBLE RVTMNT ASSEMBLE RVTOCS ASSEMBLE RVTOCT ASSEMBLE RVTOPC ASSEMBLE RVTOPN ASSEMBLE RVTQLB ASSEMBLE RVTQY1 ASSEMBLE RVTQY2 ASSEMBLE RVTRST ASSEMBLE RVTSCR ASSEMBLE RVTSHU ASSEMBLE RVTSPX ASSEMBLE RVTSTS ASSEMBLE RVTST1 ASSEMBLE RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV4 ASSEMBLE
VP550010 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VP550010 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: This update inserts the storage macros into all applicable modules. BUILD_Reqd: VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVPCCW ASSEMBLE RVPCFG ASSEMBLE RVPCON ASSEMBLE RVPCQY ASSEMBLE RVPCSP ASSEMBLE RVPDBM ASSEMBLE RVPDBT ASSEMBLE RVPIFC ASSEMBLE RVPIOR ASSEMBLE RVPOPN ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPRST ASSEMBLE RVPSET ASSEMBLE RVPSHU ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE
VS550010 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VS550010 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: This update inserts the storage macros into all applicable modules. BUILD_Reqd: VSSICP VSSICMS Toolmin: 1.0 144 (2012-01-22) Modules: VSXCREG COPY RVSCFG ASSEMBLE RVSPRM ASSEMBLE RVSUTL ASSEMBLE
VT550009 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VT550009 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: VSSI modules will now use the VSCPSTOR (for CP) and VSSTOR (for CMS) macros to obtain and release storage. These macros: . Enforce use of VSSI ID references (i.e., VSCPSTOR OBTAIN,ID=vssibk instead of HCPGETST LEN=some_length) . will zero out any obtained storage BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 144 (2012-01-22) Modules: RVTEXCBK COPY RVTMDLAT MACRO 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 RVTSUM ASSEMBLE RVTSV1 ASSEMBLE RVTSV2 ASSEMBLE RVTSV3 ASSEMBLE RVTSV4 ASSEMBLE VTBKVOL ASSEMBLE
VP550009 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VP550009 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: VSSI modules will now use the VSCPSTOR (for CP) and VSSTOR (for CMS) macros to obtain and release storage. These macros: . Enforce use of VSSI ID references (i.e., VSCPSTOR OBTAIN,ID=vssibk instead of HCPGETST LEN=some_length) . will zero out any obtained storage BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVPEXCBK COPY RVPMDLAT MACRO 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 RVPOPN ASSEMBLE RVPOPS ASSEMBLE RVPPRC ASSEMBLE RVPQY1 ASSEMBLE RVPQY2 ASSEMBLE RVPQY3 ASSEMBLE RVPRCC ASSEMBLE RVPSET ASSEMBLE RVPSV1 ASSEMBLE RVPSV2 ASSEMBLE RVPSV3 ASSEMBLE VPCPYASM ASSEMBLE
VS550009 VMARC 01/15/12 11:43:12 * Implement VSCPSTOR/VSSTOR functionality
Update VS550009 applies to VSSI installation builds through 5502 Symptom: * Implement VSCPSTOR/VSSTOR functionality Problem: Use of HCPGETST in VSSI modules does not enforce VSSI ID verification and control block memory zeroing. Resolution: VSSI modules will now use the VSCPSTOR (for CP) and VSSTOR (for CMS) macros to obtain and release storage. These macros: . Enforce use of VSSI ID references (i.e., VSCPSTOR OBTAIN,ID=vssibk instead of HCPGETST LEN=some_length) . will zero out any obtained storage BUILD_Reqd: VSSIPL VSSICP VSSICMS Toolmin: 1.0 144 (2012-01-22) Modules: VS55MAC $EXEC VSMSGPBK COPY VSXCREG COPY RVSMDLAT MACRO VSILX MACRO VSSTOR MACRO VSXRID MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSPRM ASSEMBLE RVSSTB ASSEMBLE RVSSTL LAS55009
VT550008 VMARC 01/15/12 11:43:12 * Version 55 synchronization
Update VT550008 applies to VSSI installation builds through 5502 Symptom: * Version 55 synchronization Problem: CPXLOAD will not work with cross-module references. (e.g., RVS module symbols refer to RVT ADCONs, and vice-versa). VSSI product components (RVS|RVP|RVT) must be able to be loaded and unload separately, as follows: . 1 CPXLOAD for all RVS (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVP (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVT (TEMP; can be unloaded/reloaded) In order for this to work, no component should have ADCON references to entry points in other component modules. Resolution: 1. All modules for a given component are CPXLOADed in one shot (via CPXLOAD INCLUDE directives). All internal ADCON cross-references are resolved during the CPXLOAD event. 2. Several data-only modules referred to from both VSSI Common code (RVS) and other components (VPARS, VTAPE) have been moved to new RVS modules. 3. Components needing to reference other component ADCONs have been changed to invoke CPEXIT code to access the symbols. 4. A stub module, RVSSTB, has been added. This module performs several critical and global CPEXIT tasks, and MUST be statically linked into the CP NUC. As this module is not expected to change frequently, regular VSSI maintenance should not require a CP NUC GEN. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVTMDLAT MACRO 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 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
VP550008 VMARC 01/15/12 11:43:12 * Version 55 synchronization
Update VP550008 applies to VSSI installation builds through 5502 Symptom: * Version 55 synchronization Problem: CPXLOAD will not work with cross-module references. (e.g., RVS module symbols refer to RVT ADCONs, and vice-versa). VSSI product components (RVS|RVP|RVT) must be able to be loaded and unload separately, as follows: . 1 CPXLOAD for all RVS (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVP (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVT (TEMP; can be unloaded/reloaded) In order for this to work, no component should have ADCON references to entry points in other component modules. Resolution: 1. All modules for a given component are CPXLOADed in one shot (via CPXLOAD INCLUDE directives). All internal ADCON cross-references are resolved during the CPXLOAD event. 2. Several data-only modules referred to from both VSSI Common code (RVS) and other components (VPARS, VTAPE) have been moved to new RVS modules. 3. Components needing to reference other component ADCONs have been changed to invoke CPEXIT code to access the symbols. 4. A stub module, RVSSTB, has been added. This module performs several critical and global CPEXIT tasks, and MUST be statically linked into the CP NUC. As this module is not expected to change frequently, regular VSSI maintenance should not require a CP NUC GEN. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: RVPMDLAT MACRO 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 VPCPYASM ASSEMBLE
VS550008 VMARC 01/15/12 11:43:12 * Version 55 synchronization
Update VS550008 applies to VSSI installation builds through 5502 Symptom: * Version 55 synchronization Problem: CPXLOAD will not work with cross-module references. (e.g., RVS module symbols refer to RVT ADCONs, and vice-versa). VSSI product components (RVS|RVP|RVT) must be able to be loaded and unload separately, as follows: . 1 CPXLOAD for all RVS (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVP (TEMP; can be unloaded/reloaded) . 1 CPXLOAD for all RVT (TEMP; can be unloaded/reloaded) In order for this to work, no component should have ADCON references to entry points in other component modules. Resolution: 1. All modules for a given component are CPXLOADed in one shot (via CPXLOAD INCLUDE directives). All internal ADCON cross-references are resolved during the CPXLOAD event. 2. Several data-only modules referred to from both VSSI Common code (RVS) and other components (VPARS, VTAPE) have been moved to new RVS modules. 3. Components needing to reference other component ADCONs have been changed to invoke CPEXIT code to access the symbols. 4. A stub module, RVSSTB, has been added. This module performs several critical and global CPEXIT tasks, and MUST be statically linked into the CP NUC. As this module is not expected to change frequently, regular VSSI maintenance should not require a CP NUC GEN. BUILD_Reqd: VSSIPL VSSICP Toolmin: 1.0 144 (2012-01-22) Modules: VS55MAC $EXEC VSSIEQU COPY RVSMDLAT MACRO VSILX MACRO VSMSGHE MACRO RVSCFG ASSEMBLE RVSCMD ASSEMBLE RVSMSG ASSEMBLE RVSPRM ASSEMBLE RVSSTB ASSEMBLE RVSUTL ASSEMBLE RVSSTL LAS55008