| Home | Engineering | Management | Networks | Learning | Cobol Access Plus | Support Forum | Links | Contact us |
| ___ ___ |
|
| Home | Engineering | Management | Networks | Learning | Cobol Access Plus | Support Forum | Links | Contact us |
| ___ ___ |
|
|
Technote
April 1999
Capacity to create dynamically a new table into existing DID Support of ‘generic START‘, with limitation of cursor size Validation of ORACLE 8 environment Possibility to fully identify connected remote clients, and manage them
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 !
 Add a new table into a running DID
Create database structure for 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.
Under Windows, two new RDMS engines are now available : DB2/UDB CA-INGRES They propose same functionalities than others, without restrictions.
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.
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 - FRANCE - Tel: +33(0)3 20 17 26 60 - Site Version3.0 |
News
Cobol Access Plus
Technical Support