APAR status
Closed as canceled.
Error description
DB2 logic expects and REQUIRES that the START commands for the internal jobs (MSTR,DBM1) will be issued INTERNALLY. In as such, any AUTOMATION package, User Exit, security package (RACF, ACF2) Command AUTHORITY failure, or SSI that rejects these internally issued START commands, may result in some or all of the following errors. Some of these error scenarios follow: CUSTOMER IPL'D - START DB2 - ABEND04E RC00E80013. CUSTOMER IPL'D AGAIN - START DB2 - ABEND04E RC00F30216. (GTFTRACE also revealed RC00E80001). DSN3EC00 - GOOD PARAMETERS WERE PASSED TO MVS INTERNAL STARTUP MACRO SVC34 MGCR. MGCR RETURNED A BAD ASID IN GPR0 (FF000064) WHICH CAUSED THE ABEND04E RC00F30216. abend0C7 in DSN3EC0X (dump title may show failure in IEFJRASP) OEM MAINT- It was learned that OEM maintenance had been applied that was creating this problem (SEE SCRATCH PAD). (Note: Contact IBM lvl2 for SCRATCH PAD (Z) info.) This OEM product was intercepting the START command out of the SSI (SubSystem INTERFACE) and passed back a Return Code of 4 to MVS indicating to MGCR SVC34 to ignore this START command. This explains the BAD information passed back to DB2 since reg0 and reg15 would remain what they were after the FREEMAIN in MGCR, and it also explains why DB2 would NOT start. DB2 was started without the OEM product and all DB2 address spaces started successfully. No DSN3104i or DSN3100i messages when DB2 is shut down. DSN3104i Termination Complete DSN3100i Subsystem xxxx Ready for START Command msgDSN3104i msgDSN3100i Nothing at all: User issues -STA DB2 from an unauthorized source. The START command is accepted, but the S dsnMSTR internal command is rejected due to security. The START dsnMSTR command does NOT complete, subsequent -STA DB2 cmds produce NO results whatsoever.. The DB2 ERLY block has been left in an indeterminate STATE, IPL is needed to recover (see ow26652). Nothing at all: Same scenario as above, but instead of a security failure, the S dsnMSTER command fails because the SVC34 gets hit with an ECSA or Aux storage shortage. Command is lost, IPL is needed to recover. Additional Keywords: Start command ignored =====MTANG 08/13/2012 ============= Netview CRT (Command Revision Table) active can affect the START command. As with any MVS Command Exit, a return code of 4 means that the exit made a decision to suppress thecommand. In the CRT, there are 2 ways of doing this: by using a REVISE statement with 'Y' DELETE or by specifying NETVONLY. System trace shows z/OS module calls Netview as Command Installation Exit. DSIRVCEX executing during the SVC 22 (MCGR) call. The following abends occurred aside from the 00F30216 abnd ABND=04E-00E30080,U=SYSOPR ,M=? ,C=101.IPC -DSNYAGCS,M=DSNYECTE,LOC=DSNTLM2 .DSNTLIDE+0F74 MODULE DXRRL732:02 PM15077 P-LOCK DIAGNOSTIC DUMP (DIAG,PLOCK) DIAGNOSTIC DUMP INITIATED BY JTF1 MODULE DXRRL732:02 P-LOCK DIAGNOSTIC DUMP (DIAG,PLOCK) =============MTANG 01/03/2012 ========================== RC00F30216 dump shows R3=4 which is MGCR return code indicating the START command was suppressed by the SSI or a command exit. Mtrace shows message from vendor product: OPS1000I SSMSTART: DESIRED STATE OF DMVSMSTR CHANGED FROM UP TO UP|| The abending primary asid is a batch job which was ended right before the message OPS1000I. Customer was able to start up DB2 after he issued AutoOps shut down and brought it back up via the command RT ssssMSTR DOWN and then RT ssssMSTR UP. List of known fixes ------------------- ================================================================ 4/3/01 SGC Additional Info: A customer that experienced the ERLY overlay of the fullword at offset + x'30' (with an apparent low private address) reported that Candle has identified a problem with a feature called Historical Collector (aka History Collector). The customer also advised that this feature of Omegamon can be deactivated as a workaround. No specific fix info available at this time. ============================================================ 1/30/95 Additional info: Another situation with RC00E80013 as the restart symptom was found to be due to user coded procedures for oem product Automate from Legent. Deactivating Automate allowed DB2 to restart. ============================================================== ALSO BEWARE automation product AutoOps . Some times it tells the user to issue 'DB2 restricted' MVS command: S ssnmMSTR the object being that the OEM product will intercept this MVS command, and change it to a: -START DB2 command. This could cause problems. If you get out of sync and cannot Start DB2 and need to use the following zap, then AutoOps must first be disabled.. -------------------------------------------------------------- 11-07-01 rjl rc00f30219 has been seen for damage to the ERLYEMST state number. The value was greater than 02. 00 01 02 are the only valid values. This is location +33 in the erly. Overlaid data is also seen in ERLYASID erly+30 for two bytes and erly+32. This byte is not used and should be 00. Storage getmain failures have been reported just prior to db2 starting the termination that does not complete due to the overlay of the erly control block. This prevents a restart of db2. The zap given in the Z page usually allows db2 to restart without an IPL. ===========MMT 03/04/2008============================ Notes on using the 'zap' technique: "In LPAR E79, subsystem DB02, ERLYCPFS = M (System scope). In LPAR E80, subsystem DB02, ERLYCPFS = S (Sysplex scope). If ERLYCPFS = 'S' during initialization (or 'X' during IPL), initialization code will do a CPF DEFINE to register the command prefix. During termination, DB2 code will do a CPF DELETE to unregister the command prefix. However, if ERLYCPFS is zapped to 'M' after ERLY initialization then at DB2 termination, the CPF DELETE is not going to be executed and the command prefix will remain registeredon E79. After zapping +6E to M to enable DB2 to start, customer needs to zap it back to S to allow the command prefix to be unregistered at termination time." Customer has tested this and it works - avoided a re-ipl.
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
THIS IS AN INFORMATION APAR. ADDITIONAL COMMENTS/SYMPTOMS: SYSLOG ABEND04F rc00000000, LOGREC has RC00E80001 In another scenario, the automated operations package was coded to issue -START dsnMSTR, which CANNOT be done. MSTR and DBM1 cannot be started separately. DB2 cmd : -START DB2 MUST be used to start the DB2 Started Tasks internally.!!!!!! ---------------------------------------------------------------- Additional info: Another customer having the rc00f30216 problem found that their oem automated operator had a 'RULE' defined such that all MVS start commands (ie; for Started Tasks) would be intercepted. Removing this RULE allowed db2 to start without error. ---------------------------------------------------------------- This error is in no way confined to OEM products. In fact, any SSI that handles and rejects the internal DB2 job start commands will cause the DB2 ABEND04E RC00f30216 to be issued. SVC34 = commands SVC35 = messages Normally, all SVC34 and SVC35 operations are first handled by the JES SSI (HASPSSSM for JES2). RACF and many other B1 level security products have the function and ability to intercept and REJECT any command issued from any source in the MVS/ESA system. For DB2 R510, most if not all of the aforenoted scenarios can be fixed by installing MVS apar ow26652 and DB2 pq18098 an pq24229. But, one cannot totally predict the future, nor can one predict how standard logic will always react to non-standard alterations, inasmuch, there will probably always be a need for the associated ERLY control block 'ZAP'.... Some items of note: If MVS Master Scheduler rejects a command, msgIEE707i is issued. When the DB2 subsystem logic detects that DB2 has come down, 2 DB2 messages are issued: msgDSN3104i Termination Complete msgDSN3100i Subsystem xxxx Ready for START Command If an error occurs during DB2 subsystem termination that prevents these messages from being issued, there is a good possibility that DB2 restart will fail because the ERLY block has been left in an indeterminate state. A failure in DSN3SSI1 can cause this mishap, see pq24229. (check the 'Z' page of this infoapar for OEM and ZAP info) (the ZAP of the ERLY control block may save an IPL.)
APAR Information
APAR number
II04773
Reported component name
PB LIB INFO ITE
Reported component ID
INFOPBLIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1990-12-18
Closed date
1990-12-18
Last modified date
2012-08-13
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
13 December 2020