Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Upgrade to a GUI 1

Status
Not open for further replies.
webrabbit

webrabbit

MIS
Joined
Jan 31, 2003
Messages
1,059
Location
US
I have an application that I sell that is written in Micro Focus COBOL 3.4.6 (DOS). I would like to rewrite it for Windows with a GUI. I have Visual Basic, Visual Object COBOL, NetExpress 2.0, 3.0, and 4.0, although th3 4.0 is only an "Educational" version.

What would be the best language/version to use? What are the considerations?
 
Sort by date Sort by votes
If you are going to make the effort to do this, you might want to consider (ahem) additional vendors.

Another consideration would be to bypass the Windows GUI, using instead a browser. This would allow you to target all the folks you would get with Windows, plus everyone else with a nonWindows browser. In fact, by targeting a browser, you could 'sell' the application as an 'on-demand' application (in the manner of salesforce.com, for example) over the web, freeing your customers from maintaining the IT structure required to support your application.

If you wish, perhaps you could share some facts about the application?

Tom Morrison
 
Upvote 0 Downvote
This application is retail inventory control. Originally it was for shoe stores, but I want to also convert it to any piece goods. There is also a companion Point-of-Sale system that most of my customers run under DOS with network such as Novell.
 
Upvote 0 Downvote
I would use NetExpress 2.0 (Dialog System) because it allows you to distribute the runtime without cost and it is very easy to convert 16 bit COBOL to Netexpress. I have also found that anything I have coded is compatible with win 98/2000/nt/xp etc. even though NE2 was a win 95 product.

Alternately Tom's browser idea is good except that I have generally found it better to convert COBOL to PHP rather than using the CGI approach. It is faster and more compatible with the web than NE.

Incidentally, when working at MF I made some NetExpress utilities which you would be welcome to have if you wish.



Clive
 
Upvote 0 Downvote
What is PHP?

I would like to see the utilities you mention.
 
Upvote 0 Downvote
PHP is a non-commercial, widely supported, free, server-side language that is very compatible with HTML on the web.

If you would like to see an example of a converted COBOL to PHP conversion, visit:
When I first wrote the program in COBOL, I thought that it would be hard to do in any other language. However, I duplicated it in PHP in one evening.

If you contact me via my website, I would be happy to send you the utilities. If there is general interest I would gladly post a direct link to a zip file.

Clive
 
Upvote 0 Downvote
CliveC said:
Alternately Tom's browser idea is good except that I have generally found it better to convert COBOL to PHP rather than using the CGI approach. It is faster and more compatible with the web than NE.
Click to expand...

Ah, Clive, CGI is so last month! [upsidedown]

Of course, that is why I suggested (cough, cough) other vendors. Business Information Server is a COBOL-based web application engine that allows the COBOL programmer to focus on his business rules and implement the visual representation either directly in a browser (using 'standard' editing tools such as Dreamweaver or FrontPage), or reuse his COBOL legacy to create web services and use web-service-aware technologies (Visual Studio .NET, Java-based web application engines, etc.) to implement the user interface.

Given that this is retail inventory control, one solution might be to implement the inventory control as a web service, and the place the visual user interface in a handheld scanner implemented in WindowsCE (or whatever it is called these days).

The important concept is that reimplementing your business rules, the valuable part of your COBOL legacy, in some other langauge is not necessary to gain access to modern user interface technologies. Inventory control business rules a decade from now will be virtually identical to your existing rules, but I can almost guarantee that user interface technologies will be different. The benefit of the Business Information Server approach is that you will be saving the valuable portion of your COBOL legacy code and reimplementing the portion you will throw away in a very few years - the user interface - in a technology (XML and XML-based standards) that will be the basis of the next two or three generations of user interface technolgies.

Tom Morrison
 
Upvote 0 Downvote
The run-time distribution is a concern. I had read on another thread that it is free for 3.0 also.

The problem with other vendors is that they want money. NE2, NE3,and VIOC are already paid for.
 
Upvote 0 Downvote
Tom,

I am not exactly sure what your post is saying. I was just trying to answer the question within the boundaries of what technology Webrabit already had.

I have been coding with COBOL for 35 years and I think it is a great language... I sometimes dream in COBOL. However, in my humble opinion, all programming is much the same and re-writing is usually faster than trying to convert.

I am not familiar with Business Information Server, and maybe this is a good approach.

Clive
 
Upvote 0 Downvote
Just a GUI or going for .NET? The latest Micro Focus products intergrate fluidly with Visual Studio workbench.

Not a MS lover (like me)? Going for J2EE? Your MF-COBOL programs can be encapsuled en behave like EJB or SOAP objects.

