idms idd components in ca endevor - minerva softcare … · idms idd components in endevor 4...

IDMS IDD components in CA Endevor®

IKAN Elias

2IDMS IDD components in Endevor

IntroductionThe CA Endevor Software Change Manager is a leading SCM tool in the mainframe arena and has been

implemented at over a thousand customer sites. It brings all mainframe development eff orts under

control with the use of comprehensive automated transformation processes, module relationship man-

agement capabilities, parallel development management support and powerful release automation

features.

The Endevor functionality expects software components to be a member in a Pds or a sequential fi le.

This means that CA IDMS IDD components cannot be handled by Endevor itself natively because those

components are stored in a database that cannot be read by Endevor.

To extent the Endevor implementation to IDMS IDD components is a labour intensive and complex

process that needs a lot of knowhow.

IKAN has developed a set of tools and templates that help the user to bring the CA IDMS IDD compo-

nents under full control of Endevor and full Endevor functionality without any exception.

By using the IKAN Elias solution, implementation time can be shortened and Endevor will be set up in

a perfect way.

IKAN Elias is a toolkit which will be applied by experts (in both IDMS and Endevor) who will customize

the implementation to the needs of the organization.

Using the IKAN Elias solution will shorten the implementation time needed with approximately 70%.

Besides CA IDMS IDD components support, the tool set comes with utilities that allow to run the ship-

ment process under control of the Endevor alternate id and running Jcl during ship to activate a change

in the Endevor destination (like Db2 bind, new copies etcetera).


TerminologyIn this document we describe several CA owned software products. We use the abbreviated from of

these products.

● “CA IDMS DB” is called “IDMS”

● “CA IDMS IDD” is called “IDD”

● “CA IDMS Endevor/DB” is called “Endevor/DB”

● “CA Software Change Manager” is called “Endevor”

● “Target IDD” is an IDD into which a migration will add/update IDD components

● “Source IDD” is an IDD from where a migration will extract sources and information

The Elias solution is the in-house development solution of IKAN Solutions Nederland B.V.

PurposeThis document will describe the IKAN Elias solution that will enable an IDD user to take full advantage

of the Endevor Software Change Manager.

● Version Control

● Confi guration Management

● Process Management

● Package Processing

● Parallel Development

● Shipping

Requirements● CA IDMS DB/DC software license

● CA IDMS Endevor/DB software license

● CA Endevor Software Change Manager software license

● IKAN Elias user license


BackgroundEndevor/DB keeps track of all change events regarding IDD components. This log of change events is

the basis for the migration strategy of Endevor/Db from one IDD (the source IDD) to another IDD (the

target IDD, e.g. from Development IDD to the Test IDD).

It has 4 main functionalities regarding the migration of IDD components from one IDD to another.

● Selection

● Verifi cation

● Delivery

● Confi rmation

SelectionThe selection process creates a list of IDD components that should be migrated and is primarily based

on selection of components that are connected to each other in a change set. Such a change set is

identifi ed by a Ccid (Change Control Identifi er). The components are connected to such a change set

automatically during a change event if Endevor/DB knows to what change set the entity belongs (pre-

authorization) or components are added to the change set manually.

Part of the selection process contains out of sync´ checks which means that it will report on child-par-

ent relations when the child has changed but the parent has not, while normally´ the parent should

have been changed/regenerated. E.g. a record (the child) is used by a dialog and map (parents) and it

has been changed, but the using dialog and map did not change. This will be reported by the selection

process as out of sync .

Verifi cationThe list of IDD components from the selection process is compared with the IDD into which one wants

to migrate (the target IDD). Some components are not-IDD owned .Such an entity cannot be changed

in the IDD because the IDD rules prevent it.

E.g. a record in the target IDD is used by a Map. In this specifi c situation the Record has the status of

not-IDD owned´ and cannot be changed in the target IDD. The only way to migrate such a Record to the

target IDD is to delete the owning Map before the Record is migrated into the target IDD. The verifi ca-

tion process will report such situations, forcing the migrator to include the Map as well in the entity list.

If not, the migration will fail because of this IDD rule. If the Map is included in the list then the Delivery

process will make sure that the Map is removed in the target IDD before the Record is added/modifi ed

