New features proposed by each upgrade
April 4th, 2003
Version 6.1x new features : ( announced, not yet available )
- Possibility to force LiteSql requests requiring long time, to be processed by a separate accessor, dedicated to, and eventually activated dynamically , to avoid hang situation between many users sharing resources into Cobol Access servers.
- Support of IBM/DB2 database in native mode, under Unix systems ( only if agreement can be finalised with IBM )
- A better cursor’s management into accessors
o The technique to allocate, de-allocate, reuse or free a cursor resource into server has been completely rewritten, to be more robust and optimised.
o Now, the server tries to ‘keep alive’ as long as possible any pre-parsed statement, to gain the required time by RDBMS, to prepare & parse statements.
o That improves a lot the global performances
- New approach for cursor usage, to avoid the ‘snapshot’ effect due to RDBMS, generating some integrity problems in concurrent access for updates.
o If two different programs execute a START on the same table, at the same time, each of them takes a ‘instantaneous picture’ ( named a ‘snapshot’) of the table, at START execution time ( they’ll probably be identical, at this step ).
o If one of them executes READ NEXT, and UPDATEs the record, no problem
o But, if this program releases the Cobol lock, to do something else …….
o The other program load the record pointed by its ‘snapshot’ : It’ll retrieve the old state of record ( not modified ). The Cobol lock being available ( see previous step ), it can also update it ( using old & initial state ) : Problem !
o To avoid this, the new release proposes a new policy :
§ When executing START, we don’t take a ‘snapshot’ of records, only a LIST OF RECORDS pointers ONLY if file is opened in I-O mode !
§ When each program executes READ NEXT, we fetch the pointer, and use another pre-compiled statement to really read record content : We’re sure to read the ‘real time’ state of record.
§ If nobody else has locked the record, the client program is authorised to update it, without integrity conflict !
o The strategy is determined by a switch on client side ( Cobol runtime environment )
§ Without switch, still work like in the past
§ With PLUSSW=…. R… , the new policy is applied ( immediate cursor on START, named ‘Start List’ into tracer report)
§ Possibility, during a Cobol procedure, to override static switch R:
· only for ONE following START,
· or for all others, until reverse overriding occurs
o To assume this strategy, each accessor must have two separate resource pools :
§ One to execute main statements ( SELECT, UPDATE, DELETE,…..) and keep resulting lists returned by RDBMS
§ One to keep alive a list of pre-parsed statements ( one per table) , used to really fetch data columns
This version allows to manage the size of each cursors pool :
§ If no variable is set, each pool will be sized to 50 cursors ( total = 100 per accessor)
§ If, into $PLUSDICO directory, a file exists like DIDname.cfg , it must contain values described below :
MAX_DESC determines size of 1st cursor pool ( for complex statements ), and MAX_POOL determines size of 2nd pool ( for ‘one shot’ READ statements based on a list )
These values are static, evaluated when a server is started, and all accessors serving this DID will inherit of same values
o An extension has been developed into CAPCOM ( management tool under Windows ) to measure and survey this resources states inside accessors. That allows to detect if pool sizes must be increased, or can be decreased, checking if some overflow occurs, or if one of the pools is too short, in your particular environment and usage.
Version 6.0x new features :
- Possibility, for a Cobol program, to retrieve and process full return-codes after a Cobol Access exception ( API named ‘GetLastError’, code 99 )
o That includes Main status from C.A. server ( ex: 33 = fatal, I-O not processed)
o Secondary status from server ( ex : 08 = unexpected status from RDBMS )
o RDBMS return value ( ex : 3114 = Oracle not available )
The Cobol program can display messages, to help operator, by example in DIRECTIVES procedures.
- Possibility to choose the policy , when a program must initialise a scan of records into a table :
o When a Cobol program executes a START, previous Cobol Access releases was forced to execute three SELECT statements to begin a scan operation :
§ SELECT of key fields WHERE (….. ) to retrieve pointer on first record corresponding to key
§ SELECT all columns WHERE ( ACC_RN = value ) to really read the record pointed by previous START
§ SELECT all columns WHERE (…. ) to have a cursor on following records, ordered by key value, for READ NEXT processing
o With release 6.0x & following, it’s possible to force C.A. server to immediately create the cursor on the first SELECT statement ( of course, the select list includes all database columns, instead only key fields ! ) ; This execution is a bit more expensive, but it’s not necessary to execute the two others SELECT to begin a scan operation !
o The strategy is determined by switch on client side ( Cobol runtime environment )
§ Without switch, still work like in the past
§ With PLUSSW=…. X… , the new policy is applied ( immediate cursor on START, named ‘Start Curs’ into tracer report)
§ Possibility, during a Cobol procedure, to override static switch X, only for following START, or for all others, until reverse overriding occurs
- Support & optimisation for Oracle 9i
o The Oracle 9i optimiser has been completely redesigned by Oracle; The consequence is a different comportment regarding Cobol Access SQL statements submitted , which use HINTS !
o The technique used till version 8i was generating too much ‘full table scan’, having catastrophic impact for large tables.
o With version 6.0x, the SQL Statement dynamic generation is completely different, to use ‘aliases’ inside the statement itself ( the select list refers to alias c1, the where clause criterias refer to alias c2, c1 & c2 being two aliases on same table ) ; The result is a very nice comportment of Oracle’s optimiser !
- Many cursors available on the same table, for one user
o With previous releases, only one cursor per table and per user was maintained into accessor : If a program is executing a scanning using START / READ NEXT sequence, the fact to access directly to another record in the same table ( i.e READ… KEY IS EQUAL…. ) forces to close the running cursor, and eventual following READ NEXT to generate a new SELECT statement into RDBMS, decreasing global performances for program.
o Since version 6.0x, the Cobol programmer can now OPEN many times the same database table, using many logical FDs into program : One of theses FDs will be used for the scanning operation, by example ( START / READ NEXT ) and the other will be used by programmer to execute direct READs. Each FD having an individual possibility of cursor into accessor, one FD has no influence on access done through another. It’s also possible to process two sperate scans inside the same database table, using two FDs in Cobol !
- Dynamic extension of PLUSDBLIST content ( Cobol side )
o In Transactional mode only, it’s now possible to OPEN a DID which was not listed in PLUSDBLIST when the runtime session has been started.
- Code optimisation for db_snet ( Nt_snet ) process :
o This process, relaying Cobol requests between client ( Windows or Unix ) to server ( Windows or Unix ) has been optimised to consume less CPU.
Version 5.4x :
- Suppress the record size limit
o With previous releases, the Cobol buffer was statically limited to 4 Kbytes
o With version 5.4x and following, this size is unlimited ( not tested over 32 Kbytes, because some Cobol doesn’t allow ! ). It’s dynamically evaluated and configured when opening all DIDs listed in PLUSDBLIST, at runtime start time.
- Possibility to invoke stored procedures inside a LiteSql request
o A LiteSql request becomes capable to be ‘multi-statements’, using semi-columns : With Oracle, by example, that allows to invoke PL/SQL procedures & packages, giving them parameters.
- The CAPCOM tool, under Windows, is now capable to automatically detect all others Cobol Access installations, on the same network segment ( same subnet mask )
o When CAPCOM is started on a Windows PC, it send a broadcast on network and identifies all servers/administrators machines, running an agent process.
o It’s now important to install differently :
§ servers ( connecting some DIDs to databases ) : One server = One license !
§ administrators workstation ( maintaining DIDs and administrating remote servers ) : no license required
§ Cobol clients only using Cobol runtime & C.A. plugin
o A license number ( serial number ) cannot be used twice as server on the same network
o Administration workstations & Cobol clients aren’t considered as requiring individual licenses.
Version 5.3x :
- Support Relative files
o Full support of relative files under Cobol Access , for both Micro Focus & RM/Cobol environments.
o A new DIRECTIVE into Cob2did : RELATIVE
( like FOREIGN or TABLENAME)
- Possibility to activate / deactivate the server’s debug facility, dynamically, using CAPCOM ( under Windows) or a command line utility ( under Unix )
o It’s no more necessary to have two kind of Cobol Access server binaries ( one for normal mode, one for debug mode )