Visual COBOL

[victora]

Hello everybody,
We have an SQL database on the backend and I'm writing reports using Crystal Report. Now I'm looking for an alternative so I can develop home-grown apps using the Windows platform. I started with COBOL many years ago and I guess it was my first language i can truly say, I was comfortable. But for many years, I did different flavors of RPG in the AS400 box.

How is PC COBOL nowadays? Can somebody help me fall in love again with the language? Is it now GUI? How do you deploy compiled objects. Can u now web-enable Cobol apps? Is it compatible with Win 98, 2000, XP? (I'm looking at a solution where I can do all my development on a PC and my compiled objects deployed on Windows)

If you can refer me to a research site, re: "NEW COBOL on a PC", it will be greatly appreciated.

thanks
victora

 

[3gm]

Victoria -

There are quite a few vendors that produce a good COBOL compiler capable of doing GUI screens on Windows 9x/NT/2000/XP including (but not limited to) Microfocus (NetExpress?), AcuCOBOL, RMCobol, and Fujitsu. Fujitsu even offers a .NET COBOL.

AFAIK, all of them allow access to the Windows API so you can do most, if not all, the stuff you need to do to run "properly" under Windows. Also, if you've not used COBOL in a while, you may discover new features that make programming in it much more "modern" including scope termination (END-IF, END-READ, etc), Case statements (EVALUATE), and reference modification (direct byte extraction/insertion) among others. There are also COBOL compilers that are truly object-oriented if you want to go that far.

The gotcha with these is the cost. Many of these options sell for thousands of dollars per copy. An option some recommend is to buy one of the COBOL textbooks that includes a compiler for personal use. Check the COBOL FAQ for more info:

http://cobolreport.com/faqs/cobolfaq.htm

Glenn

 

[TomKane]

I'd never hear a bad word said against COBOL - but you might be better off using something a little less "specialised" - don't flame me - maybe VB?

Sorry....

 

[TonHu]

Victoria,

Cobol now can do all the required tricks to produce 'real' Windows programs, just like you asked, but... Being developed from the ground up as a means to produce Windows app's, Delphi (or VB if you press hard enough) is my way of doing things the Windows-way. I've not been a Cobol developer for that long, but I do like the way things can be solved 'in it's special Cobol way' ;-) But I'd never grab Cobol to do a q&d tool or hack to get something going in Windows... It feels like taking the 18-wheeler to do the weekly 1 bag shoppin' round. Cobol has learned all the tricks of the trade, and Fujitsu a.o. is even teaching .NET to Cobol, it's just that the old fox learned a new trick, but he never said he liked it...........
I don't want to start the religious discussion of languages over here, it's just what I'm comfortable with.
TomKane probably has done good bussines with VB, so that might just do your job as well?

On the other hand, if you are planning some large to huge project, like keeping inventory of, say, Marks and Spencers, including planning of logistics, and tracking goods around the globe, Yes, then I'd reccomend Cobol ;-), but also a fine 'big-iron' mainframe to get (and keep) it runnin' s-).

My opinion: Cobol for big and trusty things, Windows and Delphi/VB/C++/whatever for smaller projects. Ever used a modern word-processor that was written in Cobol, lately?

Just my 2 euro-cents ;-)
TonHu

 

[Dimandja]

Hi victora,

COBOL is still out there. Of course there are successful attempts at guiing COBOL (Fujitsu, Micofocus).

You still need a robust backend/server language in any application. COBOL will do nicely.

If you need to develop in Windows, then you probably need to pick user interface GUI and backend processes. You can develop your GUI or DLLs in COBOL. Its a matter of choice. Things are getting to the point where choosing a development language is a matter of comfort rather then efficiency.

If you look at the .NET Framework, for example, you can choose to develop your system in any language you like: performance will be the same. In .NET you can use COBOL for web development, as you can use any other language you prefer. This is the trend.

Dimandja

 

[victora]

thanks guys for all your input. my firt cobol program was in the mid 80's in a mini NCR. Moved to IBM where I learned my RPG. If its first love then I guess the word is true.(??)

