GUI Programming questions
Pete
of programs that run in DOS. Our clients currently run those programs on
DOS, Win 95/98, and Win NT computers. Nice for us since we only need one
set of programs. However, as with most places I am sure, our customers
are now clamoring for Windows interfaces. I am hoping some of you who
have experienced this already will share with me the solution you came
up with. Did you drop COBOL entirely for those systems running windows?
Use Visual Basic or C to do interfaces for your programs? Use one of the
new cobol compilers like Micrfocus' Netexpress? Anything other ideas?
And how is it working out for you?
Sebastian Mayer
Pete schrieb:
Hi Pete,
it愀 too much to say that we have experience with the migration to GUI,
but we are
beyond evaluation. Our program system contains ca. 500 programs which
have user
interfaces.
The present interface is a DOS interface. We have developped our own
tools to generate a program out of a resource file (for example a dos
dialog box or a dos table). A generated program consists of two parts.
One part is once generated and then adapted by a programer (for example
to handle constaints) the other part is
always new generated if the resource file gets changed.
As you said the customers are now clamoring for Windows interfaces.
What we have looked for is a tool which alows us to migrate to windows
with the minimum of changes of the Code. All the partner firms of us
which have already started with window gui have made the same
experience. All have recoded their programs (from pascal to delphi, from
MF Cobol to Visual Basic, from MF Cobol to oracle ...) and all of them
have failed to do this in the estimated time (mostly 1 year). The nearly
have all spent twice of it. But the worst is, that the programs
have become incompatible to theire predecesors, will say features that
were highly estimated by the DOS users are now missing.
To resume our situation: only 1/2 of our programs have user interfaces,
those you have interfaces are well structured, will say have a very
common pattern (due to the code generator we have used).
The choice of visual basic (or other "foreign" languages) was quickly
dropped because we can愒 use our old code which is well testet. For
example if we enter a vat code (we have 120 differnt one to handle all
german special cases) it was checked whether the amount enter before has
the right sign, if it fits to the entered account, the percentage is
read from the vat table, the vat acount number and so on. Cause of the
same reason we don愒 have choosen dialog system because the interface is
capsuled in it and we have strong interactions between the data fields.
We have some NetExpress version installed at our place and I started to
play with OO-Cobol and especially the gui classes. After the usual
starter problems they are a nice thing to deal with (but it愀 hard to
find some one who has experience with them).
When playing with the features i have come across the gui paradigma
which means that you have an event driven programm, that means you enter
a dialog box, make your input, press the ok-button and check the input
for consistence. Our DOS programs make one accept at one field and then
analyse at once the input. What we did is we bend the event handler.
When a data field is entered and would lose it愀 focus, we stop the
event handler and the program goes on like in DOS. So what we have
actually done is replace the "accept" statment by a winapi call. Our dos
dialogboxes can be nearly automaticly changed to windows resource files.
All the code to do this is wrapped in an automaticly generated dialog
descriptor and in a special class doing the dialog handling. The result
is, that our code (the part which is adapted by the programmer) must be
changed only by 3 percent. The behaviour of the program stays the same
in the way of handling input but is enhanced in the way that you can use
the mouse, hot keys, context menus and push buttons.
Conclusion:
Most of our migration work is to adapt the tools we need, i.e general
dialogbox class, a table handler, adapt the source code generator and so
on. We think that we do this in 2 man-month. Afterwards we hope to port
a dos programm to window in between 0 (totally done by generator) and 3
days.
regards
Sebastian
(see http://www.maysoft.de/progen.htm)
Cheesle
>up with. Did you drop COBOL entirely for those systems running windows?
>Use Visual Basic or C to do interfaces for your programs? Use one of the
>new cobol compilers like Micrfocus' Netexpress? Anything other ideas?
I once was in charge of an experiment doing one of your above suggestions.
The project were ran on behalf of the European Union Research Council. What
we tried was to move a part of an Inventory/Invoice system from Acucobol to
Delphi. The lessons learned was that moving an application from 1 language
to another is not easily accomplished. Generally speaking the most
significant factors were:
- Modern languages like Delphi, VB, VC is a lot more complex and have a
learning curve that
makes the task complicated. It isn't just to hire new employees which
now the actual language,
they do not have the application experience of the current staff.
- User interface, is not just user interface. When moving from character
based to graphical you
are taking a huge step. I would say it is almost impossible to do a
straight forward transfer.
Where the character edition had a limited number of ways to accomplish
a dialog, a gui offers
an enormous number of options. Finding the right one and using it wise
is difficult.
- While at least Delphi and VC allows you to do "anything" you will in
most instances come into
a situation where you wish you had Cobol. Cobol is made for business
logic.
- With Cobol you have a database as a part of the language, with Delphi,
VC, VB you will have to
make a choice.
I would advice you to stay with Cobol and extend your current applications
into the wonderful world of gui from there. Doing so will allow you to focus
on the important issue; To produce the best possible user interface for your
users. Changing to Delphi, VC, VB would cost you a lot of effort to get
familiar with those environments, it will take years to obtain the same
level of knowledge that you do now have for Cobol.
Most modern Cobol's support gui today, although in different ways. Acucobol,
the choice of mine supports gui by having extended the language to support
gui controls. Like
DISPLAY LABEL AT 0301 Title "This is a label".
Others use third party utilities like Flexus sp2
I don't know for other Cobol's, but Acucobol let you run gui and character
mode instantly, depending on the host. You may also run charactermode using
a native Windows runtime as you do today and upgrade program by program. I
have done so for a few programs. Although it might look stupid having a
character interface, pressing a key and suddenly have a full featured gui
window, it is really efficient. Implementing gui gradually means low cost
and effective production as continously maintainance also applies to new
development with no extra effort.
I am satisfied with the way Acucobol has implemented gui support, most of
its gui controls also have character counterparts, thus may be used on a
variety of platforms. You will certainly receive opinions from others as
well, there is a number of good products out there, it is a consideration
you will have to go through. I am most certain that you will do a good
choice whatever you decides to go for.
Cheesle
Tony M. Mina
as our GUI interface and then switched our compiler to Fujitsu Cobol
using the same Cobol SP2 for our GUI. Make sure you do your homework
right before you attempt to do the conversion. The decision we took
was everything in Cobol.
Visit our site www.mc-sys.com to see the Fujutsi/Cobol SP2 screen
shots.
Tony M. Mina
On Thu, 06 May 1999 13:33:43 -0400, Pete <pivk...@amiscu.com> wrote:
>The company I work for uses Microfocus COBOL to program a large system
>of programs that run in DOS. Our clients currently run those programs on
>DOS, Win 95/98, and Win NT computers. Nice for us since we only need one
>set of programs. However, as with most places I am sure, our customers
>are now clamoring for Windows interfaces. I am hoping some of you who
>have experienced this already will share with me the solution you came
>up with. Did you drop COBOL entirely for those systems running windows?
>Use Visual Basic or C to do interfaces for your programs? Use one of the
>new cobol compilers like Micrfocus' Netexpress? Anything other ideas?
Thane Hubbell
> The company I work for uses Microfocus COBOL to program a large system
> of programs that run in DOS. Our clients currently run those programs on
> DOS, Win 95/98, and Win NT computers. Nice for us since we only need one
> set of programs. However, as with most places I am sure, our customers
> are now clamoring for Windows interfaces. I am hoping some of you who
> have experienced this already will share with me the solution you came
> up with. Did you drop COBOL entirely for those systems running windows?
> Use Visual Basic or C to do interfaces for your programs? Use one of the
> new cobol compilers like Micrfocus' Netexpress? Anything other ideas?
> And how is it working out for you?
>
>
No, you certainly do NOT drop COBOL. What I use is the COBOL of my
choice (or yours) and COBOL sp2 from Flexus - see
http://www.flexus.com
Plug alert -
If you don't presently receive "The COBOL Report" go to
http://www.objectz.com and subscribe. In the next issue will be an
article, by me, about new COBOL GUI development, and also conversion
of existing text based systems to GUI using COBOL.
-------------------------
Trust the computer industry to shorten "Year 2000" to Y2K. It was
this
kind of thinking that caused the problem in the first place.
Visit my updated website at
http://www.geocities.com/Eureka/2006/
Robert Kovacic
based "GUI interfaces". i.e. use a browser interface and remold you COBOL
programs as CGI programs.
Although such an interface has restrictions compared to a true GUI
interface, if you are coming from a COBOL character based environment you
are unlikely to miss all the interface bells and whistles available with VB,
Delphi, etc. The potential long term benefits in GUI independance and client
flexibility are a plus.
Regards, Robert Kovacic.
Pete wrote in message <3731D276...@amiscu.com>...
Mojo
>In your circumstances you could consider NetExpress and use it to build web
>based "GUI interfaces". i.e. use a browser interface and remold you COBOL
>programs as CGI programs.
>Regards, Robert Kovacic.
*** My shop basically had to make the same decision. As our 'GUI
Solution', we chose SP2 from Flexus to be our frontend to the
COBOL programs developed with MF Workbench 4.0.32.
There's many issues that need to be considered when going from
character to gui, but I can highly recommend SP2 as a
development tool without exception.
Mike Madara
Prince Frederick, MD
GaryBRC
from character to GUI? We are currently looking at both sp2 and COBOL-WOW.
sp2 seems to be much simpler GUI. Does this translate into a limited GUI
interface? We are converting DOS, character mode source to GUI.
Tony M. MIna
We are using SP2 and SP2 thin client and we haven't encountered any
limitations yet. We are using it on Windows NT client/server
connected to a Unisys 2200 mainframe using Tuxedo.
Tony M. Mina
Thane Hubbell
>Did you look at ETC's COBOL-WOW product when deciding what tools to use to go
>from character to GUI? We are currently looking at both sp2 and COBOL-WOW.
>sp2 seems to be much simpler GUI. Does this translate into a limited GUI
>interface? We are converting DOS, character mode source to GUI.
Simple is good. Sp2 *IS* simple. However, it is NOT limited.
Because sp2 is simple to use and implement does not mean it is limited
in function - it is actually VERY Powerful.
Moshe Shulman
>On 9 May 1999 13:10:50 GMT, gar...@aol.com (GaryBRC) wrote:
>>Did you look at ETC's COBOL-WOW product when deciding what tools to use to go
>>from character to GUI? We are currently looking at both sp2 and COBOL-WOW.
>>sp2 seems to be much simpler GUI. Does this translate into a limited GUI
>>interface? We are converting DOS, character mode source to GUI.
>Simple is good. Sp2 *IS* simple. However, it is NOT limited.
What is Sp2?
Thane Hubbell
Bob Wolfe
>On Sun, 09 May 1999 21:01:24 GMT, red...@ibm.net (Thane Hubbell) wrote:
>>On 9 May 1999 13:10:50 GMT, gar...@aol.com (GaryBRC) wrote:
>>>Did you look at ETC's COBOL-WOW product when deciding what tools to use to go
>>>from character to GUI? We are currently looking at both sp2 and COBOL-WOW.
>>>sp2 seems to be much simpler GUI. Does this translate into a limited GUI
>>>interface? We are converting DOS, character mode source to GUI.
>>Simple is good. Sp2 *IS* simple. However, it is NOT limited.
>
>What is Sp2?
Hi Moshe:
Our company produces and sells sp2. It is a COBOL Graphical User
Interface Development tool (we also have versions which support
character mode user interface).
To keep the message short and to the point, please visit
http://www.flexus.com for more details.
Bob Wolfe, flexus
Check out The Flexus COBOL Page at http://www.flexus.com
Mojo
>Did you look at ETC's COBOL-WOW product when deciding what tools to use to go
>from character to GUI? We are currently looking at both sp2 and COBOL-WOW.
>sp2 seems to be much simpler GUI. Does this translate into a limited GUI
>interface? We are converting DOS, character mode source to GUI.
*** No we didn't. Mainly because I wasn't familar with it when we
were doing the evaluation. Because we are an MF shop, we evaluated
Dialog (when it was still a separate product and not part of
NetExpress) and SP2. We chose SP2 for a number of reasons:
1) COBOL call convention to interface with the product
2) Compiler independent
3) And, at least to us, it was much more STABLE than Dialog,
especially the earlier versions, in a development environment.
I've been working with the product for about 3 months now.
We have four major software modules and I'm just about done
"gui-izing" one with SP2. I guess my user base will be the final
judges as to whether it is "limited". I don't think so.
Mike Madara
Bob Wolfe
Mike:
I think that COBOL-WOW may only work with RM COBOL. I don't believe
that it works with Micro Focus COBOL. If I am wrong, I will gladly
submit to a beating with a horsewhip at the hands of Bob England in
Elliot, Iowa, home of ETS!
...I'll even pay my own travel expense!