Stubx Processor Messages (COPnnn)

COPE Stubx Processor messages (COP nnn ) are documented both in this space and interactively under IMS and ISPF in help panels. To access the
Explanation: text of a COP nnn message, enter COP nnn or nnn on any COPE ISPF menu, or from the COPE screen under IMS. To get the COPE screen under IMS, press Clear, type COPE, and hit Enter. Alternatively, type "COPE COP nnn " or " COPE nnn " from a cleared screen.

Number

Description

COP033

=ERR=> Old COPERCFE is linked in xxxxxxxx, but COPERCXL is new

Explanation: You have installed the latest release of COPE incorrectly. You have the old version (pre- release 3.9.9) of the Front-End, COPERCFE, linked on the front of DFSRRC00 (or other front-ended IMS module), but you have the new version of the XLate, COPERCXL, loadable from the current STEPLIB or Tasklib.
When you installed the new version of COPERCXL you should have re-linked DFSRRC00 with the new version of COPERCFE on the front.

System Action: The COPE front-end, COPERCXL, terminates with a condition. code 16. DFSRRC00 (or other front ended IMS module) is not executable from this RESLIB till you fix this problem.

User Response: Do option 1.6 and run the job that this generates, to re-link DFSRRC00 (and any other IMS modules that are front-ended) with the new COPERCFE.
Be sure that you rerun this Linkedit JCL on all RESLIBs for which you will run COPE regions from.
To determine which RESLIBs have COPERCFE in them, browse all RESLIBs, select DFSRRC00, and F COPERCFE. If it is found, look at the release number. If it is earlier than 3.9.9, this is the old RCFE, and must be re-linked. If it is not found, this DFSRRC00 does not have the COPE front-end (and should not have it) so don't re-link in this RESLIB.

COP034

=ERR=> Cannot execute COPERCFE stand-alone, must be linked with DFSRRC00

Explanation: The COPE front-end, COPERCFE, was executed, but it has no resolved reference to DFSRRC00 in its table of weak externals. This means that you are executing COPERCFE standalone (or have link edited RCFE with an IMS module that it should not be link edited with). You should be executing a version of DFSRRC00 that has RCFE linked on the front of it.
DFSRRC00 must be linked with COPE module COPERCFE, with and ENTRY COPERCFE, and a NAME DFSRRC00(R). The same applies to IMS utility modules front-ended, other than DFSRRC00.

System Action: The process terminates with RC=16.

User Response: Access option 1.6, then regenerate and run the front-end linking job. Execute DFSRRC00 (e.g. EXEC PGM=DFSRRC00), not COPERCFE.

COP035

=WARN> Chose xxxx Wxtrn in yyyyyyyy: zzzz

Explanation: The COPE front-end, COPERCFE, is link edited with a program that contains more than one entry- point or Csect with names that COPE intercepts. For example, you might have link edited COPERCFE with a module that has Csects called DFSRRC00 and FABHX034 inside it. These two would be seen by RCFE's weak externals, and therefore it is uncertain whether you want DFSRRC00 or FABHX034 invoked.

The list of weak externals is inside RCFE.

This is a warning only -- the situation will probably be resolved, because COPE will assume you want the Csect name that matches the module name, for this module.

