z/OS v11 Can't get bindagent to work

Tim Wilkins

z/OS v11 Can't get bindagent to work

We have two systems, east and west.  An application area wants to create a program on west and access tables on the east system too.  The communications table is set up and it works.   

The problem come in with doing a copy bind from west to east.  I know this sound screwy but here is what we are running into.  If a programmer does a compile bind on the west side and the job runs under their ID the copy bind works on the UNIT system.   If they use a change management system where the jobs run under one of two ID's depending on what they are doing the copy bind fails to work.  

 

Here is what we have done on the EAST side.

UNIT system

Security has granted SYSADM to ID DB2DBAU because the security ID has security admin rights from the zParm.

INTG system

Security has granted SYSADM to ID DB2DBAI because the security ID has security admin rights from the zParm.

I verified they do have SYSADM granted by the security ID.

 

I ran these grants for unit and intg

SET CURRENT SQLID='DB2DBAU';

GRANT BINDAGENT TO GROUPA;

GRANT BINDAGENT TO USERA;

GRANT BINDAGENT TO USERB;

 

SET CURRENT SQLID='DB2DBAI';

GRANT BINDAGENT TO GROUPA;

GRANT BINDAGENT TO USERA;

GRANT BINDAGENT TO USERB;

 GROUPA has programmer ID's connected to it.

 

The bind parms are set up like this.  

UNIT

BIND PACKAGE(COLLECTIONA) OWNER(RDEV) QUALIFIER(ALL1) -

MEMBER(PROGRAM1) ACTION(REP) ISOLATION(CS) VALIDATE(BIND) -

ENCODING(EBCDIC) DEGREE(ANY) RELEASE(DEALLOCATE)

BIND PACKAGE(EASTUNIT.ALL1) +

COPY(WEST.PROGRAMA)

OWNER(DB2DBAU)  QUALIFIER(ALL1) +

----- other bind parameters

ACTION(REP)

 

INTG

BIND PACKAGE(COLLECTIONA) OWNER(RDEV) QUALIFIER(ALL1) -

MEMBER(PROGRAM1) ACTION(REP) ISOLATION(CS) VALIDATE(BIND) -

ENCODING(EBCDIC) DEGREE(ANY) RELEASE(DEALLOCATE)

BIND PACKAGE(EASTINTG.ALL1) +

COPY(WEST.PROGRAMA)

OWNER(DB2DBAI)  QUALIFIER(ALL1) +

----- other bind parameters

ACTION(REP)

 

The first BIND PACKAGE binds the program on the WEST side.  The second BIND PACKAGE copies it to the east

 unit system using DDF EASTUNIT in the communications table. to collection ALL1.  The same for INTG, EASTINTG.

 

When the programmer does a compile bind on the west system lets say for a new program and the job runs using their ID the copy bind works.  No problem on the UNIT system .   If they do a rebind and the job runs using their ID it works only in UNIT and not INTG .  INTG fails to rebind using OWNER DB2DBAI.   Their ID is connected to GROUPA.   

Now if they use the change management system and lets say they migrate to INTG and the job runs using either ID USERA or USERB the copy bind fails with a message that DB2DBAU and DB2DBAI package owners are invalid and cannot be used.   

It's like USERA and USERB are not BINDAGENT's yet they have been granted BINDAGENT by DB2DBAU and DB2DBAI.  They should be able to bind to owners DB2DBAU and DB2DBAI. 

Also in this mix is WEST is RACF and EAST is ACF2 security.  

We are baffled why the change management jobs fail to copy/bind to EAST.  Also why does the INTG rebind fail to OWNER DB2DBAI when the job runs using the programmer ID yet it works on UNIT.  Is this screwy or what?   I have looked at this as well as our security group.   Our security group has no clue which security does the verification, ACF2 or RACF.  Neither do I.  I would presume ACF2 the target system for the copy/bind.

For the interim until we figure this out I do the copy/bind using my DBA ID which has SYSADM authority.

 

 

 

Tim Wilkins

RE: z/OS v11 Can't get bindagent to work
(in response to Tim Wilkins)

The BINDAGENT grants were done on the EAST ACF2 system only.

The compile and bind jobs execute on the WEST system.  

James Campbell

z/OS v11 Can't get bindagent to work
(in response to Tim Wilkins)
Are your SYSIBM.USERNAMES changing the IDs used on EASTINTG?

The secondary auth-ids used on WEST are irrelevant to EAST. Since EASTxxxx uses
ACF2, it is the secondary auth-ids that ACF2 provides to whatever incoming id that matter.

You might need to run a trace on IFCID 83 on EASTINTG - this will reveal the actual
secondary auth-ids that are being provided - as well as the primary id that is the result of any
USERNAMES translation.

