Arthur.Mihailidis.3.3

Element Locking during Package Processing

Discussion created by Arthur.Mihailidis.3.3 on Jan 16, 2019
Latest reply on Jan 23, 2019 by EdwardMarks

Site Brief:

Environment Map :

DEV -> SIT -> UAT -> PRE -> PRD       This is the main Development Map

    ENS-^  ENU-^  ENR-^                          These are ‘Entry’ Environments used to resolve Source Differences

                                                                 For the purpose of this issue, we ADD to ENU then MOVE to UAT, PRE, PRD

In C1DEFLTS : SOFETCH=N

In ENCOPTBL : ENHOPT PKG_ELEMENT_LOCK=(ON,Y) is enabled

 

The process we have here is to build 6 Application Releases per year.

The Cumulative changes are loaded into ‘UAT’ and once major testing is complete, we MOVE to ‘PRE’ for the last couple of weeks and final patches and testing is completed. Then we use Package Processing to MOVE from 'PRE' to 'PRD'.

 

Until recently, we used Batch SCL Submission for loading changes into ‘UAT’ (MOVE from ‘ENU’).

 

Now we changed to using Package Processing and do the following:

1/ Build/Cast/Execute Package to ADD changed components into ‘ENU'.

    Some Compares and automatic changes to MODDECKS are performed here.

2/ Build/Cast/Execute Package to MOVE from ‘ENU’ to ‘UAT’.

3/ Build/Cast/Execute Package to GENERATE all New Delivered Components and also GENERATE any Impacted Components (Programs impacted by Copybook changes)

 

Sometimes, while a Release is accumulating in ‘UAT’, we may need to implement a minor fix into Production (in between releases) if the change itself is technically isolated from the release.

 

Recently, we had a change located in ‘PRE’ with a Package Created/Cast, but awaiting Approval.

When the next batch of Release Changes were being loaded into ‘UAT’, the GENERATE Package Failed to CAST due to ‘Locked Elements’.

 

I have been informed that;

1/ If the Element Already Exists in ‘UAT’ the Element can be Generated.

2/ If the ‘COPYBACK’ Option is used, and the Element up the Map is in a Package, then it is considered Locked – and the Package CAST will Fail.

 

 

But if I use Batch SCL Submit in this exact scenario, the Element Status up the Map is not Honored.

I.e. The Element is Successfully Copied Back from ‘PRE’ into ‘UAT’ and the GENERATE completes fine.

 

I agree that a Package to MOVE and Element from ‘UAT’ to ‘PRE’ should fail to cast if the same Element exists in 'PRE' and is already part of another Package awaiting Approval/Execution.

 

To me, this just seems to stop the ability to have separate changes for Copybooks at different stages if they share similar Impacted Programs.

 

 

So What Do You Think?????

 

Should the Package CAST Fail if the Element needs to be ‘Copied Back’ from somewhere up the Map that happens to be 'locked' bu a Package even though your Action is neither the Source or Target of that Element up the Map?

 

Please let me know your thoughts.

Outcomes