System Action: The COPE front-end processor, COPERCXL, will choose between the multiple weak externals on the basis of which one matches the CDE. If none match the CDE, it will default to the first one (in RCFE's list).
If the choice turns out to be wrong, for the program being front-ended, the results are unpredictable.

User Response: Check you followed correct COPE install instructions, when running option 1.6 (the job that Linkedits the RCFE front-end on DFSRRC00 and other IMS modules). Call BMC for assistance if needed.

COP040

Non-recursive invocation

Explanation: The COPE front-end processor has received control for the first time. This is normal operation.

System Action: The COPE front-end processor, COPERCXL, continues.

User Response: This message is information only. Its absence would indicate that the COPE front- end is not getting control properly, or that it is getting control recursively, which may or may not be an error. This message is intended to assist with debugging problems with the COPE front-end, COPERCXL, should they occur.

COP041

=WARN> RCXL is below 16M line

Explanation: The COPE front-end processor, COPERCXL, is residing below the line. This will affect below-the line region size (RCXL is about 200K in size).

System Action: The COPE front-end processor, COPERCXL, continues.

User Response: This message is information only. If necessary, link-edit COPERCXL with MODE AMODE(31), RMODE(ANY) to make it reside above the line, as it should.

COP042

Linking to COPERC00, passing dd=xxxx

Explanation: The front-end, COPERCXL, is linking to COPERC00, in order to initialize the environment for translating database names in PCB's.

The passed DD is the allocated "STEPLIB" which from this point onward, will be concatenated in front of the existing STEPLIB.

System Action: COPERCXL links to COPERC00, which will attach DFSRRC00, with DCB=passed DD, and TASKLIB=same DD, on the ATTACH. DCB= causes DFSRRC00 itself to come from the allocated STEPLIB (if DFSRRC00 is present). TASKLIB= causes all subsequent modules to come from allocated STEPLIB. This gives a second entry into RCXL, which this time invokes the IMS DFSRRC00.
IMS invokes the Stubx passed by COPERC00 on the Parm, which then calls the application program.

User Response: The absence of this message would mean that no Stubxcan be invoked, which means no PCB translation can occur. This would be incorrect in MSG IFP BMP DLI or DBB regions, but is correct in other region types: ULU, UPB, CTL, DLS, DBR.

COP043

=ERR=> COPERC00 missing from STEPLIB/JOBLIB/Tasklib

Explanation: The COPE Unconverted JCL preprocessor has determined that the COPE region controller module COPERC00 is required and has issued a LINK to it. The module could not be found in the JOBLIB or STEPLIB defined in the JOB.

System Action: The process terminates with RC=8.

User Response: Add a DD statement to the JOBLIB or STEPLIB that points to the COPE installation load library that contains the load module COPERC00.

COP044

No recognizable COPE system Id - invoking xxxx unaltered

Explanation: The DFSRRC00 front-end has failed to find an identification of a logical system in either the IMSID position in the Parm field or the second positional parameter in the Jobcard or as the last qualifier of the dataset name allocated to a COPEBSYS DD.
If this is a non- COPE region, this is intentional.

For DLI/DBB/ULU regions, IMSID is 12th parameter (11 commas in)

For BMP regions, IMSID is 14th parameter (13 commas in)

System Action: The COPE front-end, COPERCXL, invokes DFSRRC00 (or other IMS program specified on the EXEC PGM=), unaltered. The effect of this is non- COPE execution (no PSB name translate, or reallocations).

User Response: If you want to execute in a COPE region, change the JCL or allocations so that the Lsys name you want to execute in is in either the IMSID position in the Parm field or the second positional parameter in the Jobcard or as the last qualifier of a dataset name allocated to a COPEBSYS DD.
If you want to execute in a non- COPE region, ignore this message -- it is for information only, and has no effect.

For DLI/DBB/ULU regions, IMSID is 12th parameter (11 commas in).

For BMP regions, IMSID is 14th parameter (13 commas in).

COP045

xxxx region is unmodified by COPE

Explanation: This DLI region type is not supported by the COPE unconverted JCL option.

System Action: The processing of the application continues without alteration.

User Response: If modifications to the JCL are required, they must be made explicitly before execution of the JOB. Similarly, all PSB and DBD names must be converted to COPE values before job submission.

COP046

Calling xxxx, tasklibs=yyyy

Explanation: We are about to transfer control from COPE processing to IMS code, either DFSRRC00 or an IMS utility. The current tasklib DDs are displayed. These act like a STEPLIB made up of a concatenation of multiple DDs.

System Action: The front-end processor, COPERCXL, calls DFSRRC00, DFSUDMP0, FABXH035, PCPCHECK, or other IMS or vendor utility that has RCFE linkedited on the front.

User Response: Information only. The tasklib DDs displayed should clarify the order of DDs searched for modules, when solving module-version or load failure application problems.

COP047

Length=xx bad in PARM=yyyyyyyy zzzzzzzz...

Explanation: The front-end processor, COPERCXL, has been invoked with a PARM= that has a length less than zero or greater than 255. This means that you have some application that calls DFSRRC00, or some other IMS program, and passes this bad parm. R1 is meant to point to a pointer to a 2-byte binary length (that does not include itself) on the front of the Parm string.

System Action: COPERCXL ignores the bad parm, which means that any PSB name that should be in the parm won't be translated, and the Psys/Lsys might not be identified (if you intended to use the IMSID field in the parm for this purpose). When COPE passes this bad parm to IMS, IMS will prob- ably issue a U64x abend, or similar.

User Response: The display of the parm field given in the message should provide clues as to why some one of your applications is calling DFSRRC00 or other IMS utility with this bad parm.

COP048

* Stepname=xxxx start of COPE allocation information

Explanation: The front-end processor, COPERCXL, has found the Lsys this region is to run in, and is starting to allocate libraries, translate utility input cards, and translate PSB and DBD names, and the IMSID, on the PARM=.

The messages following this box show you the actions taken by COPE .

System Action: COPERCXL continues normally.

User Response: The stepname appearing in the message helps you identify the step in a multi-step job that the allocation messages following this box apply to.

COP051

=WARN> No TASKLIB found for xxxx in XRF4

Explanation: The load COPEXRF4 module does not contain a TASKLIB definition for the defined Lsys.

System Action: Processing continues - probable error.

User Response: Check the TASKLIB definitions using option 4.11, and regenerate COPEXRF4 and submit the generated job.

COP052

=ERR=> Bad XRF4, xxxxxxxx

Explanation: The COPE subroutine COPESXLS determined that the format of COPEXRF4 was bad.

System Action: The processing is terminated with RC=12.

User Response: Correct and regenerate COPEXRF4 using option 4.11. Rerun the job.

COP054

=ERR=> Lsys xxxx not found in COPEXRF1

Explanation: The COPEXRF1 translate table was generated when this Lsys did not exist in this Psys, or XRF5 for this Psys points to the wrong XCOPEPGM (Stubx) library.

System Action: COPERCXL bypasses translation and reallocation of database DDs. If this is a DLI or DBB region, this could mean that the application program will get NA (Not Available) status codes for all databases.

User Response: Check the COPEXRF1 module was loaded from the correct Stubx library. If the Stubx library dataset name (given in previous messages) is not correct for this Psys, the problem is in COPEXRF5, which contains the Stubx library dataset name. Run option 1.6 in the Psys to generate a new XRF5.

Browse the COPEXRF1 load module in the Stubx library. Do a Find on the Lsys. If not found, regenerate COPEXRF1 in the Psys, using option 4;2;REFRESH, and then it will contain this Lsys. If Lsys is found, call BMC for assistance.

COP056

=ERR=> Bad XRF1, xxxxxxxx

Explanation: Some format error in COPEXRF1 has been found.

System Action: The process is terminated with RC=12.

User Response: Use option 4.2.REFRESH to regenerate COPEXRF1 after checking that the COPEXRF1 has been loaded from the correct PGMLIB associated with the Physical system.

COP061

Psys/Lsys=xxxx.yyyy (from zzzz tok=aaaa bbbb)

Explanation: The COPE front-end has identified the Lsys within Psys to run in.

The token that caused the identification came from the IMSID on the PARM=, or from the 2nd Programmer name field of the JOB card, or from the last qualifier of the COPEBSYS DD, as stated in the "from zzzz" in the message. COPE looked up the token in the COPEPSYS table load module, loaded from STEPLIB, and found the token-type "aaaa" and token value "bbbb". Token types can be EIMSID or JPGMR, and correspond to the type in the table entries in option 1.6, and token values are 1-17 characters, also specified in option 1.6.

System Action: The front end processor, COPERCXL, continues normally, and will start allocating datasets, converting allocated database DDnames, and translating PSB and DBD names in the PARM= and in utility input cards, and the IMSID in the PARM=.

User Response: If the Psys/Lsys is not the one you want to run this job step in, change the JCL to specify a token (usually the Lsys name) in either (1) the IMSID field in the Parm field, or (2) the programmers name field in the JOB card or (3) a COPEBSYS DD dataset name suffix.

If running in TSO foreground, the IMSID method is usually the most convenient.

For DLI/DBB/ULU regions, IMSID is 12th parameter (11 commas in).

For BMP regions, IMSID is 14th parameter (13 commas in).

If you use the COPEBSYS method, the COPEBSYS DD can be in any step of the job (does not need to be current step), and COPE will use the first COPEBSYS in the job. However, it will only use COPEBSYS if the other two methods fail to produce a match first. COPE tries the IMSID, then the job card 2nd parameter, then COPEBSYS.

To see what tokens identify which Psys/Lsys's, go into ISPF option 1.6.

To set new tokens to identify Psys/Lsys's, go into ISPF option 1.6, change the table, and submit the generated job.

COP062

COPEXRF1,2,4,5 loaded from xxxx

Explanation: The COPE front end on DFSRRC00 processor has loaded the XRFn translation tables from the Stubx library (XCOPEPGM variable) named.

System Action: The processing continues.

User Response: Use these messages to help debug any problems with the translation process. Ensure that the dataset is the correct XCOPEPGM library for the Psys.

COP063

=ERR=> Open failed for load DD xxxxxxxx

Explanation: The DDname in the message is allocated to the Stubx lib for the Psys being processed by the unconverted JCL preprocessor, and has failed to open.

System Action: Processing is terminated with RC=12 in COPERCXL.

User Response: Check that the PGMLIB (Stubx library - variable XCOPEPGM) is correct for this Psys. If not, use option 1.6 to define a new PGMLIB for the Psys and rerun the job generated by option 1.6.

COP064

=ERR=> Dsn=xxxx missing from yyyy required in TSO

Explanation: The DFSRRC00 front-end is executing under TSO and the COPE Stubx library (XCOPEPGM library) is not allocated to the Tasklib DD (current Task's STEPLIB).

You must allocate this DD to the Stubx library, plus the COPE software LOAD library, plus your regular program libraries, in order to execute in TSO foreground (for example, under VIACOM, or Cobol II Debug).

System Action: The COPE front-end processor, COPERCXL, continues. Later, when DFSRRC00 goes to load the Cnnnnnnn Stubx, it will get a load failure, because the Stubx library is not on the Tasklib.

User Response: If running under Viacom, make sure that your program load library screen has XCOPEPGM and XCOPE1.LOAD included. For Cobol II Debug, or other TSO foreground invocation, include these libraries in the ALLOCATION DD(TASKLIB) Clist statement, or other method you use to do allocations. Call BMC support if the problem cannot be resolved.

COP065

Allocation xxxx to yyyy zzzz

Explanation: The COPE front-end processor will allocate the named DDname to the named dataset name, so that a COPE DLI region can work.

Cnnnnnnn is a Database that you explicitly included in the JCL (under its non-Cnnnnnnn name). This stops IMS from allocating using DFSMDA, or via DBRC in some environments.

STEPLIB is where application program loads will come from. JCL libraries (from STEPLIB in JCL) come before Lsys libraries (from option 4.11, via XRF4) which come before Psys libraries (from ZDEFAULT via XRF5).

IMS or IMSACBx are the COPE PSB/DBD/Acb libs, containing the COPE C-number PSB's/DBD's/ ACB's.

RECONn are the COPE Recons for this Psys.

COPEBSYS is to a dataset name with the last qualifier equal to the Lsys. This tells internal COPE processing which Lsys to run in.

System Action: The processing by COPERCXL continues normally.

User Response: Use these messages to help identify any problems in the event of a problem that is associated with allocations, load failures, etc.

COP066

Bad return from dataset allocation as follows

Explanation: An internally generated dataset allocation command failed for reasons shown in the following messages.

System Action: The processing terminates with RC=8.

User Response: Use these messages to help fix the allocation problem.

COP067

DD=xxxx yyyy

Explanation: An internally generated dataset allocation command failed for reasons shown in these messages.

System Action: The processing terminates with RC=8, in COPERCXL.

User Response: Use these messages to help fix the allocation problem.

COP067

DD=xxxx yyyy

Explanation: An internally generated dataset allocation command failed for reasons shown in these messages.

System Action: The processing terminates with RC=8, in COPERCXL.

User Response: Use these messages to help fix the allocation problem

COP068

********** Execution Terminated **********

Explanation: An internally generated dataset allocation command failed for reasons shown in the preceding messages.

System Action: The processing terminates with RC=8, in COPERCXL.

User Response: Use these messages to help fix the allocation problem.

COP070

Returned Tasklib DD Name = xxxx

Explanation: COPE allocates a new Tasklib using a system SYSnnnnn DDname.

System Action: The processing continues.

User Response: Use these messages to help identify any problem that may occur.

COP071 *

Stepname=xxxx end of allocation information

Explanation: A message delimiting the end of the set of messages generated by the JCL conversion process.

System Action: The processing continues.

User Response: Use these messages to help partition the allocation messages on the system job- log into portions associated with individual steps.

COP072

=ERR=> No TASKLIB DD returned from ALUJ

Explanation: The COPE JCL conversion process requested a new DDname be assigned, but one was not returned from the COPEALUJ subroutine.

System Action: The processing terminates with RC=12.

User Response: Probable logic error. BMC support should be contacted and a copy of the JOBLOG messages kept for problem resolution.

COP073

=ERR=> Variable XCOPEPGM not found in COPEPSYS

Explanation: The load module COPEPSYS generated by option 1.6 is missing the XCOPEPGM key for this Psys. The key missing is CPVX..psys..XCOPEPGM.

System Action: The processing terminates with RC=12.

User Response: Ensure that the correct COPEPSYS module is being loaded. Regenerate a new one using ISPF 1.6 option G.

COP080

Check you have installed COPEBA11

Explanation: An internal processing error has occurred.

System Action: The processing terminates with RC=16.

User Response: Probable version error or error caused by an incorrect Linkedit doing system maintenance.

COP081

=WARN> xxxx yyyy not translated

Explanation: The referenced PSB/DBD could not be found in the COPEXRF1 translation table.

System Action: The processing continues.

User Response: Probable error. Either import the PSB/DBD into COPE and perform the option 4.2;REFRESH ISPF application before rerunning the JOB or correct the PSB/DBD name.

COP082

Translated DLI Parm=xxxx

Explanation: The Parm field passed to DLI after the COPE Untranslated JCL preprocessor has finished converting the contents.

System Action: The processing continues.

User Response: Use these messages to help identify any problem in the execution of the application.

COP084

=ERR=> xxxx missing from yyyy, or load fail

Explanation: The referenced module could not be loaded from the dataset.

System Action: The processing completes with RC=12.

User Response: Check that the module is in the dataset. Generate a new version in ISPF.

COP085

=ERR=> Variable xxxx missing from yyyy

Explanation: The COPE front-end on DFSRRC00 processor expected to find the variable xxxxxxxx in COPEXRF5 or COPEPSYS. It was not found.

The variables in COPEXRF5 and COPEPSYS come from the ZDEFAULT variables.

System Action: The processing in module COPERCXL terminates with condition code 12. The DLI/etc program won't be run.

User Response: Probable version error. Check that the correct COPEXRF5 module is being loaded and generate a new one using ISPF option 4.11. Check that the correct COPEPSYS is being loaded from STEPLIB and generate a new one using ISPF option 1.6.

COP086

* Recreate xxxx in ISPF yyyy, and submit zzzz job

Explanation: Table module xxxxxxxx is missing or bad. Recreate it using ISPF Option yyyyyyy, and submit the job that generates (called zzzzzzzz).

System Action: The step will either terminate with cond code 12, or COPERCXL will attempt to continue.

User Response: Check that the module is in the dataset (XCOPEPGM for XRFn, STEPLIB/Joblib/ Tasklib for COPEPSYS).
If the dataset name is incorrect generate a new COPEPSYS module with Option 1.6 Option G, for Generate.

COP087

****************************************************************

Explanation: An eyecatcher delimiter.

System Action: The process continues.

User Response: The message surrounded by eyecatchers is important.

COP087

=WARN> Retrying translate using Stubx from xxxx

Explanation: When translating the PSBNAME on the Parm, the Stubx loaded was bad, or did not contain the Lsys. COPE retries the translate using the Stubx in the XCOPESTG library.

System Action: The processing continues. When COPE calls DFSRRC00 later, if the Stubx was truly bad (e.g. the module is not a Stubx), the bogus Stubx will probably abend.

User Response: Usually none. If later abends or messages show the Stubx not to be a Stubx, do a manual copy of the Stubx from XCOPESTG to XCOPEPGM, then rerun the job.

COP088

=ERR=> Could not allocation Stging

Explanation: When translating the PSBNAME on the Parm, the Stubx loaded was bad, or did not contain the Lsys. COPE tries to allocate XCOPESTG, so that it can retry using that library. Either XRF5 did not contain XCOPESTG, or contained XCOPESTG pointing to a bad dataset name, or the allocation for that library failed.

System Action: The processing continues. When COPE calls DFSRRC00 later, if the Stubx was truly bad (e.g. the module is not a Stubx), the bogus Stubx will probably abend.

User Response: Run option 4.11 and check that the ZMDS member contains the correct XCOPE- STG dataset name. Then rerun the job.

COP091

=ERR=> Open failed for output DD xxxx

Explanation: An output file failed to open.

System Action: The processing terminates with RC=12.

User Response: Identify and correct the reasons for the failure and resubmit the job.

COP092

=ERR=> Open failed for input DD xxxx

Explanation: An input file failed to open.

System Action: The processing terminates with RC=12.

User Response: Identify and correct the reasons for the failure and resubmit the job.

COP093

Input record >xxxx

Explanation: COPE has determined that control cards must be translated and is displaying the image of it before the translation process.

System Action: The processing continues.

User Response: Use these messages to help identify problems if there is an incorrect operation.

COP094

Output record >xxxx

Explanation: COPE has determined that control cards must be translated and is displaying the image of it after the translation process.

System Action: The processing continues.

User Response: Use these messages to help identify problems if there is an incorrect operation.

COP100

Stubx "xxxx" TP Pcbs=yy, but IMS'=zz!!

Explanation: Mismatch between the description of the PCB list in the Stubx, and the actual PCB list in the PSB. The Stubx is generated at PSBGEN time (option 4.7, or 2.PSB), into a staging library, XCOPESTG. A step in the option 4.8 ACBGEN copies the staging library to the online Stubx library, XCOPEPGM. The ACBGEN job also issues a REFRESH to cause the message regions to bring in new Stubx's. You must issue a /MOD PREPARE ACBLIBand /MOD COMMIT to tell IMS to flip to the new ACB's.
Most likely this problem is due to not issuing the /MOD, or having the wrong ACBLIBin CTL region and/or DLS region JCL (the two regions must have identical ACBLIBS).
TP PCB's= value is NOIOPCB (on COPEEND) +1 if MPP, BMP, or DLI+CMPAT=YES. IMS's= value is number of TP PCB's passed from IMS, including the IO PCB, if present.

System Action: Discards the transaction.

User Response: Issue /MOD PREPARE ACBLIB and /MOD COMMIT commands. Issue the COPE REFRESH command. Check your ACBLIB dataset names in CTL and DLS regions against the XCOPEACA and XCOPEACB ZDEFAULT variables (use SVARS or EVARS from the COPE ISPF primary menu to view ZDEFAULT). Browse the ACB in the ACBLIB and check the date created. Browse the Stubx (Cnnnnnnn module) in XCOPEPGM and check the date. Check that no-one used 3.3 to copy Stubx's from a different Psys (Stubx's must be generated for each Psys). Run option 4.7 PSBGEN, and option 4.8 ACBGEN and check the output carefully, looking for syntax errors in the PSB, or library SB37, SD37 or SE37 abends.

COP101

"Dummy" PSB present for TRANCODE=xxxx

Explanation: When this transaction's PSB was generated via option 4.7, no PSB's had been imported for the transaction. Alternatively, DBD's referenced by this PSB had not been imported, or DBD's referenced were not in the IMSGEN. Then an option 4.8.FIX ACBGEN was run, which puts dummies out for all such PSB's, so that IMS won't hang the terminal on a NOTINIT PSB.

System Action: Discards the transaction.

User Response: Use COPE ISPF option 2 to see if the PSB is in COPE . If it is not, use option 2.PSB to import the PSB into COPE . If it is in COPE , note down all DBD names referenced, and use option 2 to check that each DBD was imported. Don't forget secondary indexes and logically related DBDs. If a DBD wasn't imported, use option 2.PSB to import it. perform a 4.7 Combined PSB-GEN, 4.8 ACBGEN, and /MOD PREPARE ACBLIB, /MOD COMMIT. If all DBDs were imported, use option 4.2.E.S to check the Stage 1 input of the IMSGEN, for all the DBDs. If some are missing, add them, then perform a 4.1 Stage 1 Gen, and run IMSGJCL and XREFJCL. Check the dynamic allocation for the DBDs in option 3.DYN. If some are missing, add them, then generate the additions.

COP102

Your Logical System=xxxx is unknown to this Physical IMS=yy!

Explanation: The DYNJCL job of option 4.11 loads a record for each logical system into UST in USTDLMGR for your User id (Lterm or Signon id), which contains the logical system name you are logged on to. There is a mismatch.

System Action: Discards the transaction.

User Response: Try COPE LOGOFF, then LOGON. This will normally fix the problem. If it doesn't, check that the logical system name was in the ZDBDATA member out of 4.11. If it isn't, check that the system exists in option 4.1, and do a 4.11, and run DYNJCL. If the system name was in ZDBDATA, and you ran DYNJCL, check the physical IMS id number in the ZDEFAULT member (XCOPEINU variable) against the one in the message. If different, issue a COPE IMS nn command to set the physical IMS id number in IMS. If they are the same, the problem is probably a System Error (call BMC support).

COP103

This Transaction has a Stubx that has a bad PhysicalIMS Id=xx!!

Explanation: Option 4.7 Combined PSBGEN created the Stubx, and placed the XCOPEINU Physical IMS id number in it. The physical IMS you are running in has a different id number.

System Action: Discards the transaction.

User Response: Issue LIB COPESTEP command to display the libraries on the COPESTEP DD in the message region. Check that the Stubx library whose dataset name is in the ZDEFAULT member variable XCOPEPGM is present, preferably on top of the concatenation. Correct the JCL if it is not. If it is, check the XCOPEINU variable. If different, 4.7 regenerate the Combine PSB, and run 4.8 ACBGEN, to make the Stubx id the same. If the XCOPEINU variable was the same, issue IMS nn command, to set the online Physical IMS id. If there is still a problem, it is probably a System Error (call BMC support).

COP105

"xxxx" Transact is Stopped in system yyyy

Explanation: The USTDLMGR record for this TRANCODE in this logical system has a status of Stopped. A prior abend, or a person using COPE SS, could have stopped the transaction. The IMS status is not stopped (because the same TRANCODE is used across logical systems).

System Action: Discards the transaction.

User Response: SS, then start the transaction within the logical system (using S, TR for transaction, the TRANCODE, and the system name, on the Start/Stop screen). If the problem is due to an abend, fix the program, then compile and link the program.

COP106

All Transactions are Stopped in system xxxx

Explanation: The USTDLMGR record for the transactions in this logical system has a status of Stopped. A person using COPE SS, or the "STO TR Lsys" command, could have stopped the system.

System Action: Discards the transaction.

User Response: SS, then start the system (using S, TR for transaction, a blank TRANCODE, and non- blank system name, on the Start/Stop screen). Check that the DBs for the system are also started.

Starting the TRs for the system will reallocate the program libraries for that system (in Tasklib Switching), if they are not DISP=OLD by some other job. The TRs for the system may have been stopped by someone wanting to access the libraries DISP=OLD.

COP107

"xxxx" PSB is not "Parsed" in system yyyy

Explanation: The Stubx for the Combined PSB has a PARSED=NO flag on, for this logical system. At the time this Combined PSB was generated (in ISPF 4.7), the PSB for this logical system had not been imported.

System Action: Discards the transaction.

User Response: Use ISPF option 2.PSB, , to import the missing PSB. Run 4.7 Combined PSB GEN, then 4.8 ACBGEN. /MOD PREPARE ACBLIB, and /MOD COMMIT. The REFRESH command (which is issued at the end of the ACBGEN jcl) will bring in the new Stubx. Check that the XCOPEPGM library (which contains the Stubx's) is on the COPESTEP DD in the message region, using the LIB COPESTEP command.

COP108

WARNING -- All processing will be disabled, after xxxx/yyyy/zzzz

Explanation: The COPE license is about to expire. The system will cease to operate on the date shown.

System Action: All processing will be disabled. Call BMC Support for assistance.

COP109

Overflow tran xxxxxxxx not auth to user yyyy

Explanation: The Stubx specifies that for this logical system, a transaction switch should take place, but the user is not authorized (via RACF, etc) to switch to the overflow TRANCODE. All users should be authorized to switch to all Cnnnnnnn (overflow) TRANCODES. This is not a security exposure. Use XIMSSEC=T on a production system, to check security.

System Action: Discards the transaction.

User Response: Set up RACF, ACF2 or Top Secret rules to allow all users to switch to all Cnnnnnnn TRANCODES. This is required in all COPE systems (both test and production).

If this is a production system and you require TRANCODE security, set ZDEFAULT XIMSSEC=T, and setup rules to check Class=OTHER Resource Type=Lsys and Key=TRANCODE. If this scheme is not suitable for your security system, change the security exit, COPESXSX. XIMSSEC=T checks security on all transactions (the real TRANCODES and the overflow C-number TRANCODES). It uses the non C- number name in the check for the overflow transaction. For further information see the extensive documentation at the beginning of ASM(COPESXSX).

COP110

Overflow PSB TRANCODE xxxxxxxx is not in IMSGEN

Explanation: The Stubx specifies that for this logical system, a transaction switch should take place, but the TRANCODE to switch to is not in the IMSGEN.

System Action: Discards the transaction.

User Response: Run 4.1 Stage 1 Gen, and check that the TRANCODE in the message appears in the STAGE1 member. Then run IMSGJCL, and /MOD PREPARE MODBLKS and /MOD COMMIT. If the Trancode is not in the STAGE1 member, then do a 4.7 Combined PSBGEN, 4.8 ACBGEN, and /MOD PREPARE ACBLIB, /MOD COMMIT, then do 4.1 Stage 1 Gen, etc, as above.

COP111

DB name in IMS PCB=xxxxxxxx, but Stubx=yyyyyyyy

Explanation: The Stubx has a list of the DBD names that should match those passed from IMS in the PSB, but they do not match.

System Action: Discards the transaction.

User Response: Check that after the last ACBGEN, you did a /MOD PREPARE ACBLIB and /MOD COMMIT. If this is not the problem, try REFRESH (the ACBGEN normally does a REFRESH, but the step may have been run when IMS was down). If that is not the problem, rerun 4.7 Combined PSBGEN and 4.8 ACBGEN

COP112

xxxx Databases NA (Not Available) in Lsys yyyy

Explanation: The database(s) listed on the line after this message are Stopped, or not in the JCL, or not in the DYNALLOC, and HANDLNA=N in the Stubx.

The database(s) could be stopped by a person issuing /STO, /DBR, or P in COPE SS (Start/Stop). Or IMS could have stopped them due to an I/O error. IMS passes an NA status code to the program in the PCB for a stopped database.
HANDLENA= is an option in COPE 2.5 for PSB source, where you tell COPE whether or not pro- grams that use the PSB can handle NA status codes (or NU status codes).

HANDLENA=N means you specified that the program can not handle NA. HANDLENA=Y or F means the program can (no difference between Y and F).

NA status codes often happen when there is a conflict in database allocation between different regions, especially online regions versus batch regions.

System Action: In an MPP or IFP region, COPE will discard the transaction. In a BMP, DLI or DBB region, COPE will allow the program to continue.

If this is a BMP, DLI or DBB region, either include the dynamic allocation load library on the STEPLIB, or put the database DDs that are missing in the JCL.

If the program can handle NA and NU status codes, go into COPE 2.5 under ISPF, on the PSB Source, and set the HANDLENA option to Y, then run 4.7 Psbgen and 4.8 Acbgen.
In BMP/DLI/DBB, remove the COPETRAC ( COPE Trace) DD from the JCL, if you wish to not get the message and do not want to set HANDLENA=Y.

COP113

=WARN> Databases NU (Not Updateable) in Lsys xxxx

Explanation:   The database(s) listed on the line after this message are Read-only, or their indexes or logically related databases are Stopped, or not in the JCL, or not in the DYNALLOC, and HANDL- NA=N in the Stubx, and the procopt in the PSB is update.
The database(s) could be stopped by a person issuing /STO, /DBR, or P in COPE   SS (Start/Stop). Or IMS could have stopped them due to an I/O error. IMS passes an NU status code to the program in the PCB for a Not Updateable database.
HANDLENA= is an option in COPE   2.5 for PSB source, where you tell COPE   whether or not pro- grams that use the PSB can handle NU status codes (or NA status codes). HANDLENA=N means you specified that the program can not handle NA/NU. HANDLENA=Y or F means the program can (no difference between Y and F). NA status codes often happen when there is a conflict in database allocation between different regions, especially online regions versus batch regions.

System Action: In all regions, COPE will allow the application program to continue.

User Response:   If this is an MPP or IFP region, clear the screen, type COPE   SS, Enter, S for Start, DB for Database, and the database name, and hit enter. This will attempt to start the database.
If this is a BMP, DLI or DBB region, either include the dynamic allocation load library on the STEPLIB, or put the database DDs that are missing in the JCL.
If the program can handle NA and NU status codes, go into COPE   2.5 under ISPF, on the PSB Source, and set the HANDLENA option to Y, then run 4.7 Psbgen and 4.8 Acbgen.
In BMP/DLI/DBB, remove the COPETRAC ( COPE   Trace) DD from the JCL, if you wish to not get the message and do not want to set HANDLENA=Y.

COP114

=ERR=> Databases Stopped in Lsys xxxx

Explanation: The database(s) listed on the line after this message are Stopped to COPE , and either they are DEDBs, or this is an IMS 1.3 system.
The database(s) could be stopped by a person issuing /STO, /DBR, or P in COPE SS (Start/Stop). Or IMS could have stopped them due to an I/O error.

System Action: In MPP or IFP regions, COPE discards the transaction. In BMP, DLI or DBB regions, COPE will produce messages, then issue a U1992 abend.

COP115

All Databases are Stopped in system "xxxx"

Explanation: The USTDLMGR record for the databases in this logical system has a status of Stopped. A person using COPE SS, or the "STO DB Lsys" command, could have stopped the system.

System Action: Discards the transaction.

User Response: SS, then start the system (using S, DB for database, a blank database name, and the system name, on the Start/Stop screen). Check that the TRs for the system are also started. Starting the DBs for the system will enable database allocation by transactions. If databases are DISP=OLD by a batch job, they will get stopped again, with ALLOCATION FAIL showing in the description for the lowest D level in Start/Stop (but not in the higher B and G levels). The DBs for the system may have been stopped by someone wanting to access the databases from a batch job. Since database allocation and deallocation is slow, you should try to avoid starting databases that can't be allocated. Check with the person who originally stopped them, if possible. Note that, if other persons are using the databases, the original person may not be the current user.

COP116

Last reason xxxxxxxx stopped, is "yyyyyyyy"

Explanation: The transaction or database named was stopped by the command or user shown. This is the last user that stopped from within COPE SS. It is likely to be the reason for the current stopped status, but it is not guaranteed to be, because it is possible to cause stopped status's outside COPE 's control.
The "last reason" field will show "Abend ..." if the transaction abended, or "ALLOCATION FAIL ..." if the database is stopped because a batch job prevented the online from allocating the database. System Action: In MPP or IFP regions, COPE discards the transaction. In BMP, DLI or DBB regions, COPE will produce messages, then issue a U1992 abend.

User Response: Use the information in the reason field to determine who to contact to sort out any conflicts in usage of the transaction or database.
Use COPE SS to start the transaction or database(s).

COP117

Start the xxxx in COPE SS and rerun

Explanation: The transaction or database(s) listed in previous messages are stopped. COPE is discarding the MPP or IFP transaction, or will abend the BMP/DLI/DBB batch step.
If MPP/IFP/BMP, you can start transactions or databases in COPE SS (Start/Stop). In DLI/DBB, you can put the dynamic allocation load library on the STEPLIB, or put the database DD cards in the JCL, or remove the COPETRAC DD to turn off COPE checking of stopped status.

System Action: In MPP or IFP regions, COPE discards the transaction. In BMP, DLI or DBB regions, COPE will produce messages, then issue a U1992 abend.

User Response:   If this is an MPP/IFP/BMP region, clear the screen, type COPE   SS, Enter, S for Start, DB for Database, and the database name, and hit enter. This will attempt to start the database. If a transaction is stopped use TR for transaction and the TRANCODE.
If this is a DLI or DBB region, put the dynamic allocation load library on the STEPLIB, or put the missing database DDs in the JCL, or remove the COPETRAC DD to turn off COPE   checking of stopped status.
If there is a conflict in database allocation between different regions, schedule the regions at different times. Use COPE   SS to allocate or deallocate databases from the online region.

COP118

Abending batch step U1992 because of stopped status

Explanation: The database(s) listed in previous messages are stopped or not in the DYNALLOC or not in the JCL.

There is a COPETRAC ( COPE Trace) DD in the JCL, which says you want a DLI call trace, plus COPE checking of stopped status for batch steps.

System Action: COPE issues a U1992 without a dump.

User Response: Put the dynamic allocation load library on the STEPLIB, or put the missing database DD cards in the JCL, or remove the COPETRAC DD to turn off COPE checking of stopped status in batch steps.
If there is a conflict in database allocation between different regions, schedule the regions at different times. Use COPE SS to allocate or deallocate databases from the online region.

COP119

=WARN> No INIT Call issued, yet Stubx HANDLENA=xxxx

Explanation: The PSB had the 2.5 HANDLENA option set to Y or F, saying that the program could handle NA status codes, and associated NU, BA and BB codes, yet the program did not issue an INIT STATUS GROUPA call.

System Action: COPE produces the message and continues. There is no difference between the HANDLENA=Y and HANDLENA=F actions.

User Response: Either change the program so that it issues an INIT call, or set HANDLENA to N in 2.5 then 4.7 Combined PSBGEN and 4.8 ACBGEN, or ignore this message.
This message is warning you that IMS will give you an abend if your program was to issue a call against an NA/NU PCB. Your program might test for the NA/NU status before issuing calls, in which case there is no need to issue the INIT call.

COP120

Pgm xxxxxxxx is in new extent of library, do REFRESH

Explanation: When the program was linked or copied into the program library, the library went into a new DASD extent. The message region opened the program library prior to this, and therefore cannot load the program. The REFRESH command will tell all message regions to close, reallocate, and open the program libraries, and then the program will be able to be loaded. Alternatively, a compress of a program library could have made a message region BLDL invalid. REFRESH will also clear all BLDLs, and then the load will work.

System Action: The transaction is discarded.

User Response: Issue REFRESH command. Rerun the transaction and the program should load correctly. You can retry the load without running the transaction by issuing the VERSION <program> command. If the program still fails to load, it could be because it is being loaded from the COPESTEP DD (which is not re-opened by REFRESH). Stop and start the message regions, and the program should then load. If it doesn't, suspect a damaged program library directory, and investigate further by browsing the library directory, looking for error indicators (such as "*DELETED"). If the directory is undamaged, then the load module itself is bad. Compile and Linkedit the program, checking the output from the Linkedit.

COP121

Storage unavailable, region full, or REGION= too small

Explanation: The program cannot be loaded into the message region, because there is not enough storage available in the region to hold it.

System Action: The transaction is discarded.

User Response: Issue DEBUG REGION to display the storage available in the region. If it is too small for the program, check the REGION= parameter in the message region JCL, and increase it, or check the size of the program by browsing the program library directory. If the REGION= should be sufficient (allow about 500K for system code), then suspect a problem with some program not freeing storage. Stop and start the message regions. To test the loading of the program, issue VERSION <program>, which will load the program named, show you its size, then delete it from the region. Examine the dump, looking for clues on which program is doing a Getmain for storage and not freeing it. If it appears to be a System Error, call BMC support.

COP122

Pgm xxxxxxxx not found in library/Load fail, R1=yyyyyyyy R15==zzzzzzzz

Explanation: The program is not present in the libraries used for this logical system, or is present but the Linkedit marked it NOEX (Not Executable), or is present but is in a new extent, or is present but the library was compressed without doing a REFRESH (this last condition will only apply to Non-Tasklib Switching with BLDL, because Tasklib Switching does not use BLDL).

System Action: The transaction is discarded.

User Response: Issue REFRESH command. This deallocates and reallocates Tasklib Switching libraries, and refreshes Non-Tasklib Switching BLDLs. Then issue VERSION <program> to retry loading the program. If you still get a Load Fail, the module is probably not in the library.
Issue LIB, to see the libraries that are loaded-from, for this logical system, and check that they are correct (if they are not, do 4.11 (MDS) corrections, and REFRESH, for Tasklib Switching, or change the message region JCL for Non-Tasklib Switching). If the program is not present in the library, compile and relink it, or copy or import it in. Importing only applies to Non-Tasklib Switching.

COP123

Possibly PSBGEN done w/o ACBGEN, ACBGEN required.

Explanation: The Stubx and the PSB are mismatched. The Stubx comes from the XCOPEPGM library on the COPESTEP DD in the message region. The PSB (ACB) comes from the active ACBLIB that you see when you do a /DIS MODIFY ALL. When a Stubx changes, a REFRESH must be performed to clear out IMS's BLDL (it is automatically done by 4.8 ACBGEN), so that the new Stubx is accessed.

System Action: The transaction is discarded. For Batch/BMP, abend U1993.

User Response: Resynchronize the Stubx and the PSB by doing 4.7 Combined PSBGEN, then 4.8 ACBGEN, and /MOD PREPARE ACBLIB and /MOD COMMIT. Check that the ACBGEN job last step (COPEIMS3 step) issued the REFRESH command (it will give condition code 4 if the ACBGEN was run on another CPU), and issue REFRESH yourself if it did not.

COP124

xxxx

Explanation: A previous error was encountered. The error condition is described in a previous message.

System Action: The transaction is either discarded or runs to completion, dependent on the previous error message.

User Response: The information provided in this message may help diagnose the problem. The fields are:

Message Fields

Field	Meaning
Pgm=	The real program name (not the C-number name). In Tasklib Switching, this is the load module name.
Tran=	Transaction code.
CPgm=	C-number program name. In Tasklib Switching, this name is not used for the load module name, but it is used for the DB2 Plan name. In Non-Tasklib Switching, this is the physical load module name as well as being the DB2 plan name.
CPsb=	C-number PSB name, or physical PSB name as known to IMS. It is not the same as the program name. It is the same as the Stubx name (as far as IMS knows, the Stubx is the program). The PSB is a Combined PSB. There is one PSB for this transaction in all logical systems, not one per logical system.
User=	The Lterm or Signon-id, that identifies the User to COPE . It is this name that is logged on to a logical system. If you do not use the /SIGN command, the id is the Lterm name. If you use the /SIGN command, it is the Signon-id.
Lsys=	The Logical System that the User is logged onto.
Ctrn=	C-number TRANCODE, if this is a COPE overflow transaction.
Date=	The month and day, to help when viewing old abends, via the ABS (Abend Summary) command.

COP125

xxxxxxxx

Explanation: A program abended in the region. The program name, plus hex offset of the abend, and abend code are given in the message. The program name will be the name of a subroutine or sub-module within a load module, not the name of the load module itself. The subroutine name is more useful, because it will be the source member name, usually. The offset is relative to the start of the sub-module, not relative to the start of the load module.

This is a regular user abend or IMS abend, unrelated to the presence of COPE , unless the name of the program appearing in this message begins with the characters " COPE ".

This message is followed by COP124, which gives the IMS Pgm (prog) name, TRANCODE, Lsys, etc.

System Action: The COPE Estae traps the abend, formats this and other Abend Summary messages, and then allows the abend to continue. It does not stop the abend, nor change the dump options.

User Response: Look in the compile listing (not the Linkedit map) at the offset given, to find the statement where the abend occurred or was issued. For a complete description of the Abend Summary messages, refer to G;8;3 in ISPF Help, or UP;G;8;3 in IMS Help, or the COPE for IMS/DC Programmer's Guide.

If this is a Unnnn abend, it is not a COPE abend unless it is a U1989, U1990, U1991, U1992 or U1993, and is issued by a COPExxxx program. If it is a COPE abend, it will be preceded by COPE messages giving an explanation, plus an explicit "Abending Unnnn because of this" message. If this is an Sxxx abend, it is not a COPE abend unless the name of the program appearing in this message is COPExxxx.

If the name of the program appearing in this message is not COPExxxx, then this a regular application program Unnnn or Sxxx abend, or an IMS Unnnn abend, unrelated to the presence of COPE .

If the name of the program is not COPExxxx, yet the problem occurs in a COPE system, but not in a non- COPE system, the problem is most probably in the setup of this IMS system, and is not related to the presence of COPE.

OP126

No "DYNX" entry for Lsys=xxxxxxxx

Explanation: When the dynamically-called module was Imported into COPE , the logical system named had not been defined, so doesn't appear in the DYNX (Dynamic Stubx). This condition can-not occur in Tasklib Switching, because DYNXs are not used there.

System Action: Abend U1989. The transaction is discarded.

User Response: Issue LIB COPESTEP to check that the correct XCOPEPGM library (which contains the DYNXs) is present in the message region JCL. Import the program load module again into COPE , using 2.PSB , to regenerate a DYNX into the XCOPESTG library, then either do a 4.8 ACBGEN, or ordinary ISPF 3.3 copy, to copy the DYNX from XCOPESTG to XCOPEPGM. Alternatively, mass re-generate the DYNXs in 5.10.4.

If you are using Tasklib Switching, this condition indicates that a load module was erroneously imported into COPE (programs do not have to be imported in Tasklib Switching). Use 5.10.13 to generate a copy Stubx job, to copy just the Stubxs to another library. Then delete and reallocate the XCOPEPGM library, and copy the Stubxs back, thus getting rid of the Dynxs.

In special cases, you may want to import programs that do not change often into COPE , even though you are using Tasklib Switching, and then this error indicates that the DYNX needs regenerating because a new logical system has been defined.

COP127

Pgm xxxxxxxx not found in STEPLIB or load fail!

Explanation: The dynamically-called subroutine is not present in the libraries used for this logical system, or is present but the Linkedit marked it NOEX (Not Executable), or is present but is in a new extent, or is present but the library was compressed without doing a refresh. This error applies only to Non-Tasklib Switching.

System Action: The transaction is abended with a U1989.

User Response: Issue REFRESH command. This refreshes Non-Tasklib Switching BLDLs. Then issue VERSION <C-number> (using the C-number name for this program in this logical system) to retry loading the subroutine module. If you still get a Load Fail, the module is probably not in the library.

Issue LIB, to see the libraries that are loaded-from, for this logical system, and check that they are correct (if they are not, change the COPESTEP DD in the message region). If the program is not present in the library, compile and relink it, or copy (using the C-number name) or import it in. This error can also occur if the DYNX is bad (for example, it could belong to another physical COPE system). Check the COPESTEP DD points to the XCOPEPGM library named in the ZDEFAULT member. To regenerate the Dynx, either re-Import the load module (using 2.PSB), or run 5.10.4 to re-generate all DYNXs.

COP128

Abend in DLI Call (e.g. database ptr U85x abend)

Explanation: IMS issued an abend from within a DLI call. COP125 message preceding this one gives the abend code. If the COP125 is missing, then the abend is probably a U85x (database pointer bad, or DBD bad). The abend code will always appear on the message region JOBLOG.

System Action: If COP125 precedes, the message is being issued from the COPE Estae, and the abend will continue. If COP125 does not precede, the message is being issued from the next trans- action through the region. This next transaction will continue unaffected. In the later case, the Trancode will be stopped to IMS, i.e. to all Lsys's, and COPE will not automatically restart it.

The database which has the problem is named in the COP124 message following this one.

COP129

Func=xxxx, PCB=yyyy, AIB Nam=zzzz, Lsys=aaaa

Explanation: IMS issued an abend from within a DLI call. The PCB name and Lsys will identify the problem database (assuming the abend is a U85x).

System Action: If COP125 does not precede this message, the prior transaction (the one that abended with a U85x) will need to be started using /STA TRAN and /STA PROG commands. COPE does not automatically restart transactions that abend in the DLI buffer handler (it does for other abends).

User Response: Note the message region jobname on the top line of the screen. Go to that region's JOBLOG to see the abend code. The abend code is not reported in this screen if it is unknown to COPE (if the COPE Estae did not get control on the abend). If the abend is a U85x, check the DBD matches the database dataset. DBDGEN and ACBGEN the correct DBD. Use a pointer-checker utility such as DB Tools to check for bad pointers in the database, and restore or repair the database.
Issue /STA TRAN ALL and /STA PROG ALL to restart the transaction that was stopped by the abend ( COPE does not automatically restart the tran for U85x-type abends, so same-named TRANCODES in other Lsys's will be stopped until you do this).

COP130

Abend early in processing, so no abend summary sent

Explanation: COPE tried to send an Abend Summary screen to the user via the express PCB, but could not do so, because the abend occurred prior to SXP2 processing that finds the express PCB.
Such an "early abend" is probably in IMS, or in an IMS user exit, such as a DLI "Data capture" exit, or other exit.

System Action: COPE bypasses sending the Abend Summary screen. COPE ESTAE exits normally, without modifying any dump options (which COPE never modifies).

User Response: View the Abend Summary information on the message region JOBLOG. Identify the module issuing the abend, and debug the abend as you normally would. If the abend was not issued by a COPE module, the abend is *not* related to the presence of COPE (it is a regular user program or IMS abend).

Be aware that if you issue the COPE ABS command to see the Abend Summary screen, you will see the one (stored on USTDLMGR) for some prior abend to this one. This absence of an Abend Summary screen is due to the unusual "early" nature of the abend that occurred.

COP131

No express PCB, so abend summary not sent

Explanation: COPE tried to send an Abend Summary screen to the user via the express PCB, but there is no express PCB in this PSB. Since this is not a batch (BMP, DLI or DBB) run, this is an error in COPE 4.7 PSBGEN processing.

Although this is an error in COPE generation processing, this error has nothing to do with the abend that occurred.

System Action: COPE bypasses sending the Abend Summary screen. COPE ESTAE exits normally, without modifying any dump options (which COPE never modifies).

Call BMC Support for a fix to COPE 4.7 PSBGEN, so that this message will not occur on future abends using this PSB. We repeat: although this message indicates a problem in COPE 's PSBGEN, this problem has nothing to do with the abend you are trying to debug.

COP132

=ERR=> DMLOGIC lost its preload in msg region xxxx

Explanation: DMLOGIC was present in the region at startup (it was preloaded) but the current load count is now zero (from the LLE). Some application program probably deleted it (which is not proper for any application to do).

System Action: COPE produces the message and ends the Start/Stop scrolling-screen transaction. Note that this message occurs only if the DMLOGIC entry in the saved LLE list was there, but has a zero "current load count" in the halfword at +26.

User Response: Check that DMLOGIC is in your DFSMPLxx member of //PROCLIB. Check you have no application programs that would delete DMLOGIC. Call BMC for assistance. You cannot use Start/Stop scrolling screens till you fix this. You can use STA and STO (non-scrolling) commands to perform the same function.

COP133

=ERR=> DMLOGIC is not preloaded in msg region xxxx, must preload it

Explanation: DMLOGIC was not preloaded exactly once, in the preload list (DFSMPLxx member of //PROCLIB) for this message region. When you installed COPE , you probably failed to set up your preload list to include DMLOGIC. Start/Stop transactions require DMLOGIC to be preloaded.

The DFSMPLxx suffix is specified in the 4th parameter of the PARM= (3 commas in).

Perhaps you assigned the class for this tran so that it runs in a region that you don't want to run COPE SS transactions in.

System Action: COPE produces the message and ends the Start/Stop scrolling-screen transaction.

User Response: Check that DMLOGIC is in your DFSMPLxx member of //PROCLIB, place it in there if it is missing, delete the duplicates if it in there more than once, and stop and start the message regions. You cannot use Start/Stop scrolling screens till you fix this. You can use STA and STO (non-scrolling) commands to perform the same function.

Issue a /DIS TRAN COPExxxx command to see the current class, and /DIS A to see the msg regions and their classes.

COP134

=ERR=> xxxxxxxx yyyyyyyy call zzzzzzzz=aaaaaaaa status=bbbbbbbb, at SXP7+

Explanation: COPE is trying to switch to an overflow tran or an Xpediter tran, and got an unexpected status code from IMS.
Usually, this problem is due to an error in COPE , when it generated the Stage1, or the Stage 1 currently active does not match what is expected inside Stubx's, or XRFn tables.

Possibly, you ran a new Stage1 and didn't do the /MOD PREPARE MODBLKS and /MOD COMMIT.

Possibly, the Stubx in the XCOPEPGM library on the COPESTEP DD has an incorrect SWITCHTO= overflow TRANCODE.

Possibly, the user has an Xpediter intercept active that needs to be deactivated using XP QUIT.

System Action: The transaction is ended without switching and without calling the application program. COPE displays the messages on the IMS screen, and on the msg region JOBLOG. The condition will continue on new transactions with the same TRANCODE, until the Stage 1 or Stubx's are fixed.

User Response: Check you did a /MOD PREPARE MODBLKS and /MOD COMMIT after a recent MODBLKS gen.

If the problem occurs with one user but not others, check the user has no Xpediter intercept active by looking for the ==XP=> line on the COPE screen under IMS -- do XP QUIT to deactivate, and then the transaction will work.

Check the XCOPEPGM library on the COPESTEP DD is the correct Stubx library for this Psys.

Call BMC Support for assistance with this problem.

COP135

=ERR=> Xpediter active -- do XP QUIT then try again

Explanation: COPE is trying to switch to an Xpediter tran, and got an unexpected status code from IMS. Usually, this is because there has been an IMSGEN across which the Xpediter user has not changed the TRANCODE they want to intercept, and COPE has incorrectly reassigned TRANCODE attributes to the transaction (such as conv/nonconv attributes). The fix is to get the user to XP QUIT from the COPE screen in IMS. Then the user can run their transaction again, either in Xpediter, or in regular msg regions, and it will now work, because in Xpediter, it will pick up a transaction with the correct attributes.

System Action: The transaction is ended without switching and without calling the application pro- gram. COPE displays the messages on the IMS screen, and on the msg region JOBLOG. The condition will continue on new transactions with the same TRANCODE, until the user does XP QUIT.

User Response: Do an XP QUIT from the COPE screen under IMS, and rerun the transaction.

COP136

Abending batch step U1993 because of above errors

Explanation: Previous errors, such as Stubx mismatches with the PSB, mean the batch/bmp step cannot run, so COPE is issuing a U1993 without dump to terminate the job.

System Action: COPE issues a U1993 without a dump.

User Response: Look on the JOBLOG for previous error messages, correct the problem, and rerun the job.

COP151

xxxx

Explanation: You issued a COPE command from a batch job via a COPEIMS3 BMP step. This message, and subsequent ones, show the output of the COPE command, on the message region Job log.

System Action: The command completes.

User Response: Use these messages to help determine whether your COPEIMS3 steps are issuing the commands that you want them to issue (for example, REFRESH, at the end of MFS compiles and ACBGENs).

COP161 Xpediter intercept is not active, XPOID=xx

Explanation: Dependent $XP segment was not found in the COPE USTDLMGR database.

System Action: Any messages are displayed to "ALL", followed by those messages to LTERM.

User Response: Call BMC Support for assistance with this problem.

COP162

Xp intercept was usurped, redo. Other user=xxxx

Explanation: The Lsys detected was not the Xpediter Lsys.

System Action: Processing continues - probable error.

User Response: Call BMC Support for assistance with this problem.

COP163

Xp Lsys xxxx bad, fix in ISPF option 7 screen

Explanation: The Xpediter Lsys was not found after all Lsys's were examined.

System Action: Processing continues - probable error.

User Response: Call BMC Support for assistance with this problem.

COP164

You are on Lsys xxxx but your XP Lsys is yyyy

Explanation: The Xpediter Lsys is not the current LOGON.

System Action: Processing continues - probable error.

User Response: Call BMC Support for assistance with this problem.

COP165

Xp intercept has bad tran count (too big) =xx

Explanation: MESSAGE is self-documenting.

System Action: Processing continues - probable error.

User Response: Call BMC Support for assistance with this problem.

COP175

=WARN> Clrbldl, Stubx=xxxx yyyy

Explanation: COPE is clearing IMS's Bldl for the Stubx, because the Stubx does not match the PSB. This occurs once per message region after an Acbgen on a PSB. COPE clears the Bldl, then tries loading the Stubx again. This will pick up any new Stubx that might be in the XCOPEPGM library.

System Action: COPE retries loading the Stubx. If the new Stubx still does not match, COPE will copy try loading the Stubx from XCOPESTG, and if that Stubx is good, will copy it into XCOPEPGM (for other msgs regions to get).

User Response: Usually none; this message shows you that the mechanism for synchronizing the Stubx after an Acbgen is working correctly. If the message does not appear in each message region, after an Acbgen, this could mean you are lacking a "99" for the Bldl parameter on then message region PARM=, or it might mean that no one used the transaction recently. Check the PARM=, 4th parameter, and change it to 99 if it is omitted or is some other value. This is important for performance reasons.

COP176

=WARN> xxxx

Explanation: COPE is about to copy the Stubx from XCOPESTG to XCOPEPGM. This occurs once across all message regions, after an Acbgen on a PSB. This will pick up the new Stubx that was placed in the XCOPESTG library by Psbgen. The message text describes the detailed nature of the mismatch; this information is only useful in case of an internal COPE problem with Stubx generation.

System Action: COPE has already checked that the Stubx from staging is good. It copies to XCOPEPGM, then continues normally. If the copy fails, each transaction will load from staging repeatedly, which will slow the system down (because the load from staging OPEN/CLOSE's a DCB). The cure is then to compress XCOPEPGM (for example) so that the next copy will work.

User Response: Usually none; this message shows you that the mechanism for synchronizing the Stubx after an ACBGEN is working correctly. If the message appears more than once for a particular Stubx, for one ACBGEN, it indicates that XCOPEPGM is full and needs compressing, or that there is a problem in Psbgen (Stubx generation) -- retry Psbgen using ISPF option 2.PSB, rerun option 4.8 Acbgen, check the output of these jobs carefully. Probably you have a problem with dataset full (needs compress).

If you cannot resolve the problem, call BMC support.

COP177

=WARN> Copying from stging, Stubx=xxxx

Explanation: COPE is about to copy the Stubx from XCOPESTG to XCOPEPGM. This occurs once across all message regions, after an Acbgen on a PSB. This will cause other message regions and BMPs to pick up the new Stubx generated by Psbgen.

User Response: Usually none; this message shows you that the mechanism for synchronizing the Stubx after an ACBGEN is working correctly. If the message appears more than once for a particular Stubx, for one Acbgen, it indicates that XCOPEPGM is full and needs compressing, or that there is a problem in Psbgen (Stubx generation), retry Psbgen using ISPF option 2.PSB, rerun option 4.8 Acbgen, check the output of these jobs carefully. Probably you have a problem with dataset full (needs compress).

If you cannot resolve the problem, call BMC support.

COP178

=ERR=> xxxx yyyy

Explanation: COPE has tried to load the Stubx from XCOPESTG. This occurs once across all message regions, after an Acbgen on a PSB. Either the load failed (due to bad XCOPESTG dataset name, for example), or the new Stubx still does not match the PSB. The text of this message shows the mismatch, however the problem is probably not related to the particular character of the mismatch. It is more likely to be a problem with the dataset name in the XCOPESTG variable, or that Psbgen did not place the new Stubx in XCOPESTG, because XCOPESTG is full.

System Action: COPE produces the =ERR=> message and will end the transaction without invoking the application program.

User Response: Check to see if XCOPESTG is full. Compress it if it is, then rerun Psbgen, using ISPF option 2.PSB, and ACBGEN, using option 4.8. Check that the blksizes of XCOPESTG and XCOPEPGM are both 32760. Rename, delete, realloc and copy over if not, then rerun PSBGEN and ACBGEN. Check the output of the PSBGEN and ACBGEN jobs carefully.

If you cannot resolve the problem, call BMC support.

COP179

=ERR=> BA xxxxxxxx RC=yy (zzzzzzzz) at SXCH+aaaaaaaa

Explanation: COPE 's Btree-Access had a bad return code. BA return codes are described in ASM(COPEBA6F). Probably caused by a problem in the install of the COPE modules COPEBA11 or COPERCXL.

System Action: Discards the transaction. No transactions will run until this problem is fixed.

User Response: Check you copied COPEBA11 and COPERCXL from the last COPE SMPE installation. Make sure you copied COPERCXL into all RESLIBs that you had previously copied it into.

Call BMC Support.

COP180

=ERR=> xxxxxxxx

Explanation: COPE was trying to dynamically allocate the XCOPESTG and XCOPEPGM libraries, and got an allocation failure. The dataset names for the allocation come from COPEXRF5 loaded from COPESTEP (in message regions), or STEPLIB (in BMP and Batch). Most likely you have set up the wrong dataset names in the XCOPESTG and XCOPEPGM variables in ZDEFAULT (change them using EVARS from the primary COPE menu under ISPF, and regenerate XRF5 using option 4.11).

System Action: Discards the transaction. No transactions with this TRANCODE will run till this problem is fixed.

User Response: If the problem is "wrong dataset name", you must check/correct the XCOPESTG and XCOPEPGM variables (use EVARS from the ISPF COPE primary menu), and regenerate XRF5 (use option 4.11). Issue REFRESH from IMS to make sure the message region in-core XRF5's are refreshed.

If you cannot resolve the problem, call BMC Support.

COP181

=WARN> Allocation stging and pgmlib took xx seconds

Explanation: COPE dynamically allocated the XCOPESTG and XCOPEPGM libraries, but the allocation took more than 5 seconds elapsed. This is too slow for acceptable user response time. This allocation processing occurs once in each message region, at the first Stubx mismatch due to Acbgen. This is not frequent, but it is still not acceptable to have this delay. The problem is probably in MVS contention for the datasets.

System Action: Produces the warning message and continues processing normally. The user who entered this particular transaction will see a long response time.

User Response: Check you are not running batch jobs that hold XCOPESTG or XCOPEPGM while the online is up. Call your MVS systems programmer to try to resolve any MVS problems in allocation.

If you cannot resolve the problem, call BMC Support.

COP182

=WARN> Stubx copy took xx seconds

Explanation: COPE copied the Stubx from the XCOPESTG library to the XCOPEPGM library, but the copy took more than 5 seconds elapsed. This is too slow for acceptable user response time. This copy processing occurs once across all message regions, for each PSB subject to ACBGEN. The problem is probably in MVS contention for the datasets, or possibly due to low dispatching priority, or due to an overall MVS slow-down.

System Action: Produces the warning message and continues processing normally. The user who entered this particular transaction will see a long response time.

User Response: Check you are not running batch jobs that hold XCOPESTG or XCOPEPGM while the online is up. Call your MVS systems programmer to try to resolve any MVS problems in OPEN/ CLOSE.

If you cannot resolve the problem, call BMC Support.

COP183

=WARN> Stubx read took xx seconds

Explanation: COPE loaded the Stubx from the XCOPEPGM library, but the load (using BPAM read) took more than 5 seconds elapsed. This is too slow for acceptable user response time. This read processing occurs once across all message regions, for each PSB subject to ACBGEN. The processing consists of OPEN on a BPAM DCB, BLDL, FIND, multiple READs, and CLOSE ( COPE does not issue an ENQ for this processing). The problem is probably due to low dispatching priority of the message regions, or slow MVS OPEN/CLOSE processing, or excessive DASD response time, or due to an overall MVS slow-down.

System Action: Produces the warning message and continues processing normally. The user who entered this particular transaction will see a long response time.

User Response: Call your MVS systems programmer to try to resolve any MVS problems with low dispatching priority, slow OPEN processing, or slow dasd reads.

If you cannot resolve the problem, call BMC Support.

COP201

No Batch SCD "DFSBSCD0" Found!

Explanation: COPE searched the CDE chain for the batch SCD and didn't find it. This is a DLI or DBB region. COPE needs the SCD in order to find the CMPAT=Y and PLI bits in the PSB.

System Action: Assumes CMPAT=N and not PLI.

User Response: Call BMC - system error.

COP202

$DB root is missing -- run COPEIMS1 to load the control database

Explanation: The $DB root should have been loaded to database USTDLMGR by job DYNJCL out of 4.11. Most probably you didn't run DYNJCL.

System Action: No transactions will run.

User Response: Perform a 4.11 and run DYNJCL job.

COP204

You are not logged on - enter logical system name above

Explanation: To run a transaction (other than a COPE or Start/Stop transaction) you have to be logged onto a logical system. Either your User name (Lterm or Signon-Id) has never been logged on before, or you entered the LOGOFF command, or your System Administrator has loaded USTDLMGR using the PROCOPT=L load (which will clear out all logon records).

System Action: Discards the transaction.

User Response: If you know which logical system you want to logon to, enter the name on the =====> line at the top of the screen, and press Enter. Then re-run your transaction. If you don't know the names of the systems, just hit Enter. The system names are listed on an AVAIL> line. Type one in, and hit Enter, to logon to that system.
Alternatively, your System Administrator can set up and run a job to do mass-logons, to be run after clearing out the USTDLMGR database. Example JCL is:

//LOGONALL EXEC GM=DFSRRC00,REGION=2M,
//PARM='BMP,COPEIMS3,COPEIMS1,,,,,,,,,,,COPE
//STEPLIBDD DSN=TFTPROD.COPE.LOAD,DISP=SHR
//DD DSN=IMSVS.TEST2.RESLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
COPE TFT4 FROM #TS1002
COPE TFT4 FROM #TS1003
COPE MACPACD1 FROM #TS1004
...etc...

In the above, TFT4 and MACPACD1 are two logical system names. #TS1002, #TS1003 and #TS1003 are User ids (Sign-on Id's if you use /SIGN ON, Lterm names if you do not).

COP208

Check your DFSVSMnn member of Ctl Region PROCLIB contains

Explanation: IMS could not allocate and/or open the COPE terminal database, USTDLMGR.

Possible causes are:

- No 22K OSAM database buffers specified in DFSVSMnn
- DFSMDA member USTDLMGR not in Ctl and/or DLISAS STEPLIB
- Dataset for USTDLMGR is not there
- Randomizer DFSHDC40 not in Ctl and/or DLISAS STEPLIB
- Some other database allocation and/or open problem

System Action: All transactions produce a "Status=AI" message, and the MPP program is not invoked.

User Response: Check that DFSVSMnn member of Ctl Region //PROCLIB library contains buffers for USTDLMGR:

IOBF=(22K,16,N,Y)RTT 1ST ENTRY

The above is suitable if DBD USTDLMGR is ACCESS=(HDAM,OSAM) and SIZE=22528. You may have changed these values, e.g. to VSAM (use VSRBF=24576,16), or to a different blocksize/CIsize (ISPF 3.2 the dataset for OSAM, LISTC ENT('..) ALL for Vsam).

Check the Ctl and DLISAS region STEPLIB has the dynamic allocation module for USTDLMGR - regenerate if missing (the JCL is in DYNJCL, out of 4.11). Browse the module to check the dataset name.

Check the Ctl and DLISAS region STEPLIB has the randomizer module DFSHDC40 (its normally in RESLIB).

Look on the DLISAS region JOBLOG (and/or Ctl Region JOBLOG) for a DFS0730I message, and look up the code in the message in the IMS messages manual, for help with other allocation or open problems.

COP209

Saving LLE chain

Explanation: COPE saves the names of preloaded modules in an in-storage table when the first transaction runs through a message region, using the Load List Elements. On a logical system change, COPE cleans up all modules except the ones on this saved list.

System Action: Transactions process normally.

User Response: None - information only.

COP210

xx module name(s) saved

Explanation: The names of preloaded modules have been saved in an in-storage table. You can display this table using VERSION LLE. This tells you what modules were preloaded.

System Action: Transactions process normally.

User Response: None - information only.

COP211

Hiding modules for Lsys number xx

Explanation: COPE is cleaning up modules that were left loaded by application programs, on a logical system change. COPE will "hide" the modules, by renaming them in their CDEs to a ›nnnnnnn name. When the message region switches back to the logical system that loaded these modules, they will be "unhidden", by renaming them back to their real names. This message appears only if DEBUG 2 is on.

System Action: Transactions process normally.

User Response: None - information only.

COP212

Deleting modules to saved LLE status

Explanation: COPE is cleaning up modules that were left loaded by application programs, on a logical system change. Deleting occurs because you have DEBUG MODE 9 on. The recommended MODE is OFF, which "hides" rather than deletes. This message only appears if DEBUG 2 is on.

System Action: Transactions process normally. If your modules won't tolerate this cleanup, you may get S0C4's later.

User Response: If your modules depend on not being deleted from the message region, you should be running DEBUG MODE OFF, rather than MODE 9. This will "hide" rather than delete the modules, on a logical system change. The modules are "unhidden" when the message region switches back to the logical system that loaded them.

COP213

Module "xxxxxxxx" not on saved LLE, LN=yy

Explanation: COPE will cleanup this module, because it was left loaded in the message region by an application program, and the message region is switching to a different logical system. This message appears once, the first time that cleanup occurs for a module. The LN is the logical system number being switched to.

System Action: Transactions process normally.

User Response: Normally none. If you retain a pointer to this module in a preloaded, un-imported, module, that pointer will not be changed, and therefore this version of the module will be used in all logical systems. If you need variation of this module across logical systems, you must import the preloaded module that contains the pointer. If you retain no pointers to modules, variation will always occur, without the need for importing.

COP214

Module "xxxxxxxx" disappeared from region, LN=yy

Explanation: COPE is trying to cleanup a module that was previously left loaded in the message region, and has found that it is no longer in the region.

System Action: Transactions process normally.

User Response: Normally none. You should probably check that your application programs are deleting this module, even though they previously left it undeleted. Alternatively, an abend may have deleted the module.

COP215

"xxxxxxxx" was hidden name for "yyyyyyyy"

Explanation: If the missing module was hidden, this message gives the real name of the module.

System Action: Transactions process normally.

User Response: None - information only.

COP216

Del minor xxxxxxxx yy time(s). To preload count=zz

Explanation: A preloaded minor CDE (alias entry point name) is being deleted by COPE cleanup, in DEBUG MODE 9.

System Action: Transactions process normally.

User Response: None - information only.

COP217

Del minor xxxxxxxx yy time(s). Not Preloaded

Explanation: A non-preloaded minor CDE (alias entry point name) is being deleted by COPE cleanup, for DEBUG MODE 9.

System Action: Transactions process normally.

User Response: None - information only.

COP218

Delete xxxxxxxx yy time(s). To preload count=zz

Explanation: A preloaded module is being deleted by COPE cleanup, for DEBUG MODE 9.

System Action: Transactions process normally.

User Response: None - information only.

COP219

Delete xxxxxxxx yy time(s). Not Preloaded

Explanation: A non-preloaded module is being deleted by COPE cleanup, for DEBUG MODE 9.

System Action: Transactions process normally.

User Response: None - information only.

COP220

No modules Preloaded, Loaded or Exempt!

Explanation: The VERSION LLE command was entered to display Load List Elements and Exempt module names. There are no modules in the preload list, nor have any modules been loaded since region startup, nor are there any modules exempt from COPE cleanup, and therefore the VERSION LLE command has nothing to display.

System Action: The VERSION LLE command completes, without displaying any Load List Elements or Exempt modules (there are none to display).

User Response: This is a System Error -- call BMC Support. Since the Exempt list is hard-coded in module COPESXP2, this condition should not occur.

COP221

TSO switch TRANCODE taken by user xxxxxxxx

Explanation: You are trying to run this transaction in a TSO region for Xpediter debugging, but another user has taken the TRANCODE that was originally allocated to you. The pool of TRANCODES that COPE uses to support switching to TSO regions is limited in size. When too many users try to switch to TSO simultaneously, COPE automatically takes the least-recently-used TRANCODE and allocates it to a new user. Your TRANCODE was taken in this way.

The size of the pool of TRANCODES is set by the XEXPUSER ZDEFAULT. Either this is too small, or possibly there is a shortage of transaction classes, in which case the IMSGEN MAXCLASS= parameter is too small.

System Action: Discards the transaction. Additional transactions from the same Lterm/Signon, in this logical system, will continue to produce this message, until you delete your TSO switch request, by issuing the XP QUIT command.

User Response: If you no longer wish to switch this transaction to a TSO region for Xpediter debugging, type "XT QUIT" and hit Enter. Then re-run your transaction. It will run in a non-TSO message region. The XT END command deletes your switch-request record in USTDLMGR.

If you still wish to run this transaction in a TSO region for Xpediter debugging, you should talk to other users, and arrange for equitable sharing of the pool of switched TRANCODES.

Then you can enter:

"XP PSBNAME TRANCODE TSOID tsoid",

or go into the COPE XP option under TSO, to re-activate your TSO switch request.

If you want to increase the size of the pool of available TRANCODES, increase ZDEFAULT variable XEXPUSER (estimated Xpediter user count), then run 4.1 Stage 1 Gen, IMSGJCL, XREFJCL and /MOD PREPARE MODBLKS and /MOD COMMIT. To increase MAXCLASS=, you do an option 4.2.ES, change it, then do a Ctlblks (not Modblks) IMSGEN. You might also need to increase MAXREGN=.

COP222

Load fail for Stubx=xxxxxxxx

Explanation: The Stubx named is missing from the XCOPEPGM library, or cannot be loaded. This Stubx name came from the COPEXRF1/2 modules, when COPE setup for switching to a TSO region for Xpediter debugging of a transaction.

User Response: If you no longer wish to switch this transaction to a TSO region for Xpediter debugging, type "XP QUIT" and hit Enter. Then re-run your transaction. It will run in a non-TSO message region. The XT END command deletes your switch-request record in USTDLMGR.

If you still wish to run this transaction in a TSO region for Xpediter debugging, you should regenerate the PSB in 2.PSB, then run an option 4.7 combined PSBGEN, and 4.8 ACBGEN. If this is an Overflow PSB, you might also need to run option 4.1 Stage 1 Gen, IMSGJCL, XREFJCL and /MOD PREPARE MODBLKS and /MOD COMMIT.

COP351

Lsys xxxxxxxx not in XRF1!

Explanation: You issued SYNC, but there is a logical system in USTDLMGR (from ZDBDATA) that is not in COPEXRF1 (from XREFDATA). The mismatch could be due to not running DYNJCL, or XREFJCL after a 4.2.G, 4.11 or 4.1 Stage 1 Gen, or the wrong library on the COPESTEP DD in the message region.

System Action: Assumes the logical system is not there, for SYNC purposes. Other transactions will run correctly. / commands under COPE won't know about the missing logical system. Start/Stop won't reflect the IMS status of databases in the missing logical system.

User Response: Run ISPF 4.2.G, and run IMSGJCL, DYNJCL and XREFJCL. Do a /MOD PREPARE MODBLKS, /MOD COMMIT, and REFRESH. Check that the ZDEFAULT XCOPEPGM library is on the COPESTEP DD of all message regions, preferably on top of the concatenation. If it is wrong, correct it, and do a REFRESH to bring in the correct COPEXRF1 module.

In most cases, it is not urgent to correct this problem.

COP352

Sync status xxxxxxxx -------------------------------------------.

Explanation: Following this line is a summary of the IMS status of databases, transactions and pro- grams, obtained by SYNC, by issuing /DIS STATUS commands.

System Action: Summary lines of databases STOPPED, NOTINIT, etc, are produced following this line.

User Response: The SYNC status display may alert you to problems such as databases that are OTINIT (no DBD) or unallocatable (ALLOCF) or programs that are NOTINIT (no PSB), which you can correct in COPE ISPF option 4.7, 4.8, and 4.2.ED. If the display is truncated at the bottom of the screen, look on the message region JOBLOG for the complete display. Lists of database names, etc., are truncated on the right in both places; you use regular IMS /DIS STATUS commands if there are more than just a few problems.

COP353

Sync actions xxxxxxxx --------------------------------------.

Explanation: Following this line is a summary of the actions taken by the SYNC command, on the basis of the results of the /DIS STATUS commands issued by SYNC, as in this example:

Sync Actions ------------------------------------------
2 CTF4 DB *SYNC'D*: ACCOUNTS CUSTOMER
2 CTF4 DB P'D: ACCOUNTS CUSTOMERIOBF=(22K,16,N,Y)
1 CTF4 TRAN *S'D*: SMACF100
1 TFT4 TRAN *S'D*: SMACF100
1 TRAN *SYNC'D*: SMACF100

*SYNC'D* means a /DBR command was issued for databases, or a /STA TRAN and /STA PROG was issued for transactions.

*P'D* means the database was COPE -stopped.

*S'D* means the transaction was COPE -started.

System Action: Summary lines of actions taken by SYNC, are produced following this line.

User Response: The SYNC actions display shows you what Databases, Transactions and Programs have been IMS-started or stopped, or COPE -started or stopped. Transactions that were hung or not working because of out of sync conditions will then work.

COP354

Sync ran out of main storage - xxK available

Explanation: REGION= is too small in the message region. SYNC Getmains storage in 4K blocks below the line. The message tells you how much storage had been gotten by SYNC prior to GETMAIN failure for another 4K.

System Action: The SYNC command frees all storage it has gotten, and terminates, without correcting any out-of-sync conditions. Transactions which were hung because of out-of-sync conditions remain hung.

User Response: Increase the REGION= parameter in the message region (e.g. to REGION=5M). Sync uses 96 bytes per stopped database or transaction (which it frees on completion). Use the DEBUG REGION command to see how much storage is available in the message region. If there appears to be plenty of storage, then this is probably a System Error -- call BMC support.

COP355

Error doing /DIS TRAN COPExxxx, Code=xxxxxxxx

Explanation: SYNC attempted to do a /DIS TRAN ALL, or /DIS TRAN COPExxxx, in order to get the names of the MSC remote physical systems (which are defined via COPExxxx TRANCODES), but got an error, either in looking up XRF2, or in issuing the /DIS, or in storing the results onto USTDLMGR with CPXXxxxx keys.

System Action: Other Sync processing, such as synchronizing Start/Stop, unhanging terminals by starting transactions, etc., continues. MSC remote logon "dot" commands won't be recognized properly.

User Response: Report the error to BMC. This error only affects your ability to enter MSC remote logons with a "dot" format command (e.g. A.A1). You can use LOGONRS A A1 instead (no dot, and with LOGONRS on the front).

Information for BMC personnel only: The code is returned by COPEUTPS, COPESXLS or COPEBAxx. Look at the comments in the module's source. If from a BAxx module, the second and/or third byte will be the xx module suffix.

COP401

Psys Id bad -- regen Stubx to fix, $DB Id=xx, other Id=yy

Explanation: There is a mismatch of Psys id (XCOPEINU variable) between records in USTDLMGR and Stubx's.
This happens typically if a Stubx library is copied from one Psys to another. Stubx's must be regenerated in each Psys, not copied, because they contain Lsys names, and PCB layouts for the Lsys's which can be different in different Psys's.

System Action: Discards the transaction.

User Response: Check to see if Stubx's were copied from another Psys. Another possible cause is a change to the XCOPEINU variable. Then generate all affected Stubx's (4.7 PSBGEN). If unsure of which Stubx's are affected by the problem, generate all of them.

Also check the Psys id that was loaded into USTDLMGR. If this is the problem, do a 4.11 and run BMPUJCL.

COP402

Lsys xxxx not found in this Psys!

Explanation: The user is logged onto a logical system that is not defined in the USTDLMGR records in this physical system. The user should logon to a defined logical system to correct the problem.

Possible causes are:

- Lsys was deleted
- COPEBSYS DD specifies bad Lsys (BMP/Batch only)
- Bad Lsys transmitted from remote physical system
- Wrong Psys ZDBDATA records loaded into USTDLMGR.

System Action: Discards the transaction.

User Response: Logon to a valid logical system. If this is a Batch job, correct the Lsys name specified as the last qualifier of the dataset name on the COPEBSYS DD. If bad Lsys came from remote MSC system, call your COPE Support person (internal error). If records from the wrong Psys were loaded into USTDLMGR, run option 4.11 and BATLJCL to load the correct records.

COP403

xxxxxxxx In Use by yyyyyyyy, system zzzzzzzz

Explanation: Allocation of the datasets for this logical system had failed because the dataset named is DISP=OLD by the Job named on the system (i.e. CPU) named. The dataset name was originally specified as one of the datasets for this logical system in ISPF COPE option 4.11 (MDS).

System Action: This message is produced on every transaction in this Lsys, until you fix the problem. COPE will assume non-switching, so will probably also give you a C-Pgm load fail message following this message.

User Response: Either cancel the Job named, or wait for it to complete, or if it is a TSO user, ask them to issue a FREE DA('...dsn...) command. Then REFRESH and run the transaction again.

COP404

xxxxxxxx was previously In Use

Explanation: Allocation of the program libraries for this logical system had failed because the dataset named was DISP=OLD by another JOB, at some previous time. Allocation does not retry until a user issues the REFRESH command.

User Response: Either cancel the Job named, or wait for it to complete, or if it is a TSO user, ask them to issue a FREE DA('...dsn...) command. Then REFRESH and run the transaction again.

COP405

xxxxxxxx Not Found

Explanation: The dataset named is not in the catalog. Either the dataset name is misspelled (in option 4.11 MDS, or 4.2. MDS, or 4.1.5) or the dataset needs to be allocated on disk.

User Response: If the dataset name is misspelled, correct it in option 4.11 (MDS), submit the job that 4.11 generates, and issue the REFRESH command under IMS. If the dataset should be on disk, allocate it. The next transaction for this Lsys will pick up the newly-allocated dataset.

COP406

Program libraries for system xxxx not allocated

Explanation: When this User last logged on, a DD was dynamically allocated in the message region for the Tasklib Switching program libraries for the logical system. That DD is no longer allocated, and cannot be allocated. Either program libraries are allocated DISP=OLD by another job, or this logical system has been removed or made "not used", or other logical systems have been deleted or added which make the COPELnnn DD name that was used before no longer usable, or the COPEXRF4 module loaded from the XCOPEPGM (Stubx) library in the message region is not the correct one for this physical COPE system.

User Response: Type LOGOFF on the =====> line and hit Enter, type REFRESH DELETE and hit Enter, then type the name of a logical system and hit Enter. Then rerun the transaction. If the problem returns, use the LIB command to check that the correct program load libraries are allocated for this logical system. To correct them, go to ISPF 4.11, submit the job this generates, then REFRESH. Check that the job ran, and placed the COPEXRF4 module in the XCOPEPGM library on the COPESTEP DD in the message region. Use the LIB COPESTEP command to see what libraries are on this COPESTEP DD. Alternatively, use the VERSION COPEXRF4 command to see what library COPEXRF4 is loaded from.

Note

When you add, or delete logical systems, or change them from Used to Unused or back, you should make sure all users LOGOFF and logon again. You can do this by using the PROCOPT=L load of USTDLMGR (in member LOADJCL in option 4.2.E).

COP407

Program libraries for system xxxx unavailable

Explanation: The Tasklib Switching program libraries for this logical system cannot be allocated, because one or more of them are either not found, or are allocated DISP=OLD by another job. A subsequent message will show the name of the library, and the cause of the problem.

User Response: Look at the messages after this one. If a program library is not found, either allocate it, or correct the spelling of the dataset name in option 4.11 (MDS). If you correct the spelling, submit the job 4.11 generates, then REFRESH. Check that the job ran, and placed the COPEXRF4 module in the XCOPEPGM library on the COPESTEP DD in the message region.

If a program library is allocated DISP=OLD by another job, either cancel the job, or wait till it completes, then do a REFRESH. The libraries will then be allocated in all message regions

COP408

=ERR=> Unauth STEPLIB, or COPERC00 not AC(1) -- fix msg reg JCL

Explanation: The Tasklib cannot be switched because the COPE Region Controller, COPERC00, is unauthorized. This is usually due to bad message region JCL. COPE requires you to set up message region JCL with a single authorized library on the //STEPLIB that contains COPERC00, and all other libraries common to all Lsys's, such as the COPE Stubx library, COBOL run-time library, COPE LOAD library, and RESLIB (Note!) on the //COPESTEP. This is explained in the spaces, and shown in the JCL(COPEMSG1) example JCL member. This is an APF-authorization issue.

System Action: This message is produced on every transaction, until you fix the problem. COPE cannot switch the Tasklib if COPERC00 is unauthorized. Switching the Tasklib means changing the Lsys-specific concatenation (defined in option 4.11) on each transaction. This concatenation is ahead of the COPESTEP, which is ahead of the STEPLIB, in MVS search order. Together the three concatenations form a "STEPLIB" that is functionally equivalent to a regular //STEPLIB in a non- COPE system.

User Response: Change the message region //STEPLIB to point to a SINGLE Authorized library(recomm DYNLOAD). Copy COPERC00 into that library. Note that no module other than COPERC00 will ever be loaded from this library (all modules including DFSRRC00 and other DFS modules will come from the COPESTEP), in the message region. Add or change the message region JCL //COPESTEP so that it points to the Stubx library, XCOPEPGM (usual suffix PGMLIB), then the COBOL run-time library (or other cross-Lsys language or support libraries), then the COPE.LOAD library, then RESLIB. This order (Stubx, Cobol, LOAD, RESLIB) will give you best performance. The "cost" of unnecessary libraries in a concatenation is about 10 mS per module load.
The cost of omitting a necessary library is load failure and terminal hangs. /STO and /STA message regions to bring in the new JCL.

COP451

xxxx

Explanation: This message shows the response returned by IMS for a command that you issued from the COPE =====> line, or preceded by COPE .

System Action: The command completes. Note that /STA, /STO, /DBR, etc commands are not necessarily completed at the time you receive this message. IMS processes such commands asynchronously.

User Response: If you need to know when an asynchronous command (such as /STA, /STO or / DBR) completes, issue /DIS commands repeatedly.

COP452

Command "xxxx" issued for yy name(s)

Explanation: The command you issued contained 6 or more database, transaction or program names. The number of names is shown. If you used an * in a name, this number reflects the "expanded" count of names.

System Action: The command completes. Note that /STA, /STO, /DBR, etc commands are not necessarily completed at the time you receive this message. IMS processes such commands asynchronously.

User Response: If you need to know when an asynchronous command (such as /STA, /STO or / DBR) completes, issue /DIS commands repeatedly.

COP453

"xxxx" is misspelled or not an IMS command

Explanation: The command you issued got a CA status code from IMS.

System Action: The command is discarded.

User Response: Correct the spelling of the command, or look up the command in the IMS Operations Reference Manual.

COP454

"xxxx" must be issued from a cleared screen

Explanation: The command you issued got a CB status code from IMS. IMS does not allow this command to be issued from a program, and therefore it cannot be issued from the COPE =====> line, or preceded by COPE .

System Action: The command is discarded.

User Response: Clear the screen, then issue the command, without preceding it with COPE .

COP455

Transact "xxxx" not in system yyyy

Explanation: The STA or STO command you issued had a transaction code that is not in the Start/ Stop records on USTDLMGR, for this logical system.

System Action: The command is discarded.

User Response: If you misspelled the TRANCODE, reissue with the correct spelling. Note that STA and STO commands do not accept an * on the end of the name (unlike /STA and /STO). If the TRANCODE was correct, check the ZDBDATA member out of option 4.2.G or 4.11 for presence of the trancode. You may need to rerun option 4.11, and run DYNJCL to reload the records onto USTDLMGR.

COP456

Tran "xxxxxxxx" Prog "yyyyyyyy" Lsys "zzzzzzzz" aaaa'

Explanation: The STA or STO command you issued has worked. The Tran has been COPE -started or COPE -stopped. Note that the IMS TRANCODE and program have been /STA'd, even if you issued STO, because they have to be always started, for transactions in other logical systems to be able to run.

System Action: The command completes.

User Response: None, the command has completed normally.

COP458

Database "xxxx" not in system yyyy

Explanation: The STA or STO command you issued had a database name that is not in the Start/ Stop records on USTDLMGR, for this logical system.

System Action: The command is discarded.

User Response: If you misspelled the database name reissue with the correct spelling. Note that STA and STO commands do not accept an * on the end of the name (unlike /STA and /STO). If the DBD name was correct, check the ZDBDATA member out of option 4.2.G or 4.11 for presence of he DBD. You may need to rerun option 4.11, and run DYNJCL to reload the records onto USTDLMGR.

COP459

xxxxxxxx "yyyyyyyy" Lsys "zzzzzzzz" aaaa'

Explanation: The STA or STO command you issued has worked. The database has been started or stopped.

In IMS release 1.3 or lower (only) the IMS database has been /STA'd, even if you issued STO, because they have to be always started, for transactions in other logical systems to be able run. The database will have been allocated to a dummy dataset if it is Cope-Stopped.

In IMS release 2.1 or higher, the IMS status and the Cope status of the database will match.

System Action: The command completes.

User Response: None, the command has completed normally.

COP460

"xxxx" must be DB or TR for yyyy ALL

Explanation: The 2nd parameter of the STA or STO command for all in a logical system was not DB or TR.

The format is:

STA/STO DB/TR &LS/ALL/Lsys

The third parameter &LS is equivalent to ALL, and means all databases in the logical system. Lsys as the 3rd parameter says all in that logical system.

System Action: The command is discarded.

User Response: Specify either DB or TR when you are trying to start or stop all databases or transactions in a logical system.

COP461

"ALL", "&&LS" or system name required on xxxx yyyy command

Explanation: The 3^rd parameter of the STA or STO command was blank. The format is:

STA/STO DB/TR DBD/tran/&LS/ALL/Lsys (Lsys)

The third parameter &LS is equivalent to ALL, and means all databases in the logical system. Lsys as the 3rd parameter means 'all in that logical system'.

The fourth parameter (Lsys) is optional. You would use it for an individual database in a logical system other than the one you are currently logged on to.

System Action: The command is discarded.

User Response: Specify either DBD, TRANCODE, &LS, ALL, or a logical system name as the 3rd parameter.

COP462

"xxxx yyyy zzzz" complete for aa name(s)

Explanation: The STA or STO command for all in a logical system, started or stopped the number of database or transaction names given.

System Action: The command completes. IMS will asynchronously process any /STA, /STO and / DBR commands that were generated internally.

User Response: None. The command has completed normally. Note that the IMS status of data- bases and transactions may not immediately reflect the effects of the command, because the IMS / STA, /STO and /DBR commands are processed asynchronously. If you need to know when the effect is complete, issue /DIS commands repeatedly.

COP501

Module "xxxx" missing

Explanation: The COPE C-number cross-reference module is missing, or could not be loaded, from the //COPESTEP DD in the message region. These modules should have been placed in the XCOPEPGM library by option 4.1 Stage 1 Gen job XREFJCL (for COPEXRFn modules), or MFSGEN or option 5.10.5 (for the COPEMFSX module).

System Action: The transaction continues processing. Translation of real names to C-numbers and vice-versa will not be performed. For XRFn modules, this means that /DIS commands from the COPE screen won't be translated, and the SYNC command won't unhang terminals that are hung due to out-of-sync conditions. For MFSX, screens won't vary correctly across logical systems.

User Response: If XRFn modules are missing, run option 4.1 Stage 1 Gen, then submit the XREFJCL job.
This places COPEXRF1-4 modules in the XCOPEPGM library (named in ZDEFAULT). Check that this library is on the COPESTEP DD in all message regions, preferably on top of the concatenation.

For MFSX, if you want screens to vary across logical systems, import the MFS into the systems (using option 5.7, for example). Check that the MFSGEN jobs generated by import ran with condition codes not greater than 4. If the BMP "REFRESH" step failed, fix it, or just issue the REFRESH under IMS.

If you do not want MFS to vary across logical systems, or if you are sure you have imported all the MFS you need, go into 5.10.5. It will submit a job that creates an MFSX.

When the modules (XRFn or MFSX) are in the XCOPEPGM library (check using Browse), issue REFRESH, to cause all message regions to re-load all XRFn's and MFSX. Display the module in storage in the message region, using the @ command, for example, @COPEMFSX (no space between @ and the module name).

COP554

Expected operator, got "xxxx"! After "yyyy"

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. An operator was not found in the expected position. Operators are: =, =, <, >, <=, >=, <, >.

System Action: Displays the before and after substitution images of the )SEL line.

User Response: Correct the )SEL line in the member of the COPEJCL library that is being submitted via the COPE SUB command. Remember that blanks are needed to delimit variables, constants and operators on the )SEL line. Embedded blanks in variable values are not supported. Quotes are not used to delimit strings.

COP555

Expected operand, got "xxxx"! After "yyyy zzzz aaaa"

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. An | (Vertical bar) or && (double ampersand) expected in the position shown.

System Action: Displays the before and after substitution images of the )SEL line.

COP556

Expected && or | , found "xxxx"! After "yyyy zzzz aaaa"

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. An | (Vertical bar) or && (double ampersand) is expected in the position shown.

System Action: Displays the before and after substitution images of the )SEL line.

COP557

Expecting && or | , found "xxxx"! After "yyyy zzzz aaaa"

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. An | (Vertical bar) or && (double ampersand) is expected in the position shown.

System Action: Displays the before and after substitution images of the )SEL line.

COP558

Expecting variable after "xxxx yyyy zzzz &&

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. A variable or constant is expected after && (double ampersand).

System Action: Displays the before and after substitution images of the )SEL line.

COP559

Expecting operator, but got "xxxx"! After "yyyy zzzz && aaaa"

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. An operator is expected after a variable or constant.

Operators are: =, =, <, >, <=, >=, <, >.

System Action: Displays the before and after substitution images of the )SEL line.

COP560

=BEF=> xxxxxxxx

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. The statement before substitution of & variables is shown.

System Action: Displays the after substitution image of the )SEL line.