All I want to do is use my PC (Win XP) to develop apps that can access data from diff source i.e. SQL, Oracle, DB2, and other ODBC-compliant data source. I cannot tell my users anymore to do their data entry on a text mode. So GUI it is...

Visual Basic is cool and so is Delphi...I agree with TonHu and TomKane. Or maybe .Net is the next big thing...

Is there a licencing scheme like, u know, in Visual Basic, u can distribute an .exe and dll's without calling Microsoft and get a green light on your deployment initiative. In other PC-based languages (Visual RPG for example), u have to get a licence for everything...How is COBOL in this aspect?

What is the up front $$ involve in the complete package. I cheked RM Cobol and its like $3,300.00 +. Hows the the other guys? In your opinion, who has the least $$$ and what can you get with that money...

VA

 

[3gm]

Well, AcuCOBOL requires a runtime license for each user and is not cheap. I'll let others speak to Fujitsu and Microfocus.

I'd echo TomKane; VB is probably the way to go for the kind of development you seem to be planning. Inexpensive. Easy to learn. Fairly capable in Windows (you have to define external functions for many Windows API's, e.g. CreateProcess; that can be tricky in some cases. The good thing is there is a ton of sample code out on the web for all sorts of VB-based solutions.) Lots of samples for SQL access etc.

VB is also very useful when working with Microsoft Office and third-party software that speaks VBA. Finally, VB Script, a relative of VB, is useful for Web work or even batch scripts a la DOS .BAT files. All-in-all, if you don't have some pressing reason to do it in COBOL (or FoxPro or Delphi or C or C++ or C# . . . ), I'd opt for VB.

Glenn

 

[Dimandja]

Hi victora,

Seeing as you are being shepherded to VB pastures, I thought I would try to show you what object-oriented (and .NET peppered) COBOL 'feels' like.

It is still COBOL, with a few new tricks up its sleeve. These new features are required in order for COBOL to be object oriented. In the .NET framework, COBOL can use (and create) any object that any other .NET enabled language can use and create. The old incompatibilities between languages and code produced by different languages are simply erased; because all languages compile into the same intermediate (and locally compilable) code.

