Installing Z/vm On Hercules
Error description: Running zVM 5.4.0 as the primary OS on Hercules and performing a normal zVM 6.3.0 install as second level guest leads to iterative DSP005 system errors after restoration of the system mini disks and IPL of that newly generated system. During the first IPL the installation process is not finished yet. The system restores certain disks using DDR restore. During this phase the DSP005 happens, the guest OS takes a dump and restarts. After second DSP005 the system enters disabled wait state 9026. The collection of that dump information is quite difficult because the system is not installed completely and therefore there is no interactive environment to use.
DSP005: Explanation: The value of the processing unit timer is greater than it was at user dispatch. There is probably an error in switching timers. User response: Examine the CP trace table and storage dump for possible solutions. CR12 points to the next available CP trace table entry after the failure. Hi Ivan, Yes indeed.
Because of the information about the changes done regarding SIE, I compiled yesterday the latest committed version of Hyperion. In first level, up to now, I didn't face the problem of the TCP/IP start any more. This is great. That bug of getting a network connection or not was a nightmare for many years. However up to now I didn't face any DSP005 abends during a second level installation. Some weeks ago I run a first level installation of zVM 6.3.0 and more ore less it was successful.
There the problem was that under some unknown conditions CMS faced a corrupted storage area in its nucleus and abended. That affected for instance the ipwizard exec and left the TCP/IP stack unconfigured. So that problem seems to be fixed with the current change. This time I wanted to run a clean install for 6.3 to replace my old 5.4 version once and for good. Well, unfortunately, there seems to be still at leased one obstacle in front.
Z/VM install files and Hercules. Jan 11, 2008. Hello guys, I'm new in this Mainframe world and I have a question: I have the z/VM installation DVD.
If I can provide you with more info please let me know. Hi Ivan, Yes indeed. Because of the information about the changes done regarding SIE, I compiled yesterday the latest committed version of Hyperion.
Download video super 7 sahabat best friend forever. In first level, up to now, I didn't face the problem of the TCP/IP start any more. This is great.
That bug of getting a network connection or not was a nightmare for many years. However up to now I didn't face any DSP005 abends during a second level installation. Some weeks ago I run a first level installation of zVM 6.3.0 and more ore less it was successful. There the problem was that under some unknown conditions CMS faced a corrupted storage area in its nucleus and abended. That affected for instance the ipwizard exec and left the TCP/IP stack unconfigured. So that problem seems to be fixed with the current change. This time I wanted to run a clean install for 6.3 to replace my old 5.4 version once and for good.
Well, unfortunately, there seems to be still at leased one obstacle in front. If I can provide you with more info please let me know. Dear Florian, I have been unable to reproduce the DSP005 Abend during the 2nd level z/VM 6.3 (non-SSI) installation. Just to be sure, I tried it two times, but on both occasions all worked perfectly ending up with a clean z/VM 6.3 installation.
Z/vm Version 6.3 Commands
Both took indeed more than 6 hours. Down below you’ll find an extract of the installation log including the two DDR’s restores which I saw happening. I tried this under (one of the members of) my z/VM 6.3 (SSI).
However, somehow I don’t think that z/VM 5.4 as a 1st level z/VM is the cause of the DSP005, but perhaps rather the fact of z/VM 5.4 having been installed or running under Hercules prior to the TLP/ALB PURGE fix might have become somehow corrupt. I know this is a wild guess. But after the TLB/ALB PURGE fix, my z/VM 6.3 system’s DIRMAINT exhibited a CRC error, which I could correct by performing a USER DIRECT recovery (as prescribed in an IBM manual). This too, I thought, was caused the TLB/ALB PURGE problem (but then subsequently, after the TLB/ALB PURGE fix, recovered).
In summary, I think the TLB/ALB PURGE fix has resulted in SIE working perfectly. It might be improved on performance wise by purging a more limited number of TLB/ALB entries, but I think the functionality now is better than it ever was. Perhaps even perfect. (As usual, until we discover the next problem of course ). Dear Florian, I have been unable to reproduce the DSP005 Abend during the 2nd level z/VM 6.3 (non-SSI) installation. Just to be sure, I tried it two times, but on both occasions all worked perfectly ending up with a clean z/VM 6.3 installation.
Installing Z/vm On Hercules
Both took indeed more than 6 hours. Down below you’ll find an extract of the installation log including the two DDR’s restores which I saw happening. I tried this under (one of the members of) my z/VM 6.3 (SSI). However, somehow I don’t think that z/VM 5.4 as a 1st level z/VM is the cause of the DSP005, but perhaps rather the fact of z/VM 5.4 having been installed or running under Hercules prior to the TLP/ALB PURGE fix might have become somehow corrupt. I know this is a wild guess. But after the TLB/ALB PURGE fix, my z/VM 6.3 system’s DIRMAINT exhibited a CRC error, which I could correct by performing a USER DIRECT recovery (as prescribed in an IBM manual).
This too, I thought, was caused the TLB/ALB PURGE problem (but then subsequently, after the TLB/ALB PURGE fix, recovered). In summary, I think the TLB/ALB PURGE fix has resulted in SIE working perfectly. It might be improved on performance wise by purging a more limited number of TLB/ALB entries, but I think the functionality now is better than it ever was. Perhaps even perfect. (As usual, until we discover the next problem of course ).
Z/vm Installation Guide
Thanks for the info John. In my case, z/VM 6.3 (SSI) installed prior to TLB/ALB PURGE fix worked fine, apart from the intermittent known anomalies (e.g.
TCPIP not always starting up, sometimes PIPE errors, etc.). Subsequent to the TLB/ALB PURGE fix all these went away. But then when I tried to perform another DIRM ADD (VMINSTAL, for my 2nd level z/VM install) DirMaint complained about a CRC error, which I recovered from using an earlier USER DIRECT backup following IBM’s published procedure. So to me this looked like the TLB/ALB PURGE problem had created an incorrect / corrupted CRC.
Which is what leads me to now distrust any z/VM installed or running with that Hercules problem unsolved. In my case the CRC algorithm has not changed, but perhaps with the TLB/ALB PURGE problem it may have created wrong CRC’s. Thanks for the info John. In my case, z/VM 6.3 (SSI) installed prior to TLB/ALB PURGE fix worked fine, apart from the intermittent known anomalies (e.g. TCPIP not always starting up, sometimes PIPE errors, etc.).
Subsequent to the TLB/ALB PURGE fix all these went away. But then when I tried to perform another DIRM ADD (VMINSTAL, for my 2nd level z/VM install) DirMaint complained about a CRC error, which I recovered from using an earlier USER DIRECT backup following IBM’s published procedure.
So to me this looked like the TLB/ALB PURGE problem had created an incorrect / corrupted CRC. Which is what leads me to now distrust any z/VM installed or running with that Hercules problem unsolved. In my case the CRC algorithm has not changed, but perhaps with the TLB/ALB PURGE problem it may have created wrong CRC’s.