Transférez facilement vos fichiers ISAM et RELATIFS vers les bases de données ! Et bénéficiez de la puissance des bases de données pour les exploiter ! Relational Language & Database Technology
Recherche :
  Accueil | Développements | Administration | Réseaux | Formations | Cobol Access Plus | Contact 
  English French
Nouveau : le forum est ouvert !

 

 News
Technote Jan. 2004 
Technote Avril 2003
Technote Février 2000
Technote Avril 1999

Cobol Access Plus
Pourquoi Cobol Access Plus ?
Comment ça marche ?
Architecture Client/Server
Environnements Supportés
TELECHARGEMENT GRATUIT
Demande De Documentation
FAQ
Nos distributeurs

 Support Technique
Oracle
Informix
Sybase
SQL Server
DB2
Ingres

 

Technote April 1999
COBOL Access +
Version 4
new features

 


Support of 'OPEN OUTPUT' statement

Capacity to create dynamically a new table into existing DID

Support of ‘generic START‘, with limitation of cursor size

Support of new RDBMS

Validation of ORACLE 8 environment

Possibility to fully identify connected remote clients, and manage them


 

Support of 'OPEN OUTPUT' Cobol statement :

 

With previous releases of Cobol Access +, the OPEN OUTPUT statement was only accepted if the concerned table was empty, to assume transparency , for programs initializing a set of files ( during application installation, by example).

If a table was not empty, an error status was returned to Cobol Program.

A lot of Database Engines proposing now to accept SQL statement like 'Truncate Table', and execution time being reasonable, Cobol Access + is now able to support this kind of request, from Cobol client.

Of course, the file must not be in use by another user, otherwise the calling program will receive a status rejecting the OPEN OUTPUT ( like in pure Cobol environment, using ISAM files ).

The execution result of an OPEN OUTPUT, now, is similar to Cobol/Classic files : the datafile is cleared. But the database table must exist into DID : The structure of table is not created into database schema, with sole execution of an OPEN OUTPUT ! See following section, about dynamic table creation.

All supported RDBMS have this functionality, except INFORMIX:

To be transparent for applications, this functionality is emulated under INFORMIX, by execution of statement : 'DELETE FROM table WHERE 1=1'.

That works fine, but if you have a large table ( with a large number of rows ), this I-O can be very expensive !

 


     

Capability of dynamic table creation into existing (and running) DID:

 

With version 4 of Cobol Access +, a Cobol program ( running on a client station or on server itself ), can invoke Cobol Access + to :

 Add a new table into a running DID

 Create database structure for this new table

 Work immediately on this new table.

All these operations are executed without any manual operation on DID service : It's not necessary to stop the service, upgrade manually the DID with modified version, restart the service, and so on.

The sole restriction is obligation to be in exclusive mode on the DID : If somebody else, or the requesting program, has at least one table opened on the concerned DID, Cobol Access + rejects the request of table creation : All other files must be closed by program itself, and other programs can be connected on the DID, but without any active file.

 

The dynamic creation of table is a Cobol Access + API, like commit, rollback, etc…

Similarly to other API calls, you must declare in Working Storage area, a buffer containing :

01 BAB-DYNA.

02 BAB.

03 BAB-NAME PIC X(16).

03 BAB-PASSWD PIC X(16).

03 BAB-STATUS PIC 9(4).

03 FILLER PIC X(12).

02 PARAM-DYNA.

03 DYNA-REFERENCE PIC X(20).

03 DYNA-TARGET PIC X(12).

03 DYNA-TOGGLE PIC X(20).

03 DYNA-NEWVAL PIC X(20).

03 DYNA-TABLETYPE PIC X.

03 DYNA-CREATE PIC X.

01 ACC-OP PIC X(4).

 

But, to use table creation, you must add PARAM-DYNA fields to block .

To use others API functions, like COMMIT & ROLLBACK, …., you should invoke :

CALL "SGBD" USING ACC-OP, BAB.

 

To use the dynamic table creation API, you must :

Store into DYNA-REFERENCE a string like "@MFDYNA:XXXIO"

Where MFDYNA is the reference (template) DID name, in which find the model for table to be created : the table model is XXXIO in this example (this table must exist into template DID).

 

Store into DYNA-TARGET the future table name to create into current DID :

MOVE "TEST1IO" TO DYNA-TARGET.

The future new table will be named TEST1IO in this case.

 

Store into DYNA-TOGGLE the string to search into template FD, to replace it by value of DYNA-NEWVAL :

MOVE "XXX" TO DYNA-TOGGLE.

MOVE "TEST1" TO DYNA-NEWVAL.

In this example, each time an object name contents the string XXX ( at any place into it) , this sequence will be replaced by TEST1 .

It's necessary to don't have many indexes having the same object name, into database.

 

Put "A" into DYNA-TABLETYPE ( reserved for future extensions ).

 

Put "Y" or "N" into DYNA-CREATE :

Y implies the database table, and indexes, will be created into current database, if DID extension was successful : The new table will be immediately usable, after an OPEN statement.

N implies that only DID extension will be done : objects will not be created (That will require to invoke manually CAPCOM or Unix equivalent db_admin, to create this new object in database).

 

Now, program can invoke the API :

CALL "SGBD" USING ACC-OP, BAB-DYNA.

Note : this API uses BAB-DYNA (level 01) , not BAB (level 02) like previous CALLs.

