Endevor Override Signout

[Russ Gunter]

Hello All.
Does anyone know if there is an Override Sign-out report?
I looked at some of the reports and they note SIGNIN but I don't see an Override Signout report.
If there is something in a CSV someone knows about that would be helpful also.
Thanks,
Russ

------------------------------
Russ
------------------------------

[Eoin OCleirigh]

Hi Russ,

Having recently played with this I can confirm - there IS an OverRide Signout flag/field available in the SMF data (and/or via that source in the CSV data).  The field/column you are looking for is SIGNOUT OVRD and it will Show a 'Y' if Signout Override was specified on the request.  (see snippet below.

|SIGNOUT OVRD|RETR COPY ONLY|EXPND INCL|REPLACE|ELM DEL|
|N           |              |          |       |N      |
 -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
|Y           |N             |N         |N      |       |
|N           |              |          |       |N      |
|N           |              |          |       |N      |
|N           |              |          |       |N      |

Note: you may have to do additional work to determine if an ACTUAL signout override happened (i.e. if the Action UsrID is not the same as the LastLevel Usrid etc. depending on the request), But at least you know who's requesting it. 

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Russ Gunter]

Hi Eoin,

I have gone through the my SMF record and I see the field you are referring.
What I am not sure about is, what field shows who owned the element at the time of the override and what field shows the user that did the override. 

For example i am looking at one records where, a the same userid is in the ELM LAST LL USRID and in the LAST PROC USRID filed and the SIGNOUT TO USR field is blank.

I have 5 other records where the ELM LAST LL USRID and in the LAST PROC USRID fields are different. 

I suppose the first one could be someone does override signout on every thing, even their own elements. if that happened Would the Y in the SIGNOUT OVRD field still be a Y?

if you you can clarify those two fields are the ones I need then you suggestion is what I need.

Thanks, 

------------------------------
Russ
------------------------------

[Eoin OCleirigh]

Hi Russ,

Yeah, it's not perfect - the SIGNOUT OVRD flag will just show a 'Y' if Signout Override was on the SCL statement (or set as a SET OPTION).  Whether a signout change actually took place requires knowledge of the knowledge of the "state" before hand.  In most of my examinations, I was interested in a particular element, and so I could filter down and look at how that element had gotten to the place it was, and the presence of the "SIGNOUT OVRD" flag would help me determine WHO had performed the override.

If you have enabled the email notification on signout override (default unless SUPPRESS_OVERRIDE_EMAIL optional feature is enabled), the person who was "overridden" should receive an email and you might be able to detect that by scanning the email logs for messages from Endevor with subject lines in the format "<userid> overrode your signout of <ele>/<typ>". 

Hint: In the case of folks how have left the organisation, you could adjust the ESMPTTBL to forward their emails to you or a support group/team lead.

In the end I guess it depends on your motives? I hold the opinion that "signout override" should be treated as a warning/check, to encourage communication, but that the developer should make the call when they decide to use OVE SIGNO. The email notification helps fill the gap by letting the other party know too.  Scanning the SMF will help you identify the folks who are using Override Signout, whether they need to or not.  If you can find patterns that certain folks are just using override singout all the time, maybe you have an education opportunity, maybe you should consider disabling Signout check for that/those systems?  If the reasons that Override Signout was being requested related more to generates than retrieve, add/updateYou could also consider the option features table which has options to bypass the signout for generate in place/copyback (see GEN_DO_NOT_CHK_SIGNOUT, GEN_INPLACE_DO_NOT_SET_SIGNOUT, & GEN_COPYBCK_DO_NOT_SET_SIGNOUT options). At our shop one team in particular uses GENERATE COPYBACK to pick up vendor supplied copybook changes, so arguably the "signout is less important" in that case, the element that would have been signed out has not changed, it's the copybooks you need to track!  But I'd also add the anecdotal evidence that most of our package failures are due to signout being required but not specified, and since the elements are locked, the only recourse is to reset the package (and fix the elements or add OVE SIGNO - no prizes for guessing which is easier!) but then the teams are in a rush to get their approvals again.  OK so the end effect is increased communication, but maybe at the wrong time.  I'm considering adding a CAST EXIT to fail the cast if a signout would be needed (but is not specified) - at least then the notification would be earlier in the process, but might just encourage the 'SET OPTION OVE SIGNO'. as standard behavior.