COP561

=AFT=> xxxx

Explanation: The syntax of a )SEL statement in a JCL member is incorrect. The statement after substitution of & variables is shown.

System Action: Continues syntax checking, but will not submit the JCL.

COP562

Nothing following ")SET"!

Explanation: The syntax of a )SET statement in a JCL member is incorrect. The statement should specify a variable name, an = sign and a value or arithmetic calculation, as in these examples:

SET VOLSER = TSG901
SET V1 = TSG90&LN
SET P1 = &P1 - 23 + &P2

System Action: Continues syntax checking, but will not submit the JCL.

User Response: Correct the )SET line in the member of the COPEJCL library that is being submitted via the COPE SUB command. Remember that blanks are needed to delimit variables, constants and operators on the )SET line. Embedded blanks in variable values are not supported. Quotes are not used to delimit strings.

COP563

"=" must follow ")SET xxxx"!

Explanation: The syntax of a )SET statement in a JCL member is incorrect. The statement should specify a variable name, an = sign and a value or arithmetic calculation, as in these examples:

SET VOLSER = TSG901
SET V1 = TSG90&LN
SET P1 = &P1 - 23 + &P2

System Action: Continues syntax checking, but will not submit the JCL.

COP564

OPEN SYSOUT DCB+48=xxxxxxxx...

