Coolgen-CASE Tool

25) Coolgen Interview Questions - Set 05

Talk about the Batch model and packaging etc in COOLGEN, CA-GEN

· Choose model and appropriate batch business system (E.G. modelname).

· Add Procedure/Procedure step and create as a type = BATCH

· Packaging as Batch, give the job name

· Use host encyclopedia load module packaging. Give Load module name as a program that is used in a batch JCL

· Build the JCL and make sure you have allocated TIRIOVF dataset.

· Decide Check pointing logic if required

· Check pointing logic is required if the job has to be made as restart-able without any manual intervention.

· Time based check pointing or record based check pointing

· Time base check pointing means take a commit point ofter predefined interval and save the key of the record processed.

· Record based check pointing means take a commit point after certain number of records and save the key of the record processed.

24) GEN, CA GEN, CoolGen client procedure related best practice

The control to the client procedure comes from the following ways:

1. From previous client

2. From the server

3. From the same client (for displaying an error)

4. From the next client (on success or failure)

To know where the control comes is quite tricky.

Best Practice:

The usual way of communicating from client to client OR client to server is through the IEF variable command. But as explained above this alone is not sufficient to signify where the control comes from. Hence the following convention is followed:

· Two variables curr_command and prev_command are maintained. curr_command is assigned to prev_command, command is assigned to curr_command in the beginning of the client procedure.

· Command is set to "return" whenever the control transfers from the server

· The convention is as follows:

Client procedure:

...

/* Execute client validations here */

CASE of Command

CASE…

…

Otherwise…

End CASE

/* Execute client code after window has been displayed */

CASE of curr_command

CASE…

…

Otherwise…

End CASE

/* Execute client code after return from server */

CASE of prev_command

CASE return

/* Code to be added return from server */

…

CASE…

…

Otherwise…

End CASE

Note: Client validations can also be executed as events.

23) GEN, CA GEN, CoolGen client procedure related best practice

Exit states cannot be set across server procedures. This becomes a major impediment in the following cases:

· Server wants to return an error message to client by means of an exit state

Note: COOL:Gen allows exit states to be passed across procedures. But this practice is not valid for earlier versions

Best Practice:

Every client and server procedure does the following:

· In the beginning USE an init action block

· Just before exit USE an exit action block

The client procedure looks like:

Import Views:

Export Views:

Local Views:

USE client_init_action_block ...

...

USE client_exit_action_block...

The server procedure looks like:

Import Views:

Export Views:

Local Views:

USE server_init_action_block ...

...

USE server_exit_action_block...

The client_init_action_block contains code as follows:

CASE of exit_state_code

CASE 0

Set exit_state as exit_state_a

CASE 1

Set exit_state as exit_state_b

...

END CASE

The client_exit_action_block contains code as follows:

Move all import views to export views

The server_init_action_block contains code as follows:

Move all import views to export views

The server_exit_action_block contains code as follows:

CASE of exit_state

CASE exit_state_a

Set exit_state_code to 0

CASE exit_state_b

Set exit_state_code to 1

...

END CASE

Exit state is return_to_client

Note: return_to_client is the exit state to transfer control to the client from the server. If a rollback is to be done, then exit state is set to return_to_client_rb which has the rollback attached to it.

22) GEN, CA GEN, CoolGen server procedure related best practice

The Read action block fails to use the index even though the predicates in normal COBOL programs would have made use of the index.

Best Practice:

In spite of having separate Read action blocks for each read, the entity views in the RAB should contain the required attributes. If attributes other than those in index are to be accessed then, it is better to have separate entity views.

For eg: Assume table T1 has index I1, I2, I3 respectively and the attributes in I1, I2 and I3 are A1, A2 and A3 respectively. Then a Read of the following type will be an Index read instead of an Index Only Read.:

Entity View: Entity T1 A1,

A2,

...

Read T1 where A1 = local view lcl_a1_value

The better way of coding this:

Entity View: Entity ent1_T1 A1,

Entity ent2_T1 A2,

Entity ent3_T1 A3.

...

Read ent_T1 where A1 = local view lcl_a1_value

21) GEN, CA GEN, CoolGen server procedure related best practice

In the server procedure sometimes the Read generates an extra predicate (which has not been coded as part of the read statement). Hence the index is not used even if one exists.

Best Practice:

Each Read is coded in open action block each. They are often called the Read Action Blocks (RAB). COOL:Gen generates the extra predicate whenever it is not sure whether the read is for an update or just a read only.

20) GEN, CA GEN, CoolGen server procedure related best practice

Use of Read Each for a batch program with restart logic, opens and closes the cursor repeatedly causing performance degradation

Best Practice:

Instead of invoking the program repeatedly, it is replaced by the following logic:

...

Set commit_count to 0

Set commit_freq to 10000

Read Each table (with cursor hold)

...

commit_count = commit_count + 1

If commit_count = commit_freq Then

USE ext_commit_action_block

...

End Read Each

...

Note: ext_commit_action_block is an external action block, which contains only SQL statement: COMMIT.