The most that RACF on WEST might be doing here is providing a pass ticket if that is used
for the authentication on the communications between EAST and WEST. (Sounds like a
cold war spy story :-)

James Campbell.


On 21 Sep 2018 at 7:30, Tim Wilkins wrote:

>
> We have two systems, east and west.  An application area wants to create a program on west
> and access tables on the east system too.  The communications table is set up and it works.   
> The problem come in with doing a copy bind from west to east.  I know this sound screwy but here
> is what we are running into.  If a programmer does a compile bind on the west side and the job
> runs under their ID the copy bind works on the UNIT system.   If they use a change management
> system where the jobs run under one of two ID's depending on what they are doing the copy bind
> fails to work.  
>  
> Here is what we have done on the EAST side.
> UNIT system
> Security has granted SYSADM to ID DB2DBAU because the security ID has security admin rights
> from the zParm.
> INTG system
> Security has granted SYSADM to ID DB2DBAI because the security ID has security admin rights
> from the zParm.
> I verified they do have SYSADM granted by the security ID.
>  
> I ran these grants for unit and intg
> SET CURRENT SQLID='DB2DBAU';
> GRANT BINDAGENT TO GROUPA;
> GRANT BINDAGENT TO USERA;
> GRANT BINDAGENT TO USERB;
>  
> SET CURRENT SQLID='DB2DBAI';
> GRANT BINDAGENT TO GROUPA;
> GRANT BINDAGENT TO USERA;
> GRANT BINDAGENT TO USERB;
>  GROUPA has programmer ID's connected to it.
>  
> The bind parms are set up like this.  
> UNIT
> BIND PACKAGE(COLLECTIONA) OWNER(RDEV) QUALIFIER(ALL1) -
> MEMBER(PROGRAM1) ACTION(REP) ISOLATION(CS) VALIDATE(BIND) -
> ENCODING(EBCDIC) DEGREE(ANY) RELEASE(DEALLOCATE)
> BIND PACKAGE(EASTUNIT.ALL1) +
> COPY(WEST.PROGRAMA)
> OWNER(DB2DBAU)  QUALIFIER(ALL1) +
> ----- other bind parameters
> ACTION(REP)
>  
> INTG
> BIND PACKAGE(COLLECTIONA) OWNER(RDEV) QUALIFIER(ALL1) -
> MEMBER(PROGRAM1) ACTION(REP) ISOLATION(CS) VALIDATE(BIND) -
> ENCODING(EBCDIC) DEGREE(ANY) RELEASE(DEALLOCATE)
> BIND PACKAGE(EASTINTG.ALL1) +
> COPY(WEST.PROGRAMA)
> OWNER(DB2DBAI)  QUALIFIER(ALL1) +
> ----- other bind parameters
> ACTION(REP)
>  
> The first BIND PACKAGE binds the program on the WEST side.  The second BIND PACKAGE
> copies it to the east
>  unit system using DDF EASTUNIT in the communications table. to collection ALL1.  The same
> for INTG, EASTINTG.
>  
> When the programmer does a compile bind on the west system lets say for a new program and
> the job runs using their ID the copy bind works.  No problem on the UNIT system .   If they do a
> rebind and the job runs using their ID it works only in UNIT and not INTG .  INTG fails to rebind
> using OWNER DB2DBAI.   Their ID is connected to GROUPA.   
> Now if they use the change management system and lets say they migrate to INTG and the job
> runs using either ID USERA or USERB the copy bind fails with a message that DB2DBAU and
> DB2DBAI package owners are invalid and cannot be used.   
> It's like USERA and USERB are not BINDAGENT's yet they have been granted BINDAGENT by
> DB2DBAU and DB2DBAI.  They should be able to bind to owners DB2DBAU and DB2DBAI. 
> Also in this mix is WEST is RACF and EAST is ACF2 security.  
> We are baffled why the change management jobs fail to copy/bind to EAST.  Also why does the
> INTG rebind fail to OWNER DB2DBAI when the job runs using the programmer ID yet it works on
> UNIT.  Is this screwy or what?   I have looked at this as well as our security group.   Our security
> group has no clue which security does the verification, ACF2 or RACF.  Neither do I.  I would
> presume ACF2 the target system for the copy/bind.
> For the interim until we figure this out I do the copy/bind using my DBA ID which has SYSADM
> authority.
>  



---
This email has been checked for viruses by AVG.
https://www.avg.com

Tim Wilkins

RE: z/OS v11 Can't get bindagent to work
(in response to James Campbell)

There is no translation taking place in table SYSIBM.USERNAMES.

I suppose we could add the ID's to that table and test.   I somewhat figured the ID being passed from West to East isn't what we think it is by the copy/bind failures..