Explanation: The VERSION OPEN command, which tests the Qsam Intercept for Program Traces, opened a SYSOUT, SYSOUU or SYSOUV DD.

System Action: Continues with the test.

User Response: None, information only.

COP566

CDE

Explanation: The VERSION command found a CDE for the program, indicating that the program was already loaded in the region. A CDE is a Contents Directory Entry. A CDE is only found if the program is preloaded, or was loaded without being deleted.

System Action: Displays the CDE.

User Response: If the program is not preloaded, and is not Exempt from cleanup, be aware that COPE will delete this program from the region on a logical system change. Use VERSION LLE to display a list of all Preloaded, and Exempt from cleanup, modules. You may need to preload the program, using the DFSMPLnn list. Modules can be made Exempt from cleanup by modifying the list in COPESXP2 (normally preloading is equivalent to doing this).

COP567

xxxxxxxx yyyyyyyy

System Action: Displays the CDE.

User Response: If you need to decode the CDE, use the Dsect in SYS1.MACLIB(IHACDE). Information in the CDE is normally not very useful.

If the program is not preloaded, and is not Exempt from cleanup, be aware that COPE will delete this program from the region on a logical system change. Use VERSION LLE to display a list of all Preloaded, and Exempt from cleanup, modules. You may need to preload the program, using the DFSMPLnn list. Modules can be made Exempt from cleanup by modifying the list in COPESXP2 (normally preloading is equivalent to doing this).

