Find Answers

Filter Search Results
All Operating Systems:
All Products:

All Solution Types:
Source:
 
Ask a Question
Example: "Database could not be verified"  
Tips | Start Over | Solutions | Alerts | Patches | Defects  
Pages [Next]
  Results
CMS-XML COBOL Compile failure after the precompile step of a DB2 program causes CMNBATCH to issue an RC=12.
When the COBOL compile step for a DB2 program fails, CMNBAT90 has already run to create records to tie the DBRM relationship back to the source. When the COBOL compile step subsequently fails, the DBRM member does not get copied to the staging dataset, due to the bad condition code, as that step runs after the compile step. When The CMNBATCH / FAILURE step subsequently runs, RC=12 is issued due to the missing DBRM in the staging library and issues the following message:
CMS-XML DB2 COBOL compile step fails with RC=12 resulting in FAILURE step also getting a RC=12 when it should be RC=00
When the ' DB2 Processing' option is selected and the COBOL compile step fails with a RC= 12 , this time the DB2 precompile step ( DB2 PC) and B90DBR Steps are added to the job and the FAILURE step will also get a RC= 12 resulting in the user not being notified of the compile failure. Only indication of the compile failure is the componenet is still in INCOMP status.
CMS-XML Dim CM 12.2 - Incorrect variable reference in DB2 template expansion running Build
When running a DB2 Build template the build is failing and the following error is displayed under the Build Monitor: - "MDHTPL1601029E Incorrect variable DB2OWNERNAME reference in template expansion - Bad variable - not defined" The following details appear in the error log: -
CMS-XML SUCCESS step rc=12 ERROR OCCURRED DURING HASHING OF MEMBER
Compiling a component with CMNCOBE and DB2 Processing selected, without SQL in the source will generated a blank DBR and the ERROR OCCURRED DURING HASHING OF MEMBER in the SUCCESS step
CMS-XML CMNDB2PL fails with Invalid syntax encountered. DB2 keyword = PATH
CMNDB2PL is failing with a RC= 12 and the following messages...
CMS-XML DMCM12: Is it possible to run UPGRADEDEPLOY in two databases in parallel?
Taking two databases as an example, database 1 (DB1) has areas defined against z'OS agents and database 2 ( DB2 ) has areas defined on Windows and AIX agents. Each set of agents for the two databases are completely separate - the only common thing is the Dimensions server.
CMS-XML S0C4 in CMNDB2PL at offset 12F4 when "source" template is entirely filled.
Using the "search and replace" templating technique in DB2 PL, if you completely fill the "source" column" you will encounter a S0C4 in CMNDB2PL at offset 12 F4. For example, the SRCQUALTEMPLATE has a max length of 8. If you supply a template that is 8 bytes long, you will encounter the S0C4. For example...
CMS-XML Dim 12/14: z/Os Build returns: IGW01001T ABEND 213-00000030 IN MODULE ???????? AT OFFSET ????
When building a db2 cobol program, the compiler creates the DBRM, when specifying the //*SBEM TGT DBRM to preserve the dbrm component, an abend 213 rc=30 is returned sporadically.
CMS-XML CMNRAHAR parm error processing 'short' DB2 subsystem names
The CMNRAHAR utility is provided to maintain the size of the ERO DB2 history table. The DB2 subsystem is passed to the program as a JCL parameter. When processing 'short' DB2 subsystem names (i.e. any that are three characters or less) the CMNRAHAR job fails with a RC= 12 in the EXTRACT step and the following error message:
CMS-XML S0C7/S0C4 abends in PDSPEDIT using VERT mode from DB2 table display
4) when the table displays, enter VERT on the command line 5) s0c4 abend results in customer environment using DB2 V 12 . PDS999E S0C4-0004 U0000 AT +00024E56 IN PROGRAM PDSPEDIT:*UNKNOWN
Pages [Next]

Welcome kb sso

My Recent Searches

Search Feedback

Are we answering your questions?

Additional Assistance

  • Submit a Case Online
  • FAQs