There is no need to turn away from Micro Focus. Come to Amsterdam ( next month and see for yourself.
 
Upvote 0 Downvote
My main concern in something like this venture would be being able to support all these platforms. In that case, I would do everything I could to try to isolate my business logic into its own modules and then try to come up with the different presentation layers. (of course that's a foreign idea to most standard COBOL shops, I've found, unless they DO have to support multiple platforms)

Like for example, in your case I would try to find a 32-bit text-based Win32 COBOL compiler (no GUI required). AFAIK, NetExpress 2.0 had that capability. Then stick your business logic into DLL(s). Then you can call those DLLs from various presentation layers (VB for the client side GUI, NetExpress maybe for the web-side stuff, basically whatever you can imagine, there are even free DOS compilers out there that will do 32-bit DOS-only apps). You'd even have a lookin on Linux doing things that way too, assuming you find compatible tools.

But basically as long as you can find the tools on each platform to implement your basic business logic modules, you should be able to move your program into any platform, and going the DLL or module approach with a capable COBOL compiler should make your business logic reusable on whatever platform you're trying to reach.
 
Upvote 0 Downvote
Very much agree with you glenn9999. Exposing you cobol business logic al callable modules or SOAP's (also very well possible on mainframe CICS) is thé way to go.
 
Upvote 0 Downvote
I don't think I will be going for multiple platforms. My target market is the mom&pop stores. Most of these are computer illiterate. The big shops are impressed by big expensive products. (My multi-store version sells for $2000 + $200 per store. My biggest customer replaced it with a system that cost $400,000, + $50,000 per store and runs on an AS400. The former DP manger says it is not any more capable than my system and much harder to use. They spent $8000 just to duplicate one of the reports from my system.) I wrote a very powerful and easy to use text-based menu system for it, but everyone wants a GUI these days.
 
Upvote 0 Downvote
Like for example, in your case I would try to find a 32-bit text-based Win32 COBOL compiler (no GUI required). AFAIK, NetExpress 2.0 had that capability. Then stick your business logic into DLL(s). Then you can call those DLLs from various presentation layers (VB for the client side GUI, NetExpress maybe for the web-side stuff
Click to expand...

I think there is some misunderstanding here on what NetExpress is.

1. It can be used for pure COBOL even in text based DOS mode. All modules will be re-compilable and runable.

2. NE can handle the windows GUI side, using Dialog System, one of its components.

3. NE can also be used to create a web based intererface, which at version 2. used CGI.

4. Using DLLs is possible using NE but it forces you to link modules. By building modules instead you gain the mainentance advantage of being able to update single modules without re-linking everything.

All dialog system screensets can be represented as pure text, or created using pure text, and this again makes maintenance very easy.

Hope this helps!

Clive
 
Upvote 0 Downvote
4. Using DLLs is possible using NE but it forces you to link modules. By building modules instead you gain the mainentance advantage of being able to update single modules without re-linking everything.
Click to expand...

Maybe I'm missing something, but aren't DLL's "dynamic link libraries"? Basically when I use them, I don't have to re-compile them or re-link them at all - I just have to make sure the DLL file is there, and the calling program takes care of the rest. The only time when the business logic would have to be changed with respect to the presentation layer is if the call conventions of the procedures change. At least that's the way I've always worked with DLLs. In any event, the advice still applies for a file that is directly linked into the executable (LIB, OBJ, whatever). As I remember NetExpress 2.0 enforced this separation anyway in its scripted COBOL code.
 
Upvote 0 Downvote
Hi Glenn, What I mean is that to use DLLs your whole application needs to be linked. MF provides an alternative to linking that is faster and more efficient and means that all modules are automatically dynamically linked.
Click to expand...

OK, so NetExpress operates differently with DLLs in the sense that they must be linked to an application? I haven't worked with DLLs and NE, but with other things, I've always just wrote the calls using the published convention for the DLL and the program took care of the rest (including abending if the DLL file wasn't found at execution).

You learn something new everyday I guess.
 
Upvote 0 Downvote
You might not, but the main idea I guess is that you might in the future. As the others have pointed out, "Windows with a GUI" can mean about a dozen different things these days, so that's the main reason why I made the suggestion and I think people are bringing up all these variations and options. Of course, we don't know what option(s) you want or would want in the future through customer request.

I don't think I will be going for multiple platforms. My target market is the mom&pop stores. Most of these are computer illiterate.
Click to expand...
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

W
  • Locked
  • Question Question
JCL on a PC
Replies
10
Views
1K
mikrom
mikrom
C
  • Locked
  • Question Question
IBM AS400 COBOL Conditionally have a record blink
Replies
0
Views
423
chuckw0325
C
klophockey
  • Locked
  • Question Question
How To Determine Encoding Of A File - And see the contents in Hex
Replies
3
Views
881
fredericofonseca
fredericofonseca
AMCM
  • Locked
  • Question Question
COBOL SEQQUENTIAL FILE TO CSV
Replies
16
Views
2K
AMCM
AMCM
AMCM
  • Locked
  • Question Question
COBOL ERROR : Transfering data from txt file to another
Replies
12
Views
1K
AMCM
AMCM

Part and Inventory Search

Sponsor

Back
Top