Migrating programs to DBCTL

Considerations for migrating programs to DBCTL include using your existing local DL/I programs with DBCTL, and changing CICS® shared data base programs and "native" IMS™ batch jobs to run as BMPs.

Migrating a DL/I program to a DBCTL program

Your existing CICS application programs should not require any changes in order to run in the DBCTL environment.

However, you must define the names of all DMBs to be owned by DBCTL to DBCTL using system definition DATABASE statements. Make sure that you have defined the names of all PSBs to be used by application programs when accessing DBCTL databases using system definition APPLCTN statements (which are equivalent to DFHDLPSB in local DL/I). All DMBs to be owned by a given PSB must be owned by the same DBCTL. See the IMS Application Programming: Design Guide for further guidance on defining PSBs.

Your applications may receive some different abend codes. You may also get a message that DL/I is not available. This may occur because DBCTL can be disconnected dynamically from CICS, using the CDBC transaction, and because, unlike local DL/I, a failure in DBCTL should not cause CICS to fail, but merely leaves it without DL/I services. New abend codes are summarized in Summary of DBCTL abends and return codes.

An application program that updates DL/I databases owned by DBCTL and has activated an exit to use HANDLE ABENDs, should terminate the abend exit routine with an ABEND request.

We recommend that programs that have read-only access to the database, and an abend exit is active, should not attempt to reschedule a PSB as part of abend processing. This is because if the high order bit of the DBCTL return code (PAPLRETC) is set on, the DBCTL thread has been withdrawn from use by the transaction and any further DBCTL request is abended with a code of AEY9. The only exception to this is if the abending request was a schedule, this is because the thread is not obtained until the schedule completes successfully.

Migrating CICS shared database batch jobs to BMPs

With CICS Transaction Server for z/OS®, Version 3 Release 1, you must migrate any batch jobs that currently use the CICS shared database facility to BMPs so that they communicate directly with the DBCTL address space. BMPs perform batch processing and are started with job control language (JCL) like programs in a batch environment. The JCL for this is in the IMS procedure IMSBATCH. (For further guidance on IMSBATCH, see the IMS System Definition Reference manual manual or IMS Installation Volume 2: System Definition and Tailoring.) Migrating these batch jobs gives you:

Automatic backout, which you will already be using for your shared database programs, also applies to BMPs.

With BMPs, the PCB always includes an I/O PCB. If you have specified CMPAT=Y in the JCL to execute your CICS shared database job, need not change any source code in your application. If you have specified CMPAT=N, change your code to allow for the addition of an I/O PCB. For example, in COBOL, you do this by changing the ENTRY statement in the PROCEDURE division to include the I/O PCB. For guidance on doing this, in COBOL, PL/I and assembler language, see the IMS Application Programming: EXEC DLI Commands manual or the IMS Application Programming: DL/I Calls manual manuals.

Migrating native IMS batch jobs to BMPs

You are advised to migrate "native" IMS batch jobs to BMPs that use DBCTL. This will give you:

General design considerations for BMPs

Your applications must take checkpoints and must be restartable from the last checkpoint (also known as checkpoint restart). This is particularly important for batch programs migrated to BMPs. A disconnection request cannot complete until a BMP checkpoint occurs if a CICS thread is waiting for a lock held by a BMP.

Design and code your batch programs to be restartable from checkpoints, even if you have no immediate intention of running them as BMPs. This is because it is simpler to design batch programs with checkpoint restart than to introduce it to existing programs if you do decide to migrate them later.

The following is a summary of what to consider when designing BMPs and applications to run in a DBCTL environment:

Related concepts
Application programming for DBCTL
Overview of application programming for DBCTL
Programming languages and environments for DL/I
Additional facilities available with DBCTL
Summary of DBCTL abends and return codes
[[ Contents Previous Page | Next Page Index ]]