Idea Details

Let "do nothing" really "do nothing"

Last activity 12-10-2018 12:00 PM
John Dueckman's profile image
11-30-2018 02:56 PM

As an administrator, I want to define a "do nothing" process(or) for GENERATE in (for example) production that really "does nothing" so that I do not accidentally create or delete load members or other output components or relational information. 

 

For many years, I have been preaching "do not allow generates in production" only to realize Endevor doesn't do what I thought it would/should do! I have always advocated putting *NOPROC* as the GENERATE processor in the production stage. I've recently discovered a major "flaw" in that design that I'd like CA/Broadcom to address. 

 

This is best illustrated with an example...

 

Let's say I have changed a COBOL program and created the requisite LOAD. ACM captured the information and all is good. Now I MOVE the COBOL program through the life-cycle using MOVE processes, moving along the LOAD and ACM information. I successfully promote my program to my PROD stage using MOVE processes (not GENERATE). In my PROD stage, the GENERATE processor is defined as *NOPROC* to ensure I do not try to recompile and recreate things "in production".

 

But someone DOES make a package that contains GENERATE in PROD. That should be OK since *NOPROC* won't do anything.... or does it? In fact, the generate that takes place in PROD will cause ACM to drop the information it so carefully tracked through the life-cycle! Yikes! 

 

So what I need is a processor that really "does nothing"; an Endevor IEFBR14 if you will. Maybe call it something like *NILPROC..... if you define that as the processor, Endevor might *blink* but that's all. Best would be a default message that says something like "GENERATE is not enabled at this stage" or something like that but without the spin of the Endevor wheels. 


Comments

12-08-2018 06:05 PM

That commitment to Segregation of Duties is an indication that your company is well managed. Blocking people who move to PROD from modifying source code makes sense. Individual employee self-interests sometimes conflicts with the business self-interest, therefore businesses that enforce Segregation of Duties may perform better over the long term, particularly for larger businesses whose employees specialize.

12-08-2018 04:33 PM

ESI works for us. We already have stage-specific rules anyway. It would be nice to have the NILPROC option though, for those shops that need it, or make *NOPROC* to absolutely nothing.

12-07-2018 08:50 AM

Ah yes... the great debate about "backout"... You're not going to pull ME into that black hole! 

 

(and for the record, I am NOT a fan of "backout" in any form...  )... 

12-07-2018 03:14 AM

My personal view is your security rules should be handling this. At our site we get a lot of audits, and auditors like to see that an action cannot be performed, not that you can preform an action but it doesn't do anything. As you've found out it does do something currently. It's a lot easier to show ESI preventing an action than going through and proving that the action has done 'nothing'. 

 

One thing that would be useful is a new type of backout that could restore all environments back to their previous state. An example we have is that we have moved source from a pre-PROD source environment to our PROD source environment prior to the "real" deployment via ship and the change gets pulled. Currently our developers have to manually pull back their code to a Dev environment and then we backout and delete the package that did the PROD move for them.

 

For your scenario you could just backout the generate and know that everything was back how it was prior to the event. 

12-04-2018 01:02 AM

Hi John,

 

I see merit in this idea because it would make it a lot easier in a simple setup to have the *NILPROC* instead of the need for all the ESI Rules. I guess it may depend very much on each site though.

 

I actually use ESI Rules for a heap of exceptions within our site.

We have a very stringent need for Segregation of Duties to allow us to achieve industry compliance.

So for some of our Applications, we have had to go to the degree of 'locking out' the Endevor Administrators from ANY possible way to modify Source Code (ADD/UPDATE/TRANSFER) because we have access to MOVE into PROD!

 

Endevor Administrators should know ESI (like a good friend) and make the right 'blocks' where needed.

Yes, I do manage the ESI Rules, but if I change a rule, It is audited by the security team and I receive a 'please explain'.

12-03-2018 08:56 AM

Yes, that's an option.... I was just trying to avoid having special rules for specific stages.... 

11-30-2018 03:34 PM

If I want to stop users from using Generate in Production Environment  I would use ESI rules. So I would allow nobody to do a generate if it's the production stage. You can allow the administrator access to do the generate as you never know what will be required to fix a problem.