and then the Map will be added again.


DeliveryThe delivery process will process the list of migrating IDD components and will export (Punch) all the

IDD components from the list, creating several sequential fi les that contain the exported sources. These

exported sources are imported (added) into the target IDD after solving the not-IDD owned´ issues.

The export of the sources is part1. The import is part2.

Confi rmationAfter adding the sources into the target IDD, the confi rmation process will identify all the changed

components in the target IDD and will set indicators in the Endevor/DB change event logs of the target

IDD which components were migrated in (compared to modifi ed directly) and from which sending IDD.

The same is valid for the sending IDD in the sense that the change event log of the sending IDD will set

indicators in its Endevor/DB change event log for the components that were migrated out to the target

IDD.

WeaknessesEndevor/Db can be used as a stand-alone tool to migrate IDD components from a source IDD to a target

IDD but that solution has the following weaknesses:

1. Migration is manual

2. No forcing out of sync´ and not-IDD owned´ situations

3. Migration ´in between´ results can be changed (no auditing)

4. No version management

5. No load to source synchronization

6. No approval Processing

7. No backout functionality

8. No shipment capabilities

9. Diff erent software tools to be used to deploy to production (IDD entities and non-IDD like Cobol)

e.g. Endevor/Db and Endevor

10. No confi guration management

11. No naming convention enforcement

11. No implementation capabilities (during ship)


IKAN Elias SolutionBy using the IKAN Elias solution the Endevor customer can extent his existing Endevor implementation

to IDD components and he can take full advantage of all its features.

All IDMS entity types are fully and without exception processed and controlled by Endevor.

The basic Endevor features are extended by the IKAN Elias solution like running Package shipment

under control of the Endevor alternate id and the possibility to add implementation Jcl to the Shipment

Jcl to do Db2 binds, Cics and IDMS/Dc new copies, IDD updates etcetera.

The IKAN Elias solution implementation is fast and easy and only some customizing is necessary.

A number of the remarks mentioned in the weaknesses´ will be solved by running the mentioned proc-

esses (selection, verifi cation, delivery and confi rmation) in an Endevor processor which solution is part

of the IKAN supplied tool set. The other weaknesses mentioned before(shipment, naming convention

and implementation) will be solved by using the IKAN supplied tool set outside of an Endevor proces-

sor (see later in this document).

By running the Endevor/DB utilities inside an Endevor processor we are able to solve the bulleted is-

sues below :

bb Migration is manual

✓ By bringing the IDD migration under control of Endevor the migration process is

automated.

bb No forcing out of sync´ and not-IDD owned´ situations

✓ The Endevor/DB utilities do not prevent a out of sync´ and not-IDD owned´

migration. By running these utilities in a processor, the process has been standardized

and rules can be forced.

bb Migration ´in between´ results can be changed (no auditing)

✓ Because all the IDD sources are stored in the Endevor controlled libraries, nobody is

able to change the IDD components between an export and a successive import.

bb No version management

✓ Because all the IDD sources are stored in Endevor and versioning is done automatically

by Endevor.


DEV TEST ACCT PROD

DEVIDD TESTIDD ACCTIDD PRODIDD

bb No load to source synchronization

✓ The IDD components are processed by Endevor processsors. Therefor the output load

members can be footprinted.

bb Diff erent software tools to be used to deploy to production (IDD entities and non-IDD

like Cobol) e.g. Endevor/Db and Endevor

✓ Endevor is the only tool that will deploy software components to production.

bb No confi guration management

✓ The IDD components can be registered in the Endevor Xref database

bb No naming convention enforcement

✓ The use of a before action exit allows the enforcement of naming conventions.

Life CycleThe Life Cycle of the IDD components can be set up anyway you like (as in the standard Endevor setup).

Every stage in the Endevor life cycle should match one (or more) corresponding IDD s. See Example

below. In this example the Developer develops his code in the DEVIDD. When done he generates the

appropriate Endevor type to start the addition of the IDD components into Endevor.


In the example above we defi ne an Endevor Life Cycle with four stages (Dev, Test, Acct and Prod).

Each stage corresponds to one IDD (Dev-DevIDD, Test-TestIDD, Acct-AcctIDD and Prod-ProdIDD). The

