Graphical User Interface
Steven Helsen
I'm planning on making a program (a quiz) in Cobol.
To make it more attractive, I would like to make use of a GUI (I'm kinda fed
up with typing 100s of lines in the screen section just to obtain some lousy
dos-screebs). I also want to work with *.gif or *.jpg pictures (i.e.
displaying them on the screen during the program). I'm using CA-Realia 3.0
on a Win-platform.
My questions:
Steven Helsen
* How can I get a more attractive "lay-out" for a Cobol-program?
* Is it possible to work with pictures in Cobol and, if yes, how to do so?
Thanks in advance,
Steven
s.he...@planetinternet.be
PS: sorry for accidently sending this message twice
Foodman
> * How can I get a more attractive "lay-out" for a Cobol-program?
> * Is it possible to work with pictures in Cobol and, if yes, how to
do so?
Hi:
Check out SP2 from Flexus www.flexus.com - you can do graphics (BMP)
sounds, etc.
Tony Dilworth
Sent via Deja.com http://www.deja.com/
Before you buy.
Ken Foskey
>
> Hi,
>
> I'm planning on making a program (a quiz) in Cobol.
> To make it more attractive, I would like to make use of a GUI (I'm kinda fed
> up with typing 100s of lines in the screen section just to obtain some lousy
> dos-screebs). I also want to work with *.gif or *.jpg pictures (i.e.
> displaying them on the screen during the program). I'm using CA-Realia 3.0
> on a Win-platform.
> My questions:
> * Is it possible to work with pictures in Cobol and, if yes, how to do so?
Why restrict yourself. Make the program work off a browser and use
CGI. This make is totally portable as well. It gives you a new
potential market too.
To imbed graphics in HTML is trivial, setting a web server is becoming
easier and easier now.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
For fast secure document delivery on the Net
http://www.themailxchange.com.au/
Tony M. Mina
don't need screen section in your cobol program. Visit their site at
www.flexus.com. I believe you can download an evaluation copy.
Tony M. Mina
On Sat, 24 Jun 2000 04:07:58 +0200, "Steven Helsen"
<s.he...@planetinternet.be> wrote:
>Hi,
>
>I'm planning on making a program (a quiz) in Cobol.
>To make it more attractive, I would like to make use of a GUI (I'm kinda fed
>up with typing 100s of lines in the screen section just to obtain some lousy
>dos-screebs). I also want to work with *.gif or *.jpg pictures (i.e.
>displaying them on the screen during the program). I'm using CA-Realia 3.0
>on a Win-platform.
>My questions:
>
>
Tony M. Mina
Email: je...@nbnet.nb.ca in...@mc-sys.com
Web: www.mc-sys.com
Bob7536
Flexus Sp2 is a great product and easy to use.
Bob Hennessey
ROBERTO
In my opinion the best is PowerCobol by Fujitsu.
See it at www.adtool.com.
In article <8j15e1$mjf$1...@news.planetinternet.be>, s.he...@planetinternet.be says...
> Hi,
>
> I'm planning on making a program (a quiz) in Cobol.
> To make it more attractive, I would like to make use of a GUI (I'm kinda fed
> up with typing 100s of lines in the screen section just to obtain some lousy
> dos-screebs). I also want to work with *.gif or *.jpg pictures (i.e.
> displaying them on the screen during the program). I'm using CA-Realia 3.0
> on a Win-platform.
> My questions:
> * How can I get a more attractive "lay-out" for a Cobol-program?
> * Is it possible to work with pictures in Cobol and, if yes, how to do so?
> Thanks in advance,
> Steven
> s.he...@planetinternet.be
>
Super-User
Try MicroFocus NetExpress from MERANT
It's the best COBOL development tool anywhere. It has a modern IDE and will handle GUI
and WEB application development extremely well.
Super-User
go to www.merant.com and follow the microfocus or traditional development links. You
should be able to order and evaluation CD
Alternatively go to amazon and look for books by Wilson Price. Among those are: Elements
of COBOL Web Programming using Microfocus NetExpress and the other book is a similar
title but for GUI programming. These are excellent tutorial books and can be ordered with
the University Edition of NetExpress.
If you are a corporate user then contact MERANT through the official channels, details on
www.merant.com
Cheers,
JSA
You are free to believe it is a great product, but it is anything
but easy to use. Your code becomes so entangled with the
windows interface that you might as well write in C++.
A good screen interface would handle all of that for you.
Try GUI Screenio at http://www.screenio.com/
Thane Hubbell
I have been a Screenio AND an sp2 user.
I'm not going to say that one is better than the other, but your
comments lead one to believe that there is a distinct difference in
architecture that makes one more convoluted than the other.
In fact, the two products take very similar approaches. Each paints a
screen in a separate panel (Although Sp2 allows dynamic creation as
well), and each processes this panel by making a call to a custom
runtime. This runtime then returns the reason for the return from the
call and the data values associated with the panel in working storage.
This is not dissimilar from the screen section or from BMS Macros.
As I said I have used both products. In fact, the premise behind both
is excellent - separate your business logic from your user interface.
Given that, how can you say that Sp2 makes the code more "entangled
with the Windows user interface" than Screenio does. It's just not
true.
To quote somone else who frequents this group:
"It's the artist, not the paintbrush."
---
Try a better search engine: http://www.google.com
My personal web site: http://www.geocities.com/Eureka/2006/
Foodman
>
> You are free to believe it is a great product, but it is anything
> but easy to use. Your code becomes so entangled with the
> windows interface that you might as well write in C++.
Hi:
Having used SP2 for more than three years and having converted
more than a quarter-million lines of COBOL, I don't agree with
the above. After all, it really depends on how you use SP2 and
how you stick the required SP2 code into your program. Anybody
could mess that up, perhaps you did?
Thanks
brucepbarrett
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:395f33b5....@207.126.101.100...
> >You are free to believe it is a great product, but it is anything
> >but easy to use. Your code becomes so entangled with the
> >windows interface that you might as well write in C++.
> >
Thane Hubbell
System and PowerCOBOL together for this post if you don't mind - each
takes a similar approach.
Sp2 and Screenio present and process a whole "window" for you.
Control returns to your program when a specific "action" occurs. This
could be a push button, a menu selection or even a change in value in
a field - if you so define your "panel". There's no "CODE" in your
panel definitions -- you simply specify certain field attributes and
this controls how the fields are formatted and when control is
returned to your program.
Calls to the runtime are standard COBOL code.
Dialog System and Fujitsu POWER COBOL are "event driven" tools. There
is a certain level of tedium when creating the (Dialog = Screensets,
PowerCOBOL = Forms). You must put "CODE" behind EACH object on the
screen. With PowerCOBOL this code is COBOL. With Dialog System, this
code is a proprietary language called Dialog System. One big
difference between Dialog System and PowerCOBOL is that the POWERCOBOL
COBOL code behind the objects is compiled into your program. Dialog
System is not, and thus it is interpreted at runtime by the Dialog
System runtime.
Dialog System only now:
As I said, one must put the keys one wishes to detect, and the events
one wishes to respond to in the "dialog" behind each object. The
dialog is evaluated at several levels. When an "event" occurs - be
that a key press, a mouse over, a gain or loss of focus, or whatever,
the runtime first checks the objects dialog to see if any action is
coded for. If not, it then checks the Windows dialog to see if any
action is coded. If not, it then checks the "Global" dialog to see if
any action is coded. This is done for each and every event that
occurs. It can be quite time consuming to code for because you can
have "accidental" effects quite easily. For example. Let's say that
you want a specific action to happen on "lost focus" so you code a
loss focus event in your window dialog. The code behind this event
you want only to execute when the WINDOW loses focus and not any of
the objects in the window. In this case, you have to code dummy noop
lost focus events on each and every control in the window -- or else
your "window" lost focus event will trigger when any object loses
focus. (We battled side effects like this for quite some time until
we came up with some very strict standards for how things were to be
done).
The bottom line is that the root difference is that Dialog System and
PowerCOBOL are event driven tools, where Sp2 and Screenio handle the
event driven tedium for you and return "screens" of data, not unlike a
Screen Section or BMS defined Map with CICS.
Because of this is it MUCH easier to separate the interface from the
application using Sp2 or Screenio.
An additional note - there's more than screen handling that can happen
in "Dialog" - you can move data around, call programs, etc within the
Proprietary dialog language. This makes maintenance harder, as it's
difficult to find out where something is really happening.
James J. Gavan
Thane Hubbell wrote:
>
> Good Question. I have also used Dialog System. I'll lump Dialog
> System and PowerCOBOL together for this post if you don't mind - each
> takes a similar approach.
>
> Sp2 and Screenio present and process a whole "window" for you.
<snip>...
I thought ouch ! when I saw the first query on this topic, but in both
your posts you have been fair - I was a little curious when you
emphasised the separate 'dialog' routines triggered events, but then you
confirmed later that SP2/Scrennio in fact do this for you.
For the other person who commented, note that Bob Hennessey attended a
NetExpress Dialog System course and then finished up using SP2 - what
does that tell you.
Thane your quote "It's the artist not the paintbrush". MCM will be ever
so pleased - you got it right this time <G>
Jimmy
now...@freedsl.com
(http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
If some of you cannot grasp the finesse behind this work, let me just ask one
question: can any of the 3 mess ketir* cited above do what is shown in
picture 1 through 13 in 3 second flat on a 200mhz machine?.
*-One of my middle Eastern friend told me that ketir means "a lot". Got it??
By the way all products have been evaluated, and we are top experts in Dialog
(now try changing fonts in a screenset already loaded, flipping controls or
even moving a control 1 single pixel from is location)
If you can't do it 100% in COBOL then may be you should consider changing
career!
COBOL is dead, Long live COBOL
Nowitt Oal
Ken Foskey
>
> I challenge Dialog, SpII and ScreenIO to even come close to doing this
> (http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
> efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
I am note a power cobol expert but the little I have seen indicates
that it is a fundamentally bad design of code wizards. A little
explanation is needed.
If you design an application in power cobol version xx and upgrade to
version xx+2 does your application magically take on the benefits of
the new release. The answer is no because the code is generated
directly into the application. This also means that bugs in version
xx will not automatically be corrected when you upgrade.
Windows needs to be hidden more behind called modules (or OO methods)
this means that the upgrades will automatically work.
Also putting so much code into the business space leads to a tight
interconnection between the screen and the business. This is bad
design as we move from windows to Unix to other platforms much faster
now days.
The isolation of screenio and SPII gives it some benefits in this
regard. A simple relink is the most that would be needed to correct
some flaw in the screen generation code.
Ken Foskey
>
> I challenge Dialog, SpII and ScreenIO to even come close to doing this
> (http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
> efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
I am note a power cobol expert but the little I have seen indicates
Bob Wolfe
Perhaps I am making an incorrect assumption, but I believe that you
are John Andersen with Norcom, the developers of GUI Screenio,
correct?
If I am incorrect, please forgive me.
But if this is correct, I'm not sure if the COBOL newsgroup is a good
place to start a vendor to vendor flame war.
You are entitled to your opinions regarding our products. Whether
they are easy to use or difficult to use is generally a matter of
personal preference. I know programmers who consider WinAPI
programming easy, but I'm not sure if I share their opinion.
Certainly the Norcom Screenio product is a good user interface
development tool and should be recognized as such.
But it is my belief that the COBOL newsgroup is not the appropriate
place to engage in a product flame war, especially between competing
vendors. These debates are better conducted between the end users.
From time to time, vendors should add their comments in order to
correct inaccuracies or provide suggestions. I doubt that the regular
newsgroup readers/participants want to see a vendor flame war...it's
quite unproductive.
Therefore I will only make the comment that your statement below is
incorrect.
Both sp2 and screenio utilze a CALL USING approach to screen handling.
None of our products require knowledge of the WinAPI, even when
implementing Active X controls, displaying JPG bitmaps, printing
through the Windows Print Manager, running remotely across TCP/IP or
displaying screens directly in the child window of a web browser.
Everything is accomplished with COBOL CALL USING statements, just like
Screenio.
If you wish to debate this through private e-mail, I would be happy to
do so, but as a vendor, I avoid debating these issues directly in the
newsgroup, simply because I don't want to use this forum as a sales or
promotional platform.
"JSA" <j...@kona.penguinpowered.com> wrote:
>In article <20000624140646...@ng-fd1.aol.com>, bob...@aol.com
>(Bob7536) wrote:
>> Good Morning,
>>
>> Flexus Sp2 is a great product and easy to use.
>>
>> Bob Hennessey
>>
>
>You are free to believe it is a great product, but it is anything
>but easy to use. Your code becomes so entangled with the
>windows interface that you might as well write in C++.
>
>A good screen interface would handle all of that for you.
>
>Try GUI Screenio at http://www.screenio.com/
>
>
>
Bob Wolfe, flexus
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com
now...@freedsl.com
now...@freedsl.com wrote:
>
> I challenge Dialog, SpII and ScreenIO to even come close to doing this
> (http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
> efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
I am note a power cobol expert but the little I have seen indicates
that it is a fundamentally bad design of code wizards. A little
explanation is needed.
Yes you are right: You are not an expert. Therefore your opinion has no
significance if no value at all. How can you pretend to speak of
"fundamental bad design" when you know so little about what you can do
with this master tool or even how it is structured.
If you design an application in power cobol version xx and upgrade to
version xx+2 does your application magically take on the benefits of
the new release. The answer is no because the code is generated
directly into the application. This also means that bugs in version
xx will not automatically be corrected when you upgrade.
It is obvious that you have no clue about how PowerCOBOL works.
For your information the system components described in
http://www.ils-international.com/goldmine/newcobol.htm were developed
in Feb. 1999 using version 4.2. In May 2000 they have been rebuild at
a click of button (Project Rebuild Menu option) a few minutes later all
DLL and main EXE run with no glitches under version 5.0b and with
NO user programs modifications.
Your theory is quite false actually. Because the code is indeed generated
directly into the application, we can be sure that any bad code generated
in
the previous version (and we have encountered none) would be generated
correctly, provided that indeed there was some buggy code generated in
the previous version and that Fujitsu has rewrote it.
Windows needs to be hidden more behind called modules (or OO methods)
this means that the upgrades will automatically work.
It is again obvious that you have not understood how PowerCOBOL works.
ALL controls activation-deactivation, manipulation and properties are
performed via the INVOKE "methods" USING "properties".
it is unmistakably Object Orientation. It is OO COBOL. This DOES mean
that upgrades will automatically work. Converting from v. 4.2 to 5.0 DID
prove that your theory is false.
In addition Windows and its cryptic WinAPI ARE hidden totally behind
INVOKE "methods" (CALLed modules using your language).
Also putting so much code into the business space leads to a tight
interconnection between the screen and the business. This is bad
design as we move from windows to Unix to other platforms much faster
now days.
WRONG!! As a wise person did put it earlier, "it's not the brush, it's
the artist"
the system described in
http://www.ils-international.com/goldmine/newcobol.htm was
designed is such a way that COBOL programs are used 100% for the business
logic and the User Interface parameters storage and validation (user
logon,
user taste [colors, fonts, graphics, native tongue, writing direction,
etc., etc. etc.]
are all retrieved, validated, updated and saved using COBOL programs.
The GUI part simply gets what is passed to it by the appropriate COBOL
program
and respond accordingly. In fact one could use Windows handlers such as
SPII
or GUI ScreenIO and connect to the COBOL programs described above and it
would run OK. In fact with some graphic limitations one could use a
character
screen handler such as and use the business and user interface
COBOL programs. In both instances (SPII / GUI ScreenIO and CHAR ScreenIO
one would loose all the other functionality that ONLY PowerCOBOL offers is
the
100% control that the properly trained developer would have over the
COMPLETE
Windows development such as real-time change of ALL controls properties
and
other things such as control flipping, native tongue switching, etc.)
The isolation of screenio and SPII gives it some benefits in this
regard. A simple relink is the most that would be needed to correct
some flaw in the screen generation code.
The isolation of screenio and SPII [and DIALOG SYSTEM] give the
sophisticated
programmer only one thing: Limitations.
Unlike PowerCOBOL which gives you Full power and control over the real
Windows
Environment GUI development like C++, products such as SPII, GUI ScreenIO
and the famous DIALOG SYSTEM still use the old fashion mentality of
DISPLAY/ACCEPT character Screen or the CICS SEND/RECEIVE way of working
with the GUI Windows Environment.
As to "a simple relink is the most that would be needed to correct some
flaw in the screen
generation code", so does PowerCOBOL. A simple click on the "Rebuild
project" Menu
option give you a freshly compiled and relinked application, and thanks to
the generated
code being being part of the application, PowerCOBOL give you something
that now
other Screen Handler can: High speed execution. and lightening speed
window displays.
My regards to the people of the land down under
Nowitt Oal
Gazaloo
brand of expertise to the group but assuming that you do indeed know it all,
there's still no need to be an arrogant pig.
Gazaloo
g...@home.com
Bob Wolfe
>I challenge Dialog, SpII and ScreenIO to even come close to doing this
>(http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
>efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
[snip]
>
>If you can't do it 100% in COBOL then may be you should consider changing
>career!
Nowitt:
I don't care to enter into a vendor debate in the newsgroup as I
mentioned before. Everyone knows ILS sells Fujitsu COBOL.
I can say this. Everyone has different motivations for using a
particular compiler, screen handler or some other type of tool.
I can say this. If the program you demonstrate on your web site is
100% COBOL, then I challenge you to recompile it with any of the
following 32 bit Windows versions of:
CA-Realia II Workbench
Merant NetExpress
Acucorp's Acucobol GT
Liant's RM COBOL
Egan Systems Interactive COBOL
IBM Visual Age
>COBOL is dead, Long live COBOL
>Nowitt Oal
[snip]
Thane Hubbell
> It is again obvious that you have not understood how PowerCOBOL works.
> ALL controls activation-deactivation, manipulation and properties are
> performed via the INVOKE "methods" USING "properties".
> it is unmistakably Object Orientation. It is OO COBOL. This DOES mean
> that upgrades will automatically work. Converting from v. 4.2 to 5.0 DID
> prove that your theory is false.
> The isolation of screenio and SPII [and DIALOG SYSTEM] give the
>sophisticated
> programmer only one thing: Limitations.
>
What is obvious is that you don't understand Sp2, Screenio or Dialog
System. Dialog System and PowerCOBOL have the same "problem". That is
each utilizes an event driven programming model that requires the
programmer to write code for each object on the screen. Sp2 and
Screenio do not. Which is better? I have my opinion, others have
theirs.
I have a suggestion for you. Please, if you are going to compare and
contrast, give specific examples not just generalities. If you are
going to make statements like the above, try not to be so insulting
to your desired audience. Read that again -- it says that if you are
a "Sophisticated" programmer than the other tools give you
limitations. This infers several things: Being a "Sophisticat" is
good. If you are not such a programmer, you are not good. PowerCOBOL
is unlimited. (Really?).
I'm asking you also to please tone this down a bit. I don't think you
realize it but you are coming off as a bit of a snakeoil salesman.
If this is Roger (and I don't think it is, but I could be wrong) or
someone who works for Roger, please give me a call -- you have my
number and we need to talk.
> Unlike PowerCOBOL which gives you Full power and control over the real
>Windows
> Environment GUI development like C++, products such as SPII, GUI ScreenIO
> and the famous DIALOG SYSTEM still use the old fashion mentality of
> DISPLAY/ACCEPT character Screen or the CICS SEND/RECEIVE way of working
> with the GUI Windows Environment.
>
> As to "a simple relink is the most that would be needed to correct some
>flaw in the screen
> generation code", so does PowerCOBOL. A simple click on the "Rebuild
>project" Menu
> option give you a freshly compiled and relinked application, and thanks to
>the generated
> code being being part of the application, PowerCOBOL give you something
>that now
> other Screen Handler can: High speed execution. and lightening speed
>window displays.
>
>My regards to the people of the land down under
>Nowitt Oal
>
>Thanks
>Ken Foskey
>http://www.zipworld.com.au/~waratah/
>
>For fast secure document delivery on the Net
>http://www.themailxchange.com.au/
>
>
---
William M. Klein
I only read his "first" name and thought that it was fairly accurate, i.e.
"No Wit"
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Gazaloo" <g...@home.com> wrote in message
news:zo585.24835$i5.2...@news1.frmt1.sfba.home.com...
now...@freedsl.com
What is obvious is that you don't understand Sp2, Screenio or Dialog
System. Dialog System and PowerCOBOL have the same "problem". That is
each utilizes an event driven programming model that requires the
programmer to write code for each object on the screen. Sp2 and
Screenio do not. Which is better? I have my opinion, others have
theirs.
Perhaps it is you who really did not understand my lines:
I have described SPII and GUI ScreenIO as Screen handler similar to CICS
and the old character ScreenIO based on the ACCEPT/DISPLAY technology.
DIALOG although is somewhat Event Driven - I grant you that - behave still as
if one is working with the character screen ACCEPT/DISPLAY. The proof?
There is noway in DIALOG to return to the COBOL program that has
loaded the screenset until you do a RETC - which technically is a SEND screen.
Once you return to the COBOL program and AS LONG AS the program
is processing - let say a large database search - your active window in the
screenset
is ""dead". You can do nothing with it: enrty fields are locked, radio/check
buttons
are inoperable, etc.. they do not come back "alive" until the COBOL program
performs a CALL DIALOG-SYSTEM USING DATABLOCK....It is technically
a RECEIVE screen.
If the user desides that it was enough waiting for the data to show on the
screen and clicks on
-let say an "Exit" button the "Event" will not be processed until the COBOL
program has
completed the CALL DIALOG-SYSTEM....
This what I would call "faked" Event Driven support.
I have a suggestion for you. Please, if you are going to compare and
contrast, give specific examples not just generalities. If you are
going to make statements like the above, try not to be so insulting
to your desired audience. Read that again -- it says that if you are
a "Sophisticated" programmer than the other tools give you
limitations. This infers several things: Being a "Sophisticat" is
good. If you are not such a programmer, you are not good. PowerCOBOL
is unlimited. (Really?).
Specific example? Hum...
1- DIALOG, SPII, GUI ScreenIO. Try moving a control, any control
from one place to another on a window at runtime.
2-DIALOG, SPII, GUI ScreenIO. Try flipping controls as if you were
looking at them in a mirror at runtime.
3-DIALOG try changing fonts in a screenset already loaded in memory.
Datablock - Why one has to carry all that fat unused space in the screenset
just because i.e. the fourth program down the line is using a table or 20
rows
of 250 bytes?
4-DIALOG why to you have to build multiple screensets and "push 'n pop"
screenset clugging memory with bulky screensets megabytes sized? Not to
mention the record breaking craches for corrupted memory
I could go on for a long time...
Good or bad has nothing to do with being "Sophisticated".
By "Sophisticated programmer" I mean someone who is looking
into accomplishing much more that the average programmer
who is given a tool, GUI or otherwise, happy to accept just
what the tool is allowing him/her to accomplish.
With GUI tools mentioned in this topic, the programmer's
imagination and creativity are limited by those tools.
With PowerCOBOL the capabilities of the tool are limited only by
the probrammer's imagination and creativity which makes the tool unlimited.
I'm asking you also to please tone this down a bit. I don't think you
realize it but you are coming off as a bit of a snakeoil salesman.
It seems that you asking to too many people to "tone down a bit" today...
What are you? Somekind of user group classroom teacher??
Anyhow, why is it that when highlighing defects and qualities of various
product is someone accused of being snakeoil salesman?
If this is Roger (and I don't think it is, but I could be wrong) or
someone who works for Roger, please give me a call -- you have my
number and we need to talk.
Yes. You are 100% wrong I am no Roger, and I do not have your number.
I will be happy to call you if provide me with it. My direct email is
now...@freedsl.com.
Regards
Thane Hubbell
> Perhaps it is you who really did not understand my lines:
>
> I have described SPII and GUI ScreenIO as Screen handler similar to CICS
> and the old character ScreenIO based on the ACCEPT/DISPLAY technology.
>
Such Features make these two ideal for legacy code conversion.
> DIALOG although is somewhat Event Driven - I grant you that - behave still as
> if one is working with the character screen ACCEPT/DISPLAY. The proof?
> There is noway in DIALOG to return to the COBOL program that has
> loaded the screenset until you do a RETC - which technically is a SEND screen.
> Once you return to the COBOL program and AS LONG AS the program
> is processing - let say a large database search - your active window in the
>screenset
> is ""dead". You can do nothing with it: enrty fields are locked, radio/check
>buttons
> are inoperable, etc.. they do not come back "alive" until the COBOL program
> performs a CALL DIALOG-SYSTEM USING DATABLOCK....It is technically
> a RECEIVE screen.
When multi-threading is NOT used with PowerCOBOL the same is true of
it, is it not?
> Specific example? Hum...
> 1- DIALOG, SPII, GUI ScreenIO. Try moving a control, any control
> from one place to another on a window at runtime.
>
This is possible with Sp2, but I don't really want my
users manipulating the user interface.
> 2-DIALOG, SPII, GUI ScreenIO. Try flipping controls as if you were
> looking at them in a mirror at runtime.
>
What is the real world advantage of this? Serious question.
>
> With GUI tools mentioned in this topic, the programmer's
> imagination and creativity are limited by those tools.
> With PowerCOBOL the capabilities of the tool are limited only by
> the probrammer's imagination and creativity which makes the tool unlimited.
Check past news group postings for PowerCOBOL limitations - especially
in the area of a high number of items in a list box. Even PowerCOBOL
has it's limitations.
>
>I'm asking you also to please tone this down a bit. I don't think you
>realize it but you are coming off as a bit of a snakeoil salesman.
>
> It seems that you asking to too many people to "tone down a bit" today...
> What are you? Somekind of user group classroom teacher??
> Anyhow, why is it that when highlighing defects and qualities of various
> product is someone accused of being snakeoil salesman?
I'm actually trying to help you. I'm nobody. I'm just a user of
these products and a programmer. However, I have also been involved
in marketing myself and my products. You may not realize it, and this
is where I am trying to help you -- and Paul from Merant: You begin
to sound insulting and franky, Rabid after a time. Additionaly you
are posting frequently and repetatively. This is known as news group
Spam. I'm gratified to see that you are reading the responses to your
messages -- this alone separates your messages from spam. From the
other replies I am sure you can see that I am not the only reader that
has a negative attitude after reading one of your messages.
What I'm trying to say is -- You'll attract more flies with honey.
Try posting messages touting the advantages and features of your
product WITHOUT even mentioning the "Competition". If your tool is
indeed that superior there will be no need to slam the competition --
the tool will speak for itself.
>
>If this is Roger (and I don't think it is, but I could be wrong) or
>someone who works for Roger, please give me a call -- you have my
>number and we need to talk.
>
> Yes. You are 100% wrong I am no Roger, and I do not have your number.
> I will be happy to call you if provide me with it. My direct email is
>now...@freedsl.com.
I don't use the phone much. You have my email address if you wish to
dicuss any of this privately.
Michael Mattias
news:395FB812...@home.com...
>
> Thane your quote "It's the artist not the paintbrush". MCM will be ever
> so pleased - you got it right this time <G>
>
Thane obviously be good people.
MCM
William M. Klein
a SINGLE user who seems to be "supporting" the tone of your posts?
--
Bill Klein
wmklein <at> ix dot netcom dot com
<now...@freedsl.com> wrote in message news:39612B21...@freedsl.com...
>
<snip>
>
> That's the spirit Bob. Healthy debates can only be beneficial to
the
> users by giving
> them information they would perhaps never get otherwise.
Jerry P
Ken Foskey <war...@zip.com.au
>
> I am note a power cobol expert but the little I have seen indicates
> that it is a fundamentally bad design of code wizards. A little
> explanation is needed.
>
> If you design an application in power cobol version xx and upgrade
to
> version xx+2 does your application magically take on the benefits of
> the new release. The answer is no because the code is generated
> directly into the application. This also means that bugs in version
> xx will not automatically be corrected when you upgrade.
You're right. Upgrading from version "x" to version "y" doesn't do
anything for modules compiled under version "x." Upgrading from
COBOL65 to COBOL85 doesn't do anything for programs compiled under
COBOL65 either. Since the OO code in PowerCobol is, in fact, COBOL,
it's obvious that you must recompile to take advantage of new features
or bug fixes. This is not a big deal.
One small example: Version 5 of PowerCobol added word-wrap to text
boxes. In order for our programs to take advantage of the new feature,
we had to check an option box on the form designer and recompile the
programs. It seems to me this is no different than having COBOL65
programs and wanting to use in-line performs or reference
modification. I'd have to recompile with a newer compiler. If we
didn't need or want the word-wrap feature, there would be no need for
immediate recompilation.
>
> Windows needs to be hidden more behind called modules (or OO
methods)
> this means that the upgrades will automatically work.
Nah. Not if you didn't code for the new feature. In the case above, we
were able to discard our hand-crafted word-wrap routine and let
PowerCobol handle wrapping text lines. In the case of bugs, you may
have originally included circumvention code to handle a bug. Now that
the bug is gone, your circumvention code may become a bug!
>
> Also putting so much code into the business space leads to a tight
> interconnection between the screen and the business. This is bad
> design as we move from windows to Unix to other platforms much
faster
> now days.
Not necessarily. It is possible in PowerCobol to put ALL the business
logic in mainline routines that are intersected by event procedures.
>
> The isolation of screenio and SPII gives it some benefits in this
> regard. A simple relink is the most that would be needed to correct
> some flaw in the screen generation code.
Yep. I bet, however, that there are many, many more bugs in the
business logic code (necessitating a recompile plus link) than in the
proprietary screen routines (link only).
Jerry P
Thane Hubbell <tha...@softwaresimple.com>
>
> What is obvious is that you don't understand Sp2, Screenio or Dialog
> System. Dialog System and PowerCOBOL have the same "problem". That
is
> each utilizes an event driven programming model that requires the
> programmer to write code for each object on the screen.
Nope. In PowerCOBOL you need not write an event for ANYTHING on the
screen. You write code only for the things in which you are
interested. We've never written any code for such things as the user
resizing the window, mouse movements, or hundreds of other things.
William M. Klein
> On Tue, 04 Jul 2000 00:07:00 GMT, now...@freedsl.com wrote:
>
<SNIP>
> >
> > Although not compiled under some of the above compilers, the
program
> >would
> > compile and execute error free if all of the above are certified
ANSI
> >COBOL-85.
>
> That's just a plainly untrue. The Syntax used by ANY vendor to
> interface with the API is non standard. The second you use a COMP-5
> field you are non-standard. You see, these are EXTENSIONS to the
> standard. Please, please please refrain from making such statements
> that are blantenly unsupportable. You simply look silly. You
> yourself said that PowerCOBOL generated OO syntax, using INVOKE etc in
> order to function. You claimed it to be comletely OO. There is no OO
> in the 85 standard, so any of the MANY Ansi 85 compilers will NOT be
> able to compile the code. In fact, only one can. That's no fault of
> Fujitsu at this point -- there IS NO STANDARD.
>
Although Thane has already pointed out how silly (and conflicting) your
comments are (especially when you simultaneously claim to be ANSI'85
compliant *and* to use the INVOKE statement), I thought I would suggest that
you compile just ONE of your PowerCOBOL programs with the Fujitsu compiler
directive,
FLAGSW(STDH)
Then post your output showing exactly how ANSI compliant (or not) you really
are. Again, as Thane pointed out, this is not a problem (per se) with
Fujitsu, it is simply a case of where CLAIMING your code is portable across
compilers because it is ANSI compliant, is too full of holes to have any
credibility.
William M. Klein
news:kJc85.123$Vp5.1...@nnrp1.sbc.net...
>
> Thane Hubbell <tha...@softwaresimple.com>
> >
> > What is obvious is that you don't understand Sp2, Screenio or Dialog
> > System. Dialog System and PowerCOBOL have the same "problem". That
> is
> > each utilizes an event driven programming model that requires the
> > programmer to write code for each object on the screen.
>
> Nope. In PowerCOBOL you need not write an event for ANYTHING on the
> screen. You write code only for the things in which you are
> interested.
Jerry, I think you are missing the point. when you write code for the things
"in which you are interested" - what PowerCOBOL (and Dialog) both do is
require you to associate that with an "event" for that thing. This is what
the "event driven programming model" means - and PowerCOBOL does work that
way. The event may be data entry, change of focus, or any of a NUMBER of
other "events" - but they most definitely ARE "events" in this sense of the
word.
Jerry P
Thane Hubbell <tha...@softwaresimple.com>
>
> > DIALOG although is somewhat Event Driven - I grant you
that - behave still as
> > if one is working with the character screen ACCEPT/DISPLAY.
The proof?
> > There is noway in DIALOG to return to the COBOL program
that has
> > loaded the screenset until you do a RETC - which
technically is a SEND screen.
> > Once you return to the COBOL program and AS LONG AS the
program
> > is processing - let say a large database search - your
active window in the
> >screenset
> > is ""dead". You can do nothing with it: enrty fields are
locked, radio/check
> >buttons
> > are inoperable, etc.. they do not come back "alive" until
the COBOL program
> > performs a CALL DIALOG-SYSTEM USING DATABLOCK....It is
technically
> > a RECEIVE screen.
>
> When multi-threading is NOT used with PowerCOBOL the same is true of
> it, is it not?
Don't think so, if I understand what you're saying. Assume a program
is processing a large database. On the screen is a button labeled
"Stop." The program has an event procedure to set the variable
STOP-BUTTON-PRESSED to "Y" when the user clicks the button. The
program can test STOP-BUTTON-PRESSED for "Y" anytime.
> Check past news group postings for PowerCOBOL limitations -
especially
> in the area of a high number of items in a list box. Even
PowerCOBOL
> has it's limitations.
I dunno. I put 65,000 100-character lines in a listbox and PowerCOBOL
didn't croak (it slowed significantly as Windows paged stuff
in-and-out, though).
>
>
Jerry P
Gazaloo <g...@home.com> wrote in message
news:zo585.24835$i5.2...@news1.frmt1.sfba.home.com...
> Nowitt Oal (Know It All? gotta be a joke...), appreciate you adding
your own
> brand of expertise to the group but assuming that you do indeed know
it all,
> there's still no need to be an arrogant pig.
I think he's young. For most of us old COBOL farts, testosterone is
but a wistful memory, the hint of a smile, and fond remembrance my
friend "Woody" ("Hell, woman, it's like beaver teeth, you gotta keep
it wore down or it'll kill ya!) It now takes me all night to do what
I used to could do all night.
Sigh.
now...@freedsl.com
Bob Wolfe wrote:
now...@freedsl.com wrote:
>I challenge Dialog, SpII and ScreenIO to even come close to doing this
>(http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
>efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
[snip]
>
>If you can't do it 100% in COBOL then may be you should consider changing
>career!
Nowitt:
I don't care to enter into a vendor debate in the newsgroup as I
mentioned before. Everyone knows ILS sells Fujitsu COBOL.
That's the spirit Bob. Healthy debates can only be beneficial to the
users by giving
them information they would perhaps never get otherwise. Now this does
not
necessarily make me an ILS salesman, but I do participate actively to
COBOL Gold Mine.
It is true that ILS sells Fujitsu COBOL - tested by COBOL Gold Mine and
found to be the best.
But it is also true that ILS does not sell CA-Realia COBOL. Yet I can
tell you - and the
rest of the audience that Realia COBOL WAS THE BEST ever COBOL compiler
for DOS
(quality & execution speed) I was top expert in that product also
1984-1990. I designed and
wrote 4 systems totaling nearly 1 million LOC with the product.
During the same period, I also used Character ScreenIO to the maximum of
its usability
again ILS does not sell it but ScreenIO is till today at the TOP OF ITS
CLASS.
I still like it. But that is the past and today the word is PowerCOBOL.
Times are a changin'.
I can say this. Everyone has different motivations for using a
particular compiler, screen handler or some other type of tool.
And I agree with you. Many people drive a Cadillac, a Mercedes, a Ferrari
or a Lexus. Others
drive a VW or a ford Escort and are happy with what they got until one
day they have
the opportunity to drive a Cadillac, a Mercedes, a Ferrari or a Lexus.
Then is when they
will understand the difference and will be wishing for more "power" when
they go back to their
VW or a ford Escort. In this context PowerCOBOL is simply the Lexus or a
Ferrari.
I agree also with you that some still would not want to trade their VW
for a Lexus or a Ferrari.
I can say this. If the program you demonstrate on your web site is
100% COBOL, then I challenge you to recompile it with any of the
following 32 bit Windows versions of:
CA-Realia II Workbench
Merant NetExpress
Acucorp's Acucobol GT
Liant's RM COBOL
Egan Systems Interactive COBOL
IBM Visual Age
Although not compiled under some of the above compilers, the program
would
compile and execute error free if all of the above are certified ANSI
COBOL-85.
As it is mentioned in
http://www.ils-international.com/goldmine/newcobol.htm
a majority of the programs were developed from the mid 1980s to early
1990s using
a different COBOL Compiler. They have been enhanced functionality wise
and recompiled
without compatibility issues because there was a strict discipline in
using 100%
ANSI COBOL-85 standards in coding. I. e. Why use a vendor specific
function
to convert a COBOL string from upper to lower case and vice versa. When
changing
compiler this surely will create a problem. Instead use the COBOL-85
Statement
INSPECT WS-X REPLACING 'ABC......XYZ' WITH 'abc....xyz' (and vice versa).
Any COBOL Compiler supporting ANSI COBOL-85 should accept the above
statement without generating an error and would give the correct result
when
converting the string.
All Business Logic and User Interface parameters management is handled
100% using COBOL-85 with the exception of a main module handling all
ASSIGN TOs and FDs. Statements getting physical file names from System
variables in UNIX/DOS/Windows can easily be deleted and handled by JCL
if there ever was a need to move the application to and IBM S/390 for
example.
The main module than handles ALL System CALLs to the Operating System
such
as GETDIR, MKDIR, GETDISKSPACE etc. can also be relatively easy to
modified to replace or simply eliminate System Functions that are not
needed on
the target platform (GETDIR, MKDIR, GETDISKSPACE would not be needed
under MVS and under UNIX can quickly be modified)
>COBOL is dead, Long live COBOL
>Nowitt Oal
[snip]
Thane Hubbell
>I can say this. If the program you demonstrate on your web site is
>100% COBOL, then I challenge you to recompile it with any of the
>following 32 bit Windows versions of:
>
>CA-Realia II Workbench
>Merant NetExpress
>Acucorp's Acucobol GT
>Liant's RM COBOL
>Egan Systems Interactive COBOL
>IBM Visual Age
>
> Although not compiled under some of the above compilers, the program
>would
> compile and execute error free if all of the above are certified ANSI
>COBOL-85.
That's just a plainly untrue. The Syntax used by ANY vendor to
interface with the API is non standard. The second you use a COMP-5
field you are non-standard. You see, these are EXTENSIONS to the
standard. Please, please please refrain from making such statements
that are blantenly unsupportable. You simply look silly. You
yourself said that PowerCOBOL generated OO syntax, using INVOKE etc in
order to function. You claimed it to be comletely OO. There is no OO
in the 85 standard, so any of the MANY Ansi 85 compilers will NOT be
able to compile the code. In fact, only one can. That's no fault of
Fujitsu at this point -- there IS NO STANDARD.
Additionally there are calls to Fujitsu specific routines that are not
part of any of the other Vendors code. PowerCOBOL is a Fujitsu
PowerCOBOL only solution. Even using Fujitsu (Which has an EXCELLENT
Product in their Regular and Enhanced (POWERCOBOL) offerings cannot
compile and run PowerCOBOL applications using Standard Fujitsu COBOL.
That is kind of the point behind having a proprietary solution.
One last note before I close. I know of NO deficincies in the Fujitsu
offering. I have found the products to be of above average quality,
generally free of bugs and performing as advertised (By Fujitsu) and
my comments in this debate should not be construed as Anti PowerCOBOL
or Anti Fujitsu in any way. I am a VERY satisfied Fujitsu customer.
My SOLE objection to PowerCOBOL is Architectural. I don't like having
to hadle the tedium of event driven programming if I don't have to.
Now in closing, I hope what I have pointed out above has helped you to
see just how you are coming across, how desparate you sound and how
silly the whole thing is. If not, I'm going to stop because you are
doing a good enough job on your own. I tried.
James J. Gavan
now...@freedsl.com wrote:
I've been watching this thread, and to satisfy my curiosity, could you
please produce COBOl source code for the following window, plus any
validity checks you want to throw in :-
............................................
Customer # [ ]
Customer Name [ ]
<OK> <Cancel>
.............................................
It's not a catch question - but at least may help to illustrate your
points, without a diatribe.
Jimmy, Calgary AB
Ken Foskey
>
> Ken Foskey <war...@zip.com.au
>
> >
> > I am note a power cobol expert but the little I have seen indicates
> > that it is a fundamentally bad design of code wizards. A little
> > explanation is needed.
> >
> > If you design an application in power cobol version xx and upgrade
> to
> > version xx+2 does your application magically take on the benefits of
> > the new release. The answer is no because the code is generated
> > directly into the application. This also means that bugs in version
> > xx will not automatically be corrected when you upgrade.
>
> You're right. Upgrading from version "x" to version "y" doesn't do
> anything for modules compiled under version "x." Upgrading from
> COBOL65 to COBOL85 doesn't do anything for programs compiled under
> COBOL65 either. Since the OO code in PowerCobol is, in fact, COBOL,
> it's obvious that you must recompile to take advantage of new features
> or bug fixes. This is not a big deal.
You are missing the point. What about if the bug is in the code that
the wizard generated for you, i.e. the cobol source? Far to much code
is generated to use a feature and this is the problem. You have
pointed out an instance where this is not the case but I am certain
that there are other cases as I describe.
Hajo Schepker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 03.07.00, 20:06:44, schrieb fle...@epix.net (Bob Wolfe) zum Thema Re:
Graphical User Interface:
>snip<
> I can say this. If the program you demonstrate on your web site is
> 100% COBOL, then I challenge you to recompile it with any of the
> following 32 bit Windows versions of:
> CA-Realia II Workbench
> Merant NetExpress
> Acucorp's Acucobol GT
> Liant's RM COBOL
> Egan Systems Interactive COBOL
> IBM Visual Age
You are a millionaire? :-))).
Mit freundlichen Grüßen
H. Schepker
www.schepker.de
Ken Foskey
>
> Ken Foskey wrote:
> now...@freedsl.com wrote:
> >
> > I challenge Dialog, SpII and ScreenIO to even come close to doing this
> > (http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
> > efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
>
> I am note a power cobol expert but the little I have seen indicates
> that it is a fundamentally bad design of code wizards. A little
> explanation is needed.
> Yes you are right: You are not an expert. Therefore your opinion has no
> significance if no value at all. How can you pretend to speak of
> "fundamental bad design" when you know so little about what you can do
> with this master tool or even how it is structured.
I appreciate you have a different opinion. What you call a benefit I
call a draw back, I hate code. I like my source small and compact and
focused on the business requirements. I have reviewed the output of
Powercobol and I believe it is bad due to the code bloat introduced.
I have seen wizard type code building happen to many other compilers,
Microsoft C, Borland C went with the wizards (similar to power cobol)
about 5 years ago. They now encapsulate functionality as I describe.
Microsoft does still use them to some degree however and if you look
in comp.object you will see some opinions on this, negative
unfortunately.
Cobol is some 5 years behind in the windows race. I think that the
cobol vendors must understand what else is out there and look at the
bad design decisions that the others made and put simply not make them
again.
Thane Hubbell
wrote:
>> When multi-threading is NOT used with PowerCOBOL the same is true of
>> it, is it not?
>
>Don't think so, if I understand what you're saying. Assume a program
>is processing a large database. On the screen is a button labeled
>"Stop." The program has an event procedure to set the variable
>STOP-BUTTON-PRESSED to "Y" when the user clicks the button. The
>program can test STOP-BUTTON-PRESSED for "Y" anytime.
>
Try this when deployed using the single threaded runtime. I think you
will see that the same thing happens as happens with dialog. Only one
thing can happen at a time. The Window may accept the push of the
button, but control will not return to process the message and set the
flag until your database access finishes. That is UNLESS there is
another thread processing the window and updating the flag in memory.
This multi-treading is a powerful part of PowerCOBOL and is included
in the development version by default, but not in the runtime
distribution unless you specifically install and request it.
>> Check past news group postings for PowerCOBOL limitations -
>especially
>> in the area of a high number of items in a list box. Even
>PowerCOBOL
>> has it's limitations.
>
>I dunno. I put 65,000 100-character lines in a listbox and PowerCOBOL
>didn't croak (it slowed significantly as Windows paged stuff
>in-and-out, though).
That's a limitation. I'm not saying PowerCOBOL is bad. Far from it.
It's just that the original poster is, shall we say, a little over
enthusiastic.
Jerry P
William M. Klein
> >
> > Nope. In PowerCOBOL you need not write an event for ANYTHING on
the
> > screen. You write code only for the things in which you are
> > interested.
>
> Jerry, I think you are missing the point. when you write code for
the things
> "in which you are interested" - what PowerCOBOL (and Dialog) both do
is
> require you to associate that with an "event" for that thing. This
is what
> the "event driven programming model" means - and PowerCOBOL does
work that
> way. The event may be data entry, change of focus, or any of a
NUMBER of
> other "events" - but they most definitely ARE "events" in this sense
of the
> word.
>
Uh, OK. I guess I am missing the point. We can agree that with
PowerCOBOL, inter alia, if you are not interested in something on the
screen, you need not write any code for that something (say a mouse
movement or screen resize). Right?
I would think the converse would be axiomatic in any development
system: If you are interested in what the user did, you HAVE to write
code to process the situation (say a customer name change or a check
amount).
I was quibbling about the other two cases: (1) Code for ALL possible
events (including ones in which you have no interest) and (2) NO code
for items that do excite you (say a customer name change). The first
(in PowerCOBOL) is not true, and the second seems impossible. Although
in the latter, I admit, some data validation (dates, value ranges,
even spelling) could take place without the programmer's supervision.
Jerry P
Ken Foskey <war...@zip.com.au
>
> You are missing the point. What about if the bug is in the code
that
> the wizard generated for you, i.e. the cobol source? Far to much
code
> is generated to use a feature and this is the problem. You have
> pointed out an instance where this is not the case but I am certain
> that there are other cases as I describe.
>
almost as proto-code and passes my original source through the
equivalent of a precompiler. The result - which is finally handed to
the compiler - bears only a passing resemblence to the code I wrote.
If one is worried about a bug in the 'Wizard' (or precompiler), the
chance of that is, in my experience, vanishingly small. On the order
of a bug in the compiler itself or the Linkage Editor. Not to say
compler bugs can't happen, of course, but they're so far below the
radar, they're subterranean.
In my view, a bug in the PowerCOBOL 'Wizard' (if one exists and I hit
it) would be equivalent to a bug in the panel processor run-time of
SP2 or a bug in the compiler itself; I can wait for a fix from the
vendor or code around the problem.
That's my story, and I'm stickin' to it. If you beat me, I might
change my mind.
Jerry Peacock
Paddy Coleman
Did someone say they would like a way to change the fonts in Dialog
at runtime? If so, then I have a small utility/demo which shows how
to do it.
If you are interested then please feel free to email me directly and I
will send it to you.
All the best.
Paddy Coleman
Manager, E-Business Support, EMEA
MERANT International.
Jerry P <jer...@bisusa.com> wrote in message
news:wYm85.339$Kz2.1...@nnrp2.sbc.net...
Paddy Coleman
attributes in Dialog System at runtime now. This is done via the
DSOBJCFG utility. More information can be found in the Dialog
System online help.
All the best.
Paddy Coleman
Manager, E-Business Support, EMEA
MERANT International.
Paddy Coleman <paddy....@merant.com> wrote in message
news:8jt664$1hd$1...@hyperion.mfltd.co.uk...
now...@freedsl.com
Ken Foskey <war...@zip.com.au
>
> You are missing the point. What about if the bug is in the code
that
> the wizard generated for you, i.e. the cobol source? Far to much
code
> is generated to use a feature and this is the problem. You have
> pointed out an instance where this is not the case but I am certain
> that there are other cases as I describe.
>
I agree with your observation. PowerCOBOL treats my COBOL source code
almost as proto-code and passes my original source through the
equivalent of a precompiler. The result - which is finally handed to
the compiler - bears only a passing resemblence to the code I wrote.
If one is worried about a bug in the 'Wizard' (or precompiler), the
chance of that is, in my experience, vanishingly small. On the order
of a bug in the compiler itself or the Linkage Editor. Not to say
compler bugs can't happen, of course, but they're so far below the
radar, they're subterranean.
IF according to what you state above and your first comment "> >
I am note a power cobol
expert but the little I have seen indicates that it is a
fundamentally bad design of code wizards.<<"
AND if you are familiar with CICS, then CICS also "s a
fundamentally bad design of code wizards"
Both CICS and PowerCOBOL are similar in concepts and
architectural design...
1- Both handle online-user interface through interactive
screen the 1st character, the 2d graphical
2- Both offer a screen design the 1st BMS (character, the 2d
PowerFORM editor (graphical)
3- Both offer a screen layout code generator the 1st Symbolic
map, the 2d WS and Procedure code
4- Both need COBOL user program(s) to get the data from the
user interface (CUI or GUI)
and pass it to a procedure for validation/business processing
(within the same program of
by CALLing another one.
5- Both use a "Wizard" to transform the code written by the
programmer to more complex
sets of statements,
-the 1st trough a "pre-compiler" transforms all
"clear" CICS code between
EXEC-CICS....END-EXEC to more "cryptic" COBOL
statements that few COBOL
programmers ever dared or cared to take a close look
at. When modifications or
enhancements are needed. The programmer goes to the
original program source to
do the work NOT to the source code generated by the
pre-compiler and then
re-pre-compile and compile again!!
-the 2d through a "wizard" transforms all "clear"
INVOKE statements, Windows controls
and "Windows Event" handling designed and coded
through PowerCOBOL forms/controls
"properties" and "methods" to more "cryptic"
COBOL/WINAPI calls statements that COBOL
programmers really should NOT care to take a close
look at. When modifications or
enhancements are needed. The programmer should go to
PowerFORM tool to do the work
NOT to the source code generated by the PowerFORM
"wizard" and then click the
Project rebuild menu option to "re-generate
(re-pre-compile) and compile again!!
So according to You Mr. Foskey and Mr. Peacock IBM had it
aaaaalllllll wrong for over
twenty years now. Gee! I wonder what it would take to have
IBM admit the incompetence
of their CICS engineers and hire you to head their CICS
System team!!! Not to mention that
according to your statements the Fujitsu PowerCOBOL team is
also "headed by the same" type
of people as IBM.
...but there are 2 major differences
-The 1st is "Screen based" hence "single event"
handling.
-The "pre-compiler" generates less COBOL code because
it only deals with a
24 x 80 character screen and only handle the event of
the "SEND" screen
triggered by ONE of the following: Enter key /
PA(1,2,3) key, CLEAR key,
PF1-24 keys, etc...
-The 2d is "Graphical" and is "Windows and Controls
based" hence "multiple events "
handling
-The "Wizard" generates a lot more COBOL code because
it has to create instances
of windows and ALL their controls (as opposed to 24 x
80) and has to handle all events
that NEED TO BE HANDLED for the user INCLUDING the
Event of the use of other
windows. THIS IS BOUND to use more COBOL code. I am
not 100% sure but I
believe there are around 480 Windows "Events"!!
In my view, a bug in the PowerCOBOL 'Wizard' (if one exists and I hit
it) would be equivalent to a bug in the panel processor run-time of
SP2 or a bug in the compiler itself; I can wait for a fix from the
vendor or code around the problem.
Agree 100%!
Foodman
>
>With GUI tools mentioned in this topic, the programmer's
>imagination and creativity are limited by those tools.
>With PowerCOBOL the capabilities of the tool are limited only by
the probrammer's imagination and creativity which makes the tool
unlimited.
Hi:
Why not post a program which you have written which will
demonstrate conclusively that you know what you are
talking about?
Thanks
TOny Dilworth
Sent via Deja.com http://www.deja.com/
Before you buy.
Thane Hubbell
> So according to You Mr. Foskey and Mr. Peacock IBM had it
>aaaaalllllll wrong for over
> twenty years now. Gee! I wonder what it would take to have
>IBM admit the incompetence
> of their CICS engineers and hire you to head their CICS
>System team!!! Not to mention that
> according to your statements the Fujitsu PowerCOBOL team is
>also "headed by the same" type
> of people as IBM.
>
You don't seem to know when to give up. Even a cursory read of
Jerry's posts should lead you to realize that he has EXTENSIVE
PowerCOBOL experience and actually LIKES the product a great deal. He
was AGREEING with you to some degree.
Can you please answer a question (Unrelated to the above observation).
With PowerCOBOL is there a single data area returned corresponding to
data on the "form" containing all of the data values under a single 01
level -- as is the case of a RECIEVE MAP with CICS? This is a serious
query.
now...@freedsl.com
If you can read my lines correctly, try to "read my lips"!
Here it is below one more time in a simple form of bullets:
Thane Hubbell wrote:
On Tue, 04 Jul 2000 00:07:00 GMT, now...@freedsl.com wrote:
>I can say this. If the program you demonstrate on your web site is
>100% COBOL, then I challenge you to recompile it with any of the
>following 32 bit Windows versions of:
>
>CA-Realia II Workbench
>Merant NetExpress
>Acucorp's Acucobol GT
>Liant's RM COBOL
>Egan Systems Interactive COBOL
>IBM Visual Age
>
> Although not compiled under some of the above compilers, the program
would
> compile and execute error free if all of the above are certified ANSI
COBOL-85.
That's just a plainly untrue. The Syntax used by ANY vendor to
interface with the API is non standard. The second you use a COMP-5
field you are non-standard. You see, these are EXTENSIONS to the
standard. Please, please please refrain from making such statements
that are blantenly unsupportable. You simply look silly. You
yourself said that PowerCOBOL generated OO syntax, using INVOKE etc in
order to function. You claimed it to be comletely OO. There is no OO
in the 85 standard, so any of the MANY Ansi 85 compilers will NOT be
able to compile the code. In fact, only one can. That's no fault of
Fujitsu at this point -- there IS NO STANDARD.
O The entire business and data validation/manipulation is written in ANSI-85
o The files manipulation central program (READ, WRITE, DELETE) is
written in ANSI-85
o No use whatsoever of COMP-5, COMP-X , Level 78 etc..
o No use of INVOKE or any OO syntax
o No Fujitsu COBOL specific routines (i.e.. use INSPECT REPLACING
instead of
to_upper / to_lower) functions
o Single program centralizing all SYSTEM CALLS (getdir, mkdir,etc).
can be eliminated or modified easily)
o Reporting programs write to disk files which are redirected to
print
spooler.
o All data and parameters - user and system are passed using LINKAGE
SECTION
to the CUI or GUI interface program. (in the case of CUI character
ScreenIO
was used in the case of GUI, VB was used years ago but could not
handle the
job very well. Later COBOL GUI tools were evaluated and dropped
because of
the Screen Oriented architecture of lack of features and
flexibility.
PowerCOBOL passed the test of the most complex GUI development in
both
availability of Controls and ease of integration of ActiveX and
execution
speed and commendable stability).
"Why flip all controls of a window as if you were looking at them
in a
mirror or move them from one place to another? you asked. Well, go
back
a take another look (this time do it slowly and from top to bottom)
at
http://www.ils-international.com/goldmine/newcobol.htm and you will
see how the same application can run in USA, France, Brazil,
Israel,
India, Russia, Saudi Arabia or any other part of the world in the
local
native tongue.
That is the power of forward thinking, that is the power of
multi-use in
a multi-community of multi-users. It is called "Efficiency" and
saves
tons of bucks. When NASA came up with the idea of the Space
Shuttle,
they stopped producing their wasteful one-launch monstrous rockets
and they did save a lot of [taxpayer] money. Of course they find a
way
to waste some of it in other programs, but that is a different
story.
I hope again you were able to grasp the finesse of such design.
Additionally there are calls to Fujitsu specific routines that are not
part of any of the other Vendors code. PowerCOBOL is a Fujitsu
PowerCOBOL only solution. Even using Fujitsu (Which has an EXCELLENT
Product in their Regular and Enhanced (POWERCOBOL) offerings cannot
compile and run PowerCOBOL applications using Standard Fujitsu COBOL.
That is kind of the point behind having a proprietary solution.
O The entire user Interface (CUI or GUI) is separated from the business and
data
validation/manipulation and communicate through the LINKAGE. In this case
PowerCOBOL syntax is and OO COBOL are used in PowerCOBOL modules and for
the
GUI only. If need be this can be replaced by SPII, GUI ScreenIO or even
BMS
on IBM mainframe.
One last note before I close. I know of NO deficincies in the Fujitsu
offering. I have found the products to be of above average quality,
generally free of bugs and performing as advertised (By Fujitsu) and
my comments in this debate should not be construed as Anti PowerCOBOL
or Anti Fujitsu in any way. I am a VERY satisfied Fujitsu customer.
My SOLE objection to PowerCOBOL is Architectural. I don't like having
to hadle the tedium of event driven programming if I don't have to.
It is a reflection of the CICS architecture with the difference that
in is graphical and "event driven" as opposed to character based and
screen driven. I gave my point of view to Mr. Foskey and Mr. Peacock.
Now in closing, I hope what I have pointed out above has helped you to
see just how you are coming across, how desparate you sound and how
silly the whole thing is. If not, I'm going to stop because you are
doing a good enough job on your own. I tried.
As a teacher you should have more vision and you should be more open
to ideas that today rules the computing world.
"Even driven programming" is among some of the key features of the most
popular (not necessarily the best) platform that has partially caused
the downfall of COBOL and some other languages.
"Even driven programming" is an integral part of Windows.
"Even driven programming" is what made VB and C++, Delphi, etc... so
successful.
"Even driven programming" is an integral part of OO design.
"Even driven programming" is an integral part of MODERN PROGRAMMING.
The comeback of COBOL can only be a reality if in addition to teaching
COBOL
the new architecture of "Event driven" programming tools in this case
PowerCOBOL is well understood and appreciated.
You said "I don't like having to hadle the tedium of event driven
programming if I don't have to". How can any of your COBOL student
be taken seriously in the fierce market of GUI Client/Server and Windows
development if he has to compete for a job against VB, C++ and other
advanced Windows Architecture developer. How can OO COBOL be taken
seriously by the IT World and take back its share of the market
if all you do is still teach old tricks and use obsolete screen based
and "single event" programming methodologies.
OO COBOL to succeed has to be "politically Correct" in every aspect
not just in "syntax".
Thanks for whatever help you believe you have provided me with. I'll
keep it handy for emergencies.
Arnold Trembley
> (mucho snippo)
> Both CICS and PowerCOBOL are similar in concepts and
> architectural design...
>
> 1- Both handle online-user interface through interactive
> screen the 1st character, the 2d graphical
What's this? You can have SCREENS with CICS? I don't believe it. I've
written over a hundred CICS programs that don't use a screen of any
kind.
now...@freedsl.com
Foodman wrote:
now...@freedsl.com wrote:
>
>With GUI tools mentioned in this topic, the programmer's
>imagination and creativity are limited by those tools.
>With PowerCOBOL the capabilities of the tool are limited only by
the probrammer's imagination and creativity which makes the tool
unlimited.
Hi:
Why not post a program which you have written which will
demonstrate conclusively that you know what you are
talking about?
Thanks
TOny Dilworth
Please take the time to read
http://www.ils-international.com/goldmine/newcobol.htm
from top to bottom.
If not please start your reading at the paragraph titled
"The proof of the existence of a World Class Windows programming
language"
and study the bitmaps (picture 2 - 13)
I am open to specific and intelligent questions no matter how
complex they
are and providing that the answer they would require does not
infringe on
anyone copyrights or trade secrets.
Consulting Services are also available. Solid references
regarding the
services and customer satisfaction are also available.
Thank you for your interest.
now...@freedsl.com
now...@freedsl.com wrote:
> (mucho snippo)
> Both CICS and PowerCOBOL are similar in concepts and
> architectural design...
>
> 1- Both handle online-user interface through interactive
> screen the 1st character, the 2d graphical
What's this? You can have SCREENS with CICS? I don't believe it. I've
written over a hundred CICS programs that don't use a screen of any
kind.
Yeah! You used probably INVISIBLE INK to display the info to your
users now..
shhhhhtt! and go back to sleep.
"now...@freedsl.com
> So according to You Mr. Foskey and Mr. Peacock IBM had it
aaaaalllllll wrong for over
> twenty years now. Gee! I wonder what it would take to have IBM
admit the incompetence
> of their CICS engineers and hire you to head their CICS System
team!!! Not to mention that
> according to your statements the Fujitsu PowerCOBOL team is also
"headed by the same" type
> of people as IBM.
>
You don't seem to know when to give up. Even a cursory read of
Jerry's posts should lead you to realize that he has EXTENSIVE
PowerCOBOL experience and actually LIKES the product a great deal. He
was AGREEING with you to some degree.
Yes. to some degree. Some clarification was needed...
Can you please answer a question (Unrelated to the above observation).
With PowerCOBOL is there a single data area returned corresponding to
data on the "form" containing all of the data values under a single 01
level -- as is the case of a RECIEVE MAP with CICS? This is a serious
query.
This is a serious answer: NO. there is no "single data
area returned corresponding to data on the "form"". It is
also as you know the way DIALOG works except that in DIALOG
you have to include ALL the data areas under the DATABLOCK
for all the windows in the screenset.
In PowerCOBOL since it is a normal COBOL program generated,
You have both WORKING-STORAGE and LINKAGE SECTION that you
can use to pass back'n forth the data between the Windows
controls (entry/multi lines fields, radio/check button values, etc.)
For efficiency and unlike DIALOG, each "Form" can have its own
field that you would define ONLY for the fields in THAT window
and ONLY the one you want to display/accept data from.
If a window is closed, then the storage is cleared as in any other
COBOL program.
In DIALOG if you have a screenset of 10 windows with a lot of fields
that would require many many fields, "Deleting" a window does not
release the memory and the entire DATABLOCK is kept until the
screenset is
unloaded
By the way you can also make a WS 01 level GLOBAL and also EXTERNAL
to have the data block available within nested programs of between
DLLs. Its a great feature.
Thane Hubbell
<arnold....@att.net> wrote:
>now...@freedsl.com wrote:
>> (mucho snippo)
>> Both CICS and PowerCOBOL are similar in concepts and
>> architectural design...
>>
>> 1- Both handle online-user interface through interactive
>> screen the 1st character, the 2d graphical
>
>What's this? You can have SCREENS with CICS? I don't believe it. I've
>written over a hundred CICS programs that don't use a screen of any
>kind.
Actually, if you follow current IBM guidelines you are NOT supposed to
have screens anymore. Instead you code these externally using the UI
of your choice and use ECI (External Communications Interface) to
speak with them via the Communications area. You have just been ahead
of your time.
Thane Hubbell
>Hello Thane,
May I have the pleasure of addressing you by your name?
>
> As a teacher you should have more vision and you should be more open
> to ideas that today rules the computing world.
Let me take these points on one at a time.
> "Even driven programming" is among some of the key features of the most
> popular (not necessarily the best) platform that has partially caused
> the downfall of COBOL and some other languages.
COBOL has suffered no real downfall, only a percieved one.
> "Even driven programming" is an integral part of Windows.
Windows is NOT the world. Yes it is a part of dealing with any UI and
Windows, but it's an aspect of development that need not concern the
COBOL programmer. There are tools to eliminate the tedium. I use the
word tedium intentionally - the tedium of dealing with USER INTERFACE
events slows down development tremendously. I need to get to market
faster and more reliably than that.
> "Even driven programming" is what made VB and C++, Delphi, etc... so
> successful.
And also such AWEFUL languages (except maybe Delphi) for Business
programming.
> "Even driven programming" is an integral part of OO design.
Messaging is. Everything in programming is event driven actually.
(Thanks Don). I'd like to limit our discussion to User Interface
events.
> "Even driven programming" is an integral part of MODERN PROGRAMMING.
Let's not get on this kick about "Modern Programming". Programming
does evolve. New things are tried. Some are proven to be good and
remain, and others are proven to be BAD and are discouraged. Being on
the bleeding edge is not always wise. Sometimes one gets cut. To
quote Bob Wolfe - Just because it's old doesn't mean it's bad and just
because it's new doesn't mean its good. The "Old" technology is, well
shall we say -- Proven.
>
> The comeback of COBOL can only be a reality if in addition to teaching
>COBOL
> the new architecture of "Event driven" programming tools in this case
> PowerCOBOL is well understood and appreciated.
>
> You said "I don't like having to hadle the tedium of event driven
> programming if I don't have to". How can any of your COBOL student
> be taken seriously in the fierce market of GUI Client/Server and Windows
> development if he has to compete for a job against VB, C++ and other
> advanced Windows Architecture developer.
Let's separate OO from the UI shall we? They are NOT necessarily
linked. The way my student and *I* can compete is simple. I can
create an application FASTER, BETTER and more reliable than a VB or
C++ programmer. Also, when I create my application, with my choice of
tools, I can deploy it without source change either on the users
desktop or via the internet. No other suite of tools can make that
claim -- this includes remote printing. The KEY thing is that I can
do it FASTER and it is more maintainable than the C++ or VB system.
The really neat thing is that if a NEW UI comes along, I have very
confidence that my code can be adapted to this new UI without any
source code changes.
>How can OO COBOL be taken
> seriously by the IT World and take back its share of the market
> if all you do is still teach old tricks and use obsolete screen based
> and "single event" programming methodologies.
>
> OO COBOL to succeed has to be "politically Correct" in every aspect
> not just in "syntax".
>
Take a minute and search thru DEJA.COM for posts by me about OO. You
will find that I am an OO COBOL proponant. I CAN use SP2 with OO
COBOL and have an OO system. As you stated in your argument, the
busniess logic that utilizes the OO User Interace classes does not
know, or need to know the details of the UI. Even with SP2, I am
ultimately responding to events. I might be responding to a button
press, or afield value change, or a loss of focus, or a gain of focus
-- the KEY difference is that I don't have to write a single line of
code to interface with the UI. I'm free of that tedium. I don't have
to code anything special to get the data back to my business logic.
I also gain complete compiler independence -- because I have separated
the user interface from the business logic. In the GUI world, oft
times the largest part of an application is the UI. That doesn't have
to be so. Presently I am under contract to convert a Realia COBOL
system to Fujitsu. Thankfully the client built the system using Sp2.
The only changes I have to make are from the Realia specific syntax to
Fujitsu. I also have to replace the Realia "DOS" calls with API or
Fujitsu calls. I have to do NOTHING with the user interface.
Please realize that the UI does not equal OO, and OO does not equal
the UI.
James J. Gavan
From me to : nowittAll
<OK> <Cancel>
.............................................
Jimmy, Calgary AB
.......................................................................
From : NowittAll to me
Prefer to send you directly...
Don't understand your inquiry.
What are you trying to get: how easy/difficult? the generated source
code from PowerCOBOL? What?
Try again.
Nowitt
........................................................................
OK I'll try again, in plainer English - cut the crap and in a small
example illustrate with COBOL source the arguments you are making, plus
the 'ancillary' code POWERCOBOL or whatever generates. I have no
knowledge of POWERCOBOL.
You aren't going to make money with your GOLD MINE if you are evasive
about simple questions. Anybody else have difficulty with understanding
my request, as originally worded ?
Jimmy, Calgary AB
Mike Madara
1) Are the Fujitsu GUI extensions to COBOL only in their Power Cobol
product? How 'bout their Standard Cobol?
2) If you use Power Cobol as your GUI solution, must you also use
their version of OO methodology? I'm getting the impression
from the thread that in the Fujitsu product, GUI and OO (at
least their version) are tightly linked. Correct?
TIA
Mike Madara
Thane Hubbell
wrote:
>Two quick questions:
>
>1) Are the Fujitsu GUI extensions to COBOL only in their Power Cobol
> product? How 'bout their Standard Cobol?
>
You can make direct API Calls with Standard COBOL if you desire. As
far as GUI goes, Standard COBOL has a multitude of WEB extensions (v
5..0) but not native GUI. For that you need POWERCOBOL or a third
party tool.
>2) If you use Power Cobol as your GUI solution, must you also use
> their version of OO methodology? I'm getting the impression
> from the thread that in the Fujitsu product, GUI and OO (at
> least their version) are tightly linked. Correct?
OO is how PowerCOBOL is implemented. However, when you consider
"Fujitsu's Brand" of OO, you have to remember that the different
vendors coded to the standard at different times. Fujitsu's OO
Implementation is actually much closer to the standard than any of the
other PC vendors.
The OO Code is generated. From my experience, when I experimented
with it, the code is actually quite well hidden and only visible when
you turn on debugging, or force source code listing generation.
Fujitsu doesn't force you into OO programming. They simply use OO to
facilitate PowerCOBOL -- and they hide it from you as much as
possible. (Intentionally).
Howard Brazee
"William M. Klein" wrote:
>
> If you think this is "healthy debate" that users want, why don't you point to
> a SINGLE user who seems to be "supporting" the tone of your posts?
Or a married person.
Joseph J Katnic
Thane Hubbell wrote:
>
>
> Let's not get on this kick about "Modern Programming". Programming
> does evolve. New things are tried. Some are proven to be good and
> remain, and others are proven to be BAD and are discouraged. Being on
> the bleeding edge is not always wise. Sometimes one gets cut. To
> quote Bob Wolfe - Just because it's old doesn't mean it's bad and just
> because it's new doesn't mean its good. The "Old" technology is, well
> shall we say -- Proven.
Just a quick comment:
EVENT programming is neither NEW or MODERN.
I know of a few event driven applications that run at thousands of
events per second and are written in CICS/COBOL. They are of course the
online banking system.
If you look carefully enough, you will find that there is just about
nothing that is being done today that is touted as "NEW" that hasn't
already been done, although in a slightly different format.
--
Regards,
Joe Katnic jos...@iinet.net.au
Jerry P
Thane Hubbell <tha...@softwaresimple.com
>
> Try this when deployed using the single threaded runtime. I think
you
> will see that the same thing happens as happens with dialog. Only
one
> thing can happen at a time. The Window may accept the push of the
> button, but control will not return to process the message and set
the
> flag until your database access finishes. That is UNLESS there is
> another thread processing the window and updating the flag in
memory.
> This multi-treading is a powerful part of PowerCOBOL and is included
> in the development version by default, but not in the runtime
> distribution unless you specifically install and request it.
Hmmm.
FJ added a method called 'ThruEvents' in Version 5. According to a
sample program (below) you can poke a button on the screen and have an
executing event pause and catch up with the Windows message queue
(which, presumably, has taken note of your button click).
Of course, if, as you say, "ThruEvents" is really part of the
multi-thread runtime, there's a distribution/royalty issue, but the
concept is a good one.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 RUNNING-FLAG GLOBAL PIC S9(4). *>In WS of form.
Included here for clarity
88 IS-RUNNING VALUE 1.
01 I PIC S9(9) COMP-5.
PROCEDURE DIVISION.
IF IS-RUNNING THEN
EXIT PROGRAM *> Exit to prevent nesting
of the event
END-IF
MOVE 1 TO RUNNING-FLAG. *> Sets the executing flag
PERFORM VARYING I FROM 1 BY 1 UNTIL I > 1000000
MOVE I TO "Caption" OF COUNTER *> Display counter
IF FUNCTION MOD (I 1000) = 0 THEN
INVOKE POW-SELF "ThruEvents" *> Executes any waiting event
procedures
IF NOT IS-RUNNING THEN *> Exits if the cancel button
is clicked
EXIT PERFORM
END-IF
END-IF
END-PERFORM
MOVE 0 TO RUNNING-FLAG. *> Releases the executing
flag
Click event of the Cancel CommandButton
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MOVE 0 TO RUNNING-FLAG. *> Sets the executing flag to 0
QueryClose event of the Form
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
LINKAGE SECTION.
01 POW-CANCEL PIC S9(4) COMP-5.
PROCEDURE DIVISION USING POW-CANCEL.
IF IS-RUNNING THEN
MOVE POW-TRUE TO POW-CANCEL
END-IF
Jerry Peacock (not part of the above program)
now...@freedsl.com
Two quick questions:
1) Are the Fujitsu GUI extensions to COBOL only in their Power Cobol
product? How 'bout their Standard Cobol?
Yes. To design, prototype, compile, link, debug and execute GUI,
you
need PowerCOBOL.
The 3 editions of the Fujitsu COBOL products features can be found
either at Fujitsu site(http://www.adtools.com/info/whatcobol.htm)
or
at ILS Site (http://www.ils-international.com). Prices can also
be
found on those sites.
In short :
-ALL Standard, Professional and Enterprise Editions Support
COBOL-74/85/95 and OO COBOL and web CGI support.
-Pro Edition include PowerCOBOL for GUI and PowerBSORT OCX
-Enterprise Include Pro Edition + Standalone PowerBSORT +
Team development support (source control management software)
+ PowerFORM Reporting Tool (very similar to Crystal Reports)
but works with COBOL.
2) If you use Power Cobol as your GUI solution, must you also use
their version of OO methodology? I'm getting the impression
from the thread that in the Fujitsu product, GUI and OO (at
least their version) are tightly linked. Correct?
To use GUI development and manipulate the GUI Controls and
OCX/ActiveX,
you use the "standard" [or hopefully soon to be approved standard
-
nobody seem to be sure when would that be] OO COBOL INVOKE
statement
to communicate with Objects and their properties created using the
FBASE GUI class, the OCX and ActiveX controls.
You can STILL use the existing standard COBOL-85 to develop and
CALL
standard [procedural] COBOL programs for the
business/validation/data
manipulation process under PowerCOBOL.
Hope this answers your questions.
TIA
Mike Madara
now...@freedsl.com
In short :
-ALL Standard, Professional and Enterprise Editions Support
COBOL-74/85/97 and OO COBOL and web CGI support.
Bob Wolfe
>
>Thane Hubbell wrote:
>On Mon, 03 Jul 2000 18:39:02 GMT, now...@freedsl.com wrote:
>
>What is obvious is that you don't understand Sp2, Screenio or Dialog
>System. Dialog System and PowerCOBOL have the same "problem". That is
>each utilizes an event driven programming model that requires the
>programmer to write code for each object on the screen. Sp2 and
>Screenio do not. Which is better? I have my opinion, others have
>theirs.
>
> Perhaps it is you who really did not understand my lines:
>
> I have described SPII and GUI ScreenIO as Screen handler similar to CICS
> and the old character ScreenIO based on the ACCEPT/DISPLAY technology.
No wit:
CICS screen handling is typically controlled through SENDs and
RECEIVEs. sp2 is actually based upon CALL USING technology in which
the called module is a dynamic link library and the parameters passed
in the CALL statement are used to control the DLL.
CICS screen handling is pseudo-conversational....sp2 is
conversational. CICS screen handling is typically full screen mode
and sp2 can be full screen, field-by-field or even
character-by-character screen handling.
The sp2 DLL makes direct event driven CALLs to the Windows API.
I don't think that sp2 is quite as much like CICS as you suspect it
is. I am not comfortable posting this message, because it appears as
self-promotion. On the other hand, it is important to correct the
inaccuracies which you have stated above.
Everyone should enjoy the freedom to contribute to the newsgroup, but
please try to be accurate in your statements. When you make
inaccurate statements, it actually causes you to lose credibility!
Thanks.
Bob Wolfe, flexus
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com
Thane Hubbell
wrote:
>Hmmm.
>
>FJ added a method called 'ThruEvents' in Version 5. According to a
>sample program (below) you can poke a button on the screen and have an
>executing event pause and catch up with the Windows message queue
>(which, presumably, has taken note of your button click).
>
>Of course, if, as you say, "ThruEvents" is really part of the
>multi-thread runtime, there's a distribution/royalty issue, but the
>concept is a good one.
>
>
Code snipped. It looks to me like it would NOT require
multi-threading. It's very similar to what I do with sp2. You have
to code where you want it to happen, but I just make a call to sp2 to
see if the user did anything while I have been busy. Contrasting
Dialog System, it's much harder but still possible. The difference is
that Dialog calls your program, not the other way around, so that you
need to setup some method of picking up where you left off after
dialog executes.
Question for you: With this function, what happens if SOME OTHER
event has occured - like the selection of a "Print" button where you
have print logic? Does the printing happen then control returns to
your process -- that was "suspended" when you checked the other
events?
(This assumes that I am correct and this is a single threaded
solution).
Thane Hubbell
>I don't think that sp2 is quite as much like CICS as you suspect it
>is. I am not comfortable posting this message, because it appears as
>self-promotion. On the other hand, it is important to correct the
>inaccuracies which you have stated above.
>
I'm probably most guilty of making the CICS analogy. The "simplest"
method of utilizing sp2 is SIMILAR to CICS, and SIMILAR to using the
screen section -- a full screen at a time of data comes back, and you
check why (as you would do with CICS AID keys or Function keys from a
screen section. It's not quite an ACCURATE depiction of what is
happening inside. I'm probably to blame for the proliferation of the
analogy, however.
donald tees
>
>I think he's young. For most of us old COBOL farts, testosterone is
>but a wistful memory, the hint of a smile, and fond remembrance my
>friend "Woody" ("Hell, woman, it's like beaver teeth, you gotta keep
>it wore down or it'll kill ya!) It now takes me all night to do what
>I used to could do all night.
>
>Sigh.
>
You know you are getting old, Jerry, when your date says she really likes
you and tries to set you up on a blind date with her mother. That has
happened to me twice in the last month. I am starting to get a complex.
;<)
Bob Wolfe
>
>
>Bob Wolfe wrote:
>now...@freedsl.com wrote:
>
>>I challenge Dialog, SpII and ScreenIO to even come close to doing this
>>(http://www.ils-international.com/goldmine/newcobol.htm) as elegantly and as
>>efficiently as it has been beautifully done using PowerCOBOL from Fujitsu.
>[snip]
>>
>>If you can't do it 100% in COBOL then may be you should consider changing
>>career!
>
>Nowitt:
>
>I don't care to enter into a vendor debate in the newsgroup as I
>mentioned before. Everyone knows ILS sells Fujitsu COBOL.
>
> That's the spirit Bob. Healthy debates can only be beneficial to the
>users by giving
> them information they would perhaps never get otherwise. Now this does
>not
> necessarily make me an ILS salesman, but I do participate actively to
>COBOL Gold Mine.
Debates are only healthy when the debating parties use diplomacy,
adhere to and mutually respect factual information provided by their
opponent and avoid speaking in generalities. You have done none of
the above and it should be obvious in the replies you have received
from highly respected regular contributors to this newsgroup.
If it is not obvious to you yet, I suspect that many consider you to
be just a tad zealous in your belief.....zealots are rarely considered
credible.
I have said it many times and will continue to say that in my opinion,
this newsgroup is a platform for the free exchange of ideas by
professional COBOL programmers. While I appreciate the fact that your
strong opinions are based upon the fact that you are so religious in
your views, please remember that I will avoid debate in this forum
because the debate shouldn't come from a vendor, but from those who
utilize COBOL daily in their studies, occupations or hobbies.
>I can say this. Everyone has different motivations for using a
>particular compiler, screen handler or some other type of tool.
>
> And I agree with you. Many people drive a Cadillac, a Mercedes, a Ferrari
>or a Lexus. Others
> drive a VW or a ford Escort and are happy with what they got until one
>day they have
> the opportunity to drive a Cadillac, a Mercedes, a Ferrari or a Lexus.
>Then is when they
> will understand the difference and will be wishing for more "power" when
>they go back to their
> VW or a ford Escort. In this context PowerCOBOL is simply the Lexus or a
>Ferrari.
But you are making an incorrect assumption that everyone who drives a
car in the world wants horsepower or luxury. This is simply not true.
I know many people who would sell a Mercedes or Lexus, if given to
them, and purchase a VW or Escort with the proceeds, simply because
they value economy, thrift, conservation and environmental
preservation than they value looking cool in front of their friends
and breaking the law by exceeding the speed limit.
Diff'rent Strokes for Diff'rent Folks!
.....Sly and the Family Stone
>I can say this. If the program you demonstrate on your web site is
>100% COBOL, then I challenge you to recompile it with any of the
>following 32 bit Windows versions of:
>
>CA-Realia II Workbench
>Merant NetExpress
>Acucorp's Acucobol GT
>Liant's RM COBOL
>Egan Systems Interactive COBOL
>IBM Visual Age
>
> Although not compiled under some of the above compilers, the program
>would
> compile and execute error free if all of the above are certified ANSI
>COBOL-85.
I'm afraid that I would have to see this to believe it. Are you
saying that the COBOL source code for the application featured on the
web site which you directed us toward could be compiled (unchanged),
using no Fujitsu libraries with the CA-Realia II Workbench.....AND it
would compile error-free and execute identically to the one compiled
with Fujitsu COBOL?
This is difficult to believe.
now...@freedsl.com
>Bob Wolfe wrote:
(snip)
Debates are only healthy when the debating parties use diplomacy,
adhere to and mutually respect factual information provided by their
opponent and avoid speaking in generalities. You have done none of
the above and it should be obvious in the replies you have received
from highly respected regular contributors to this newsgroup.
By healthy I mean without hypocrisy. Diplomats use diplomacy.
Software Vendors should use facts and comparison charts
provided by studies made by themselves not by "polished
factual information provided by their opponent(s). You know
about bugs in Windows NT by other software vendors NOT by
Microsoft!! Should these vendors use diplomacy? or use" factual information"
provided by Microsoft?? Nooooo I don't think so.
Now here is the reality: from the smallest politician to the candidates
for president all use diplomacy and preach diplomacy and advertise
diplomacy, until election time!!! Then and only then each one reveals
"facts provided by studies made by themselves" NOT "mutually respect factual
information provided by their opponent" I challenge you to find an ounce
of respect in their flaming campaign ads. But there is a lot less hypocrisy
toward each other during that election period. Now THAT is what I call healthy!
Respect is relative One rarely respects what one does not know or understand.
If it is not obvious to you yet, I suspect that many consider you to
be just a tad zealous in your belief.....zealots are rarely considered
credible.
Not that I am religious but Moses, Jesus, Mohamet, would be
considered zealots if they do today what they did in the past.
Early believers of anything from religion to technology are always
accused of being zealots by those who have the most to fear from
their statements.
I have said it many times and will continue to say that in my opinion,
this newsgroup is a platform for the free exchange of ideas by
professional COBOL programmers. While I appreciate the fact that your
strong opinions are based upon the fact that you are so religious in
your views, please remember that I will avoid debate in this forum
because the debate shouldn't come from a vendor, but from those who
utilize COBOL daily in their studies, occupations or hobbies.
I am not a vendor of character ScreenIO, much impressed - I would be
- and I was - using your word "zealous" about it. Even today
I would talk about it the way I talk about PowerCOBOL.
>I can say this. Everyone has different motivations for using a
>particular compiler, screen handler or some other type of tool.
>
> And I agree with you. Many people drive a Cadillac, a Mercedes, a Ferrari or
a Lexus. Others
> drive a VW or a ford Escort and are happy with what they got until one day
they have
> the opportunity to drive a Cadillac, a Mercedes, a Ferrari or a Lexus. Then
is when they
> will understand the difference and will be wishing for more "power" when they
go back to their
> VW or a ford Escort. In this context PowerCOBOL is simply the Lexus or a
Ferrari.
But you are making an incorrect assumption that everyone who drives a
car in the world wants horsepower or luxury. This is simply not true.
I know many people who would sell a Mercedes or Lexus, if given to
them, and purchase a VW or Escort with the proceeds, simply because
they value economy, thrift, conservation and environmental
preservation than they value looking cool in front of their friends
and breaking the law by exceeding the speed limit.
I do not make such an assumption. If you have read the last sentence
of the cars analogy I have wrote: "I agree also with you that some still would
not want
to trade their VW for a Lexus or a Ferrari."
Diff'rent Strokes for Diff'rent Folks!
.....Sly and the Family Stone
>I can say this. If the program you demonstrate on your web site is
>100% COBOL, then I challenge you to recompile it with any of the
>following 32 bit Windows versions of:
>
>CA-Realia II Workbench
>Merant NetExpress
>Acucorp's Acucobol GT
>Liant's RM COBOL
>Egan Systems Interactive COBOL
>IBM Visual Age
>
> Although not compiled under some of the above compilers, the program would
> compile and execute error free if all of the above are certified ANSI
COBOL-85.
I'm afraid that I would have to see this to believe it. Are you
saying that the COBOL source code for the application featured on the
web site which you directed us toward could be compiled (unchanged),
using no Fujitsu libraries with the CA-Realia II Workbench.....AND it
would compile error-free and execute identically to the one compiled
with Fujitsu COBOL?
This is difficult to believe.
I reproduce here what I have said to Mr. Hubbell:
Bob Wolfe, flexus
Ken Foskey
I find your posts just about impossible to follow. Could you please
put quotes on the original text to help us mere mortals follow what
you say as opposed to what the others are saying.
I have done CICS programming and typically the programs are 80% CICS
handling and about 20% business logic. Yes this leads programmers
into bad designs. I worked on a cobol system CHRIS (computer Human
Resource information system or like) and it magically hidden all this
complex stuff and the average program was 10% overhead and 90%
business. It is possible to clean it up, just not easy to change the
programmers mind set.
I have stated my position and I have described the reasons for my
position, prove me wrong. I hit the link you gave us, lots of pretty
pictures and no code. Show me the money (or code in this case).
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
For fast secure document delivery on the Net
http://www.themailxchange.com.au/
Jerry P
Thane Hubbell <tha...@softwaresimple.com> wrote in message
news:39637889....@207.126.101.100...
> On Wed, 5 Jul 2000 10:36:03 -0500, "Jerry P" <jer...@bisusa.com>
> wrote:
>
>
> >Hmmm.
> >
> >FJ added a method called 'ThruEvents' in Version 5. According to a
> >sample program (below) you can poke a button on the screen and have
an
> >executing event pause and catch up with the Windows message queue
> >(which, presumably, has taken note of your button click).
> >
> >Of course, if, as you say, "ThruEvents" is really part of the
> >multi-thread runtime, there's a distribution/royalty issue, but the
> >concept is a good one.
> >
> >
> event has occured - like the selection of a "Print" button where you
> have print logic? Does the printing happen then control returns to
> your process -- that was "suspended" when you checked the other
> events?
>
Gosh. I don't know. A guess: The events 'nest' (like a stack). Logic
would indicate something like:
Event "A" begins
(user presses buttons to activate events "B" "C" and "D" in that
order (or, more likely, if our user, hits the "B" button 47 times, the
last three with his fist))
Event "A" pauses
Event "B" begins
Event "B" ends
Event "C" begins
Event "C" pauses
Event "D" begins
Event "D" ends
Event "C" resumes
Event "C" ends
Event "A" resumes
Event "A" ends
Jerry P
<now...@freedsl.com>
> Now here is the reality: from the smallest politician to the
candidates
> for president all use diplomacy and preach diplomacy and
advertise
> diplomacy, until election time!!!
Winston Churchill, early in his career, was electioneering on a stump
in Hyde Park, when a heckler shouted out: "Mr. Churchill, I'd sooner
vote for the devil than vote for you!"
Without missing a beat, Churchill rejoined: "And on Wednesday next,
you'll get the chance."
Jerry P
donald tees <don...@willmack.com> wrote in message
news:8k05f9$dml$1...@news.igs.net...
The French have a word for that, but I don't know what it is.
Thane Hubbell
wrote:
>Event "A" begins
> (user presses buttons to activate events "B" "C" and "D" in that
>order (or, more likely, if our user, hits the "B" button 47 times, the
>last three with his fist))
> Event "A" pauses
> Event "B" begins
> Event "B" ends
> Event "C" begins
> Event "C" pauses
> Event "D" begins
> Event "D" ends
> Event "C" resumes
> Event "C" ends
> Event "A" resumes
> Event "A" ends
>
Sounds reasonable. Do you ever call another program from a button or
something like that? What I would be concerned about is when you
click button A and start a database update, and keep checking the Thru
event, and they click button B, which is a query against the same
database. Does the program called by B execute before you return from
the invocation of the Thru Event (I see a real boon for
Multi-Threading here)? What about undesirable side effects? Can you
control what events are allowed on the thru event checking?
Gazaloo
> If you look carefully enough, you will find that there is just about
> nothing that is being done today that is touted as "NEW" that hasn't
> already been done, although in a slightly different format.
now, ain't that the truth!
--
Gazaloo
g...@home.com
Gazaloo
> you and tries to set you up on a blind date with her mother. That has
> happened to me twice in the last month. I am starting to get a complex.
> ;<)
hey, don't be so picky and take the hint :-) maybe you'll luck out and get
both together (the mothers that is :-).
--
Gazaloo
g...@home.com
Thompson, William
like an ass.....
-----Original Message-----
From: now...@freedsl.com [mailto:now...@freedsl.com]
Sent: Tuesday, July 04, 2000 11:51 AM
To: comp.la...@list.deja.com
Subject: Re: Graphical User Interface
snip
So according to You Mr. Foskey and Mr. Peacock IBM had it
aaaaalllllll wrong for over
twenty years now. Gee! I wonder what it would take to have
IBM admit the incompetence
of their CICS engineers and hire you to head their CICS
System team!!! Not to mention that
according to your statements the Fujitsu PowerCOBOL team is
also "headed by the same" type
of people as IBM.
snip
Sent via Deja.com http://www.deja.com/
Before you buy.
Cheesle
> Please take the time to read
> http://www.ils-international.com/goldmine/newcobol.htm
> from top to bottom.
>
> If not please start your reading at the paragraph titled
> "The proof of the existence of a World Class Windows programming
> language"
> and study the bitmaps (picture 2 - 13)
In my humble opinion, your web site and bitmaps does not prove anything. It
is just another web site. What is it that should be so fantastic about
showing a bunch of screen shots in various languages?
When that is said, the designer of the application has something to learn
about use of fonts and colors in graphical applications.
Cheesle
Cheesle
news:39627DD3...@home.com...
>
> From me to : nowittAll
>
> I've been watching this thread, and to satisfy my curiosity, could you
> please produce COBOl source code for the following window, plus any
> validity checks you want to throw in :-
> ............................................
> Customer # [ ]
> Customer Name [ ]
>
> <OK> <Cancel>
I am sorry Jimmy, I could not resist, here is the Acucobol approach, and I
ask myself; Tedious? Lot of work? Difficult to understand? I add a question
here to Mr. nowitt, can you beat this number of lines and keep the
simplicity? This is all that there is needed.
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE.
AUTHOR. CHEESLE.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 CUST-NO PIC 9(08).
77 CUST-NAME PIC X(30).
77 KEY-STATUS
IS SPECIAL-NAMES CRT STATUS PIC 9(4).
88 EXIT-BUTTON-PUSHED VALUE 13.
88 CANCEL-BUTTON-PUSHED VALUE 1.
SCREEN SECTION.
01 SC-EXAMPLE.
03 LABEL LINE 20 PIXELS COL 15 PIXELS "Customer #".
03 LABEL LINE 44 PIXELS COL 15 PIXELS "Customer name".
03 ENTRY-FIELD LINE 16 PIXELS SIZE 100 PIXELS
COL 120 PIXELS PIC Z(8)9 USING CUST-NO 3-D NUMERIC
MAX-TEXT 8.
03 ENTRY-FIELD LINE 40 PIXELS SIZE 220 PIXELS
COL 120 PIXELS PIC X(30) USING CUST-NAME
3-D MAX-TEXT 30.
03 PUSH-BUTTON
LINE 80 PIXELS
COL 120 PIXELS
TITLE "Ok"
DEFAULT-BUTTON
EXCEPTION-VALUE = 13
SELF-ACT.
03 PUSH-BUTTON
LINE 80 PIXELS
COL 200 PIXELS
TITLE "Cancel"
CANCEL-BUTTON
EXCEPTION-VALUE = 1
SELF-ACT.
PROCEDURE DIVISION.
MAIN SECTION.
MAIN-000.
DISPLAY STANDARD GRAPHICAL WINDOW
LINES 9
SIZE 51
BACKGROUND-LOW
SYSTEM MENU.
DISPLAY SC-EXAMPLE.
PERFORM WITH TEST AFTER UNTIL
EXIT-BUTTON-PUSHED OR
CANCEL-BUTTON-PUSHED
ACCEPT SC-EXAMPLE
END-PERFORM.
MAIN-900.
MAIN-EXIT.
EXIT.
William M. Klein
A**'ole" had made previous comments about their code being ANSI'85
Conforming, please note that the sample code that "he deals with" includes
the following non-conforming syntax.
Repository paragraph
and
Comp-5
and
No paragraph name in the Procedure Division
and
Procedure Division statement not in the B-margin
(The "generated" code that is presented uses other non-Standard syntax and it
should be particularly noted that it does NOT match the current draft of the
next COBOL Standard as far as some of its OO syntax. OTOH, as it is "hidden"
from the programmer, I consider this less of a problem with No Wit's logic.
It does reflect, however, on the claim on the Gold Mind site about their OO
support matching the draft Standard.)
Of course when "pressed" it seems that "No Wit" seems to waiver when talking
about why he likes PowerCOBOL so much. Sometimes he talks about separating
the "business logic" from the "User Interface" and sometimes he talks about
using the same product for both.
At least this time, he has actually posted the code - so the mis-information
in his previous posts can be pin-pointed and made clear.
Again, as made clear in many of the previous posts, the lack of ability to do
this in ANSI conforming source code is NOT a problem with Fujitsu's product;
it has to do with the state of OO COBOL and the Standard. The original
AcuCOBOL source code also used extensions to the Standard.
My guess is that sp2 would NOT use extensions to do this - as they use
primarily "legitimate" ANSI conforming CALL statements.
--
Bill Klein
wmklein <at> ix dot netcom dot com
<now...@freedsl.com> wrote in message news:39652742...@freedsl.com...
> If we have to compare the number of lines I have to deal with,
> versus the number of line coded using Acucobol approach,
> one can easily see that I have 50% less code and is about
> 10 times simpler because I did not have to deal with LINE, COL
> PIXELS.
>
> I suggest you ask for a demo to ILS or Fujitsu. It is hard to
> explain how easy it is to work with PowerCOBOL. You have to
> try it. Send request to sa...@ils-international.com.
>
> You will be the judge.
>
>
> ====== This is the COBOL program I deal with when I code. =======
> ====== It is created by PowerCOBOL. I only specify the =======
> ====== Field names, Field Propmts and buttons using the =======
> ====== GUI builder PowerFORM. All UPPER cASE is pretty =======
> ====== much generated. =======
>
> 000013 SPECIAL-NAMES.
> 000014 REPOSITORY.
> 000015 .
> 000016 INPUT-OUTPUT SECTION.
> 000017 FILE-CONTROL.
> 000018 DATA DIVISION.
> #LINE 23
> 000023 LINKAGE SECTION.
> 000024 01 POW-FORM IS GLOBAL.
> 000025 02 POW-SELF PIC S9(9) COMP-5.
> 000026 02 POW-SUPER PIC X(4).
> 000027 02 POW-THIS PIC S9(9) COMP-5.
> 000028 02 Button-OK PIC S9(9) COMP-5.
> 000029 02 Button-CANCEL PIC S9(9) COMP-5.
> 000030 02 Cust-nbr PIC S9(9) COMP-5.
> 000031 02 Cust-name PIC S9(9) COMP-5.
> 000032 02 Cust-nbr-prompt PIC S9(9) COMP-5.
> 000033 02 Cust-name-prompt PIC S9(9) COMP-5.
> 000034 01 Customer REDEFINES POW-FORM GLOBAL PIC S9(9) COMP-5.
> 000035 01 POW-CONTROL-ID PIC S9(9) COMP-5.
> 000036 01 POW-EVENT-ID PIC S9(9) COMP-5.
> 000037 01 POW-OLE-PARAM PIC X(4).
> 000038 01 POW-OLE-RETURN PIC X(4).
> 000039 PROCEDURE DIVISION USING POW-FORM POW-CONTROL-ID POW-EVENT-ID
> POW-OLE-PARAM POW-OLE-RETURN.
> 000040 EXIT PROGRAM.
> 000041 END PROGRAM Customer.
> #FILE
> ================== END of my coding ========================
>
>
> ====== This is the COBOL program I NEVER NEVER deal with =======
> ====== or even have to look at, generated by PowerCOBOL =======
> ====== But I include it so you can understand how =======
> ====== PowerCOBOL inserts the CLASS names and =======
> ====== OBJECT REFERENCES, compiles and links. That's it. =======
> ====== Note that the proper elements are inserted where =======
> ====== there is #LINE ??. Again this really does not =======
> ====== even exist for the user. As I said before, This =======
> ====== is the equivalent of the generated CICS listing =======
> ====== after the pre-compile. =======
>
> 000001 IDENTIFICATION DIVISION.
> 000002* Customer.
> 000003 PROGRAM-ID. Customer.
> 000004 ENVIRONMENT DIVISION.
> 000005 CONFIGURATION SECTION.
> 000006 POW-REPOSITORY.
> 000007 CLASS AMethodSetCustomer AS "TLB=C:\Fujitsu COBOL
>
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C3-5381-11D4-816C-0000B45
32893},Fujitsu-PcobForm-4"
>
> 000008 CLASS AMixed-DCfGWnd-Main-with-DCfGroupItem-Main AS
"TLB=C:\Fujitsu
> COBOL
>
Projects\Barcode\Customer\Release\~build.tlb,{F06C8458-672C-11D2-81F0-00A0C96
13687},Fujitsu-PcobFormWnd-4"
>
> 000009 CLASS AMixed-DCmPush-Main-with-DCfGroupItem-Main AS
"TLB=C:\Fujitsu
> COBOL
>
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C5-5381-11D4-816C-0000B45
32893},Fujitsu-PcobCommandButton-4"
>
> 000010 CLASS AMixed-DCmTextbox-Main-with-DCfGroupItem-Main AS
> "TLB=C:\Fujitsu COBOL
>
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C7-5381-11D4-816C-0000B45
32893},Fujitsu-PcobTextBox-4"
>
> 000011 CLASS AMixed-DCmSText-Main-with-DCfGroupItem-Main AS
> "TLB=C:\Fujitsu COBOL
>
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C9-5381-11D4-816C-0000B45
32893},Fujitsu-PcobStaticText-4"
>
> 000012 .
> 000013 SPECIAL-NAMES.
> 000014 REPOSITORY.
> 000015 .
> 000016 INPUT-OUTPUT SECTION.
> 000017 FILE-CONTROL.
> 000018 DATA DIVISION.
> 000019 BASED-STORAGE SECTION.
> 000020 FILE SECTION.
> 000021 WORKING-STORAGE SECTION.
> 000022 CONSTANT SECTION.
> 000023 LINKAGE SECTION.
> 000024 01 POW-FORM IS GLOBAL.
> 000025 02 POW-SELF OBJECT REFERENCE AMethodSetCustomer.
> 000026 02 POW-SUPER PIC X(4).
> 000027 02 POW-THIS OBJECT REFERENCE AMethodSetCustomer.
> 000028 02 Button-OK OBJECT REFERENCE
> AMixed-DCmPush-Main-with-DCfGroupItem-Main.
> 000029 02 Button-CANCEL OBJECT REFERENCE
> AMixed-DCmPush-Main-with-DCfGroupItem-Main.
> 000030 02 Cust-nbr OBJECT REFERENCE
> AMixed-DCmTextbox-Main-with-DCfGroupItem-Main.
> 000031 02 Cust-name OBJECT REFERENCE
> AMixed-DCmTextbox-Main-with-DCfGroupItem-Main.
> 000032 02 Cust-nbr-prompt OBJECT REFERENCE
> AMixed-DCmSText-Main-with-DCfGroupItem-Main.
> 000033 02 Cust-name-prompt OBJECT REFERENCE
> AMixed-DCmSText-Main-with-DCfGroupItem-Main.
> 000034 01 Customer REDEFINES POW-FORM GLOBAL OBJECT REFERENCE
> AMethodSetCustomer.
> 000035 01 POW-CONTROL-ID PIC S9(9) COMP-5.
> 000036 01 POW-EVENT-ID PIC S9(9) COMP-5.
> 000037 01 POW-OLE-PARAM PIC X(4).
> 000038 01 POW-OLE-RETURN PIC X(4).
> 000039 PROCEDURE DIVISION USING POW-FORM POW-CONTROL-ID POW-EVENT-ID
> POW-OLE-PARAM POW-OLE-RETURN.
> 000040 EXIT PROGRAM.
> 000041 END PROGRAM Customer.
> ================== END generated coding ======================
Cheesle
news:8k3eq9$s4p$1...@slb0.atl.mindspring.net...
> The original AcuCOBOL source code also used extensions to the Standard.
True.
> My guess is that sp2 would NOT use extensions to do this - as they use
> primarily "legitimate" ANSI conforming CALL statements.
Well, I don't want to start another war, but while it is true that sp2 is
called by ANSI convensions, its form construction is way beyond. But that is
another story.
Cheesle
Cheesle
> If we have to compare the number of lines I have to deal with,
> versus the number of line coded using Acucobol approach,
> one can easily see that I have 50% less code and is about
> 10 times simpler because I did not have to deal with LINE, COL
> PIXELS.
Good, good, we got some code. And if all you gotta do now is to do ccbl
mysource.cbl and thereafter it executes with no more files, it is good. No
doubt it is smaller, indeed using a screen designer is simpler. It might
surprise you, but Acucobol also has a screen designer, so the screen section
may be done wysiwyg for those who prefer that. So... 10 times simpler?
Actually, the entire source could be made automatically using a screen
designer. No way it is simpler.
You say that you do not have to deal with positioning. How do you specify
location then?
You may have it in a separate form file? If so, my guess is that your number
of lines increases rapidly, because the code you have shown has no way of
locating stuff. Are you hiding something?
When it comes to readability, you can't deny which is.
Cheesle.
Btw: Acucobol may also use ActiveX's. Which introduces another problem, you
must install them on the receiving computer. The sample application I made
does not need any ActiveX's.
now...@freedsl.com
versus the number of line coded using Acucobol approach,
one can easily see that I have 50% less code and is about
10 times simpler because I did not have to deal with LINE, COL
PIXELS.
I suggest you ask for a demo to ILS or Fujitsu. It is hard to
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C3-5381-11D4-816C-0000B4532893},Fujitsu-PcobForm-4"
000008 CLASS AMixed-DCfGWnd-Main-with-DCfGroupItem-Main AS "TLB=C:\Fujitsu
COBOL
Projects\Barcode\Customer\Release\~build.tlb,{F06C8458-672C-11D2-81F0-00A0C9613687},Fujitsu-PcobFormWnd-4"
000009 CLASS AMixed-DCmPush-Main-with-DCfGroupItem-Main AS "TLB=C:\Fujitsu
COBOL
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C5-5381-11D4-816C-0000B4532893},Fujitsu-PcobCommandButton-4"
000010 CLASS AMixed-DCmTextbox-Main-with-DCfGroupItem-Main AS
"TLB=C:\Fujitsu COBOL
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C7-5381-11D4-816C-0000B4532893},Fujitsu-PcobTextBox-4"
000011 CLASS AMixed-DCmSText-Main-with-DCfGroupItem-Main AS
"TLB=C:\Fujitsu COBOL
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C9-5381-11D4-816C-0000B4532893},Fujitsu-PcobStaticText-4"
Bob Wolfe
>"William M. Klein" <wmk...@nospam.ix.netcom.com> wrote in message
>news:8k3eq9$s4p$1...@slb0.atl.mindspring.net...
>> The original AcuCOBOL source code also used extensions to the Standard.
>
>True.
>
>> My guess is that sp2 would NOT use extensions to do this - as they use
>> primarily "legitimate" ANSI conforming CALL statements.
>
>Well, I don't want to start another war, but while it is true that sp2 is
>called by ANSI convensions, its form construction is way beyond. But that is
>another story.
>
>Cheesle
Cheesle:
A war? With my buddy, Cheesle? Perish the thought!
;-)
Actually, if I understand what you mean by "form construction" you are
absolutely correct. While the CALL in the procedural code conforms to
the ANSI standard, the sp2 "panel definition" as well as the CALLed
dynamic link library are obviously proprietary, as is everyone's
solution at present.
When the standard is updated to include GUI syntax, I'm sure that all
the compiler and 3rd party tool vendors will move in that direction.
We'll support our existing approach in addition to generation of the
standard syntax so that existing applications are provided ongoing
support.
Thane Hubbell
it.... Oh well, here it is:
IDENTIFICATION DIVISION.
PROGRAM-ID. Customer.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-PC.
OBJECT-COMPUTER. IBM-PC.
DATA DIVISION.
WORKING-STORAGE SECTION.
COPY "sp2.cpy".
COPY "Customer.cpy".
PROCEDURE DIVISION.
MAINLINE.
******************
* MAINLINE LOGIC *
******************
PERFORM PROC-OPEN-FILE
MOVE LOW-VALUES TO Customer-DATA
MOVE "Customer" TO Customer-NEXT-PANEL
MOVE "y" TO Customer-NEW-WINDOW
MOVE LOW-VALUES TO Customer-FIELDS
MOVE LOW-VALUES TO Customer-COLRS
MOVE LOW-VALUES TO Customer-TYPES
PERFORM PROC-CON-Customer
PERFORM PROC-CLOSE-WINDOW
PERFORM PROC-CLOSE-FILE
PERFORM PROC-END-SESSION
STOP RUN
.
PROC-OPEN-FILE.
*****************
* OPEN SP2 FILE *
*****************
MOVE LOW-VALUES TO SP2-FI-DATA
MOVE "jimmy.pan" TO SP2-FI-NAME
CALL "SP2" USING SP2-OPEN-FILE SP2-FILE-DEF
.
PROC-CON-Customer.
******************
* CONVERSE PANEL *
******************
CALL "SP2" USING SP2-CONVERSE-PANEL Customer-CONVERSE-DATA
MOVE LOW-VALUE TO Customer-NEW-WINDOW
.
PROC-CLOSE-WINDOW.
************************
* CLOSE CURRENT WINDOW *
************************
CALL "SP2" USING SP2-CLOSE-WINDOW SP2-NULL-PARM
.
PROC-CLOSE-FILE.
**********************
* CLOSE CURRENT FILE *
**********************
CALL "SP2" USING SP2-CLOSE-FILE SP2-NULL-PARM
.
PROC-END-SESSION.
*******************
* END SP2 SESSION *
*******************
CALL "SP2" USING SP2-END-SESSION SP2-NULL-PARM
.
---
now...@freedsl.com
It seems to me that either you do not give attention to what I post OR you have
problem remembering what I post. Below is again what I have stated regarding the
design of the system described in
http://www.ils-international.com/goldmine/newcobol.htm.
Please take the time to review ALL my posting and show me where I have stated
that PowerCOBOL uses ANSI-85 COBOL.
The code I posted was to take up Cheesle's challenge to "beat this number of
lines
and keep the simplicity? This is all that there is needed".
Here I repeat it AGAIN"
The code posted what to take up Cheesle's challenge to "beat this
number of lines and keep the simplicity? This is all that there
is needed"..
1- It seems to me that 50% of anything is SMALLER than anything that is 100% of
the same thing.
2- The simplicity of PowerCOBOL in the example provided is obvious for there
are NO WS of PROCEDURE DIVISION statements dealing with the window definition
and its Controls.
There has never been a mis-information as you claim. As to PowerCOBOL it is
the "closest to the current OO COBOL Standards". I believe if there is anyone
to criticize about the confusing OO Standards and the lack of standardization
among the COBOL vendors, it is not such or such vendor but the OO COBOL
Standards Committee itself for dragging "their feet" to finalize the draft.
When considering that OO COBOL was born more or less in 1992-93 and the
FIRST OO COBOL Compiler was produced and running on a MAINFRAME by Hitachi
in 1994!! ["Made in Japan" - that's right - Not "Made in USA"], here we are
not too far from 2001 and and still we have crazy speculations about OO COBOL
final draft by 2003-2005 and the first Standards compliant Compiler by
2006-2008!!!
No wonder OO COBOL is a favorite JOKE among "Java/C++ and company"!
Here are a few things to think about:
-If a War is lost,
it is not the soldiers or platoon captain's fault,
but the War Room's polished 5-star Generals
who don't have to "swim" in their blood, sweat & tears.
-If a Corporation goes belly up,
it is not the employees or their manager's fault,
but the Conference Rooms polished Executive VPs and CEO
who take decisions based on the technology "du Jour".
As someone famous said in connection to the British loosing the war to the
Germans in WWII "There are no bad soldiers, there are only bad Generals"
It seems to me that OO COBOL is in urgent need of "Good Generals" or the
OO War between Java/C++ and COBOL will be lost. We can finally say what
the next standards of COBOL will be called "RIP COBOL".
Nowitt Oal
----------------------------------------------------------------
Here is what I have stated time and again:
O The entire business and data validation/manipulation is written in ANSI-85
o The files manipulation central program (READ, WRITE, DELETE) is
written in ANSI-85
o No use whatsoever of COMP-5, COMP-X , Level 78 etc..
o No use of INVOKE or any OO syntax
o No Fujitsu COBOL specific routines (i.e.. use INSPECT REPLACING
instead of to_upper / to_lower) functions
o Single program centralizing all SYSTEM CALLS (getdir, mkdir,etc).
can be eliminated or modified easily)
o Reporting programs write to disk files which are redirected to
print spooler.
o All data and parameters - user and system are passed using LINKAGE
SECTION
to the CUI or GUI interface program. (in the case of CUI character
ScreenIO
was used in the case of GUI, VB was used years ago but could not handle
the job very well. Later COBOL GUI tools were evaluated and dropped
because of the Screen Oriented architecture of lack of features and
flexibility. PowerCOBOL passed the test of the most complex GUI
development in both availability of Controls and ease of integration of
ActiveX and execution speed and commendable stability.
O The entire user Interface (CUI or GUI) is separated from the business
and data validation/manipulation and communicate through the LINKAGE.
In this case PowerCOBOL syntax is and OO COBOL are used in PowerCOBOL
modules and for the GUI only. If need be this can be replaced by SPII,
GUI ScreenIO or even BMS on IBM mainframe.
THOSE ARE THE FACTS AND "I STICK TO THEM"!
=================================================
now...@freedsl.com
>> versus the number of line coded using Acucobol approach,
>> one can easily see that I have 50% less code and is about
>> 10 times simpler because I did not have to deal with LINE, COL
>> PIXELS.
>Good, good, we got some code. And if all you gotta do now is to do ccbl
>mysource.cbl and thereafter it executes with no more files, it is good. No
>doubt it is smaller, indeed using a screen designer is simpler. It might
>surprise you, but Acucobol also has a screen designer, so the screen section
>may be done wysiwyg for those who prefer that. So... 10 times simpler?
>Actually, the entire source could be made automatically using a screen
>designer. No way it is simpler.
I am not saying that it is simpler "because the screen section
may be done wysiwyg"
but rather because "there is no Screen Section in WS or PROCEDURE
DIVISION statements of ACCEPT/DISPLAY as it is done in the Acucobol
example. There is no window/controls related code that is shown
in the PowerCOBOL sample. That is what I call 10 times simpler.
>You say that you do not have to deal with positioning. How do you specify
>location then?
It is taken from the WYSIWYG tool file and inserted in the code when
it is generated by PowerCOBOL
Please refer to the PowerCOBOL sample I posted.
>You may have it in a separate form file? If so, my guess is that your number
>of lines increases rapidly, because the code you have shown has no way of
>locating stuff. Are you hiding something?
No. It is not in a "separate form file". Nothing is hiding.
What you fail to understand is how smart the PowerCOBOL design is.
It generates all that is needed in a pre-compile (is what keeps the
code maintained by the programmer very small) and what makes the
executable so fast because all GUI support is linked in the COBOL
program.
>When it comes to readability, you can't deny which is.
30 lines (WORKING-STORAGE/SCREEN SECTION) in your example
vs. 15 lines (LINKAGE SECTION) in PowerCOBOL
16 lines in PROCEDURE in your example
vs. 1 line (EXIT PROGRAM) in PowerCOBOL
You are right nobody "can't deny which is"!
>Cheesle.
>Btw: Acucobol may also use ActiveX's. Which introduces another problem, you
>must install them on the receiving computer. The sample application I made
>does not need any ActiveX's.
Neither does the PowerCOBOL one!
William M. Klein
> Mr. Klein,
>
> It seems to me that either you do not give attention to what I post OR you
have
> problem remembering what I post. Below is again what I have stated
regarding the
> Please take the time to review ALL my posting and show me where I have
stated
> that PowerCOBOL uses ANSI-85 COBOL.
>
And I quote from Mr A**Hole's post dates, July 3rd.
"<Bob Wolfe> I can say this. If the program you demonstrate on your web site
is
100% COBOL, then I challenge you to recompile it with any of the
following 32 bit Windows versions of:
CA-Realia II Workbench
Merant NetExpress
Acucorp's Acucobol GT
Liant's RM COBOL
Egan Systems Interactive COBOL
IBM Visual Age
<No Witt, A**Hole> Although not compiled under some of the above
compilers, the program would compile and execute error free if all of the
above are certified ANSI
COBOL-85. ... They have been enhanced functionality wise and recompiled
without compatibility issues because there was a strict discipline in using
100% ANSI COBOL-85 standards in coding. "
and then you stated
"All Business Logic and User Interface parameters management is handled 100%
using COBOL-85 with the exception of a main module handling all ASSIGN TOs
and FDs. Statements getting physical file names from System variables in
UNIX/DOS/Windows can easily be deleted and handled by JCL if there ever was a
need to move the application to and IBM S/390 for example."
You never DID show us the code that you were talking about, but from the rest
of your post you SEEMED to be talking about the PowerCOBOL code (which you
were advocating). If you are actually NOW saying that this "ideal"
application isn't written using the product that you are advocating, that
adds some more interesting information to your conflicting comments.
>
> There has never been a mis-information as you claim. As to PowerCOBOL it
is
> the "closest to the current OO COBOL Standards". I believe if there is
anyone
> to criticize about the confusing OO Standards and the lack of
standardization
> among the COBOL vendors, it is not such or such vendor but the OO COBOL
> Standards Committee itself for dragging "their feet" to finalize the draft.
>
It is http://www.ils-international.com/goldmine/newcobol.htm which rather
EXPLICITLY (and incorrectly) states,
"Support COBOL standards for COBOL-68, COBOL-74, COBOL-85, OO COBOL, X/OPEN
COBOL"
I won't argue with you about the statement that it is the delay on getting an
OO Standard out that DOES cause the problems. I will, however, argue that
you should make an INCORRECT (and unsubstantiated) claim about PowerCOBOL
supporting standard ... OO COBOL - as defined in the current draft. You
might also want to contact Fujitsu about their "current and continued"
involvement with the J4 Standards committee. I think you will be "amused" by
the answer that you get. (Their current representative has ALMOST nothing to
do with the Fujitsu COBOL development team. Unfortunately, he is now
seriously ill and it is doubtful that they will have ANY continued
involvement with J4.)
Michael Mattias
>
> 30 lines (WORKING-STORAGE/SCREEN SECTION) in your example
> vs. 15 lines (LINKAGE SECTION) in PowerCOBOL
>
> 16 lines in PROCEDURE in your example
> vs. 1 line (EXIT PROGRAM) in PowerCOBOL
>
> You are right nobody "can't deny which is"!
>
Hmm. You must be one of those guys who really believes size matters.
MCM
Ken Foskey
It is only a joke due to the fact that clue less and uneducated people
discuss it with them. OO cobol is grounded (for good or bad) fairly
squarely on Java concepts, they are therefore laughing at themselves.
OO cobol is a reality, there are some significant problems with the
specification, once the standards committee realize it is about
programmers and not vendors I expect to see some real improvements.
Cheesle
news:sdN95.432$HD.1...@dfiatx1-snr1.gtei.net...
> Hmm. You must be one of those guys who really believes size matters.
Definitely the best answer I have read for a while!
Cheesle
Cheesle
number
> >of lines increases rapidly, because the code you have shown has no way of
> >locating stuff. Are you hiding something?
>
> No. It is not in a "separate form file". Nothing is hiding.
> What you fail to understand is how smart the PowerCOBOL design is.
> It generates all that is needed in a pre-compile (is what keeps the
> code maintained by the programmer very small) and what makes the
> executable so fast because all GUI support is linked in the COBOL
> program.
It is apparently so smart then, that you can't see where your fields end up.
Okay, the screen designer has made a binary object to link with the final
executable, and all position information is buried in this binary file. Have
I understood you correct?
If yes, or, btw, anyway, this is definitely nothing for me. I have been
working as a developer in almost 20 years now, and no matter whether I was
working with Modula 2, Pascal, C/C++, Cobol or Delphi, the worst thing I
know is hidden stuff, and particularly when it comes to basic stuff like
positioning of an item. But of course, it is a matter of taste.
Nevertheless, I could extract the screen section part into a copybook, and
the code would shrink correspondingly. You cannot claim I cannot do that,
because you do it yourself.
>>Btw: Acucobol may also use ActiveX's. Which introduces another problem,
you
>>must install them on the receiving computer. The sample application I made
>>does not need any ActiveX's.
> Neither does the PowerCOBOL one!
Well, to me the following is clearly references to ActiveX objects.
000007 CLASS AMethodSetCustomer AS "TLB=C:\Fujitsu COBOL
Projects\Barcode\Customer\Release\~build.tlb,{1E8D94C3-5381-11D4-816C-0000B4
532893},Fujitsu-PcobForm-4"
000008 CLASS AMixed-DCfGWnd-Main-with-DCfGroupItem-Main AS
"TLB=C:\Fujitsu
COBOL
Projects\Barcode\Customer\Release\~build.tlb,{F06C8458-672C-11D2-81F0-00A0C9
613687},Fujitsu-PcobFormWnd-4"
> >When it comes to readability, you can't deny which is.
>
> 30 lines (WORKING-STORAGE/SCREEN SECTION) in your example
> vs. 15 lines (LINKAGE SECTION) in PowerCOBOL
>
> 16 lines in PROCEDURE in your example
> vs. 1 line (EXIT PROGRAM) in PowerCOBOL
>
> You are right nobody "can't deny which is"!
You don't really get it, do you? That is probably why you have such a
problem getting your message through here in this ng. You appear to use
different glasses than others. Readability does not happen about code size,
but how easy the code is to be understood, particularly for people without
insight.
Anyway, I wish you good luck selling the product, I suspect you will need
it.
Cheesle
James J. Gavan
Bob Wolfe wrote:
>
> "Cheesle" <che...@online.NoSpamPlease.no> wrote:
>
> >"William M. Klein" <wmk...@nospam.ix.netcom.com> wrote in message
> >news:8k3eq9$s4p$1...@slb0.atl.mindspring.net...
> >> The original AcuCOBOL source code also used extensions to the Standard.
> >
> >True.
> >
> >> My guess is that sp2 would NOT use extensions to do this - as they use
> >> primarily "legitimate" ANSI conforming CALL statements.
> >
<snip>
>
> When the standard is updated to include GUI syntax, I'm sure that all
> the compiler and 3rd party tool vendors will move in that direction.
> We'll support our existing approach in addition to generation of the
> standard syntax so that existing applications are provided ongoing
> support.
You gotta be kidding - I don't see any reference to it in CD 1.8 and
besides which, your 'ol buddy down there in "Clap, Clap, Clap"-land is
more than happy with SP2 - and he isn't thrilled by event coding in
COBOL, even if he embraces OO <G> - he would rather you do it.
But as "TYCI24H" said elsewhere, if the Standard does eventually include
GUIs - it has to be ALL or NOTHING AT ALL - and so far as I'm concerned
it's got to do it for Windows, Unix, Linux, etc..., etc....
Jimmy
David W. Furin
>
> As someone famous said in connection to the British loosing the war to the
> Germans in WWII "There are no bad soldiers, there are only bad Generals"
>
The British lost? Gosh, I didn't know that... :)
--
David Furin | email: dfu...@larich.com
| smail: 2600 St. Clair Ave. NE
Information Systems Manager | Cleveland, OH 44114 USA
LaRich Distributors, Inc. | web: http://www.larich.com
Thane Hubbell
wrote:
>You gotta be kidding - I don't see any reference to it in CD 1.8 and
>besides which, your 'ol buddy down there in "Clap, Clap, Clap"-land is
>more than happy with SP2 - and he isn't thrilled by event coding in
>COBOL, even if he embraces OO <G> - he would rather you do it.
I am truly getting dense in my old age. What's the reference to
"Clap, Clap, Clap" land mean?
Thane Hubbell
<che...@online.NoSpamPlease.no> wrote:
>
>Anyway, I wish you good luck selling the product, I suspect you will need
>it.
>
The sad reality is that this guy is doing more harm than good to his
cause. He's trying to sell a quality product -- one that oft times
sells itself -- but his attitude and sales pitch turns off the
prospective customer.
BTW: of all the approaches to the "customer entry" yours was the most
elegent looking code wise. I would endorse this approach if it was
not an AcuCOBOL only solution, and if I didn't have a religious
objection to standardizing ANY user interface into the language.
Cheesle
news:3969eab4...@207.126.101.100...
> BTW: of all the approaches to the "customer entry" yours was the most
> elegent looking code wise. I would endorse this approach if it was
> not an AcuCOBOL only solution, and if I didn't have a religious
> objection to standardizing ANY user interface into the language.
I second you that a standard is preferable. And I won't say that the
Acucobol approach is the ultimate. On the other side, we should not end up
with a solution that requires complex OO constructions to develop gui in
Cobol, that is what I am afraid of.
I realize that there is a contradiction in your text above and that my
answer in that context may sound stupid. Considering GUI, I agree with you
that a standardization of user interface is a very difficult if not hopeless
task. That is the price to pay for such a portable language as Cobol is. On
the other side, does Cobol have a future if not doing so?
Generally speaking, I don't understand why the OO Cobol approach is using
the C++/Java approach, while Smalltalk is way closer to Cobol in terms of
English language look a like. Is there anyone out there that can tell me
this?
Cheesle
Joseph J Katnic
Cheesle wrote:
>
> I second you that a standard is preferable. And I won't say that the
> Acucobol approach is the ultimate. On the other side, we should not end up
> with a solution that requires complex OO constructions to develop gui in
> Cobol, that is what I am afraid of.
<snip>
> Generally speaking, I don't understand why the OO Cobol approach is using
> the C++/Java approach, while Smalltalk is way closer to Cobol in terms of
> English language look a like. Is there anyone out there that can tell me
> this?
>
The general reason for using OO is that the OS can provide a default set
of behaviors (read methods) to built and interact with a screen. Then
the User merely has to override these default behaviors with a set that
are tailored to producing the desired result on the screen.
UNFORTUNATELY, to provide for every developers solution, a rather RICH
set of default behaviors have been supplied. Even worse is that the
level of detail for these behaviors is quite extensive (merely because
some developer may want to change the way the OS draws a border for example).
This unfortunate circumstance (started by Xerox, publicized by Apple and
brought to it's ultimate futility by Microsoft) has led to the creation
of huge programs whose only job is to lay some text onto a screen.
Anyone who has seen and used ISPF on the IBM mainframe has seen a
completely different way of presenting data. Where the formatting and
presentation of the data on a screen is not at all related to the
program. That is the program merely presents the data to the IPSF dialog
manager and the dialog manager draws the screen based on a scripting language.
Now where have we heard of a similar scheme.
OH I KNOW - HTML.
YUP, Your good old Web server is a prime example of this type of thing.
There is only one problem, the current HTML does not understand the
difference between text constants and variables in programs.
So the program is reduced to creating the ENTIRE HTML document, even if
it is only going to present one variable on the screen.
In my view adding variables to the HTML standard would allow a program
to export the contents of the variables to the Web Server and then ask
the Web server to present a particular rebuilt HTML document to the
user, substituting the variables as it goes.
A further advantage of this method is that the entire interaction is
transactional. The program does not care if the user moved the mouse or
re-sized the window or any other mind numbing thing. The program is
presented with the data only after the user has finished with the window
and has decided to commit the update. AH but what if you want those
other interactions - Well then write a JAVA program to customize the
browsers behavior.
My take on the GUI standard for COBOL.
1. It should consist of commands to the Web Server to maintain
variables. It should be possible to create, destroy, get and set
variables in a pool belonging to the browser request instance. It should
be possible to tell the server to link page variable pool instances
together to form a session pool. The program also needs to be able to
tell the Server to destroy instance or session pools.
2, It should consist of commands to tell the server to display a page.
This page could be from a predefined set of pages or dynamically build
by the program. Dynamic building should not be the first choice.
I'm not certain, but I think that a lot of the above could be done via XML.
So now all we need is a Web SERVER, but for local only display a runtime
could translate the commands and directly build the pages/windows like a
combination server/browser.
--
Regards,
Joe Katnic jos...@iinet.net.au
Bob Wolfe
>
>
>Bob Wolfe wrote:
>>
>> "Cheesle" <che...@online.NoSpamPlease.no> wrote:
>>
>> >"William M. Klein" <wmk...@nospam.ix.netcom.com> wrote in message
>> >news:8k3eq9$s4p$1...@slb0.atl.mindspring.net...
>> >> The original AcuCOBOL source code also used extensions to the Standard.
>> >
>> >True.
>> >
>> >> My guess is that sp2 would NOT use extensions to do this - as they use
>> >> primarily "legitimate" ANSI conforming CALL statements.
>> >
><snip>
>>
>> When the standard is updated to include GUI syntax, I'm sure that all
>> the compiler and 3rd party tool vendors will move in that direction.
>> We'll support our existing approach in addition to generation of the
>> standard syntax so that existing applications are provided ongoing
>> support.
>
>You gotta be kidding - I don't see any reference to it in CD 1.8 and
>besides which, your 'ol buddy down there in "Clap, Clap, Clap"-land is
>more than happy with SP2 - and he isn't thrilled by event coding in
>COBOL, even if he embraces OO <G> - he would rather you do it.
Jimmy:
Firstly, I believe that it is 4 claps and then a rousing, "Deep in the
Heart of Texas!"
;-)
We won't abandon the way we currently support GUI. We'll add support
for the future standard syntax, when it becomes a standard.
Our code generator is template driven. Heck, we have a code generator
template which generates HTML from an sp2 panel. So the template
should be able to be modified to produce whatever the standards folks
tell us to produce....at least I have my fingers crossed, as we Yanks
say.
>But as "TYCI24H" said elsewhere, if the Standard does eventually include
>GUIs - it has to be ALL or NOTHING AT ALL - and so far as I'm concerned
>it's got to do it for Windows, Unix, Linux, etc..., etc....
Absolutely. That's going to be the tough part.
Bob Wolfe
>On Mon, 10 Jul 2000 04:30:10 GMT, "James J. Gavan" <jjg...@home.com>
>wrote:
>
>
>>You gotta be kidding - I don't see any reference to it in CD 1.8 and
>>besides which, your 'ol buddy down there in "Clap, Clap, Clap"-land is
>>more than happy with SP2 - and he isn't thrilled by event coding in
>>COBOL, even if he embraces OO <G> - he would rather you do it.
>
>I am truly getting dense in my old age. What's the reference to
>"Clap, Clap, Clap" land mean?
Thane:
I suspect that he means...
The stars at night,
Are big and bright,
(clap, clap, clap, clap)
Deep in the heart of Texas,
...and subsequent verses....