 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
 |
|
|
|
 |
 |
||
|
ASP.NET/COBOL.NET Database Access Example
One of the features of the .NET framework is its ability to handle multiple languages. Third party compiler vendors can create and implement a compiler targeted for the .NET runtime. In fact, over the course of the next year, you can expect to see some 28 languages ported to the .NET runtime. This will allow companies with a huge codebase in a "non-Microsoft language" to continue building onto their investment.
This article provides COBOL.NET code that accesses SQL Server and binds the results of a query to a DataGrid. I know enough COBOL to write this application but I don't know enough COBOL to write an explanation of this example.
UPDATE: COBOL guru, Pete Dashwood, had been gracious enough to explain the COBOL in my example! Pete is a well known expert in the COBOL community and frequently contributes to magazines, web sites, and COBOL newsgroups.
Below, you will find the example in it's entirety. Immediately following the example, you will find Pete's wonderfully helpful analysis of what this .NET monster is actually doing. Thanks Pete!!
Note: All of the software required to create and run COBOL.NET applications can be found here. On to the goodstuff - the code!!
<@ Page language="COBOL">
<html>
<head>
<script runat="server" language="COBOL">
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
PROPERTY DataSource
PROPERTY myDataGrid
CLASS SqlConnection AS "System.Data.SqlClient.SqlConnection"
CLASS SqlCommand AS "System.Data.SqlClient.SqlCommand"
CLASS SqlDataReader AS "System.Data.SqlClient.SqlDataReader"
CLASS Sys-EventArgs AS "System.EventArgs"
CLASS Sys-Type AS "System.Type".
OBJECT.
PROCEDURE DIVISION.
METHOD-ID. ONLOAD AS "OnLoad" OVERRIDE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 mySqlConnection OBJECT REFERENCE SqlConnection.
01 mySqlCommand OBJECT REFERENCE SqlCommand.
01 mySqlDataReader OBJECT REFERENCE SqlDataReader.
01 myType OBJECT REFERENCE Sys-Type.
01 dataSource OBJECT REFERENCE ICollection.
LINKAGE SECTION.
01 args OBJECT REFERENCE Sys-EventArgs.
PROCEDURE DIVISION USING BY VALUE args.
INVOKE SUPER "OnLoad" USING BY VALUE args.
INVOKE SqlConnection "New" USING BY VALUE "Data Source=(local); Trusted_Connection=Yes;
Initial Catalog=pubs" RETURNING mySqlConnection.
INVOKE SqlCommand "New" USING BY VALUE "Select * From Publishers" mySqlConnection
RETURNING mySqlCommand.
INVOKE mySqlConnection "Open".
INVOKE mySqlCommand "ExecuteReader" RETURNING mySqlDataReader.
SET DataSource OF myDataGrid TO mySqlDataReader.
INVOKE myDataGrid "DataBind".
INVOKE mySqlConnection "Close".
END METHOD ONLOAD.
END OBJECT.
</script>
</head>
<body>
<form runat="server">
<asp:DataGrid id="myDataGrid" runat="Server" />
</form>
</body>
</html>
Pete's analysis and commentary on the example:
Fujitsu, in partnership with MicroSoft, have undertaken to provide a COBOL compiler for the .NET environment. This compiler is currently in Beta.
Fujitsu have been one of the first COBOL vendors to implement Object Oriented COBOL, which is still in a Draft Standard (supposed to be available in 2002). In response to Market demand, some COBOL Vendors have released COBOL Compilers with their own interpretation of the OO extensions. The example below is from Fujitsu, but there are other vendors like Micro Focus who also offer OO COBOL.
I have been using COBOL since 1967 and OO COBOL for the last two years. I also use other Languages, believing in the “best tools for the job”. There are many cases where COBOL IS the best tool as it has great strength in the areas of data manipulation and providing commercial data processing solutions.
I am not currently running the .NET Compiler, but anticipate doing so when it is released.
For the sake of space and clarity I have not commented on the HTML or ASP-specific tags included. Annotations below in red...
<@ Page language="COBOL">
<html>
<head>
<script runat="server" language="COBOL">
This is a DIVISION Header.
ENVIRONMENT DIVISION.
COBOL programs are structured into the following hierarchy: DIVISION>SECTION>PARAGRAPH>STATEMENT(Sentence). There are 4 DIVISIONS: 1. IDENTIFICATION (not used here, but would document the name of the program and who wrote it, when and where, for example.). 2. ENVIRONMENT (Tells us what machine for source and object, allows the definition of special names…and, as in this case, it permits reference to the REPOSITORY…). 3. DATA (contains the data definitions of the data we intend to manipulate). 4. PROCEDURE (defines the manipulations we intend to do on the data.)
CONFIGURATION SECTION.
This is provided for OO COBOL only. It serves a similar purpose to C
Header files, but does a bit more besides.
REPOSITORY.
The REPOSITORY contains details of all the Classes we intend to use, their interfaces and parameter lists (so this can be checked for conformance at compile time if required), and may also contain GLOBAL properties, as in this example. “GLOBAL” in OO COBOL Is referred to as “FACTORY”…)
PROPERTY DataSource
PROPERTY myDataGrid
The following Class Definitions will be used by the OO COBOL constructor Method “New”, to connect to the SQL SERVER Classes on the Server and obtain an Object reference for them (“instantiate” an instance of each Class Object). This is usually achieved by using OLE. Here, the AS clause has been used to connect directly to the Classes defined for the Client in SQL Server. This implies that these Classes have been registered to the .NET Server in advance…
CLASS SqlConnection AS "System.Data.SqlClient.SqlConnection"
CLASS SqlCommand AS "System.Data.SqlClient.SqlCommand"
CLASS SqlDataReader AS "System.Data.SqlClient.SqlDataReader"
CLASS Sys-EventArgs AS "System.EventArgs"
CLASS Sys-Type AS "System.Type".
This header introduces an Object definition.
OBJECT.
PROCEDURE DIVISION.
METHOD-ID. ONLOAD AS "OnLoad" OVERRIDE.
DATA DIVISION.
WORKING-STORAGE SECTION.
Under normal circumstances [non .NET development] when dealing with Relational Databases we would need to establish whether we are using ADO or DAO. With SQL Server we are using the classes specifically provided so this is not a consideration. We just hook directly into the Classes (and Methods and Properties) provided.
Establishes a pointer to an SQL SERVER Connection Object
01 mySqlConnection OBJECT REFERENCE SqlConnection.
Establishes a pointer to an SQL Command string (text)
01 mySqlCommand OBJECT REFERENCE SqlCommand.
Tells SQL SERVER where to place the results obtained from execution of an SQL statement.
In effect, this is a pointer to a Dynaset.
01 mySqlDataReader OBJECT REFERENCE SqlDataReader.
01 myType OBJECT REFERENCE Sys-Type.
01 dataSource OBJECT REFERENCE ICollection.
Used to define the arguments passed to this program from a calling program.
LINKAGE SECTION.
01 args OBJECT REFERENCE Sys-EventArgs.
In this case we are being passed an Object Reference to an object that will contain the system events as a property array. While this particular script is not interested in things like Clicks or keystrokes, other scripts we write could be… It is very similar to being a Java “listener”. We will also see below that one of the classes above this one in the Class Hierarchy requires these parameters, so it is simple for the scripts we write to inherit them.
PROCEDURE DIVISION USING BY VALUE args.
The PROCEDURE DIVISION Header may acknowledge the parameters passed to this program via the LINKAGE SECTION above. In this case it is “receiving” the args Object Reference.
This invokes a method with the same name, which is above us in the hierarchy.
INVOKE SUPER "OnLoad" USING BY VALUE args.
We specified in the “METHOD-ID” statement above that THIS Script represents a Method which OVERRIDES the existing Method called “onload”. In effect what THIS script is doing is EXTENDING the previous “onload” method, to get it to load a specific data Grid as well as the other things it currently does… (cf. Java “EXTENDS”…). Now, if we invoke “onload” it will do what is in THIS script; if we invoke SUPER “onload” it will do what is in the original “onload”. Hence, this script includes the original as well as the new stuff…
This object reference will now point to an instance of an SQL Server Connection Object.
INVOKE SqlConnection "New" USING BY VALUE "Data Source=(local);Trusted_Connection=Yes;
Initial Catalog=pubs" RETURNING mySqlConnection.
Obtains a reference, in a form that can be used by SQL Server, to an SQL Command string.
INVOKE SqlCommand "New" USING BY VALUE "Select * From Publishers" mySqlConnection
RETURNING mySqlCommand.
Note that the already established connection to the SQL Server Connection Object is used, so as to connect the SQL Command to the same instance of SQL Server Connection.
Execute the Connection Object’s “OPEN” Method.
INVOKE mySqlConnection "Open".
This establishes a connection to the database.
INVOKE mySqlCommand "ExecuteReader" RETURNING mySqlDataReader.
Execute the SQL Command and get an Object Reference to the dynaset returned by it.
SET DataSource OF myDataGrid TO mySqlDataReader.
Use this dynaset pointer as the Data Source for our Data Grid. This is an example of using the PROPERTY Facility of OO COBOL.
INVOKE myDataGrid "DataBind".
Execute the Grid’s “DataBind” Method to tie it to the Data Source we set up in its DataSource Property in the line above.
INVOKE mySqlConnection "Close".
Close the connection. The Grid is loaded with the result of the SQL Command we ran against the SQL Server database.
Standard scope delimiter for OO COBOL
END METHOD ONLOAD.
Standard scope delimiter for OO COBOL
END OBJECT.
</script>
</head>
<body>
<form runat="server">
<asp:DataGrid id="myDataGrid" runat="Server" />
</form>
</body>
</html>
You can see from the above that COBOL has come a long way from its “Batch Processing on Mainframe” roots.
Today, using Object Oriented COBOL, it is very simple to build COM components for inclusion in systems using components built in other languages (I have GUI forms where C++, VB, and COBOL components all play nicely together and are totally transparent to the User.)
Fujitsu’s Object Oriented PowerCOBOL is a very simple “Quick Build” GUI development tool, and I have developed a number of successful commercial applications in it.
Like I said above, it comes down to using the “best tools for the job”. There is still a very useful place for COBOL when it comes to certain jobs.
You can send comments and questions to Pete here.
Click here to return to my article index