IEBCOPY failure to copy load modules during promotion
We have a build service account (SVC_JAZZ) that we use to run our mainframe builds. We were trying to setup a "primer" component promotion definition that would seed the QA stream from the Production stream. When the component promotion was running it was able to copy source files from the prod to the QA PDSs but when it tried to copy the load modules, it failed with a return code 20 as follows:
* [exec] Copy failed for member 'JKEMLIST' Return Code : 20
* [exec] ISRZ002 : IEBCOPY interface failed
* [exec] Copy failed for member 'JKEMLIST' Return Code : 20
* [exec]
* [exec] ISPD117
* [exec] The initially invoked CLIST ended with a return code = 20
Digging through the system logs we see the following messages around the same time that the above promotion failed:
BPXM023I (SVC_JAZZ) Gateway Frontend started - z/OS V2R1 01JAN12 Base BPXM023I (SVC_JAZZ) CGI_CEATSO is FALSE BPXM023I (SVC_JAZZ) ISPZINT invoking original gateway interface module ISPZINO
Suspecting a permissions issue, I switched to use my RACF ID for the build agent and the promotion ran successfully. I don't recall seeing anything in the setup instructions about needing to configure RACF for CEATSO for the build service account. Anyone have any suggestions on what we need to do? We can open a PMR or work item on jazz.net if need be.
|
8 answers
Hi Alex , you are right , in my environment I had exactly the same error but using a JCL that invoke the BUZTOOL clist In my environment I solved my problem simply adding the region=0M statement at step level.
But , in your environment (a promotion build in RTC EE ) it's important to understand HOW we can change the region (and/or increase the memory ) during the buztool.sh invocation. I'm searching for a solution but I need to prepare my environment : I'm thinking to investigate in this area : Build definitions --> z/OS dependency build --> Ant with Enterprise extension configuration ( maybe ANT arguments, but I'need to verify ) |
Hi Alex,
The promotion module didn't get the TRACE upgrade like the Packaging/Deployment stuff because it is a lot simpler and had not changed until recently due to some upgrades for Sequential file support. They are correct and there is a REXX involved, BLZPRMCP, and it is compiled. But it does not have the logic to turn tracing on currently. I will create a Task to put the trace stuff in. I have sent a test load module with trace activated to your email. I can reproduce a RC=20 for stuff like space issues. I get to see the D37, where as you only get IEBCOPY interface failed which is the short message from ISPF. (The ZERRLM is in this version only, the rest is as shipped) : Promote Manifest file : /u/dohertl/Test/Promotion502/promotionInfo.xml Copying the following members from 'DOHERTL.BUILD502.DBRM' to 'DOHERTL.PROD502.DBRM' Copy EPSCMORT Copying the following members from 'DOHERTL.BUILD502.BMSCPYBK' to 'DOHERTL.PROD502.BMSCPYBK' Copy EPSMLIS Copy EPSMORT Copying the following members from 'DOHERTL.BUILD502.OBJ' to 'DOHERTL.PROD502.OBJ' Copy EPSMLIST Copy EPSNBRVL Copying the following members from 'DOHERTL.BUILD502.LOAD' to 'DOHERTL.PROD502.LOAD' Copy EPSMLIST ZERRLM : A system abend occurred. Press Help key for further information. Copy failed for member 'EPSMLIST' Return Code : 20 ISRZ002 : System abend '0D37' Copy failed for member 'EPSMLIST' Return Code : 20 So you can see the D37 for example. But maybe there are some other issues that don't put a message out. Like incompatible load library types? PDSE to PDS for example? As it only happens with load modules can you send me the attributes of both your source and target data sets? Screen captures from 3.4 would be good. Are they both PDS or PDSE or are they different? Additionally can you see if there are any data sets on your system that have a low level qualifier of IEBCOPY, for example DOHERTL.SPF123.IEBCOPY. ISPF will sometimes create these to hole the IEBCOPY messages if an ISPF COPY fails. One orther thing that may (or may not) be relevant. We noticed an interesting issue with z/OS 2.1 on an IEBCOPY (which LMCOPY uses under the covers). It was actually in an SMP/E ACCEPT from a PDSE to a PDS. If the region size was too small it abended. The underlying issue was the REGION size being used was insufficient. In the IEBCOPY case they it was picking up a really small default region size. In the ACCEPT, the REGION size was being capped by the IEFUSI. So do you have the IEFUSI exit active on your system? I don't think the Trace is going to give us any extra information, but lets check anyway. I am more interested in the attributes of your source and target load libraries. Comments Liam,
Here are the screenshots you requested (they are both PDS/Es):
Again, I don't understand how space or type of data set would matter if I can simply switch the build user from the functional ID to my own and then the promotion works (using the same data sets).
Liam,
I sent you the build log offline with the tracing turned on. From it, we see that during the failure, there was an attempt to allocate a listing dataset for IEBCOPY. The naming convention it was using for this dataset was invalid on our system so it failed to allocate. Do you know how the dataset name is computed? Is it based on the HLQ for the user ID under whose credentials the build is running? I don't see any IEBCOPY data sets under my user's HLQ so I'm wondering if it only attempts to allocate it if there was a failure (or if it deletes it at the completion of the copy). Can you shed some light on what the lifecycle of these datasets is? Is this documented somewhere?
Also, can you clarify how the region size comes into play here? As I indicated, the functional ID does not logon to TSO, it's only used via USS/omvs. In which case, when is the region size used? At any rate, we checked and even though the functional ID isn't allowed to logon it has the default region size of 4M defined (which is the same size used by the other human user IDs we were able to substitute for the functional ID and complete the promotion successfully). Hey Alex, yeah I realized after I posted that the data set type should not be the issue as it works with your normal ID. The listing failure is because ISPF is trying to allocate that file based on the userid running the build. I am guessing that userid, called BUILD(?) does not have an Alias so cannot allocate any data sets? Can you do a TSO PROFILE and see what the PREFIX is set to for the ID. Any chance you can set the prefix to a HLQ that userid can write to? What happens is the IEBCOPY is failing and ISPF is trying to write the IEBCOPY messages out to a data set. These IEBCOPY messages will hopefully tell us what is wrong. The data set only gets allocated by ISPF (not RTC) in case of a failure and will hang around until you delete them. We need to see the contents of the IEBCOPY failure data set.
In fact in doing a test where I set my prefix to something I cannot write to, I can get the same error. Even though if I know the LMCOPY would work OK, the fact it cannot allocate the listing causes the problem. So I suspect that is the issue here. Because BUILD cannot allocate a data set the IEBCOPY fails. The peculiar thing is why the LMCOPYs work OK for non-LOAD types but fail for LOADs.
So I wonder if IEBCOPY, under the covers, is allocating some kind of work data set for the copy of LOAD modules? Although running IEBCOPY in batch I can't see any allocations. If I run a copy of a DBRM with an invalid prefix, the copy works just fine, so this points to the fact that something different is happening under the covers for LOAD modules.
showing 5 of 6
show 1 more comments
|
|
Liam,
Good news! We finally got it working. So it was a combination of the shortened ID and a modification in RACF to set the prefix for that user. I don't have the exact details but hopefully you know how to do that so you can properly document it as part of the required set up steps. Also, please provide the ZERRLM tracing as an option in the product. We wouldn't have been able to diagnose this problem without it.
|