19) GEN, CA GEN, CoolGen testing related best practice

During stress testing, very active tables and its associated children undergo deadlocks and timeouts. (Note: dsg_sequence_no is the primary index which has running sequence numbers as its value. The primary index was on the descending sequence to avoid a sort when getting the maximum dsg_sequence_no)

Best Practice:

The following three design changes to the application:

1. Create a primary index with dsg_sequence_no in ascending sequence

2. Define the subpage parameter as 1 rather than 16

3. Introduce a dummy column at the end of the table as X(250). Drop the primary index and recreate it with dsg_sequence_no and the dummy column.

The advantage of these suggestions are:

1. Ascending sequence will avoid unnecessary reordering of the index whenever new records are created.

2. Redefinition of Subpage to 1 will avoid subpage splitting altogether during creation

3. Making the key size to be approximately 250 bytes ensures only less number of entries are available in each page. This will lessen the number of deadlocks/timeouts. Further all the 3 changes require no change to the application

18) GEN, CA GEN, Coolgen and design best practice

Use of a running sequence number as the primary key instead of a logical key gives rise to the following issues:

· For new creations the access is always towards the end of the table

· Contention in an multi-user environment for accessing the last sequence number

Best Practice:

1. One solution is to a common table, which contains only two attributes: table name and last sequence number. Being a small table, this should resolve the contention problem to a great extent.

2. Instead of creating the primary key ASIS, the key is inverted and created. This will resolve the creation of new records towards the end of the table.

For eg:

If the primary key is a 6-digit number, the new records are created as follows:

· 100000

· 200000

· ...

· 900000

· 010000

· 110000

· 210000

· ...

Note: One could also use a random number generator to create unique primary key. See a post to create a random number using program..

17) GEN, CA GEN data modelling best practice

Denormalization of tables whenever the access equals or exceeds three levels but can be avoided by having additional attributes.

Eg: To get attrib1 table T1 and attrib3 from table T3 the normal sequence would be:

Read T1 Where A1 = local view lcl_a1

When Successful

Read T2 Where current view and

A2 = local view lcl_a2

When Successful

Read T3 Where current view and

A3 = local view lcl_a3

When Successful

...

End Read

Instead by storing the extra attrib1 attribute in Table T3, these three reads can be avoided.

Note: There is of course the need to update this field as when the field is updated in table T1.

16) GEN, CA GEN, CoolGEN batch job related another best practice

The batch jobs of COOL:Gen even though they execute successfully, they return with a return code of 100. For unsuccessful executions, it displays the return code as given by the TP monitor.

Best Practice:

Instead of invoking the batch program as given below:

...

//SYSTSIN DD *

DSN SYSTEM(DB2T)

RUN PROGRAM(PROGA) PLAN(PROGA)

END

Execute it as follows:

//SYSPROC DD DSN=SYS2.COOLGEN.CLIST,DISP=SHR

...

//SYSTSIN DD *

EXECDSN PROGA DB2T

The contents of EXECDSN will look like:

/* Rexx */

Parse Upper Arg programname db2system .

"NEWSTACK"

Queue "RUN PROGRAM("programname") PLAN("programname")"

Queue "END"

"DSN SYSTEM("db2system")"

Coolgenrc = Rc

"DELSTACK"

If Coolgenrc = 100 Then

Exit 0

Exit Coolgenrc

15) GEN, CA GEN, CoolGEN batch job related best practice

GEN, CA GEN, CoolGEN batch job related best practice

If a batch step due to its logic doesn’t write even a single record to the output file created in the same step, and a subsequent step has a read from this file. The read fails with an abend.

Best Practice:

The abend occurs because the EOF marker is not set if the file is not opened and closed for output. A dummy step is introduced in between these 2 steps, which will write the EOF marker if the file is empty. This is achieved as follows:

…

//STEP01 PGM=IKJEFT01

//FILE01 DD DSN=SBBT02.NEW.FILE,DISP=(,CATLG),…

…

//SYSTSIN DD *

EXECDSN progname db2system

//STEP03 PGM=IKJEFT01

//FILE01 DD DSN=SBBT02.NEW.FILE,DISP=SHR

…

//SYSTSIN DD *

EXECDSN progname db2system

Instead add the following step in between the two steps:

…

//STEP01 PGM=IKJEFT01

//FILE01 DD DSN=SBBT02.NEW.FILE,DISP=(,CATLG),…

…

//SYSTSIN DD *

EXECDSN progname db2system

//STEP02 PGM=IKJEFT01

//SYSPROC DD DSN=SYS2.COOLGEN.CLIST,DISP=SHR

//FILE01 DD DSN=SBBT02.NEW.FILE,DISP=SHR

//SYSTSIN DD *

EMPTYFLE

//STEP03 PGM=IKJEFT01

//FILE01 DD DSN=SBBT02.NEW.FILE,DISP=SHR

…

//SYSTSIN DD *

EXECDSN progname db2system

The logic in the REXX program would contain logic like this:

/* Rexx */

“NEWSTACK”