COP570

Minor CDE does not point to a major CDE

Explanation: The VERSION command found a minor CDE for the program, indicating that the program is an entry point of another program that was already loaded in the region. A CDE is a Contents Directory Entry. A CDE is only found if the program is preloaded, or was loaded without being deleted. However, the minor CDE did not point to a major CDE, as it should.

System Action: The VERSION command continues without displaying the CDE.

User Response: This condition should not occur because MVS always maintains minor CDEs so that they point to major CDEs. It indicates a System Error, call BMC Support.

COP571

XL, xx bytes

Explanation: The VERSION command found that the program is already in storage, indicating that it was either preloaded, or was loaded without being deleted. It displays the length of the program in storage, from the Extent List. This length is the length of the entire load module, not just the CSECT or subroutine that has the program name.

System Action: The VERSION command displays the start of the module in storage, using the address in the XL.

User Response: The number of bytes will match the length of the module in the directory entry. This may help when checking which version of a module is present.

COP572

xxxxxxxx yyyyyyyy

Explanation: The VERSION command found that the program is already in storage, indicating that it was either preloaded, or was loaded without being deleted. It displays the address of the start of the module, and the first 64 bytes of the module. The start of the module is not necessarily the same thing as the start of the program, because there may be multiple subroutines (CSECTs) in the module.

