IEBCOPY failure to copy load modules during promotion
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
8 answers
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
Comments
Liam,
At the time that the 3 messages appear on the system log, there are no RACF messages appearing at all. Those three messages seem to appear in isolation; there are no other messages of any type that look like they could be related to them.
That said, there must be something with the service id that is triggering the difference; i.e., we do not get those messages when you run the promotion under your userid, they only appear when running under the service id. And, likewise, the IEBCOPY of the load modules (and ONLY the load modules) only fails then running under the service id.
Rest of the response from the sysprog:
So, if the IBM guys on the forum could give us some idea of what difference in the RACF userid might be triggering whatever logic is generating the CEATSO message, that would help to identify what we need to look at specifically with the userid.
I will continue to look at things on my end, but I’m really hoping that they can provide some information to give me a better direction in which to look.
Liam,
I don't see those messages on my z/OS 2.1 system. I am checking with the ISPF team if they know anything.
Comments
Are you saying that a service account should be able to sign on to TSO to perform ISPF gateway types of processing? I'm concerned that this is probably going to be viewed as a security exposure. Hence, I cannot sign in to TSO with the service account like I can with my RACF account.
I was told that our service account does have a TSO segment although the login proc is a bit different from the one a human user uses. One thing we ran into in the past had to do with the allocation of a dataset like SVC_JAZZ.ISPF.VCMISPF.xxxe but found that setting team.enterprise.build.ant.myISPFBinPath to a concatenation allowed us to override the default HLQ that should be used (since SVC_JAZZ is not a human account, it doesn't have an HLQ/alias allotted to it). However, setting that property didn't seem to help in this case for some reason.
Update: looks the the ISPF.VCMISPF error was not relevant. It only happened when we didn't have the myISPFBinPath set but the load module IEBCOPY failure seems to occur with the service account regardless of that allocation issue. Something unique to copying load modules (since other types copy just fine) but we can't seem to pinpoint what it is since the error messages that are being returned are not very helpful (RC=20 and no other info). Help!
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?
Comments
Liam,
This is not a permissions issue. We've confirmed this by simply running the IEBCOPY using the functional ID via JCL and it copied the LOAD modules just fine. Can you please send that trace module you mentioned?
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 )
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,
Liam,
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.
I will also send you a test REXX that will hopefully set this up so we can run it from the userid directly and see if we can reproduce there. I think you answered your own question on the region size, it is defined in the TSO segment in RACF. Although you say the ID is not allowed to log on? Can you log into it (BUILD) for a test?
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.
Is it possible to log in to the BUILD userid and change it's TSO prefix to a HLQ it can write to?
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.
Comments
Hi Alex, That could be the issue, or even an additional issue. I will be interested to see what happens. In reproducing I used my normal ID, with an invalid prefix. So I suspect there are a number of things around the userid used that may cause problems. Whatever occurs I checked our doc and can't see any words relating to this. So once we are square with the cause I will raise a Doc defect to get it fixed.
We've made some progress although not fully there yet. Shortening the userid name seems to have helped some. We're not getting the Invalid TSO user error anymore and even though we specified a TSO profile that uses a valid prefix for the user, it seems to default to a prefix that's now the new user name (instead of BATCH which it was using previously). So now we need to figure out why the profile isn't taking effect.