I'm curious to see how other folks weigh in?  Which signout related features are enabled in the optional features, and how often is signout the cause for package failures?

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Russ Gunter]

Eoin,

Thank you for the great reply.

I had the override signout turned on in a test environment and it did not work but they don't keep use the ESMPTBL here they have they own hone grown email system.

Admins don't update the tables here, the Sysprog do and they …., all I am going to say.

I have realized about the FLAG being set to Y.

For now, I am going to write a REXX looking for the Y and compare the ELM LAST LL USRID to the LAST PROC USRID.

If they are the same, then ignore it. It they are not, then save the ENV/SYS/SBS/TYP/VV.LL in a record and report it.

Then I am going to have the team leads run it when they want it.

I agree with your opinion.

I'm keeping it simple at first then grow from there if needed.

Thanks again, 

------------------------------
Russ
------------------------------

[Lenn Thompson]

Just an FYI that I've moved this thread to the Endevor community!

------------------------------
Lenn Thompson
Community Manager, Mainframe Division
Broadcom Inc.
[e-mail]
------------------------------

[Russ Gunter]

Okay
Thanks

Russ Gunter

Technology Services Group – Mainframe Services
Endevor Administration
AIM: 015-W19

BNY Mellon | Technology Services Group, Inc.
508-871-3565(w)
770-595-8600(c)
[e-mail]<[e-mail]>

Planned Days Away
4/14/23 & 4/17/23

[Joseph Walther]

The SOFETCH parameter on the C1DEFLTS table can dramatically reduce concerns around SIGNOUTS and SIGNOUT OVERRIDES, and offer another way to handle Signouts.

Setting SOFETCH=N has sometimes been used for new Endevor implementations when supporting parallel paths, especially where developers use Quick-Edit.  No RETRIEVE actions are necessary when SOFETCH=N. Elements placed at the development locations of the life cycles are signed out, but not the production element. Instead, Production elements remain available for parallel development. Someone correct me if I am wrong but do not modern IDEs and Repos lack a "signout" function like the Endevor Retrieve?

When SOFETCH=N is paired with the Parallel Development Alert (PDA) you have a very effective management of parallel development. PDA is an FDP that anyone can pull down from here  Parallel Development Alert (PDA) bundle. It leverages the fact that Quick-Edit actions on elements cause them to never leave the product (Endevor+Quick-Edit), and one little API call (performed by PDA) can quickly find and display all the non-production locations for an element. Awareness of parallel development is key to its success, and to preventing accidental code regression.

Endevor's SIGNOUT feature gives developers some notification when parallel development begins. If a developer attempts to change an element that is "Signed out" to someone else, a message is given saying 'Element is signed out to another user'. It is up to the developer to find out who the user is (maybe more than one), and where they are developing their version of the element. If the OVERRIDE SIGNOUT option is used, then no additional messages are given as reminders.

In contrast, the PDA gives a very informative message pertaining to parallel development.  Not only do the PDA messages tell you the userids of persons working on the element (even if there are many). it also tells you the development locations of the other elements, whether they be in Sandboxes or Dynamic environments. Lastly, the CCID is placed into the message for each element. PDA does not give the developer just one shot at those messages. Rather they are repeated again and again for each Quick-Edit session on any of the elements belonging to any of the users in parallel development.

A second FDP that can accompany the PDA, is RETRO, a screen-assisted execution of PDM (Parallel Development Manager). It uses a PDA message to determine the Root and Derivation files for the PDM execution and makes running PDM a very simple task. (Anyone interested in RETRO can have a copy by simply asking for one).

In summary, setting SOFETCH=N can manage signouts in a different way. PDA messages can be a nagging reminder to developers to do something about parallel development conditions. Retro can help make code merging easy for them. However, If PDA warnings are ignored, then SYNC errors will be encountered, serving as yet another layer of protection from regression related to parallel development.