System Action: The VERSION command continues by loading the program, and displaying the bytes at the entry point to the program.

User Response: If there is a date/time stamp near the start of the module, this will appear in the display, and may help when checking which version of a module is present.

COP577

Loaded "xxxxxxxx", yy bytes

Explanation: The VERSION command issued a LOAD for the program, and displays the number of bytes in the entire module. If this message is not preceded by COP566, then the program was read from disk. If it was preceded by COP566, the program was already in storage (either preloaded, or was loaded by some other transaction and not deleted).

System Action: The VERSION command continues by displaying the bytes at the entry point to the program.

User Response: The number of bytes will match the size in the directory entry, which may help when checking which version of a module is present.

COP578

xxxxxxxx yyyyyyyy

Explanation: The VERSION command issued a LOAD for the program, and displays the first 64 bytes at the entry point to the program (which is not necessarily the same thing as the start of the entire module). If this message is not preceded by a COP566 message, then the program was read from disk. If it was preceded by a COP566 message, the program was already in storage (either preloaded, or was loaded by some other transaction and not deleted).

System Action: The VERSION command completes.

User Response: If there is a date/time stamp near the start of the program, this will appear in the display, and may help when checking which version of a program is present.

COP581

xxxxxxxx yyyyyyyy zzzzzzzz aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff g

Explanation: The VERSION command searched the program libraries currently concatenated in the message region, found the load module containing the program, and is displaying the link-edited date from the "short" record in the load module that precedes the module itself. If this message is preceded by a COP566 message, the program was already in storage (either preloaded, or was loaded by some other transaction and not deleted), and therefore may have been loaded while another program library concatenation was present in the message region.

System Action: The VERSION command issues a DELETE for the program (corresponding to the LOAD it issued earlier) and completes.

User Response: This link-edited date may help when checking which version of a program is present. If a COP566 does not precede this message, then the date is guaranteed to be accurate.

If a COP566 message precedes this message, then the program module was loaded into storage at some other time, possibly from a different library.

COP583

DCB xxxxxxxx DD=yyyyyyyy OPENED PUT-MOVE

Explanation: The DEBUG SYSOUT n command opened a DCB at the address given in PUT-MOVE mode (MACRF=PM).

System Action: The DEBUG SYSOUT n command randomly opens n DCBs to DDs SYSOUT, SYSOUU and SYSOUV, and writes 100 lines to each DCB, in a random order.

User Response: The DEBUG SYSOUT n command tests the QSAM intercept. This message tells you what DCBs are opened in the current test. Repeating the command will test different random combinations. You view the result of the test in COPE ISPF 2.7, to see whether the Qsam PUTs are being written to the log correctly.

COP584

DCB xxxxxxxx DD=yyyyyyyy OPENED PUT-LOCATE

Explanation: The DEBUG SYSOUT n command opened a DCB at the address given in PUT-LOCATE mode (MACRF=PL). Cobol Ready Trace uses PUT-LOCATE.

System Action: The DEBUG SYSOUT n command randomly opens n DCBs to DDs SYSOUT, SYSOUU and SYSOUV, and writes 100 lines to each DCB, in a random order.

User Response: The DEBUG SYSOUT n command tests the QSAM intercept. This message tells you what DCBs are opened in the current test. Repeating the command will test different random combinations. You view the result of the test in COPE ISPF option 2.7, to see whether the Qsam PUTs are being written to the log correctly.

COP585

Module "xxxxxxxx" was preloaded yy time(s) at region zzzz startup

Explanation: The VERSION command found that this module was preloaded in this region, at region startup.

The number of times loaded (normally 1) is shown. An example of when it should not be 1 is ILBOCOM0 and ILBOSTT0, (should be 2 for them).

In COPE message regions, IMS DFSMPLxx preload loads from the COPESTEP DD, not from the Lsys-specific libs, and not from the STEPLIB.

System Action: The VERSION command continues. Since the module is preloaded, it will next search the COPESTEP DD, to give you the link-edit date, instead of searching the Lsys-specific Cnnnnnnn DD.

User Response: Check you want this module preloaded in this message region. If this msg region is shared by multiple Lsys's, this module will be the same in all of those Lsys's (preloaded modules aren't varied). This is appropriate for system modules, but may or may not be what you want for application modules.

COP586

=WARN> "xxxxxxxx" wasn't preloaded, but is now loaded in region yyyy

Explanation: The VERSION command found that this module was not preloaded, but is now present in this message region.

Somewhere in your application, either accidentally or deliberately, you loaded this module and then didn't delete it.

MVS does not record the origin of loaded modules, so there is no way for the COPE VERSION command to accurately determine who loaded this module, where they loaded it from, and, of course, why the person who loaded it didn't delete it.

System Action: The VERSION command continues. Since the module was not preloaded, it will next search the Lsys-specific libraries to determine the link-edit date, but this might not be where whoever loaded this module loaded it from, so the result might not be the right module.

User Response: Check you want your application program (whichever one it might be) to load this module and not delete it at the end of the transaction.

COP587

=WARN> "xxxxxxxx" was preloaded, but now load count=yy in region zzzz

Explanation: The VERSION command found that this module was preloaded, but now has a different MVS "load count" from when it was preloaded.

Somewhere in your application, either accidentally or deliberately, you loaded or deleted this module. The number or loads you issued did not match the number of deletes you issued.

If you keep loading this without deleting it, you will eventually get an abend when the count exceeds 32,767.

User Response: Check you want your application program (whichever one it might be) to disturb the load count like this, and that you are not exposing yourself to abend by loading it more than 32,767 times, or S0C4's by deleting it altogether, (e.g. other modules or IMS might have retained the address somewhere, so will S0C4 after you delete it).

COP601

Recursive entry to Trace Logger, DD=xxxxxxxx

Explanation: The Trace Logger, COPESXP6, was entered recursively. This could happen if a program opens a COPERRMS DCB and writes to it.

System Action: SXP6 exits immediately, without tracing this Qsam PUT line. Some Program Trace lines may be missing from the log, because of this.

User Response: Try to find the program that is erroneously opening a COPERRMS DCB and change it so that it either doesn't open one ( COPE will still work, because it will use the one opened by COPERC00) or uses another DD name.

COP602

Writing to unopened DCB at xxxxxxxx! DD=yyyyyyyy

Explanation: The program issued a PUT (or write) to a DCB that has somehow become closed. COPE intercepts all PUTs to SYSOUT in the message region, and checks the DCB is open.

System Action: COPE passes control to the MVS PUT routine, which will then S0C4.

User Response: Check that the program opens files that it writes to, and keeps them open. This error is most likely caused by a storage overlay, so check the dump at the DCB address in the message for an overlaying I/O area, etc. The DD name is probably not valid, because it was also overlaid.

COP603

Writing to DSORGª=PS DCB at xxxxxxxx! DD=yyyyyyyy

Explanation: The program issued a PUT (or write) to a DCB that was not physical sequential.

System Action: COPE passes control to the MVS put routine, which will write this and subsequent trace records for this transaction to JES (IOF or SDSF).

User Response: This error is most likely caused by a storage overlay of the DCB. If the program abends, check the dump at the DCB address in the message for an overlaying I/O area, etc. The DD name is probably not valid, because it was also overlaid. If the program does not abend, this condition is a System Error -- call BMC support.

COP604

Writing to MACRFª=P DCB at xxxxxxxx! DD=yyyyyyyy

Explanation: The program issued a PUT (or write) to a DCB that was not open for PUTs.

System Action: COPE passes control to the MVS put routine, which will write this and subsequent trace records for this transaction to JES (IOF or SDSF).

COP605

Writing to LRECL=xx DCB at yyyyyyyy! DD=zzzzzzzz

Explanation: The program issued a PUT (or write) to a DCB that had a record length greater than 255.

System Action: COPE passes control to the MVS put routine, which will write this and subsequent trace records for this DCB in this transaction to JES (IOF or SDSF).

COP606

Writing to RECFM=U DCB at xxxxxxxx! DD=yyyyyyyy

Explanation: The program issued a PUT (or write) to a DCB that had a record format of Undefined, or the record format bits were zero.

System Action: COPE passes control to the MVS put routine, which will write this and subsequent trace records for this DCB in this transaction to JES (IOF or SDSF).

COP607

Too many open DCBs in message region

Explanation: The program has opened too many DCB's for DD's that point to SYSOUT. Each opened needs a 272-byte I/O area in the COPE intercept routine, and the 4K area provided is full.

System Action: The output will go to the message region DD, and will not be intercepted by COPE and sent to the IMS log.

User Response: Look at the message region output, for the output that could not be intercepted to the log. If problem occurs frequently, the COPEF macro can be changed on the line "&GM(14) SETC QSAM 4K" to increase the 4K to a higher value, and COPERC00 reassembled. Possibly this error is a System Error -- call BMC Support.

COP651

xxxx Terminal DB (USTDLMGR) user segment deleted

Explanation: The user segment in USTDLMGR for your terminal was deleted, in response to a LOGOFF DELETE command. Future transactions from your terminal will give a "You are not logged on" message, until you insert a new segment, by logging on to a logical system.

System Action: Other BMC segments will be scanned-for, and deleted if present. This action is the same as re-initializing USTDLMGR, except it only applies to your terminal, and not to other terminals.

User Response: By entering LOGOFF DELETE, you deleted the segment that names the logical system that your terminal is logged onto. Enter the logical system name that you want to logon to, on the =====> line, to insert a new segment. You won't be able to run any transactions until you logon (other than COPE or Start/Stop transactions).

COP652

Explanation: The BMC "P" record named, for your terminal, was deleted, in response to a LOGOFF DELETE command. Future BMC transactions from your terminal will get a "not logged on" message, until you insert a new "P" segment, by logging on via BMC. The number after the "P" is the logical system number.

User Response: By entering LOGOFF DELETE, you deleted COPE logon segments, and BMC segments. You must logon to COPE , by entering the logical system name that you want to logon to, on the =====> line. You must logon to BMC also, using your application logon transaction. You should find that any U3508 abend problems, that you had before you issued LOGOFF DELETE, will not re-occur.

COP653

xxxx "Syy" record deleted

Explanation: The BMC "S" record named, for your terminal, was deleted, in response to a LOGOFF DELETE command. This resets session information used by the BMC Dialog Manager.

User Response: By entering LOGOFF DELETE, you deleted COPE logon segments, and Standardware segments. When you log back onto COPE , and back onto BMC, you should find that any U3508 problems, that you had before you issued LOGOFF DELETE, will have gone away.

COP654

xxxx "Cyy" record deleted

Explanation: The BMC "C" record named, for your terminal, was deleted, in response to a LOGOFF DELETE command. This resets current-panel-hierarchy information used by the BMC Dialog Manager.

COP655 Lsys xxxx is Stopped

Explanation: The logical system you are logged onto, named in the message, is stopped on the TR (Transaction) side. No program libraries (Tasklibs) can be allocated when a system is stopped. Someone has probably stopped the system specifically for the purpose of preventing people from using the system and the libraries.

System Action: No transactions run in this stopped logical system. Transactions will run in other logical systems, as long as they are not stopped.

User Response: Either use a logical system that is started, or start this one. To find out which systems are started, hit Enter, and the list appears next to an AVAIL> arrow. To start a system on the TR (Transaction) side, go into SS, put S, then TR, then blank transaction Name, and then the System name, and hit Enter.

COP656

User xxxx not found

Explanation: The GHU to delete or replace the logon segment named, failed with a GE.

System Action: If this is a logon or logoff FROM ALL command, other logon segments will attempt to be processed.

User Response: This condition should not occur, because it should not be possible for the GHU to fail after a GU or GN has succeeded for the same key. You should set TRACE ON, repeat the command, and then call BMC support with the trace output available.

COP657

Ecsa initialized with xx user(s)

Explanation: The LOGON ECSA command has initialized the logon table in ESCA with an entry for each user that has been logged onto COPE since USTDLMGR was reinitialized. The table shows the logical system that each user is logged on to. When a user logs on and off logical systems, the message regions update this table. The Control Region looks up the table when it needs to translate MFS names in /FOR commands from cleared screens, or in 4700 input and output messages.

System Action: Normal processing.

User Response: None - information only. The absence of this message after IMS startup indicates that you don't have a LOGON ESCA command coded in your COLDS, WARMS, and EMERS command definitions inside the COPEO member of MENUS. You must code this, for consistent translation of /FOR from cleared screen and for 4700 translation. If you do not have 4700's, you may have chosen not to code LOGON ECSA, because of the overhead of scanning USTDLMGR at IMS startup. In this case, your users should always use COPE /FOR (rather than /FOR from a cleared screen) in order to avoid confusion.

COP658

Ecsa initialize had RC=xx, yy user(s)

Explanation: The LOGON ECSA command had a bad return code from the authorized routine inside COPERC00. You probably are not running the correct version of COPERC00 (which must be authorized on the STEPLIB of the message region).

System Action: /FOR command from cleared screen, and 4700 input/output messages, will not have their MFS names translated.

User Response: Check that you installed the correct level of COPERC00 on the message region STEPLIB. This module must match the level of COPESXP1 and COPEUTP1 that are loaded from the COPESTEP, and the DFSAOUE0 that you linked into the IMS nucleus in the control region. To check levels, browse the load modules, and compare the date/times near the beginning of the modules, which should be approximately the same as each other, and should match exactly the date/times in the load modules from a single COPE SMPE installation.

COP659

LOCAL ESET TABLE ("DFSLESE") NOT ON CDE CHAIN!

Explanation: The DB2 RTT or DB2 RTTCLOB command, which displays SSM line and RTT information and tests the DB2 interface, could not find the Local External Subsystem Entry Table in the message region. Either there is no SSM parameter specified in the control region, or there is an SSM parameter specified in the message region. COPE does not support the IMS option to specify an SSM parameter in the message region. COPE requires you to specify an SSM parameter in the control region.

System Action: COPE will not vary the plan name for SQL calls that run in this message region, nor trace the SQL calls. DB2 is not usable in this message region.

User Response: Check that the message region JCL does not have an SSM parameter specified. (14th parameter, 13 commas in). Check that the control region JCL does specify an SSM parameter (49th parameter, 48 commas in). Recommended value for this parameter is SSM, so that the name of the Sub-System Member in the PROCLIB library is the 4-character IMSid, suffixed with SSM. Check this member is present, and has an RTT table, that is available on the message region DFSESL DD (even though the SSM parameter is in the control region, the RTT is loaded from the message region).

If you are not using DB2, the command "DB2 RTT" will always give this error.

COP660

NO LOCAL ESET ENTRIES!

Explanation: The DB2 RTT or DB2 RTTCLOB command, which displays SSM line and RTT information, and tests the DB2 interface, found the Local External Subsystem Entry Table module in the message region (DFSLESE), but the pointer to the first local ESET Entry, at offset +4 in the module is zero. There is probably an SSM parameter specified erroneously in the message region PARM. COPE does not support the IMS option to specify an SSM parameter in the message region. COPE requires you to specify an SSM parameter in the control region.

System Action: COPE will not vary the plan name for SQL calls that run in this message region, nor trace the SQL calls. DB2 is not usable in this message region.

User Response: Check that the message region JCL does not have an SSM parameter specified. 14th parameter, 13 commas in). Check that the control region JCL does specify an SSM parameter (49th parameter, 48 commas in). Recommended value for this parameter is SSM, so that the name of the Sub-System Member in the PROCLIB library is the 4-character IMSid, suffixed with SSM.Check this member is present, and has an RTT table, that is available on the message region DFSESL DD (even though the SSM parameter is in the control region, the RTT is loaded from the message region).

COP661

SSM MEMBER LINE=xxxxxxxx

Explanation: The DB2 RTT or DB2 RTTCLOB command displays each SSM line, as found in the message region, as in this example:

SSM MEMBER LINE=DSN1SYS1DSNMIN10COPERTT -
RTT 1ST ENTRY
00CD874C:COPEUTP6COPEUTP6

DSN1 is the 8-character DB2 subsystem name (may be 4 characters in pre-IMS 2.2 releases, which is OK).

SYS1 is the 4-character SQL id. This may be any unique value ( COPE will clobber the SQL id in DSNHLI to match this value, on every SQL call).

DSNMIN10 is the subsystem interface module name and should always be exactly this value.

COPERTT is the RTT table name, and should appear as this. - is the command-prefix character for IMS to DB2 commands.

RTT 1ST ENTRY should appear as shown (there is only one entry in COPERTT, and it is clobbered to COPEUTP6).

System Action: The DB2 command displays every line in the SSM (usually there is only one line), and goes on to issue test SQL calls.

User Response: Check that the correct name for the DB2 system appears in the SSM line, and the name COPERTT appears. If they are wrong, modify your SSM member in the control region //PROCLIB library, and bring IMS down and up. Also check that the module, COPERTT, is available on the authorized //DFSESL DD in each message region.

COP662

NO EEVP!

Explanation: The DB2 RTT or DB2 RTTCLOB command, which displays SSM line and RTT information, and tests the DB2 interface, found a zero address of the EEVP, at +4 in the control block that holds the SSM line. This is probably a System Error.

System Action: COPE will not vary the plan name for SQL calls that run in this message region, nor trace the SQL calls. DB2 is not usable in this message region.

User Response: User Response: Check the setting up of the SSM and RTT, as described under message COP157. If this is not the problem, call BMC support.

COP663

NO RTT

Explanation: The DB2 RTT or DB2 RTTCLOB command, which displays SSM line and RTT information, and tests the DB2 interface, found a zero address for the RTT, at +28 in the EEVP control block. The SSM member probably does not specify an RTT table (it should specify COPERTT), or the RTT module could not be loaded from the authorized //DFSESL DD in the message region.

System Action: COPE will not vary the plan name for SQL calls that run in this message region, nor trace the SQL calls. DB2 is not usable in this message region.

User Response: Check the setting up of the SSM and RTT, as described under message COP157. If this is not the problem, call BMC support.

COP664

RTT+0%=0, RTT=xxxxxxxx

Explanation: The DB2 RTT or DB2 RTTCLOB command, which displays SSM line and RTT information, and tests the DB2 interface, found an RTT with zero in its first fullword. This is not a valid RTT format.

System Action: COPE will not vary the plan name for SQL calls that run in this message region, nor trace the SQL calls. DB2 is not usable in this message region.

User Response: Check the setting up of the SSM and RTT, as described under message COP157. Check that the COPERTT module on the //DFSESL DD in the message region is the same as the one delivered in the COPE load library. If this is not the problem, call BMC support.

COP665

APPLNAME.TNAME=xxxxxxxx

Explanation: The DB2 command tests the DB2 interface by issuing an OPEN and FETCH SQL calls against PLAN-TABLE. This message shows the APPLNAME and TNAME columns returned by the FETCH.

