Hi Suzette,
It seems that your Endevor processor is correctly writing members (and
footprinting them) to the output dataset. Based on what you've provided, I
would say the most likely cause of these occasional orphans is that Endevor
doesn't know about them.
How does that happen? Three things come to mind; (1) someone with
privileged access to the output dataset edited / saved the member from ISPF
instead of Endevor, (2) someone with privileged access copied them into the
dataset, or (3) another processor is pointing to the same output dataset,
overlaying the members from different systems / types. A Footprint
exception report will show you any members with issues; either missing
footprints (updated outside of Endevor) or footprint mismatch issues.
If an orphaned member has a valid footprint, the most likely reason is
someone moved or transferred the element with the "bypass from element
delete" option.
*Dave Harding *
Client Services Consultant • Mainframe Software Division
Broadcom Software
Mobile 317-403-1740 |
dave.harding@broadcom.comOn Tue, Apr 1, 2025 at 3:33 AM Suzette Ebale via Broadcom <
mail@broadcom.com>
wrote:
> Hi Joseph, Does that mean, we need reporting to run to be able to give us
> details/reason on why there are orphaned elements? -posted to the "Endevor"
> community
> [image: Broadcom] <https: community.broadcom.com>
> Endevor
> <https: community.broadcom.com mainframesoftware communities community-home digestviewer?communitykey=592eb6c9-73f7-460f-9aa9-e5194cdafcd2>
> Post New Message <
broadcom-caendevor@connectedcommunity.org>
> Re: Orphan Elements in output libraries
> <https: community.broadcom.com mainframesoftware discussion orphan-elements-in-output-libraries#bm09a9a43c-06d0-4d87-813a-0195f0447ee0>
> Reply to Group
> <
broadcom_caendevor_09a9a43c-06d0-4d87-813a-0195f0447ee0@connectedcommunity.org?subject=re:+orphan+elements+in+output+libraries> Reply
> to Sender
> <https: community.broadcom.com mainframesoftware communities all-discussions postreply?messagekey=09a9a43c-06d0-4d87-813a-0195f0447ee0&ListKey=6c02d13b-c28e-4794-b86a-c8b767e00498&SenderKey=46045f5e-493f-4382-abed-53bcb9633157>
> [image: Suzette Ebale]
> <https: community.broadcom.com network members profile?userkey=46045f5e-493f-4382-abed-53bcb9633157>
> Apr 1, 2025 3:34 AM
> Suzette Ebale
> <https: community.broadcom.com network members profile?userkey=46045f5e-493f-4382-abed-53bcb9633157>
>
> Hi Joseph,
>
> Does that mean, we need reporting to run to be able to give us
> details/reason on why there are orphaned elements?
> *Reply to Group Online
> <https: community.broadcom.com mainframesoftware communities all-discussions postreply?messagekey=09a9a43c-06d0-4d87-813a-0195f0447ee0&ListKey=6c02d13b-c28e-4794-b86a-c8b767e00498>*
> *Reply to Group via Email
> <
broadcom_caendevor_09a9a43c-06d0-4d87-813a-0195f0447ee0@connectedcommunity.org?subject=re:+orphan+elements+in+output+libraries>*
> *View Thread
> <https: community.broadcom.com mainframesoftware discussion orphan-elements-in-output-libraries#bm09a9a43c-06d0-4d87-813a-0195f0447ee0>*
> *Recommend
> <https: community.broadcom.com:443 mainframesoftware discussion orphan-elements-in-output-libraries?messagekey=09a9a43c-06d0-4d87-813a-0195f0447ee0&cmd=rate&cmdarg=add#bm09a9a43c-06d0-4d87-813a-0195f0447ee0>*
> *Forward
> <https: community.broadcom.com mainframesoftware communities all-discussions forwardmessages?messagekey=09a9a43c-06d0-4d87-813a-0195f0447ee0&ListKey=6c02d13b-c28e-4794-b86a-c8b767e00498>*
> *Flag as Inappropriate
> <https: community.broadcom.com mainframesoftware discussion orphan-elements-in-output-libraries?markappropriate=09a9a43c-06d0-4d87-813a-0195f0447ee0#bm09a9a43c-06d0-4d87-813a-0195f0447ee0>*
>
> -------------------------------------------
> Original Message:
> Sent: Mar 28, 2025 11:46 AM
> From: Joseph Walther
> Subject: Orphan Elements in output libraries
>
> A FOOTPRINT EXCEPTION report may provide some helpful details.
>
>
> Original Message:
> Sent: Mar 28, 2025 04:06 AM
> From: Suzette Ebale
> Subject: Orphan Elements in output libraries
>
>
> -
>
> Are there processes outside of Endevor that place members into
> PNEP.GLB.S3D.LOADLIB? --> NONE
> -
>
> Is there a MONITOR=COMPONENTS clause on each of the Generate and MOVE
> processors that update PNEP.GLB.S3D.LOADLIB? -->
> For Generate processor, yes we have monitor=components clause. For MOVE
> processors, there are 2 parts.
> a. BSTCOPY for the copy of load module with output step having
> Monitor=Components. After this, the last step we use in all our move
> processors is below:
> -
>
> Have there been any changes made to Base or Delta library names?
> --> naming convention hasn't changed for like more than 10yrs
> -
>
> Are users doing TRANSFER actions with the BYPASS DELETE PROCESSOR
> clause? --> This TRANSFER action is not used by all users. Only specific
> admin and release team. This TRANSFER SCL gets build via the Native Endevor
> whenever it is required only. we have bypass element delete option but I
> haven't seen anyone nor Endevor admin doing the "bypass delete processor".
> In native Endevor, below is our default screen panel.
>
>
>
>
> -
>
> Are the members in the PNEP.GLB.S3D.LOADLIB footprinted? --> As far
> as I know, our generate processors have the FOOTPRINT with MONITOR
> COMPONENTS. Checking now this library, looks like the modules are NOT
> footprinted.
>
>
> Original Message:
> Sent: Mar 27, 2025 10:28 AM
> From: Joseph Walther
> Subject: Orphan Elements in output libraries
>
>
>
> A few things to check:
>
> -
>
> Are there processes outside of Endevor that place members into
> PNEP.GLB.S3D.LOADLIB?
> -
>
> Is there a MONITOR=COMPONENTS clause on each of the Generate and MOVE
> processors that update PNEP.GLB.S3D.LOADLIB?
> -
>
> Have there been any changes made to Base or Delta library names?
> -
>
> Are users doing TRANSFER actions with the BYPASS DELETE PROCESSOR
> clause?
> -
>
> Are the members in the PNEP.GLB.S3D.LOADLIB footprinted?
>
> If all the members are footprinted, then a process that uses the footprint
> can be used to report/delete the orphans.
>
>
> Original Message:
> Sent: Mar 26, 2025 08:05 PM
> From: Suzette Ebale
> Subject: Orphan Elements in output libraries
>
> We have an Endevor processor setup that writes to an output library when
> an element is either added or moved to the target environment. However, we
> are getting some Orphan elements (left in output library) but no longer
> present / not existing in Endevor. What could be the likely cause of this?
>
> This does not happen often but occasionally we get this scenario.
>
> Example - no longer found in Endevor but in output library still.
>
>
> Our DELETE processor has this setup to delete all output components.
>
>
>
>
>
> You are subscribed to "Endevor" as
dave.harding@broadcom.com. To change
> your subscriptions, go to My Subscriptions
> <http: community.broadcom.com preferences?section=Subscriptions>. To
> unsubscribe from this community discussion, go to Unsubscribe
> <http: community.broadcom.com higherlogic egroups unsubscribe.aspx?userkey=f0102c8e-2c1c-47ba-9f18-e9e6816f2ae3&sKey=KeyRemoved&GroupKey=6c02d13b-c28e-4794-b86a-c8b767e00498>.
>
>
> Copyright © 2005-2023 Broadcom. All Rights Reserved. The term "Broadcom"
> refers to Broadcom Inc. and/or its subsidiaries.
>
> Hosted by Higher Logic, LLC on the behalf of Broadcom - Privacy Policy
> <https:
www.broadcom.com company legal privacy-policy> | Cookie Policy
> <https:
www.higherlogic.com legal privacy> | Supply Chain Transparency
> <https:
www.broadcom.com company citizenship governance-and-ethics#supply>
> | Terms of Use <http: termsandconditions>
>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Original Message:
Sent: 4/1/2025 3:34:00 AM
From: Suzette Ebale
Subject: RE: Orphan Elements in output libraries
Hi Joseph,
Does that mean, we need reporting to run to be able to give us details/reason on why there are orphaned elements?
Original Message:
Sent: Mar 28, 2025 11:46 AM
From: Joseph Walther
Subject: Orphan Elements in output libraries
A FOOTPRINT EXCEPTION report may provide some helpful details.
Original Message:
Sent: Mar 28, 2025 04:06 AM
From: Suzette Ebale
Subject: Orphan Elements in output libraries
Are there processes outside of Endevor that place members into PNEP.GLB.S3D.LOADLIB? --> NONE
Is there a MONITOR=COMPONENTS clause on each of the Generate and MOVE processors that update PNEP.GLB.S3D.LOADLIB? --> For Generate processor, yes we have monitor=components clause. For MOVE processors, there are 2 parts. a. BSTCOPY for the copy of load module with output step having Monitor=Components. After this, the last step we use in all our move processors is below:

Have there been any changes made to Base or Delta library names? --> naming convention hasn't changed for like more than 10yrs
Are users doing TRANSFER actions with the BYPASS DELETE PROCESSOR clause? --> This TRANSFER action is not used by all users. Only specific admin and release team. This TRANSFER SCL gets build via the Native Endevor whenever it is required only. we have bypass element delete option but I haven't seen anyone nor Endevor admin doing the "bypass delete processor". In native Endevor, below is our default screen panel.

Are the members in the PNEP.GLB.S3D.LOADLIB footprinted? --> As far as I know, our generate processors have the FOOTPRINT with MONITOR COMPONENTS. Checking now this library, looks like the modules are NOT footprinted.

Original Message:
Sent: Mar 27, 2025 10:28 AM
From: Joseph Walther
Subject: Orphan Elements in output libraries
A few things to check:
Are there processes outside of Endevor that place members into PNEP.GLB.S3D.LOADLIB?
Is there a MONITOR=COMPONENTS clause on each of the Generate and MOVE processors that update PNEP.GLB.S3D.LOADLIB?
Have there been any changes made to Base or Delta library names?
Are users doing TRANSFER actions with the BYPASS DELETE PROCESSOR clause?
Are the members in the PNEP.GLB.S3D.LOADLIB footprinted?
If all the members are footprinted, then a process that uses the footprint can be used to report/delete the orphans.
Original Message:
Sent: Mar 26, 2025 08:05 PM
From: Suzette Ebale
Subject: Orphan Elements in output libraries
We have an Endevor processor setup that writes to an output library when an element is either added or moved to the target environment. However, we are getting some Orphan elements (left in output library) but no longer present / not existing in Endevor. What could be the likely cause of this?
This does not happen often but occasionally we get this scenario.
Example - no longer found in Endevor but in output library still.


Our DELETE processor has this setup to delete all output components.

</http:></https:></https:></https:></http:></http:></https:></https:></https:></https:></broadcom_caendevor_09a9a43c-06d0-4d87-813a-0195f0447ee0@connectedcommunity.org?subject=re:+orphan+elements+in+output+libraries></https:></https:></https:></https:></broadcom_caendevor_09a9a43c-06d0-4d87-813a-0195f0447ee0@connectedcommunity.org?subject=re:+orphan+elements+in+output+libraries></https:></broadcom-caendevor@connectedcommunity.org></https:></https:></mail@broadcom.com>