IEBCOPY failure to copy load modules during promotion

Hi Alex

The CEATSO facility is new to ISPF, and the gateway, as configured for RTC has not yet been tested with it. It is on my todo list. However I see your invocation is using the original Gateway code by the messages above. A return code 20 from the LMCOPY is a severe error, for which unfortunately there are no additional messages. You said you changed IDs and then the promotion ran. So can you reproduce by switching the agent id back to the original? Are there any RACF messages in the system log following the ISPZINT message you spotted?

Liam

Is there something different with the service userid. Does it have a valid TSO segment in RACF? Is there a difference between it and your id with relation to the logon proc specified? Or any other settings in the TSO segment?

I don't see those messages on my z/OS 2.1 system. I am checking with the ISPF team if they know anything.

The fact that this seems to be a permissions issue, I am surprised there is nothing in the system log. Does the functional ID have the authority to copy to the target data set? RTC cannot suppress system messages such as RACF errors or E37 for example. It does at times find it more difficult  to capture them in the build output. Although we are tryiung to address that as there is a recent enhancement to capture *37 messages.

I can send you a module with Trace turned on, and some extra diagnostics, maybe ZERRLM has more info. Can you tell me what version of RTC you are running.

The CEATSO messages are a red herring. Basically some of the ISPF Gateway support for CEATSO exists in z/OS 2.1 but is disabled and CSI_CEATSO is set to FALSE always. You are only seeing that because you are getting an error running the Gateway.

Are you saying that the functional ID works OK for non load modules, and only fails for load modules? Are you sure there are no RACF (or whatever security server you arre using)  profiles that are protecting the load library?

Hi Alex , I had the same problem and I've solved it adding the statement REGION=0M to the step

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.

 Liam,

 Liam,