Idea Details


Last activity 05-31-2019 01:49 AM
Josef Thaler's profile image
03-31-2015 02:26 AM

As a developer, I need Endevor to provide me with an online summary or query for any stage that tells me when an element and/or change level arrived there (i.e. ADD, UPDATE, MOVE,TRANSFER) uniquely from when the change was created so that I can perform effective post-implementation analysis and post-implementation problem identification/tracking.


Many thanks to @John Dueckman @John.Dueckman for this compact and complete definition of the business need and for your additional help.


The disadvantageous aspects of the current appearance of SOURCE LEVEL INFORMATION have been discussed, commented, analyzed and documented in thread misleading SOURCE LEVEL INFORMATION.


To avoid the disadvantageous aspects of today and to provide a clearer and more complete information to the Endevor-users an additional timestamp in SOURCE LEVEL INFORMATION is suggested.


To illustrate the suggestion based on SOURCE LEVEL INFORMATION in PRINT ELEMENT ... HISTORY (while this information also appears in other contexts like element summary  and so on)


Today's appearance:

Endevor Source-Level-information.old.jpg      

Suggested extention with comments:



*1: two timestamps in Source Level Information need a more descriptive heading

*2: Endevor does not have this info from the past. N/A could be seen as a signal to the Endevor-user that source level creation date is (could be) different from the arrival date in this stage and he has to query other sources like smf-reports, package-execution-logs, ccid-queries etc. to get this information.

*3 Endevor updates this timestamp during source-management when it stores this source-level in the new stage.


This new timestamp would be useful for all element-types, and especially for those, where the source itself is the "active code", like JCL, all kinds of PARMLIB and so on.


This new information could be useful for all Endevor-users     


06-23-2015 05:31 AM

Nice!  Another (better?) way to answer the question "So What Changed?..."

04-14-2015 05:33 AM

Thanks for commenting, your first addition would come down to an additional time-stamp-column so that the clearified SOURCE-LEVEL-INFORMATION could look like as follows:



*1 the header Information 'STAGED' should indicate the  point of time, when the output-types (loadmodule etc.) of the element-level either arrived at this stage (by a move processor) or have been created (by generate processor @ MOVE, TRANSFER or GENERATE Action). Thanks to John Dueckman for this expression "STAGED".  

*2 For example: This source level had been created by a GENERATE action, while the source -level itself had remained unchanged. 

04-08-2015 11:52 AM

Many thanks for commenting ...

I'd like to add an imagination, that an average Endevor-user looks for an element, finds it at the requested stage and finds the source levels and takes the listed timestamp - mistakenly - as the arrival time in this stage (where should he see in the current appearance, that the timestamp markes an event on a different stage?)

04-03-2015 07:43 AM

This information is very useful when developers want to get -1/-2/.. version if MOVE action option is WITH HISTORY.

In addition, I would like to store the ARRIVE timestamp for each stages of logical map, so admnistrator can easily konw the time track to debug some issues.

04-02-2015 05:47 AM

Could this also have the generate timestamp added so that outputs can be traced back to the source? And also add the information to the "S - Display summary of levels" option.


The same information could be added in the "SX - Component list summary". Since MONITOR=COMPONENTS is now used in the MOVE processor, the timestamp of the component list is the MOVE timestamp not the GENERATE timestamp so it is difficult to match a load module to a component list. Enhancing Josef's idea we would have the generate timestamp to match outputs back to the source and component list.

03-31-2015 03:16 PM

There is no question about this, the date of arrival is sometimes needed.  Without this information we do not know which of the two possible version levels was executed.

03-31-2015 09:30 AM

Just to enhance Josef's write-up...


While you can derive the information from an SMF report, many (if not most) developers do not have access nor even know about the SMF reports.


My own opinion is this is "meta" life cycle management information that a developer could find very useful.... and not have to bother the administrator in order to find it!