Validating CCID's

[Anon Anon]

How do people validate CCID's in Endevor, other than either using the default supplied "flat file" out-of-the-box Endevor processing, or by getting Exit 2 to check directly against a predefined VSAM KSDS?

 

How well does such checking work?  Any things to be aware of?

 

Thanks

 

Charles Gaskell

[Mathew Goldstein]

You can create a table in assembler, compile and link-edit it, then have exit 2 read it.  See CSIQOPTN(@CCIDTBL) and C1UEXT02 and C1UEXT06.  We do this except we conditionally search the table for the first word of the program element comment instead of the CCID.  We renamed the macro @PROJTBL and made some minor modifications so our table is coded with lines of code like this:

@PROJTBL SUBSYS=,SYSTEM=CA,PROJ=CA01A

 

This way we ensure that every program element has a valid project ID associated with it.  We save the validated project ID to the program element data so it is "sticky" and only needs to be specified the first time the program element is added to ENDEVOR or if the project ID changes.

[Eoin OCleirigh]

Amazing!  I'd never noticed that before.  I guess I never paid enough attention to the sample exits, but there it is right in the doc (search for @CCIDTBL as a keyword at http://docops.ca.com/Endevor!)

Using an assembler table would certainly be fast, and letting Endevor collect/build the contents would allow all of the good security controls to be in place.

[wilhelm.raitz]

Hi all,

 

usually (when the customer agrees to have a DB2-Database / Repository connected to Endevor) i suggest to store all CCIDs at a DB2 table and then it's pretty easy to let Exit 02 check the table and / or do a lot of other stuff. Example: invalid a CCID when reaching production status etc..

 

Regards,

Willi

 

PS: My current customer agreed to have all elements stored at a DB2-table. Exit 02 and Exit 03 are keeping the table synchronous to the MCF at realtime. With that you can do every kind of query by SQL. My customer loves it!

[Anon Anon]

Hi Willi,

 

Sounds as though you've almost implemented the DAR that asks CA to implement it's Endevor  "database" (MCF's, PCF's etc.) as a relational database! Neat...

 

I'm planning on doing something similar - storing CCID's in a DB2 table and getting Exit 02 to check the table (via an API).  Are your exits written in Assembler, or Cobol?  Do they access the DB2 tables directly, or via intermediary programs?  How do you (and at what point do you) connect to DB2 - is this using CAF?

 

Any "gotchas" or pitfalls to be aware of when using this approach?

 

Thanks

Charles

[wilhelm.raitz]

Hi Charles,

 

usually there is much more data in context to endevor than stored at the endevor database (depending to the site for sure).
I prefer to write exit 02 and exit 03 in Assembler cause of performance. COBOL is possible too but needs a stub to be linked as the entry point to the exit. All about the stub you can find at the exit giude.

My assembler Exits connecting to DB2 by CAF and the SQL is static. To keep it small and simple there are no subroutines. Depending on the requirements each exit needs about 1500 to 2500 lines of code. That is not to much.

 

Pitfalls? ... You have to be aware about the addressing of the endevor control blocks!
EN$TRXIT helps a lot for testing.

 

Does that help?

 

Regards,

Willi

[Anon Anon]

Hi Willi,

 

Yes it does help, thanks.  I tend to prefer Cobol when doing "complicated"

stuff such as accessing DB2, for ease of maintenance, but I understand the

performance point.  I'll probably end up with a hybrid solution, with Exit

02 in assembler and the CCID / DB2 API written in Cobol.  This has the

advantage that I can develop the API in isolation from Exit 02, plus I can

reuse it outside the exit if other things need to get the same information

/ perform the same functions.

 

Do you call CAF each time you invoke Exit 02 then (going through the

sequence of Connect to the subsystem, Open the DB2 Plan, Execute the

static SQL, Close the Plan with Commit, Disconnect from DB2)?

 

Do your exits create LE environments?

 

It's nice to know that other sites have used the "hold the CCID's in a DB2

table" approach.

 

 

Hope you don't mind the follow-up questions!

 

Charles

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number

741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Melva Jackson]

Did you ever write this routine, if so did you get it to work?

[Joseph Walther]

Good timing, Melva, on bringing up this topic again.

There are some new methods that can be considered along with the older methods for validating and managing the CCID. 

New methods involve Restful API calls in either direction- inbound to Endevor or outbound from Endevor. A couple of examples: 

• Endevor making an API call to a Service Management product (like Service-Now) to validate a CCID
• A Service Management product making a call to Endevor to create a package (named with an embedded CCID) 

For a recent example, see endevor-package-integration-with-servicenow

In the near future, look for example tools for outgoing API calls from Endevor here - 

https://github.com/BroadcomMFD/broadcom-product-scripts/tree/main/endevor/Field-Developed-Programs