(IDD)developer develops his/her code in the DevIDD. The type Entlist copies the sources from the

DevIDD to the Dev stage. During the Move action from the Dev stage to the Test stage the sources of

the Endevor IDD elements are added into the TestIDD. During the Move action from Test to Acct and

from Acct to Prod the corresponding IDD s are updated.

Endevor Generate processorWithin Endevor a type will be defi ned that will run the Endevor/Db utilities (e.g. type Entlist) to execute

the selection, verifi cation and delivery processes.

The Generate processor is used during Generate/Add action in the entry stage of Endevor (stage Dev)

and is part of the IKAN tool set.

The processor will make sure that the rules regarding the out-of-sync conditions are forced upon the

user. The user decides which rules should be forced. If a rule has not been met, the IKAN tool set will

raise the failed fl ag in Endevor.

The out-of-sync rules can be set easily within in one of the components of the IKAN tool set by set-

ting true-false switches. By default we check Record-Dialogs, Record-Maps, Record-Adsa Application,

Record-Schema, Record-Subschema and Process-Dialog.

If the selection process in the source IDD has been successful then the verifi cation process will be

started. The Endevor/Db software will create a report if there are migration stoppers. A migration stop-

per is an IDD entity that should be migrated to a target IDD, but has the status of not-IDD-owned´ in the

target IDD the owning entity is not part of the migration. To make sure that the verifi cation process was

successful, the report must be interpreted automatically. This is done by one of the programs from the

IKAN solution set. If it encounters migration stoppers, it will raise the failed fl ag in Endevor.

If the verifi cation process is successful then the part1 of the delivery process will be started. Basically

this is a punch of all the selected IDD sources from the source IDD to a sequential fi le. The output from

the punch commands is processed to create Endevor Add actions to add each individual IDD entity as

an element with its source into Endevor (stage Dev). This will solve the issue of Version Management. In

the case that there are Adso Dialogs and/or Adsa Applications an Adso report is created per Dialog/Ap-

plication and those reports are added as elements (of type Dialog/Adsa).

During the Add of the IDD elements, each individual element will be processed by the processor of its

corresponding type. In these processors we are able to footprint the types that create a load module.

We also scan certain sources to pick up IDD relations. These relations are stored in the Component

List.

This is all taken care of by the IKAN tool set.


Part of the Add/Generate process is to feed the information on the IDD components to the Endevor Xref

database through the usage of the Endevor utility Conrele. The input for Conrele is delivered by the

IKAN tool set. This will allow Endevor to do confi guration management on IDD components.

During the Add of the IDD components it is possible to force naming standards by using the before ac-

tion exit (exit 2) that is also part of the IKAN tool set.

The use of this processor solves the following issues:

bb Migration was manual

✓ Now fully automated

bb No forcing of out of sync´ and not-IDD owned´ situations

✓ Processor forces rules

bb Migration ´in between´ results can be changed (no auditing)

✓ Sources are now fully controlled by Endevor, no modifi cation possible.


✓ Now versioned by Endevor

bb No load to source synchronization

✓ Loads have been footprinted


✓ IDD components information is added to Xref database

bb No naming convention enforcement

✓ Now forced by before action exit


Endevor Move processorThe IKAN tool set comes with a ready to go´ Move processor. The Move processor is used during Move

actions of the type Entlist and will take care of migrations into the target IDD that corresponds with the

Endevor target stage. The fi rst process is again the verifi cation process to check the not-IDD-owned´

status of the components in the target IDD.

The second part is the delivery. In this case it is the delivery process part2. In part1 of the delivery (see

Generate processor) we exported the sources and added them into Endevor. So in part2 we retrieve

the sources from Endevor, write them to the necessary fi les and then we run the corresponding IDMS

utility to add them into the target IDD. The using components that cause a non-IDD-owned´ status are

fi rst removed from the target IDD, after which the IDD components can be added. Last step is to add

the using components again.

If the import is successful the confi rmation process is executed to update the change event log in both

the ´from IDD´ and the target IDD .

The use of this processor solves the following issues:

bb No forcing of out of sync´ and not-IDD owned´ situations

✓ Rules are forced in processor

bb Diff erent software tools to be used to deploy to production