If I may, here is a sample of object oriented code I lifted from a Fujitsu centric site (

http://quickstartcobol.eraserver.net/quickstartcobol/howto/).

You will notice how the code is still COBOL, but with new reserved words. You will also notice how COBOL inherits and manipulates objects. See the absence of PICTURE clauses, since objects (not simple variables) are defined in WORKING STORAGE? I could go on, but see for yourself whether you can understand the following program (it is supposed to be updating an SQL database):

       CLASS-ID. adooverview2.
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       REPOSITORY.
           PROPERTY PROP-CONNECTIONSTRING AS "ConnectionString"
           CLASS CLASS-CONSOLE AS "System.Console"
           CLASS CLASS-STRING AS "System.String"
           CLASS CLASS-SQLCONNECTION AS "System.Data.SqlClient.SqlConnection"
           CLASS CLASS-SQLCOMMAND AS "System.Data.SqlClient.SqlCommand"
           CLASS CLASS-STRINGBUILDER AS "System.Text.StringBuilder"
           CLASS CLASS-SQLEXCEPTION AS "System.Data.SqlClient.SqlException"
           .
       STATIC.
       PROCEDURE DIVISION.
       METHOD-ID. MAIN.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
        01 myadooverview2 OBJECT REFERENCE adooverview2.
       PROCEDURE DIVISION.
           INVOKE adooverview2 "NEW" RETURNING myadooverview2
           INVOKE myadooverview2 "Run"
           .
       END METHOD MAIN.
       END STATIC.
       
       OBJECT.
       PROCEDURE DIVISION.
       METHOD-ID. Run AS "Run".
       DATA DIVISION.
       WORKING-STORAGE SECTION.
        01 mySqlConnection OBJECT REFERENCE CLASS-SQLCONNECTION.
        01 mySqlCommand OBJECT REFERENCE CLASS-SQLCOMMAND.
        01 mySqlCleanup OBJECT REFERENCE CLASS-SQLCOMMAND.
        01 Console OBJECT REFERENCE CLASS-CONSOLE.
        01 Message1 OBJECT REFERENCE CLASS-STRING.
        
       LINKAGE SECTION.
       PROCEDURE DIVISION.
       DECLARATIVES.
       err-section SECTION.
           USE AFTER EXCEPTION CLASS-SQLEXCEPTION
           SET Message1 TO "Couldn't insert record: "
           INVOKE CLASS-CONSOLE "Write" USING BY VALUE Message1
           *>TODO: FIGURE OUT HOW TO WRITE OUT THE EXCEPTION STRING
           .
       END DECLARATIVES.
           
           INVOKE CLASS-SQLCONNECTION "NEW" 
           USING BY VALUE "server=(local);Trusted_Connection=yes;database=northwind"
           RETURNING mySqlConnection
      
           INVOKE CLASS-SQLCOMMAND "NEW"
           USING BY VALUE "INSERT INTO Customers (CustomerId, CompanyName, ContactName, ContactTitle, Address) Values ('ABC','ABC Company', 'John Smith', 'Owner','One My Way')", mySqlConnection
           RETURNING mySqlCommand
           
           INVOKE CLASS-SQLCOMMAND "NEW"
           USING BY VALUE "DELETE FROM Customers WHERE CustomerId = 'ABC'" mySqlConnection
           RETURNING mySqlCleanup
           
           INVOKE mySqlConnection "Open"   
           INVOKE mySqlCleanup "ExecuteNonQuery"
           INVOKE mySqlCommand "ExecuteNonQuery"
           SET Message1 TO "New Record inserted into Customers table in northwind."
           INVOKE mySqlConnection "Close"
      
           INVOKE CLASS-CONSOLE "Write" USING BY VALUE Message1
           .
       END METHOD Run.
       END OBJECT.
       END CLASS adooverview2.

Dimandja

 

[MarcLodge]

Hi Victoria,
Like most people here, I won't hear a bad word against Cobol, but, horses for courses, there are possibly better all round packages out there to do what you wish to do. VB is certainly an option as it has interfaces to SQL and Crystal Reports, but if this is for a home crown application, and depending upon the business side of things, you may wish to consider Access. This can get at SQL databases and also has it's own home grown reporting facility. It's also pretty powerful on the GUI side of things, plus the ability to do the trickier things in VBA.

Just a different option for you to consider.

Marc

 

[Dimandja]

Marc,

It seems to me that Using COBOL on the PC is only limited to the environment one chooses to do development.

When developing in .NET using COBOL, you use the same GUI toolbox in the same way (pixels and all) as VB, C and Java use them. In addition, COBOL has access to the same databases supported in .NET, as those other languages. The only difference, of course, is all the code is generated in COBOL. (Vive la difference!).

Did I mention that instead of Javascript, you can use COBOLscript in your HTML page? Here is all you need to run the program I posted previously, from your HTML page:

<html>
    <script runat=&quot;server&quot; language=&quot;COBOL&quot;> 
...program goes here...
    </script>   
</html>

Did you know that you can migrate your CICS COBOL applications (EXEC CICS, BMS, PCT, PPT, FCT) to the Windows environment? And have your code accessible through ASP.NET pages and XML Web services? From

http://www.adtools.com/info/whitepaper/net.html,

here is a simple Web Service written in COBOL:

<%@ webservice language=&quot;COBOL&quot; %> 
  CLASS-ID. FOO.
  FACTORY.
  PROCEDURE DIVISION.
  METHOD-ID. ADDME.
  DATA DIVISION.
  LINKAGE SECTION.
  01 OPND-1 PIC S9(9) COMP-5.
  01 OPND-2 PIC S9(9) COMP-5.
  01 RET PIC S9(9) COMP-5.
  PROCEDURE DIVISION USING BY VALUE OPND-1 OPND-2 RETURNING RET.
 
  COMPUTE RET = OPND-1 + OPND-2.
 
  END METHOD ADDME.
  END FACTORY.
  END CLASS FOO.

I mean to say that your COBOL skills are more useful than ever, not the other way around.

Given all this, I simply don't see why these other languages "have capabilities that COBOL don't have".

Dimandja