Idea Details

User Extension Points in QuickEdit and Endevor...

Last activity 24 days ago
Eoin OCleirigh's profile image
07-10-2014 03:09 PM

As an Endevor Administrator I'd like to be able to Extend CA's solutions to integrate QuickEdit and/or Endevor into my environment by providing a simple method for me to provide custom actions which could be invoked from within QuickEdit or Endevor selections lists.


In it's simplest form, an unrecognized line command would be passed to a user routine with a name that was constructed based on a standard prefix (e.g. "UsrRtn") + the line command entered - for example entering UX against an element would invoke a command USRRTNUX passing details of the current row via shared pool variables to that command.


The Business Benefit:
Each site could Extend Endevor to provide custom, stite specific actions, that were tightly integrated into Endevor without having to wait for CA to develop and deliver that functionality in the product.  Some potential applications might include, special compile or debug options, integration with 3rd party code editors or review tools, custom deployments ("...deploy this element's executibles to my CICST3 environment"...) etc.


CA or other interested parties could 'share' these custom extensions allowing popular interfaces to be developed once, and deployed many times.


The following mock-up screen shots show how a User Command might be entered and the datails that could be passed...



A sample routine USRRTNUX might just dump the variables like this;



12-18-2017 03:02 AM

YES YES YES. That is something that should have been there from the very start. When can we have it ?

12-08-2017 05:12 AM

What is CA waiting for ?   Just GO 4 IT !!!


05-28-2016 10:36 AM

Hi SBAshby,

Please have a look at the new sample user routine (UsrRtnUS in LongName Bundle v48) which performs a retrieve and submit - I think this would be a great basis for your Retrieve and Connect:Direct idea - just invoke connect direct instead of submit, or wrap Connect:Direct JCL around it before submit...

05-28-2016 10:32 AM

I've added a new Submit UserRoutine (USRRTNUS) to the LongName FDP prototype (see here: LongName Utility FDP)


This routine simply retrieves the selected element to a temporary file, and then submits it - great when you have stored JCL in Endevor and don't want to have to Edit (possibly with Signout override) just to submit it.  The job name and job number are captured and saved in your Submit history making it easy to check when/where your job went (see screen shot below)



However, the real value of this sample is that you can use it as a model for your own commands that need the current element source to work with... for example a custom editor (SDF2, or TWS edit, RACF, TopSecret or ACF2 rule update) etc. I can't wait to see what everybody else comes up with.

10-19-2015 05:14 PM

The proto-type utility (LongName) is available for download (here LongName Utility FDP) you can have a look at some of the sample User Routines (USRRTNxx) in the supplied clist library and have a go at creating your own. 

04-20-2015 07:37 AM

I see quite a bit of value for our shop with this feature. We have a lot of developers that are used to Roscoe and its command driven interface.

This feature could be used to allow access to utilities and functions outside of Endevor but keep QE as the main focus when signed into ISPF.

04-16-2015 04:26 AM

Thanks Josef, Eoin is finally object oriented!

04-15-2015 08:01 AM

We don't use QuickEdit that much at our site, because we are mainly using an "object oriented (in the meaning of: first the elements are selected and then they are dealt by Actions or commands) interface created before QuickEdit existed....


I see the benefit of this idea and therefore here is my vote!


@ Endevor-product management: If this idea will be implemented you might want to rename "QuickEdit" to "object-oriented-Endevor-interface ..." (I'm just joking ...) [afterwards added] or more pointedly : "Element-oriented-interface to Endevor" .... .

04-15-2015 07:56 AM

Hi Rose,


If we were to use this for offhost long name files, then we could add a user extension to Connect:Direct the file in to a mainframe USS directory.

It would probably remove a lot of the options currently on our NDVRUSER panel because they would be in context.



04-15-2015 05:54 AM

This is a great idea and something that I know we would find very useful.   We would like to be able to build packages quicker by selecting elements directly from Quick Edit with a line command.  Also we have some other syntax checkers which we would like to be able to initiate from QE instead of having to go to another screen.

I would be happy to validate this enhancement if it was implemented.

04-15-2015 03:57 AM

This is now reopened for voting.  Please be sure to indicate the VALUE you would derive from this feature (or not) along with your vote and if you would be able to validate this request.


Thank you all - this is a great discussion.

04-13-2015 07:31 AM

I agree. I would also like to see this re-opened. It could be a big help if done correctly.

04-11-2015 06:03 PM

Hi Rose.Sakach,


What is the process for re-opening items, or are additional comments sufficient?  When we demoed this prototype at the EMEA usergroups there was almost universal support. 



04-09-2015 02:37 AM



in my opinion this idea should re-opened for voting.


Kind regards


Klaus-Dieter Stamm



LVM Versicherung

Kolde-Ring 21

48126 Münster


Telefon: 0251 702-2066

Telefax: 0251 702-992066




Von:     SBAshby <>


Datum:     07.04.2015 21:47

Betreff:     Re:  - User Extension Points in QuickEdit and


                                                                                CA Communities                                                                               

User Extension Points in QuickEdit and Endevor...                    

new comment by Stuart Ashby View all comments on this idea           

Could this idea be re-opened for voting please?                      

Reply to this email to respond to Stuart Ashby's comment.

04-07-2015 03:47 PM

Could this idea be re-opened for voting please?

12-18-2014 05:04 AM

Good suggestion Eoin

10-27-2014 11:20 AM

A cut-down shipment/deploy is perhaps the most obvious candidate, but other new example might include; prompting the user for UserData and then using the new ALTER syntax to update an element's UserData.  This would make it easy to pass user options or switches to a processor which can simply interrogate &C1EUDATA.


Or as a solution to the problem raised elsewhere, to "sign-in" this element further up the map to make it easier to clean-up when development plans change. See idea raised by rstringfellow -AutoSignin Option for Element Delete Action

10-22-2014 11:25 AM

Great idea Eoin, here are a few ideas for it

  • The compare option that I posted, comparing different levels of source and comparing elements up the map
  • A cut down shipment without the need for a package - e.g. we use shipment from development stages to copy to other sysplexes but of course it needs a package which developers for forget to use when moving elements (a bit like the sandbox solution that you mentioned)
  • View an element (if you have browse set as the default)

There must be many more that I can't think of now.

07-11-2014 02:45 AM

Exactly - because the Extension Point would be supported, rather than your actual extension.  Also, because the extensions are yours, there is no worry of a clashing update.  That said, I imagine there might be a few people who might like to share your Transfer Extension point - especially when you think of Transfer as perhaps the easiest method to accomplish a re-name, but also in cases where you might be using static sandboxes to control stand-alone test environments.

07-11-2014 02:38 AM

This is a very good idea to do a lot of endevor actions which are not supported by the quick edit selection panel.

I have build 20 years ago a workaround to make such unsupported endevor actions from the quick-edit selection panel. For example Transfer-Command.

With the described function it will be more easier to get the needed information for an element and do unsupported actions. Also I need no longer modify Endevor panels at each release change for the use of my workaround.