✓ Endevor/Db does run as part of Endevor processor and not standalone, one look and feel.


Endevor TypesIDD Records and Adso Processes may have names in the IDD with a length of 32 characters. This kind of

naming is not suited for Endevor unless one wants to use the Endevor Workbench.

Fortunately a lot of IDMS customers do not use the 32-character naming or if they do, they use a highly

standardized naming convention, which allows us to reduce the name of the Endevor Elements to a

length of 10 characters which can be handled by Endevor by default.

E.g. a lot of IDMS customers use the name of an Adso Process including the name of the Dialog to which

they belong, followed by the literals ´PREMAP´ in case of a premap Process, ´RESPONSE´ in case of a

response Process, ´ENTER´ in case of a enter Process or the name of the Pfkey (PF01, PF02 etc.) that

triggers the Response Process. The names can be reduced to a length of 10 characters by combining the

Dialog name and a two-character string that identifi es the Response Process, e.g. <dialog>00 identifi es

the Enter Process, <dialog>PM identifi es the Premap Process, <dialog>03 identifi es the Pf3 Process

etcetera.

The renaming of the IDD components are taking care of by a modifi able rexx program which is part of

the IKAN tool set.

The use of these types solves the following issues:


✓ Now versioned by Endevor

Endevor Package ProcessingBecause all IDD components are an element within Endevor, we are able to solve the issue of Package

Processing on IDD components. This enables the Component Validation feature, the Approval feature,

the Backout feature and the Ship feature.

Component ValidationIn the Generate processor we added information of all the IDD components processed to the Xref da-

tabase. During Component Validation the default Endevor Cast operation will make sure that the list of

IDD components are present in the package.

The usage of exit7 programs enable component validation on used IDD components.

In this scenario we extent the default Endevor Component Validation (copybooks/macro versus Cobol/

Assembler) to IDD components that are used by Cobol/Assembler programs.


ApprovalBecause all IDD components are Endevor Elements, we use the standard Approval mechanism.

BackoutBecause all IDD components are Endevor Elements, we use the standard Backout mechanism.

ShipBecause all IDD components are Endevor Elements, we use the standard Ship mechanism. Special set-

up of the Move processor(s) will allow to ship IDD components as well to update an IDD in the Ship

destination.

The IKAN tool set comes with several utilities that enable the Ship functionality to be run under control

of the Endevor alternate id and it allows to include implementation Jcl in the shipment, not only for

IDMS related issues, but also for Db2, Cics etc.

The use of the IKAN solution set solves the following issues:

bb No shipment capabilities

✓ Ship of IDD components is now automated

bb No implementation capabilities

✓ IDD components can be implemented at target destination

bb No backout functionality

✓ IDD components can be backed out now

bb No approval Processing

✓ IDD components are now subject to Approval



✓ The Xref database allows Xref reports (Acmq) on IDD components

bb No component validation

✓ Package exit processing allows to implement component validation on IDD components

DeliverablesOur solution comes with a number of deliverables:

An Ispf application that helps a user to defi ne a CCID

(in both Endevor/DB and the Endevor validation dataset)

An Ispf application that helps the customers to defi ne IDD components in an easy way

when running in full pre-authorization mode using Endevor/Db

Ready to go Processors for the types Entlist that support processing for all IDD compo-

nents (Schema, Subschema, Record, Map, Table, Dialog, Adsa Application, File, Modules)

Ready to go specifi c Processors for Map, Table, Dialog, Adsa Application and Subschema

Ready to go specifi c Processors for Record, File, Modules and Adso Processes that enable

the usage of the Ispf editor for IDD components

A number of Rexx programs to be used in Processors and Shipment functionality

Customizable before action exit

Package Processing exit if component validation on IDD components is required

Utilities that enable the Package Shipment to run under the Endevor alternate id

Utilities for implementing changes on a target Lpar after Shipment


IKAN Solutions Nederland B.V.Valutaboulevard 153825 BS Amersfoort

Tel +31 (0) 33 462 3027

TrademarksThe CA product names referenced herein are either registered trademarks or trademarks of CA, Inc. or one of its subsidiaries. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.

idms idd components in ca endevor - minerva softcare … · idms idd components in endevor 4...

Documents