Can ESI be used to ensure that a package is created sharable and backout is enabled?
search cancel

Can ESI be used to ensure that a package is created sharable and backout is enabled?

book

Article ID: 259922

calendar_today

Updated On:

Products

Endevor

Issue/Introduction

It is unclear how the Name Equates table should be coded to control package subfunctions. 

For example, to ensure that Backout Enabled is always selected, the package is sharable and always a standard package - how can the BC1TENQU table be coded to control this? 

Environment

Release : ALL

Resolution

To accomplish this make sure that the C1DEFLTS table has PKGSEC set to ESI (PKGSEC=ESI) and that the BC1TNEQU Tableis setup for Package actions and include PKGSHR, PKGBOE and PKGTYPE. 

Below is an example of what the NAMEQU for Package_Actions would look like:

NAMEQU PACKAGE_ACTIONS,      
      L1=('C1'),                                              
      L2=('PKG'),                                             
      L3=(MENUITEM),                                          
      L4=(PKGSUBFC),                                          
      L5=(PKGID),                                             
      L6=(PKGSHR),             SHARABLE PKG (Y/N)                           
      L7=(PKGBOE),              BACKOUT ENABLED (Y/N)            
      L8=(PKGTYPE(1,2))      PKG TYPE (STANDARD/EMERGENCY)

If a package was created with the name PACKAGE1234, that is SHARABLE, backout enabled and Standard - the entity passed to the external security package would look like this: 

C1.PKG.CREATE.CREATE.PACKAGE1234.Y.Y.ST 

If a package is created with the name PACKAGE1, that is Non-sharable, backout enabled and the Package Type is Emergency - the entity passed to the external security package would look like this: 

C1.PKG.CREATE.CREATE.PACKAGE1.N.Y.ER 

ACCESS=NONE would have to be coded for the Entity to ensure that a user would not get access to create a package that was non-sharable, backout enabled =n or was an Emergency package.  Below is a few of examples of the rules/resources that would need to be created: 

c1.pkg.*.*.*.n.n.em
access=none
 
c1.pkg.*.*.*.y.n.em
access=none
 
c1.pkg.*.*.*.y.n.st 
access=none 
 

So if the user has access=none and they attempt to create a package where backout enabled is set to No (n)  or is non-sharable or an emergency pakcage, the action should be denied and fail with a security violation.