System Action: A SQL CLOSE will be issued when the FETCH gives a non-zero return code, or after 16 FETCHs.

User Response: This message indicates the calls are working correctly, so no response is needed.

COP666

DB2 FETCH SQLCODE=xx

Explanation: The DB2 command tests the DB2 interface by issuing an OPEN and FETCH SQL calls against PLAN-TABLE. This message shows the first non-zero FETCH return code, or a zero return code if 16 FETCHs executed.

System Action: A SQL CLOSE will be issued.

User Response: A return code (SQLCODE) of 0 or 100 indicates all is working. If you get a -818, the plan was not bound with the DBRM that corresponds to the load module. You can rebind the plan using the DBRMLIB delivered, or reassemble and rebind COPEUTP6 using JCL similar to that provided in JCL(ASMDB2).

For other return codes, either consult the DB2 manual, or do a TRACE ON, then DB2, then look at the trace in COPE ISPF option 2.7, which will show the return code explanation text.

COP667

Error doing /DIS TRAN COPExxxx, Code=xxxxxxxx

Explanation: REFRESH attempted to do a /DIS TRAN ALL, or /DIS TRAN COPExxxx, in order to get the names of the MSC remote physical systems (which are defined via COPExxxx TRANCODES), but got an error, either in looking up XRF2, or in issuing the /DIS command, or in storing the results onto USTDLMGR with CPXXxxxx keys.

System Action: Other Refresh processing, such as reloading XRF modules, clearing BLDL lists, etc, continues. MSC remote logon "dot" commands will not be recognized properly.

Information for BMC personnel only: The code is returned by COPEUTPS, COPESXLS or COPEBAxx. Look at the writeup in these modules' sources. If from a BAxx module, the second and/ or third byte will be the xx module suffix.

COP670

DB2 CLOSE SQLCODE=xx

Explanation: The DB2 command tests the DB2 interface by issuing an OPEN and FETCH SQL calls against PLAN-TABLE, and then a CLOSE.

System Action: The DB2 test command completes.

User Response: You should look up a non-zero return code in the DB2 manual. Alternatively, do a TRACE ON, then DB2, then look at the trace in COPE ISPF option 2.7, which will show the return code explanation text.

COP671

Logical system "xxxx" is not in COPEMFSX

Explanation: You issued a /FOR command under COPE , but the logical system you are logged onto is not in the COPEMFSX cross-reference module.

System Action: The /FOR command is ignored.

User Response: Browse the COPEMFSX module in the libraries of the COPESTEP DD, and see if there are other logical system names recognizable. COPEMFSX may be missing, or may be from the wrong COPE Physical System. Check that the ZDEFAULT XCOPEPGM library is on the COPESTEP, preferably on top of the concatenation. Re-generate the COPEMFSX module into the XCOPEPGM library using COPE ISPF option 5.10.5.

COP672

CSA Anch not found in ECSA - Check RC00/DFSAOUE0 levels!

Explanation: COPE scanned ECSA looking for its anchor block, and didn't find it. The anchor block is a 4K area getmained in ESCA by the COPE DFSAOUE0 exit in the first Control Region that comes up after an MVS IPL. It remains there until the next MVS IPL. It contains a table, one entry per IMSID. An entry points to the logon table (also in ESCA). Message regions update the logon table when a user logs on or off a logical system. The control region looks up the table when it needs to find out which logical system a terminal is logged onto, so it knows how to translate MFS names in /FOR commands from cleared screens, or in 4700 input and output messages.

System Action: No MFS translation will occur in the control region.

User Response: Check that you linked the level of DFSAOUE0 into the IMS nucleus that matches the level of the COPERC00, COPESXP1 and COPEUTP1 modules. To do this, browse the load modules - the dates near the start of the modules should be about the same. The date/times should match exactly those in the load modules from a single COPE SMPE installation. Install the matching modules in the message region COPESTEP DD, and/or relink the IMS nucleus with the correct level of DFSAOUE0.

COP673 E

csa anchor is at xxxxxxxx

Explanation: COPE scanned ECSA looking for its anchor block, and found it. The anchor block is a 4K area getmained in ESCA by the COPE DFSAOUE0 exit in the first Control Region that comes up after an MVS IPL. It remains there until the next MVS IPL. It contains a table, one entry per IMSID. An entry points to the logon table (also in ESCA). Message regions update the logon table when a user logs on or off a logical system. The control region looks up the table when it needs to find out which logical system a terminal is logged onto, so it knows how to translate MFS names in /FOR commands from cleared screens, or in 4700 input and output messages.

System Action: Normal processing.

User Response: None - information only. If the address given in this message does not stay the same during a single MVS IPL, this would indicate a problem in COPE ESCA management. In this case, call BMC support.

COP732

Cannot Unlock - IMS is already running in your TSO region

Explanation: You entered "TSO UNLOCK" on the command line, which will unlock your IMS terminal, but there is a DFSRRC00 task (IMS) active in your TSO region. COPE cannot perform the UNLOCK, because it cannot start another IMS task to issue the /RST command. Possibly, you have IMS active in your split screen, or your Xpediter test is still in progress.

System Action: Issues this message and returns to the screen you were on.

User Response: If IMS is active in your split screen, try to <PF3> out of the split screen. If you have an Xpediter IMS test active, type GO, or QUIT, to try to get the test to terminate. Then you can reissue "TSO UNLOCK". If the test won't terminate, you need to go to an IMS terminal that is not locked, and issue /DIS A, and /STO REG n, to get the test to terminate.

COP733

Cannot do COPE processing - IMS is already running in your TSO region

Explanation: You are trying to run an Xpediter test, but there is a DFSRRC00 (IMS) task active in your TSO region.

System Action: Issues this message and bypasses COPE processing. Xpediter will probably terminate the test with a "PSB is invalid" condition (because COPE did not translate the PSB name to a C-number).

User Response: If IMS is running in your split screen, try to terminate it there by exiting the split screen (<PF3>). If you cannot terminate the IMS task this way, go to an IMS terminal, issue /DIS A, and /STO REG n. Then retry the Xpediter test.

This condition is probably a system error, so call BMC Support.

COP733

Cannot do COPE processing - IMS is already running in your TSO region

Explanation: You are trying to run an Xpediter test, but there is a DFSRRC00 (IMS) task active in your TSO region.

This condition is probably a system error, so call BMC Support.

COP734

xxxxxxxx is yyyyREUS zzzzRENT

Explanation: Module BTSRC000 should be NOREUS and NORENT. Another value might mean that COPE will have a problem setting its BTSIN intercept.

System Action: Issues the message and continues setting the BTSIN intercept, in module BTSRC000.

User Response: None, information only. If BTSIN is not translated to C-numbers later, then this message could provide a clue to the problem.

COP735

BTS intercept set

Explanation: COPE has successfully set intercepts in BTSRC000, that will enable it to translate BTSIN, and any /FOR commands the user enters.

System Action: COPE will translate BTSIN ./ TC= cards to C-numbers, and /FOR commands.

User Response: None, information only. If this message fails to appear, then COPE will not translate BTSIN to C-numbers later, and you will get U0428 or other abends.

COP736

BTS intercept not set, code=xx

Explanation: COPE has failed to set intercepts in BTSRC000. BTS will not work (U0428 abends, etc).

Code Values

Code	Meaning
1	XTASKLIB DD open failure
2	BTSRC000 load failure from XTASKLIB DD
3	BTSRC000 CDE not found
4	BTSRC000 XL (extent list) not found
5	Csect not found: BTSCOM00, BTSRDR00 or BTSTSORD
6	V(BTSTSORD) or GET not found in BTSRDR00

System Action: COPE will not translate BTSIN ./ TC= cards to C-numbers, nor /FOR commands, giving U0428 or other abends later.

User Response: Check for the presence of correct BTSLIB DSN in SE, sub-option B. The dataset name is something like IMSVS.BTSLIB. IMSVS.BTSLOAD is not needed. Check with your IMS systems programmer on which BTSLIB to use, which can depend on the RESLIB you are using. Codes 3 through 6 usually mean that you should call BMC, after screen-printing all of your SE options -- there is a problem with the COPE BTS intercept in these cases.

COP737

*** The COPE Intercepts are being set *** yyyy.zzzz

Explanation: COPE is allocating a C-number PSB and Tran for your Xpediter test, and is setting an intercept indicator in your USTDLMGR User Segment, so that IMS transactions from your IMS terminal will be diverted to the Xpediter test transaction. yyyy represents the Psys, zzzz represents the Lsys; together these represent the system.

Warning

Transactions that you enter on IMS before the intercepts are set are NOT diverted to your TSO region. You must wait till the intercepts are set.

System Action: Allocates C-number PSB (and Tran) from the COPE pool of Xpediter PSB's, copies the PSB to this name in the DOPT Acblib, and updates the User Segment XPOID field with the intercept number for diverting IMS transactions to the allocated C-number Tran.

User Response: You should make sure your IMS terminal is logged onto the Lsys named here. If the Lsys is wrong, <PF3> out of Xpediter, enter the correct Lsys on the COPE option 7 screen, then re-enter Xpediter.
You must wait till the message "The Xpediter Intercepts are being set", which follows this message, BEFORE entering a transaction on the IMS terminal, otherwise the transaction will not be diverted to your TSO region.

COP738

PSB "xxxx" is not in IMS system yyyy.zzzz

Explanation: Either IMS is down, or you entered a PSB name that is not in the IMS Stage1. Do a / DIS PROG command under COPE , under IMS, to check the PSB name. yyyy represents the Psys, zzzz represents the Lsys; together these represent the system.

System Action: COPE passes a PSB name to Xpediter with a "!" on the front, to force Xpediter to discontinue the test. You will see this "!" in Xpediter messages on the Xpediter Log.

User Response: Check the PSB name using /DIS PROG from IMS, or from option 7.1, and then retry the test using the correct PSB name. /DIS PROG ABC* (for example) is a useful way of displaying all PSB's beginning with "ABC".

If IMS is down, bring it up.

Check the IMSID in SE (Setup) PARMS. If it is wrong, correct it (you were trying to connect to the wrong Psys).

COP739

PSB "xxxxxxxx" is not in IMS system yyyy.zzzz

System Action: COPE passes a PSB name to Xpediter with a "?" on the front, to force Xpediter to discontinue the test. You will see this "?" in Xpediter messages on the Xpediter Log.

User Response: Check the PSB name by using the /DIS PROG command from IMS, or from option 7.1, and then re-try the test using the correct PSB name. /DIS PROG ABC* (for example) is a useful way of displaying all PSB's beginning with "ABC".

If IMS is down, bring it up.

Check the IMSID in SE (Setup) PARMS. If it is wrong correct it (you were trying to connect to the wrong Psys).

COP740

Tran "xxxxxxxx" is not in IMS system yyyy.zzzz

Explanation: Either IMS is down, or you entered a TRANCODE that is not in the IMS Stage1, or you entered a TRANCODE that is not associated with the PSB name that you entered. Do a /DIS PROG in COPE in IMS to see PSB names and their TRANCODES. yyyy represents the Psys, zzzz represents the Lsys; together these represent the system.

System Action: COPE passes a Tran name to Xpediter with a "?" on the front, to force Xpediter to discontinue the test. You will see this "?" in Xpediter messages on the Xpediter Log.

User Response: Check the PSB name using /DIS PROG from IMS, or from option 7.1, and then retry the test using the correct PSB/TRANCODE combination. /DIS PROG ABC* (for example) is a useful way of displaying all PSB's beginning with "ABC".

If IMS is down, bring it up.

COP741

*** Try "/STA TRAN xxxx" under IMS ***

Explanation: The Tran is stopped to IMS, due to either an abend, or a user issuing a /STO command. A typical abend that will cause this is S106 due to compress of a load library. /STA TRAN ALL and /STA PROG ALL would correct multiple such problems.

System Action: COPE bypasses allocating the C-number for the Xpediter test, and does not set any intercept to divert transactions to the TSO Xpediter region. Xpediter will probably terminate the test with an "Invalid PSB" condition.

User Response: Issue a /STA TRAN command to correct the problem. /STA TRAN ALL and /STA PROG ALL might be advisable if many programs/trans have been stopped by a compress of a library or similar problem. Then retry the Xpediter test.

COP742

*** Waiting for Tran xxxx to become available ***

Explanation: The Tran is either stopped to IMS or is in use by another user who is currently also in the process of setting Xpediter intercepts. This process is single-streamed. This is normally not noticeable, because the process is complete after a second or two, and the COPEXPT1 TRANCODE is then available to the other user.

System Action: COPE waits for 5 seconds, then retries the setting of the intercepts. It will repeat this sequence up to 5 times, then terminates the test if the COPEXPT1 TRANCODE is still unavailable.

User Response: None required. If this message repeats 5 times, then the COPEXPT1 tran is probably stopped, so issue /STA TRAN COPEXPT1, and /STA PROG COPEXPP1. /STA TRAN ALL and /STA PROG ALL might be advisable if many programs/trans have been stopped by a compress of a library or similar problem. Then retry the Xpediter test.

COP743 /

STA PROG xxxx under IMS

Explanation: The Prog is stopped to IMS, due to either an abend, or a user issuing a /STO command. A typical abend that will cause this is S106 due to compress of a load library. /STA TRAN ALL and /STA PROG ALL would correct multiple such problems.

User Response: Issue a /STA PROG command to correct the problem. /STA TRAN ALL and /STA PROG ALL might be advisable if many programs/trans have been stopped by a compress of a library or similar problem. Then retry the Xpediter test.

COP744

IMS System xxxx is down

Explanation: The IMS system with the IMSID named is down. Either you need to bring it up, or your SE (Setup) PARMS option specified the wrong IMSID.

System Action: COPE bypasses all C-number allocation and intercept setting. Xpediter will exit with a U0688 (IMS down) abend showing on the Xpediter log.

User Response: If the IMSID in the message is correct, then you cannot run this Xpediter test until you bring up the IMS Control Region with that IMSID on this MVS system. If the IMSID in the message is not the Psys (physical system) that you want, go into SE (Setup) PARMS and put the correct IMSID there.

COP745

IMS Region Id xxxx not COPE , in SE

Explanation: The IMSID is wrong in SE (Setup) PARMS, or the COPEXPT1 Tran and/or COPEXPP1 PSB is missing from the Stage 1. The latter would indicate a COPE install error.

System Action: COPE bypasses C-number allocation and intercept set, and Xpediter exits with an "invalid PSB" condition.

User Response: Check/correct SE (Setup) PARMS has the correct IMSID for the Psys you are trying to access. Go to IMS and do /DIS TRAN COPEXPT1 and /DIS PROG COPEXPP1. If they are missing or NOTINIT, etc, check the COPE install (particularly the 5.5 table, where these are defined).

COP746

IMS Region Id not set, PF3 out, and come back in

Explanation: The IMSID is wrong in SE (Setup) PARMS, or on the COPE option 7 screen. The value on the option 7 screen comes from ZDEFAULT XIMSID parameter.

System Action: COPE bypasses C-number allocation and intercept set, and Xpediter exits with an "in- valid PSB" condition.

User Response: Check/correct SE (Setup) PARMS has the correct IMSID for the Psys you are trying to access. Check the IMSID on the COPE option 7 screen, and if necessary, correct it by using the EVARS command from the primary menu (XIMSID parameter).

COP751

Intercept #xx Not found

Explanation: You entered "XP n" to display intercept number n, but there is no such intercept. Use "XP ALL" to display all intercepts.

System Action: Issues this message and returns.

User Response: Use XP ALL instead.

COP752

xx Intercept(s) displayed

Explanation: You entered "XP ALL" to display all intercepts, and this is the number of them found. Note that the presence of an intercept in this list does not necessarily mean it is active. COPE remembers inactive intercepts, so that it can save on processing when re-activating an intercept.

System Action: Issues this message and returns.

User Response: None -- information only. To find out whether an intercept is active or not, go to the user's IMS terminal, and say " COPE ". An ==XP=> line appears if the user has any active intercepts.

COP753

Intercept #xx not found

Explanation: You entered "XP QUIT n" or "XP QQUIT n", but there is no intercept n. Use XP ALL to display all intercepts.

System Action: Issues this message and returns.

User Response: Use XP ALL to display all intercepts.

COP754

Specify "XP QUIT TSOID <TSOID>"

Explanation: You entered "XP QQUIT" or XP QUIT" but COPE does not know what TSO user id you are trying to quit. Use XP ALL, then XP QQUIT n.

System Action: Issues this message and returns.

User Response: Use XP ALL to display all intercepts, note the intercept number you are interested in, then issue XP QQUIT n or XP QUIT n. QQUIT (Quick-Quit) is usually preferable to QUIT. The difference is that QQUIT inactivates, which allows for faster re-activation later, whereas QUIT inactivates and deletes the intercept. Deleting the intercept means that re-activation will be slightly slower (it has to allocate a new C-number).

COP755

No intercept for TSOID xxxx found

Explanation: You entered "XP QQUIT TSOID tsoid" but there is no intercept for this TSOID. Use XP ALL, then XP QQUIT n.

System Action: Issues this message and returns.

COP756

Intercept #xx has TSOID yyyyyyyy

Explanation: You entered "XP QQUIT TSOID tsoid" but the intercept has a different TSOID. Use XP ALL, then XP QUIT n.

System Action: Issues this message and returns.

User Response: Use XP ALL to display all intercepts, note the intercept number you are interested in, then issue XP QUIT n.

COP757

No Logon segment for IMS user xxxxxxxx found

Explanation: You entered "XP QQUIT n", or similar, but the IMS user is not logged onto an Lsys. Use XP ALL, then XP QUIT n.

This means that you put the wrong Lterm or Sign-on id against the "User(s)" field in ISPF option 7, or that you never logged onto a logical system from the Lterm or Signon, under IMS.

Check and correct the ISPF option 7 "User(s)" field, and logon to the Lsys you want to work in under IMS.

System Action: Issues this message and returns.

User Response: Use the XP ALL command to display all intercepts, note the intercept number you are interested in, then issue command XP QUIT n.

Check and correct the ISPF option 7 "User(s)" field, and logon to the Lsys you want to work in under IMS.

COP758

IMS user xxxxxxxx has no intercept, not quitted

Explanation: You entered "XP QQUIT n", or similar, but the IMS user has already been QQUITed. This message is information only.

System Action: Issues this message and returns.

User Response: None -- information only.

COP760

IMS User xxxxxxxx quitted

Explanation: You entered "XP QQUIT n", or similar, or issued QUIT from Xpediter under TSO, and COPE has inactivated the intercept for the IMS user named (Lterm or Signon id).

This message means the command was successful. Transactions entered from the IMS terminal after this message will not be diverted to the TSO region.

System Action: Issues this message and returns. COPE will not divert future transactions from this terminal to a TSO Xpediter session, until the intercepts are set again.

User Response: None. For information, only.

Note

The transactions you enter from the IMS terminal after getting this message will not be diverted to TSO.

COP761

No TSOid segment for Intercept #xx found

Explanation: You entered "XP QQUIT n", or similar, or issued QUIT from Xpediter under TSO, and COPE has inactivated the intercept for the IMS user named (Lterm or Signon id).

This message means the command was successful. Transactions entered from the IMS terminal after this message will not be diverted to the TSO region.

System Action: Issues this message and returns. COPE will not divert future transactions from this terminal to a TSO Xpediter session, until the intercepts are set again.

User Response: None. For information, only.

Note

The transactions you enter from the IMS terminal after getting this message will not be diverted to TSO.

COP762

TSOid xxxxxxxx Intercept #yy deleted