That allows to pass to Cobol Access + API the content of additional parameters.

 

If operation complete successfully, a status 0 is returned to program, into BAB-STATUS.

 

Otherwise, following possible status values define the situation :

100 // Current database is not valid ( not connected ? )

101 // The target table already exists in current DID

102 // Unable to OPEN one of DIDs ( reference, or current )

103 // Read error on one of DIDs

104 // Unable to copy temporary DID on current

105 // The template table doesn't exist into reference DID

106 // The reference DID doesnt exist (not found )

107 // Bad parameter value

108 // After update of current DID, unable to reload static tables into Sched and Acc

109 // Unable to activate Admin, to create objects

                                  1.     // One of DIDs structure is corrupted ( reference or current)

 

201 // Bad Admin command line

202 // Bad Admin command line ( no DID given )

203 // Admin : PLUSDICO isn’t defined in environment

204 // Admin : cannot open DID

205 // Admin : the DID is locked

206 // Admin : Read error on DID

207 // Admin : DID not found

208 // Admin : maintenance of DID not allowed

209 // Admin : Bad RDBMS type for this DID

210 // Admin : maintenance of DID not allowed

211 // Admin : Incorrect password to connect on RDBMS (check DID)

212 // Admin : Unable to connect on RDBMS ( not available ?)

213 // Admin : Unable to find object(s)

214 // Admin : Table creation rejected

215 // Admin : Index creation rejected

216 // Admin : The table to be created doesn’t exist in DID

                                  1.     // Admin : This SQL statement isn’t supported by this RDBMS

 


 

 Support of ‘Generic START ‘ :

 

With previous releases of Cobol Access +, only the start value of a SELECT was given, never the high limit of search.

So, the RDBMS engines constructs cursors containing records from given value, to end-of-table. That could be expensive on large tables.

Cobol Access + proposes now a new programming technique, to limit this overload :

As example :

You want to execute a search into a table, for all customer names starting by ‘FA’.

The common Cobol approach was :

MOVE "FA" TO CUST-NAME.

START MY-FILE KEY IS NOT LESS THAN CUST-NAME

…..

READ NEXT …..

In this example, the SQL engine will create a cursor from FA values to ZZ…..

Probably, your program will not scan all selected record, but only those starting by ‘FA’.

 

The ‘generic START ’ approach :

MOVE "FA%" TO CUST-NAME.

MOVE 2 TO W-SIZE1. ( a working area, style PIC 9(5) )

START MY-FILE KEY IS EQUAL CUST-NAME WITH SIZE W-SIZE1

……

READ NEXT ……

 

The generated SELECT SQL statement will be different, because the key size is limited, and buffer contains character % at ( W-SIZE1 + 1 ) position.

The constructed cursor will only contain records having a string containing ‘FA’ as two first characters.

During the READ NEXT loop, a status ‘END-OF-FILE’ will be returned to program, on detection of end of subset ( no more ‘FA’ key values ).

This feature can increase a lot performances, for zoom windows, or Grid controls.

With previous releases of Cobol Access +, only the start value of a SELECT was given, never the high limit of search.

That could be expensive on large tables. Cobol Access + proposes 'Generic START' technique, to limit this overload and to increase performances.

 

 


     

    Support of new RDBMS :

    Under Windows, two new RDMS engines are now available :

     DB2/UDB

     CA-INGRES

    They propose same functionalities than others, without restrictions.



     

     ORACLE 8 compatibility :

    Validation of ORACLE 8 with Cobol Access has been done !

    Binary licenses for Windows server are fully compatible, for ORACLE 7.3, ORACLE 8 and ORACLE 8i.

    Any downloaded license can be used with both ORACLE versions.

    For UNIX platforms, each license must be generated ( compiled and linked ) with the target ORACLE version already installed on the platform.

    This compatibility is obtained because Cobol Access + uses the Oracle Call Interface ( OCI method ) , really compatible between different Oracle releases.

     


     

     Remote clients management (on servers):

    For UNIX platforms, a new utility is installed with license :

    snetmgr is a character mode program, displaying connected clients and characteristics, and allowing to manage them :

     Stop a client,

     Stop all clients,

     Stop the Cobol listener ( db_snet )

    For Windows platforms ( NT/2000 servers or Windows 95/98 administrator ), this functionality is assumed through new release of Command Center ( CAPCOM ) :

    When you select a server into treeview, ( both Unix or Windows ), you can see remote activity on this server ( connected clients, I-Os done, identity of client, and so on ).

    If current server is Unix type, you can also manage each active connection .

    If current server is under Windows, you can only list them, or reinitialize all.

     

    A new supervision mechanism has been also included into client side, and server side, to detect and process broken links between clients and server.

     

    When a client connects on a server, and doesn’t require any access to database, it will send a ‘query frame ‘ to its server, each 30 seconds ( very short packet ).

    Each server process or thread must receive at least one packet during a period of 90 seconds, otherwise it releases the link, all resources, and closes the socket .

    Of course, when a client works really with database, no ‘query frame ‘ is exchanged on network.

     

    That prevents ‘ zombie client processes ‘ to keep any resources on server ( locks, license entry, exclusive access, …..).

 

This major release will be available before end of April 1999.

 


 

 RLDT SA - 2, rue de la Carnoy 59130 Lambersart - Tel: 03 20 17 26 60 - Site Version3.0