“EXECIO * DISKR FILE01 (FINIS”

Queue “”

“EXECIO * DISKW FILE01 (FINIS”

“DELSTACK”

Exit

14) CA GEN, CoolGEN and testing best practice

CA GEN, COOLGEN and testing best practice During testing normally there is a need to run monthly jobs, yearly jobs and jobs tied to some specific dates. This kind of testing is called date simulation. Best Practice: The date simulation can be brought about in two different ways: 1. For the client the system date can be set to the required date in the individual clients 2. For the server, the date exit routine TIRDATC/TIRDATX can be written in assembly to accept the date from a file. The input file can be updated to the required date before executing the job.

13) Gen, CA-GEN, COOLGEN and DB2 related issues

GEN and DB2 Related issues The SQL generated by CA GEN, COOL:Gen is not always the best and in most cases there is an need for the following: • Creation of new index • Rewrite the READ action block to access existing indexes • Change table/index parameters • Need for partitioned tables Best Practice: Once the servers are ready for execution, the bind for the plans are done with EXPLAIN option. Each and every SQL is scanned for the following: • Does it result in a join, if so can it be avoided • Does it use an existing index, if not how to influence the SQL to make use of it • Would creation of an index improve the performance • Change of parameters (for eg: for batch jobs executing without any overlap, the lock can be escalated to table level and combined with appropriate acquire and release parameters in the bind step the performance can be improved).

12) What are the different CA Gen, aka COOLGEN services when in component based environment ?

Below is just an example. Your client side may have different architecture. Using these component services a transaction is built. And the whole development code is isolated from each other and have a specific purpose. Example - D service will have all the reads, create, update, delete statements on entities. So during maintenance it needs to be touched only if affected database is changed.

Types -

H Service - Test Harness. To test the transaction

I Service - Interface. It is a Public Operation – the interface to the service

M Service - Private Operation Manager – the director or traffic cop

C Service - Contains isolated logic. e.g. editing of imports or doing calculations, client side

T Service - Translator: Transient view to Persistent view

D Service - Data Access – goes against the database

P Service - Translator: Persistent view to Transient view

X Service - External Wrapper – an EAB that interfaces with an existing program

S Service - Error Processor – translates Exit States to Return Codes

11) Syllabus topic # 3 : Modifying Existing Objects

Detailed study items on syllabus topic # 3 : Modifying existing objects

What information to be provided for entities?

Name

Description

At least one attribute

Primary identifier

Occurrences

TD physical name

What information to be provided for relationships?

Relationship properties

Source properties

Target properties

What information to be provided for attributes?

Name

Domain

Optionality

Description

TD name

Attributes may have permitted values

Attributes may be derived.

10) Syllabus topic # 2 : Modeling New Objects

Detailed study items on syllabus topic # 2 : Modeling New Objects

Modeling new objects
Creating new model
Model name
Local name
Settings multiple or single add
Consistency check level settings
TD name options
Data model tools
Adding subject areas
Adding Entities
Adding Relationships
Adding Attributes

09) Syllabus topic # 1: Gen modeling overview

Detailed study items on syllabus topic # 1:

Gen modeling overview

What are the different names-
Attribute Names
Business names
TD names
Element name
Entity/table
Identifier/primary key and index
References, online help
Logical model
Physical Model
Why model is important

08) Syllabus - Data Modelling using Cool:Gen , CA Gen

Here is the very high level syllabus if you are interested in learning how to do data modeling. Lets look at them in details in next posts....

1- Gen modeling Overview
2- Modeling new objects
3- Modifying existing objects
4- Other Data analysis and modeling options
5- Consistency check
6- Plotting
7- Reports

06) Cool:Gen Client Server mode Features

Cool:Gen Client Server mode Features

Separate client procedures for data capture and validation

Separate server procedure for database handling

Screen/window based

Flows to be maintained between client and server for every Database action

Exceptions in database actions to be handled by means of Return Codes

Cooperative packaging to be done

Client with local installation

Server with remote installation

Workstation generation for client and server

Host installation for Server using Implementation Tool Set

Complete debugging possible for client

Direct debugging not possible for server (through CICS)

Need for Client manager, Communication bridge and Server manager

Design requirements :

1. Separate Client and Server Procedure steps.

2. Each Server Procedure Step has to be packaged (Cooperative Packaging) as a separate load module.

Resource Requirements :

1. Every client workstation has a IEF Client Manager.

2. IEF COMMUNICATIONS BRIDGE is needed for each workstation or on a communications server on the network.

3. IEF SERVER MANAGER installed on the host server machine

05) Cool:Gen Batch mode Features

3) Cool:Gen Batch mode Features

No separate client and server procedures
No screen/window
For Mainframe applications
No flows/links allowed other than involute transfer
Procedures to be defined as ‘NO DISPLAY’
Embedded database action statements
May involve file handling using External Action Blocks
May need special Commit/Restart handling
Batch Packaging needs to be done
Host construction
Complete debugging facility during execution
Use of JCL for non-trace execution

Introduction