Explanation: You entered "XP QUIT n", or similar, and COPE has deleted the intercept for the TSOID named.
This message means the command was successful.

System Action: Issues this message and returns.

User Response: None. For information only.

Note

The transactions you enter from the IMS terminal after getting this message will not be diverted to TSO.

Deleting an intercept means that re-activation of the same intercept will take slightly longer ( COPE has to allocate a new C-number).

COP763

Intercepts taken by TSOid xxxxxxxx, specify QUIT or RESUME

Explanation: You entered a transaction from the IMS terminal, expecting it to be diverted to a TSO session, but there is a shortage of "Xtran" C-numbers, and another user has taken the C-number you were using.
The pool of Xtran C-numbers is specified by the XEMPUSER ZDEFAULT variable. Ask your COPE Administrator to increase this number, if conflict continues between TSO users.

System Action: Issues this message and returns. The transaction you entered is discarded.

User Response: Contact the person named by the TSOid in the message, and try to schedule usage of Xpediter so that there is no longer a conflict.

XP RESUME to retake the C-numbers you were using before, but note that this could cause the oth- er TSO user to get a similar "taken by" message.

XP QUIT to quit your usage of Xpediter. If your TSO session is hung waiting for a transaction, do a /DIS A, and /STO REGn against the region with your TSO userid, to unhang it.
Note that when COPE takes C-numbers from a TSO user, it always chooses the TSO user that set their intercepts least recently, for the same TRANCODE attributes.
If conflict continues, ask your COPE Administrator to increase ZDEFAULT variable XEMPUSER, and perform option 4.1 Stage 1 Gen, submit IMSGJCL and XREFJCL, and /MOD PREPARE MODBLKS and / MOD COMMIT.

COP764

Intercepts resumed from TSOid xxxxxxxx

Explanation: You entered a transaction from the IMS terminal, expecting it to be diverted to a TSO session, but there was a shortage of "Xtran" C-numbers, and another user had taken the C-number you were using, and you responded with an XP RESUME command, to re-take the C-numbers.

The other TSO user will get a "taken by" message, if they continue to try to use Xpediter.
The pool of Xtran C-numbers is specified by the XEMPUSER ZDEFAULT variable. Ask your COPE Administrator to increase this number, if conflict continues between TSO users.

System Action: Issues this message and returns. Your intercepts are now re-instated.

User Response: Contact the person named by the TSOid in the message, and tell them that you have taken back the C-numbers that COPE assigned to them.

Do a /FOR command or a transaction to get back to where you were, and re-enter the transaction, and it will be diverted to your TSO session, so that you can continue the test.
If conflict continues, ask your COPE Administrator to increase ZDEFAULT variable XEMPUSER, and do a 4.1 Stage 1 Gen, submit IMSGJCL and XREFJCL, and /MOD PREPARE MODBLKS and /MOD COMMIT.

COP765

System has unrecognizable XRF2

Explanation: There is a problem in the COPEXRF2 cross-reference module. This module is generated by option 4.1 Stage 1 Gen, job XREFJCL.

This message should not occur.

System Action: Issues this message and stops attempting to set any intercepts. IMS transactions will not be diverted to TSO.

User Response: Check that you ran option 4.1 Stage 1 Gen and XREFJCL, and that the XCOPEPGM library output in XREFJCL is on the //COPESTEP in the message region.

Call BMCSupport if problem is not resolvable.

COP766

System has not been generated for Xpediter support

Explanation: There are no Xtrans in the COPEXRF2 cross-reference module, so no Xpediter intercepts can be set. ZDEFAULT variables XCOPEEXP=YES and XEMPUSER=n tell COPE to produce a pool of Xpediter C-number TRANCODES for use in setting intercepts. COPEXRF2 is generated by option 4.1 Stage 1 Gen, job XREFJCL.
Note that your installation may not have Xpediter support installed (it is a separate option in COPE ).

System Action: Issues this message and stops attempting to set any intercepts. IMS transactions will not be diverted to TSO.

User Response: Check that you set XCOPEEXP=YES and XEMPUSER=n, where n is the maximum number of simultaneous Xpediter users in ZDEFAULT, using EVARS from the COPE ISPF primary menu. XEMPUSER=10 would be a typical setting. Check that you ran 4.1 Stage 1 Gen and XREFJCL, and that the XCOPEPGM library output in XREFJCL is on the //COPESTEP in the message region.

COP767

Stubx xxxxxxxx not found in Tasklib/STEPLIB, PSB=yyyyyyyy Tran=zzzzzzzz

Explanation: The Stubx (dummy COPE stub program) is not in the XCOPEPGM library, for one of the PSB's you are trying to test under Xpediter. The Stubx is generated when you do an option 2.2 PSBGEN on the PSB source, and is copied into XCOPEPGM when you do an option 4.8 ACBGEN.

System Action: Issues this message and continues attempting to set intercepts for any other PSB's that you have named.

User Response: Check that the PSB source was imported (2.PSB), PSBGENed (2.2) and ACBGENed (4.8), and redo if not.

COP768

Stubx xxxxxxxx does not contain Lsys "yyyy" PSB=zzzzzzzz Tran=aaaaaaaa

Explanation: The Stubx (dummy COPE stub program) does not have an entry for the Lsys you are trying test in under Xpediter. The Stubx is generated when you do a 2.2 PSBGEN on the PSB source, and is copied into XCOPEPGM when you do an option 4.8 ACBGEN.

Possibly you entered the wrong Lsys on the ISPF option 7 screen.

System Action: Issues this message and continues attempting to set intercepts for any other PSBs that you have named.

User Response: Check that the PSB source was imported (option 2.PSB), PSBGENed (option 2.2) and ACBGENed (4.8), and redo if not.

Check you entered the right Lsys on the option 7 screen (<PF3> out of Xpediter to get to this screen).

COP769

Stubx xxxxxxxx unrecognized, bad internal format, PSB=yyyyyyyy Tran=zzzzzzzz

Explanation: The Stubx (dummy COPE stub program) is in the XCOPEPGM library, but has a bad internal format. The Stubx is generated when you do a 2.2 PSBGEN on the PSB source, and is copied into XCOPEPGM when you do a 4.8 ACBGEN.
Possibly someone has used ISPF option 3.3 copy to copy a module that is not a Stubx into the XCOPEPGM library.

System Action: Issues this message and continues attempting to set intercepts for any other PSBs that you have named.

User Response: Check that the PSB source was imported (option 2.PSB), PSBGENed (option 2.2) and ACBGENed (4.8), and redo if not. This is the only way to generate a valid Stubx module. Stubx's cannot be copied between Psys's, and programs cannot be copied in to replace Stubx's.

COP770

Stubx xxxxxxxx unrecognized, no internal table, PSB=yyyyyyyy Tran=zzzzzzzz

Explanation: The Stubx (dummy COPE stub program) is in the XCOPEPGM library, but has a bad internal format. The Stubx is generated when you do an option 2.2 PSBGEN on the PSB source, and is copied into XCOPEPGM when you do an option 4.8 ACBGEN.

Possibly someone has used ISPF option 3.3 to copy a module that is not a Stubx into the XCOPEPGM library.

System Action: Issues this message and continues attempting to set intercepts for any other PSB's that you have named.

User Response: Check that the PSB source was imported (2.PSB), PSBGENed (2.2) and ACBGENed (4.8), and redo if not. This is the only way to generate a valid Stubx module. Stubx's cannot be copied between Psys's, and programs cannot be copied in to replace Stubx's.

COP771

Stubx xxxxxxxx load fail, PSB=yyyyyyyy Tran=zzzzzzzz

Explanation: The Stubx (dummy COPE stub program) could not be loaded from the XCOPEPGM library. The Stubx is generated when you do an option 2.2 PSBGEN on the PSB source, and is copied into XCOPEPGM when you do an option 4.8 ACBGEN.

A S106-E message accompanying this would indicate that XCOPEPGM has gone into a new extent or been compressed, and you need to exit Xpediter and re-enter.

Possibly someone has used ISPF option 3.3 to copy a module that is not a Stubx into the XCOPEP- GM library.

System Action: Issues this message and continues attempting to set intercepts for any other PSBs that you have named.

User Response: <PF3> out of Xpediter, and re-enter option 7.3, and try again.

If this does not cure the problem, check that the PSB source was imported (2.PSB), PSBGENed (2.2) and ACBGENed (4.8), and redo if not, checking carefully the output of all jobs.

COP772

IMS User=xxxx, TSOid=yyyy, Intercept #zz

Explanation: You entered an XP command to set an intercept. Normally this is done internally by COPEXPP1, and you will not see this message. This message shows the IMS Lterm or Signon id, and the TSO userid for this intercept. A list of TRANCODES and Xtrans follows this message.

System Action: Lists the TRANCODES that the intercept applies to, following this message.

User Response: None -- information only.

COP773

IMS User=xxxx, TSOid=yyyy, Class=zz, Intercept #aa

Explanation: You entered an XP command to set an intercept. Normally this is done internally by COPEXPP1, and you will not see this message. This message shows the IMS Lterm or Signon ID,the TSO userid, and the Class selected by COPE for this intercept. A list of TRANCODES and Xtrans follows this message.

System Action: Lists the TRANCODES that the intercept applies to, following this message.

User Response: None -- information only.

COP774

Intercept #xx yyyyyyyy zzzzzzzz aaaa bbbbbbbb cccc

Explanation: You entered an XP ALL, or XP n command to display an intercept. This message shows the intercept number, the value "XP" if the intercept is not "taken" by another userid or the taking userid if it was, the userid the intercept belongs to, and the date and time the intercept was last set. A list of Transactions that the intercepts apply to follows this message, with Xtran (transaction COPE will switch to, to divert to TSO), and C-PSB (C-number PSB name).

System Action: Lists the TRANCODES that the intercept applies to, following this message.

User Response: None -- information only. To quit the intercept, issue XP QQUIT n, or XP QUIT n, where n is the intercept. QQUIT deactivates without deleting, and QUIT deactivates and deletes.

COP775

xxxx

Explanation: You entered an XP ALL, or XP n command to display an intercept. This message shows the users (IMS Lterms or Signon ids) that the intercept applies to. This is whatever you entered on the COPE ISPF option 7 screen in the “User(s)” field.

Note that normally you intercept only one User (i.e. IMS terminal) for an Xpediter test. However, it is possible to intercept up to 7 terminals, by putting their names on the option 7 User(s) line, separated by blanks.

System Action: Lists the TRANCODES that the intercept applies to, following this message.

User Response: None -- information only.

COP776

xxxx

Explanation: You entered an XP ALL command, or XP n command to display an intercept. This message shows the users (IMS Lterms or Signon ids) that the intercept applies to. This is whatever you entered on the COPE ISPF option 7 screen in the "User(s)" field.

System Action: Lists the TRANCODES that the intercept applies to, following this message.

User Response: None -- information only.

COP801

DFSICLP0 Vcon not found

Explanation: The COPE AOI Exit, COPEAOUE, searched for the V-type address constant in the IMS Communications Analyzer, DFSICIO0, that points to the command processor, DFSICLP0, and didn't find it. COPE normally intercepts the /FOR command by replacing this V-constant.

System Action: /FOR commands from cleared screens will not be translated. 4700 trace /FOR commands won't work. All other processing proceeds normally.

COP802

DFSICLP0 /FOR COPE intercept active

Explanation: The COPE AOI Exit, COPEAOUE, replaced for the V-type address constant in the IMS Communications Analyzer, DFSICIO0, that points to the command processor, DFSICLP0, so that / FOR commands from cleared screens will be translated, and 4700 /FOR NODE, etc, commands will work.

System Action: Normal processing.

User Response: None - information only. The absence of this message would indicate a problem, such as COPEAOUE not linked into the nucleus, etc.

COP803

Multiple DDM routines for device type=xxxxxxxx...!

Explanation: The COPE AOI Exit, COPEAOUE, found entries in the CTT that point to different DDM routines for the same device types. COPE normally replaces the pointer to the DDM, to implement an intercept at the VTAM receive/send level, for 4700 MFS rename support. Device types are: 13 - 3270 VTAM, 19 - SLU2, and 1A - SLUP. Only the SLUP intercept is used for 4700.

System Action: Normal processing, except that if the type named is x'1A', SLUP (4700) MFS re- name will not occur.

User Response: Call BMC support. This indicates an IMS release problem. If device type is 1A, 4700's won't have their MFS renamed on input and output, which renders them unusable.

COP804

CTT/DDM COPE intercept active xx device type(s)

Explanation: The COPE AOI Exit, COPEAOUE, replaced DDM pointers in entries in the CTT. This enables 4700 support, for renaming of MFS mid and mod names on input and output. The number of device types reported in this message is not significant (unless it is zero).

System Action: Normal processing.

User Response: None - information only. The absence of this message, or zero device types re- ported in the message, indicates a problem.

COP805

Creating new COPE Ecsa anchor

Explanation: The COPE AOI Exit, COPEAOUE, getmained a new 4K block in Extended CSA (above the line). It did this, because a scan of ESCA failed to find an existing anchor block. This is normal the first time after an MVS IPL. COPE has one anchor block in ESCA for one machine. It anchors its ESCA logon tables off of this block, for /FOR translation support, and 4700 support.

System Action: Normal processing.

User Response: None - information only, as long as an MVS IPL preceded this message. If this message occurs more than once, without an intervening IPL, then there is a problem in COPE ESCA usage. In this case, call BMC support.

COP806

COPE Ecsa anchor is at xxxxxxxx

Explanation: The COPE AOI Exit, COPEAOUE, found the COPE anchor block in ESCA (above the line), at the address given. COPE maintains a table in this 4k block, one entry per IMSID that runs on this machine. A pointer in the table entry points to the logon table (also in ESCA) for users of this logical system. When a user logs on or off a logical system the ESCA logon table is updated by the message region. The control region looks up the table for /FOR commands and for 4700 input and output messages, so that it knows which logical system to use for the MFS translation.

System Action: Normal processing.

User Response: None - information only. The address should be the same for all physical IMS's that run on this machine, without an intervening MVS IPL. If the address is not the same, there is a problem in COPE ESCA usage. In this case, call BMC support.

COP807

DFSICLP0 intercept via xxxxxxxx pointer

Explanation: The COPE AOI Exit, COPEAOUE, searched for the V-type address constant in the IMS Communications Analyzer, DFSICIO0, that points to the command processor, DFSICLP0, and didn't find it, but instead found a pointer to an OPSMVS module. COPE will save and replace this address, in order to translate /FOR modnames.

System Action: /FOR commands from cleared screens will be translated normally.

User Response: None - information only. This message confirms that COPE support for OPSMVS is working.

COP821

=ERR=> Table module xxxxxxxx not found in yyyy

Explanation: The COPE AOI Exit (COPEAOUE), or the Stubx check (COPESXCH), or some other module, tried to read the module named xxxxxxxx from the dataset named yyyy.

If this is the Control Region, a //COPEPGM DD is required to point to the XCOPEPGM (Stubx) library. The COPEXRF1 module is placed in this library by 4.1 Stage 1 Gen job XREFJCL. COPEMFSX is placed there by your MFS import job (e.g. in option 5.7), or by option 5.10.5. XRF1 is used to translate C-numbers in messages bound for the MTO. MFSX is used to translate MFS names in /FOR commands from cleared screens, and in 4700 input and output messages.

If this is a MSG, BMP, DLI, DBB or IFP region, the Stubx could not be read in, and the problem is probably in XCOPESTG or XCOPEPGM dataset names in XRF5, or XCOPESTG full during PSB-gen.

System Action: In the Control region, translation will not occur for either MTO messages (XRF1) or MFS names (MFSX). In other regions, the Stubx won't match the PSB, causing msgs and/or abends.

User Response: If this is the control region, run option 4.1 Stage 1 Gen, XREFJCL and option 5.10.5, then under IMS type COPE REFRESH. If you don't have a COPEPGM DD in the Control Region JCL, put it in, pointing to the single XCOPEPGM library named in your ZDEFAULT member. If this is some other region, run option 4.11 to regenerate XRF5 (if the dataset name is the problem), then compress XCOPESTG (if full), then run option 2.PSB Psbgen and option 4.8 Acbgen, checking care- fully for error messages, such as dataset full messages.

COP822

=ERR=> Table module xxxxxxxx bad format in yyyy

Explanation: The COPE AOI Exit, COPEAOUE, or the Stubx check, COPESXCH, or some other module, tried to read the module named in from the dataset named, but the module was not in a valid load module format. COPE uses BPAM, not LOAD, to read this module in. Possibly, the dataset named is not a PDS with RECFM=U (it must be), or the dataset is corrupt and needs restore/ re-create.

System Action: In the Control region, translation will not occur for either MTO messages (XRF1) or MFS names (MFSX). In other regions, the Stubx won't match the PSB, causing msgs and/or abends.

User Response: Browse the dataset, and if it is corrupt, or not RECFM=U, or has bad directory or Blksize, rename it to some other name, allocate it, then restore/re-create it. If the problem is not the entire dataset, the bad members can be recreated -- COPEXRFs via option 4.1 Stage 1 Gen and XREFJCL, COPEMFSX via option 5.10.5, or Stubx's via option 2.PSB Psbgen. Then under IMS type COPE REFRESH. If you don't have a COPEPGM DD in the Control Region JCL, put it in, pointing to the single XCOPEPGM library named in your ZDEFAULT member. Check that this dataset is a library and has RECFM=U.

COP823

Table module xxxxxxxx read in from yyyy

Explanation: The COPE AOI Exit, COPEAOUE, or the Stubx check, COPESXCH, or some other module, successfully read the module named into storage, from the dataset named, using BPAM. COPEXRF1 is used to translate C-numbers in messages bound for the MTO. MFSX is used to translate MFS names in /FOR commands from cleared screens, and in 4700 input and output messages. C-number modules are Stubx's, which are used to map application PCBs to physical PCBs in the PSB.

System Action: If this is the Control Region, translation will occur for MTO messages (XRF1) or MFS names (MFSX). If it is some other region, COPE will create an application pcblist using the information in this Stubx. If these messages occur repeatedly in a short space of time, response time will be affected adversely -- and there is probably some problem with these modules or the libraries they are in.

User Response: Usually none - information only. When you do a COPE REFRESH, which runs in the message region, you should see these messages (for XRF1 and MFSX) in the Control Region JOBLOG. If you don't, call BMC, as this would indicate a problem in the REFRESH mechanism. In other regions, this message should occur once after an Acbgen for a PSB. If they occur repeatedly for Cnnnnnnn modules in a short space of time, then possibly XCOPESTG or XCOPEPGM is full, preventing Stubx generation and copying. Compress these libraries if they are full, and rerun option 2.PSB Psbgen and option 4.8 Acbgen.

COP995

... a system error message ...

Explanation: A COPE System Error has occurred. No COP995 messages should occur. The messages are intended for BMC COPE Support, and may refer to things unfamiliar to the user.

System Action: The transaction is usually discarded. The action depends on the particular error condition.

User Response: Screen-print, or write down, the message, and any accompanying messages. Call your COPE Support person, or COPE Administrator. They will then call BMC for a solution or work-around to the problem.

Have available the Message Region JOBLOG, and the dump (if an abend occurred). Try to determine what transaction caused the problem, and a method to reproduce the problem, if possible. A TRACE ON LOGIC trace may be useful, and a DEBUG ON trace of the problem being reproduced may be required later. Information on the MVS, IMS and COPE version and release numbers should also be available.

Note

COP995 messages are rare, and are always System Errors, and therefore BMC will always provide a fix for them.

Stubx Processor Messages (COPnnn)

BMC COPE 19.02

On this page