This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
MainView SRM Allocation
MainView SRM Allocation
When the MainView SRM started task is started, it receives the following error messages:
DIS1001E DATA COMPARE ERROR DURING VERIFY PROCESSING
SVO0400E PROGRAM ETIDYNAM HAD A RETURN CODE X'010'
SVO0627I MAINVIEW SRM/ALLOC 7.9.00 STOPPING ON ETIS
SVO0629E MAINVIEW SRM/ALLOC 7.9.00 HAS BEEN STOPPED ON ETIS
*SVO0612W START FOR SVALLOC FAILED ON ETIS
Here are two possibilities that are causing this error at start up:
1. If your site is running any of the IBM modules that MainView SRM (SVOS) hooks out of a temporary MLPA library, separate from your normal CLPA library, then SVOS needs to know about the MLPA library. Add it, temporarily, to the SMMSYSxx parm member as an additional SYSLIB parameter to be searched for IBM modules to be hooked. That would be done by using the following setup in SMMSYSxx:
SYSLIB1=clpa.library.name <==== this is usually SYS1.LPALIB
2. There may be another OEM product already active that hooks the same IBM modules as MainView SRM. Check the SYSPRINT portion of the SVOS job log and search for output similar to the following, to determine if there is another OEM product that is preventing SVOS setting it's hook. In the following example, a CA product is preventing the successful setting of a hook in IBM module IGC0001I, csect IFG01961:
DIS1000E VERIFICATION ERROR AT: 00E6EF7C. DISP: 0000209C IN IGC0001I.IFG0196L
DIS9001I -------- + DISPLAY OF MODULE AT ADDRESS 00E6EF7C
DIS9000I 00CB8F40 + 0000 A7F4005C 00BE0118 00CB8FF8 AB000000 x4.*.......8....
DIS9000I 00CB8F50 + 0010 CA7BD4C9 C4CA0100 004800A8 00000010 ..MID......y....
DIS9000I 00CB8F60 + 0020 C5C3C1F0 C5E7F0C9 40C3C3C5 D4F6F0F0 ECA0EX0I CCEM600
DIS9000I 00CB8F70 + 0030 4040A1D9 D4C9C44D D9C5E2C5 D9E5C55D .RMID.RESERVE.
DIS9000I 00CB8F80 + 0040 A140F2F0 F1F6F1F0 F1F440F1 F24BF3F0 . 20161014 12.30
DIS9000I 00CB8F90 + 0050 40000000 00000000 C3C140C3 C5D44040 .......CA CEM
DIS9000I 00CB8FA0 + 0060 40404040 40404040 40404040 40404040
DIS9000I 00CB8FB0 + 0070 40D9F54B F0404040 406040C3 D6D7E8D9 R5.0 . COPYR
DIS9000I 00CB8FC0 + 0080 C9C7C8E3 404DC35D 40F2F0F1 F6404040 IGHT .C. 2016
DIS9000I 00CB8FD0 + 0090 404040C3 C14B4040 40C1D3D3 40D9C9C7 CA. ALL RIG
DIS9000I 00CB8FE0 + 00A0 C8E3E240 D9C5E2C5 D9E5C5C4 4B404040 HTS RESERVED.
DIS9000I 00CB8FF0 + 00B0 40404040 40404040 58F0F004 0B0FF5F6 .00...56
DIS9000I 00CB9000 + 00C0 00000000 00000000 00000000 00000000 ................
DIS9000I 00CB9010 + 00D0 00000000 00000000 00000000 00000000 ................
DIS9000I 00CB9020 + 00E0 00BEAE98 F1000040 F10000D0 00C98100 ...q1.. 1....Ia.
DIS9000I 00CB9030 + 00F0 00BE72A0 00CC0020 00000000 00000000 ................
The eye catcher portion of the output shows what is preventing the successful hook. In most cases. If you can determine in what order that product and SVOS were brought up and brought down, the last time they were recycled, you can usually correct the issue by bringing the products down in the reverse order that they were brought up. If SVOS was brought up first, and then the other OEM product was brought up, since they frontend the same IBM modules, they need to be brought down in reverse order. In other words, there needs to be a last in first out relationship between the products. If SVOS was up first, and then the other OEM product, the other OEM product must be brought down before SVOS can be brought down. Try bringing down the other OEM product and try bringing SVOS back up.