COBOL GUI front end
Gordon & Gotch Publishing Limited
They are written in RM/COBOL and consist of a large number of programs.
We are currently looking at two main options:
using COBOL-WOW
or moving to ACUCOBOL
Our programs do not use screen sections, are fairly well structured using
sections.
Your comments most welcome!
Thanks
Graham
paulr
Go have a look at www.flexus.com. Very nice stuff.
-Paul
Gordon & Gotch Publishing Limited (tech...@gordon-gotch.co.uk) wrote:
: We are looking to put a GUI front end on our main application packages.
Thane Hubbell
<tech...@gordon-gotch.co.uk> wrote:
> We are looking to put a GUI front end on our main application packages.
> They are written in RM/COBOL and consist of a large number of programs.
>
> We are currently looking at two main options:
>
> using COBOL-WOW
> or moving to ACUCOBOL
>
> Our programs do not use screen sections, are fairly well structured using
> sections.
>
Go to http://www.flexus.com and check out COBOL SP2 - your conversion
from screen section programs to GUI will be mostly painless - they
have a tool to facilitate the conversion. GREAT stuff.
Fujitsu Software
Take a look at Fujitsu PowerCOBOL http://www.adtools.com/4/index.htm
Fujitsu Software Corporation
Developer Tools Group
Phone: (408) 428-0500
FAX: (408) 428-0600
Email: co...@adtools.com
Web: http://www.adtools.com
Gordon & Gotch Publishing Limited wrote in message
<6t84he$fsf$1...@eros.clara.net>...
>We are looking to put a GUI front end on our main application packages.
>They are written in RM/COBOL and consist of a large number of programs.
>
>We are currently looking at two main options:
>
> using COBOL-WOW
> or moving to ACUCOBOL
>
>Our programs do not use screen sections, are fairly well structured using
>sections.
>
Tony M. Mina
used, and still using it, when we converted our entire financial
application to Windows.
They have an evaluation copy that you can download from their site at
www.flexus.com. The product is easy to use and I don't think you will
have problems in converting your applications.
Good luck.
Tony M. Mina
cad...@acucorp.com
"Gordon & Gotch Publishing Limited" <tech...@gordon-gotch.co.uk> wrote:
> We are looking to put a GUI front end on our main application packages.
> They are written in RM/COBOL and consist of a large number of programs.
>
> We are currently looking at two main options:
>
> using COBOL-WOW
> or moving to ACUCOBOL
Disclaimer: I'm an Acucorp employee.
Why Acucobol?
The Acucobol extensions feel considerably more "natural" than usage of
library routines. The normal DISPLAY and ACCEPT verbs are used instead of
repeated CALLs, which helps the code feel more like "classic" COBOL. Also,
the same object file that displays a GUI on a Windows box will display a
similar character mode interface on non-GUI machines. This can be completely
transparent to the programmer - I have a fairly large system that is
single-source for GUI and CUI.
Because we've extended the COBOL syntax, a great deal of behaviour is
provided automatically by the runtime. If you have an entire screen of data,
you can display and accept it normally. The runtime will handle the details
for things such as menus, user navigation and cutting and pasting. If you
want to override the default behaviour, you can easily change the control(s)
in question. Additionally, because you're using COBOL for everything, you
completely avoid the data conversion issues that could be a problem with some
libraries.
I've included a few examples below. If you have any questions or comments, I
monitor this group and you're certainly free to email me (cad...@acucorp.com)
**** Here's the code to display a Push Button on the screen borrowed from two
of our sample programs: (Screen Section) 03 push-button, "E&xit Program",
ok-button, line 25, cline 23, column 27, size 13.
(Procedure Division)
display push-button, "E&xit Program",
ID = 7, ok-button,
line 23, column 25, size 13,
handle in handle-7.
Now, here's something more complex. I've borrowed this code from a interactive
report program I wrote awhile back. This creates a grid:
03 Results-Grid GRID
LINE 3.25 COL 2,
LINES Results-Grid-Lines CELLS SIZE Results-Grid-Size CELLS,
DATA-COLUMNS = (1, 9, 15, 31, 47)
COLUMN-HEADINGS CENTERED-HEADINGS TILED-HEADINGS,
HEADING-COLOR = BCKGRND-WHITE, HEADING-DIVIDER-COLOR = BLACK,
Y = 1
X = 1 CELL-DATA = "Item ID" ALIGNMENT="r"
X = 2 CELL-DATA = "Test ID" ALIGNMENT="r"
X = 3 CELL-DATA = "Category" ALIGNMENT="c"
X = 4 CELL-DATA = "Time Stamp" ALIGNMENT="r"
X = 5 CELL-DATA = "Text" ALIGNMENT="l"
ADJUSTABLE-COLUMNS
VSCROLL,
3-D,
USE-TAB,
EVENT PROCEDURE IS Grid-Event-Proc.
The event procedure allows you to override the runtime's default handling.
Here's what that program used:
Grid-Event-Proc.
EVALUATE Event-Type
WHEN MSG-FINISH-ENTRY CONTINUE
WHEN MSG-CANCEL-ENTRY CONTINUE
WHEN MSG-MENU-INPUT CONTINUE
WHEN MSG-END-MENU CONTINUE
WHEN MSG-VALIDATE CONTINUE
WHEN MSG-GOTO-CELL CONTINUE
WHEN MSG-GOTO-CELL-MOUSE CONTINUE
WHEN MSG-BITMAP-CLICKED CONTINUE
WHEN MSG-HEADING-CLICKED CONTINUE
WHEN MSG-HEADING-DBLCLICK CONTINUE
WHEN MSG-GOTO-CELL-DRAG CONTINUE
WHEN MSG-HEADING-DRAGGED CONTINUE
WHEN MSG-BEGIN-DRAG CONTINUE
WHEN MSG-END-DRAG CONTINUE
WHEN MSG-BEGIN-HEADING-DRAG CONTINUE
WHEN MSG-END-HEADING-DRAG CONTINUE
WHEN MSG-COL-WIDTH-CHANGED CONTINUE
WHEN OTHER CONTINUE
WHEN MSG-INIT-MENU
PERFORM Build-Report-Popup-Menu
WHEN MSG-BEGIN-ENTRY
SET EVENT-ACTION TO EVENT-ACTION-FAIL
WHEN MSG-BITMAP-DBLCLICK
INQUIRE Results-Grid, CELL-DATA IN Selected-Test-ID
CALL THREAD "ViewDesc" USING Selected-Test-ID
END-EVALUATE.
Event-Type is part of a SPECIAL NAMES items which is automatically filled in
by the runtime before the event procedure is called. As you can see, most of
the events were listed only for future programmer's convenience.
The MSG-INIT-MENU event is caused by a right click on a control with a defined
popup menu. In this program menus are dynamic and I have to rebuild the popup
menu before displaying it.
The MSG-BEGIN-ENTRY is triggered when the user double-clicks in a grid cell
or enters a character. Since I was only using the grid to display data, I
used the EVENT-ACTION to effectively make it read-only.
Lastly, in some cells an icon was added. When the user double clicks on it, a
MSG-BITMAP-DBLCLICK event is generated and a utility program is called in a
separate thread.
---
# Chris Adams <cad...@acucorp.com>
Any opinions expressed above may not match those of my employer.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Alan Beecher
I am using Microfocus and Dialog System is their gui answer.
The problem I have with Acucobol is the run time fees they
charge. It makes their product excessively expensive.
Interesting that you mention Cobol-WOW. I just discovered it.
They don't have a MF version ready yet. I may purchase their
Cobol-cgix product for Web programming.
Alan Beecher
75667...@compuserve.com
--
Tony M. Mina
for our GUI interface using MF Cobol Workbench. They don't have a run
time fee. They are at www.flexus.com
Good Luck
Tony M. Mina
Thane Hubbell
> Why Acucobol?
>
> The Acucobol extensions feel considerably more "natural" than usage of
> library routines. The normal DISPLAY and ACCEPT verbs are used instead of
> repeated CALLs, which helps the code feel more like "classic" COBOL. Also,
> the same object file that displays a GUI on a Windows box will display a
> similar character mode interface on non-GUI machines. This can be completely
> transparent to the programmer - I have a fairly large system that is
> single-source for GUI and CUI.
>
Why not? You become a slave to the extensions to Display and Accept
as defined by Accucobol. Upward and cross system compatibility are
compromised. I note, with great interest, that a large portion of the
next COBOL standard deals with cross system source code and
operational compatibility. This is very good and very exciting.
Chris Adams
>> Why Acucobol?
>>
>> The Acucobol extensions feel considerably more "natural" than usage of
>> library routines. The normal DISPLAY and ACCEPT verbs are used instead of
>> repeated CALLs, which helps the code feel more like "classic" COBOL. Also,
>> the same object file that displays a GUI on a Windows box will display a
>> similar character mode interface on non-GUI machines. This can be completely
>> transparent to the programmer - I have a fairly large system that is
>> single-source for GUI and CUI.
>Why not? You become a slave to the extensions to Display and Accept
>as defined by Accucobol. Upward and cross system compatibility are
>compromised. I note, with great interest, that a large portion of the
This is definitely a concern when using any vendor's extensions. Of course,
we're no different from the GUI libraries on this regard as there is no
standard way to handle a GUI. Since you're looking at non-standard code anyway,
I feel it's easier to use and maintain well integrated, very portable
proprietary routines than non-integrated proprietary routines. Certainly,
nothing stops anyone from encapsulating their GUI in separate modules for easy
migration.
We're really neutral on the issue: If you want to write ANSI standard COBOL, we
support that. If you want easy, manageable GUIs, we offer that as well.
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Thane Hubbell
Adams) wrote:
> This is definitely a concern when using any vendor's extensions. Of course,
> we're no different from the GUI libraries on this regard as there is no
> standard way to handle a GUI. Since you're looking at non-standard code anyway,
That's not correct. I can take the code written Realia, Fujitsu,
MicroFocus, etc and it's always the same, and it compiles and I still
get GUI - by making external calls.
> We're really neutral on the issue: If you want to write ANSI standard COBOL, we
> support that. If you want easy, manageable GUIs, we offer that as well.
>
Ah, but it's possible to have BOTH.
Leif Svalgaard
>On Tue, 15 Sep 1998 20:18:02, cad...@cadams-ntw.acucorp.com (Chris
>Adams) wrote:
>
>> This is definitely a concern when using any vendor's extensions. Of
course,
>> we're no different from the GUI libraries on this regard as there is no
>> standard way to handle a GUI. Since you're looking at non-standard code
anyway,
>
>That's not correct. I can take the code written Realia, Fujitsu,
>MicroFocus, etc and it's always the same, and it compiles and I still
>get GUI - by making external calls.
If you make one more level on indirection, you can have it both ways.
That is: put the external calls or the proprietary extensions in a program
you call, with your linkage section, then everything is still fine.
Chris Adams
>> This is definitely a concern when using any vendor's extensions. Of course,
>> we're no different from the GUI libraries on this regard as there is no
>> standard way to handle a GUI. Since you're looking at non-standard code anyway,
>That's not correct. I can take the code written Realia, Fujitsu,
>MicroFocus, etc and it's always the same, and it compiles and I still
>get GUI - by making external calls.
Which you can do with Acucobol as well. For instance, a quick visit to
www.flexus.com shows a platfomr list of Acucobol, Fujitsu, mbp, MicroFocus,
Realia and RM. We just happen to offer a choice...
>> We're really neutral on the issue: If you want to write ANSI standard COBOL, we
>> support that. If you want easy, manageable GUIs, we offer that as well.
>Ah, but it's possible to have BOTH.
Which is why we offer both. Once you do something non-standard, it's a question
where you'll be breaking portability. You may be able to easily switch
compilers but you're tied to your library of choice just as much as our GUI
users are tied to Acucobol.
You've decided that cross-compiler portability is most important to you.
Obviously, not everyone has the same requirements, which is why I made the
original post.
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Chris Adams
>>> This is definitely a concern when using any vendor's extensions. Of
>course,
>>> we're no different from the GUI libraries on this regard as there is no
>>> standard way to handle a GUI. Since you're looking at non-standard code
>anyway,
>>That's not correct. I can take the code written Realia, Fujitsu,
>>MicroFocus, etc and it's always the same, and it compiles and I still
>>get GUI - by making external calls.
>If you make one more level on indirection, you can have it both ways.
>That is: put the external calls or the proprietary extensions in a program
>you call, with your linkage section, then everything is still fine.
This is often a good idea in any case, simply for the added portability. A good
example might involve the current focus on internet applications. Since a web
interface[1] is a fundamentally different means of interaction than most
existing program, it's much easier to add a web interface to a program that has
the backend completely separate from the user interface.
[1] CGI, FastCGI, server module, etc.
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Mike Rochford
Thane Hubbell wrote in message ...
>On Tue, 15 Sep 1998 20:18:02, cad...@cadams-ntw.acucorp.com (Chris
>
>> This is definitely a concern when using any vendor's extensions. Of
course,
>> we're no different from the GUI libraries on this regard as there is no
>> standard way to handle a GUI. Since you're looking at non-standard code
anyway,
>
>That's not correct. I can take the code written Realia, Fujitsu,
>MicroFocus, etc and it's always the same, and it compiles and I still
>get GUI - by making external calls.
But the external calls are all proprietary and lock you into a single vendor
of the GUI interface.
AcuCobol's extensions lock you into a single vendor as well.
What's the difference ???
Both have pro's and con's. Surely it's a process of defining these and then
looking at which is most important.
Mike.
COBOL Frog (Huib Klink)
> ... 8< ... a web
> interface[1] is a fundamentally different means of interaction than most
> existing program,
As far as I have seen it, under the assumption that plain html is used without all
those nice embedded java applets or scripts and other "moving" things, .... a
web-interface basically needs just the same type of pseudo-conversationally
structured application programs as conventional transactional programs under f.e.
CICS or IMS. Basically, I repeat. The CGI-type of connection needs some other
approach then traditional call-interface between program and tp-monitor, but each
program stays the same in structure: triggered by the data entry (enter), starting
with the read/in of already transferred data, doing some processing, sending an
answer, doing some way to keep track of the state of the transaction end then stop
run/goback.
> it's much easier to add a web interface to a program that has
> the backend completely separate from the user interface.
Sure and very true. Each conversion is simpler and profits from it when the
original source is structured and modularised.
8< ....
The Frog
--
Dut: Vandaag is de eerste dag van de rest van je leven! Maak er wat van!
Eng: Today is the first day of the rest of your life! Use it!
------------------------------------------------------------------------
Two options to reach me:
* Reply to H.K...@IMN.nl
* via ICQ:
- My # is 16795376
- Go http://wwp.mirabilis.com/16795376
- Mail to 1679...@pager.mirabilis.com
(Download ICQ at http://www.icq.com/)
Shaun C. Murray
cad...@cadams-ntw.acucorp.com says...
>
>This is often a good idea in any case, simply for the added portability. A
good
>interface[1] is a fundamentally different means of interaction than most
>the backend completely separate from the user interface.
>
>
Since front ends change regularly because of changes in OS/platform interfaces
or because you may want to run the application on multiple platforms, *not*
seperating the backend logic from the front-end interface is a pretty
shortsighted method of development.
The same could be said of many areas. eg. File handling which is why I tend to
use my own file handler. The app just sees a file handler. The file handler
however could be via SQL, COBOL I/O, on a web server via TCP/IP....
--
Shaun
s...@enterprise.net PGP Key available
Judson McClendon
>Thane Hubbell wrote:
>>Chris Adams wrote:
>>>
>>> This is definitely a concern when using any vendor's extensions. Of
>>> course, we're no different from the GUI libraries on this regard as
>>> there is no standard way to handle a GUI. Since you're looking at
>>> non-standard code anyway,
>>
>> That's not correct. I can take the code written Realia, Fujitsu,
>> MicroFocus, etc and it's always the same, and it compiles and I still
>> get GUI - by making external calls.
>
> That is: put the external calls or the proprietary extensions in a
> program you call, with your linkage section, then everything is still
> fine.
This is how I implement the Btrieve interface in my COBOL programs.
In essence, it is building your own API with regard to that function.
--
Judson McClendon judm...@bellsouth.net (remove numbers)
Sun Valley Systems http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Bob Wolfe
>Thane Hubbell wrote in message ...
>>On Tue, 15 Sep 1998 20:18:02, cad...@cadams-ntw.acucorp.com (Chris
>>Adams) wrote:
>>
>>> This is definitely a concern when using any vendor's extensions. Of
>course,
>>> we're no different from the GUI libraries on this regard as there is no
>>> standard way to handle a GUI. Since you're looking at non-standard code
>anyway,
>>
>>That's not correct. I can take the code written Realia, Fujitsu,
>>MicroFocus, etc and it's always the same, and it compiles and I still
>>get GUI - by making external calls.
>
>But the external calls are all proprietary and lock you into a single vendor
>of the GUI interface.
>AcuCobol's extensions lock you into a single vendor as well.
You are 100% correct, Mike. That's why we believe that it is
absolutely essential for us to offer a source code escrow program.
Nobody should be locked into any single vendor solution. If the
vendor fails to continue business operations or is sold to a larger
company who may discontinue support for a specific platform, the
customer is in trouble.
This applies to any vendor-specific library or any compiler-specific
extensions to the language. It's certainly not just a GUI issue.
It's a file-handling issue. It's an ODBC library issue. It's a
communications library issue and it's a compiler language extension
issue.
Many of our customers have signed our 3-way source code escrow
agreement in order to protect themselves for the future. We've
offered this source code escrow contract since 1990. We've been
selling software since 1986, and plan to be around for many years to
come, but no company can provide an iron-clad guarantee that they will
be in business, next week, next month or next year.
It's not that our customers want to obtain our source code, because
it's more source code that they will have to maintain. It does
provide them with that extra bit of protection that we believe is a
smart move for any business who relies on a specific vendor for a
proprietary solution.
Now I'm curious...Are we the only COBOL tool vendor who offers such a
source code escrow contract or do any others offer the same protection
for their customers? COBOL tool vendors? COBOL compiler vendors?
Bob Wolfe, flexus
Check out The Flexus COBOL Page at http://www.flexus.com
Thane Hubbell
Adams) wrote:
> You've decided that cross-compiler portability is most important to you.
> Obviously, not everyone has the same requirements, which is why I made the
> original post.
>
I've been burned before. Imagine purchasing, as an individual, your
favorite COBOL compliler. It's FAST, it's RELIABLE, maintenance costs
are low, and support is superior. It's cool. Company having cash
flow problems, sells to another inovator - Panasophic - and there is
some concern, but all the core people move with the product.
Agreements stay the same.
Then the letterbomb arrives. Talk about a sick feeling. Your
compiler is now part of a congolmerate with a well known reputation.
Not all good. UGH!!!
Anyway, that's one issue. The other, however, is more philisophical.
Should the different vendors extend the language at all?
I've run into people who think that MicroFocus EXTENSIONS are
STANDARD. There's the danger. This is NOT MF's fault - they denote
their extensions in the language reference.
Let me stop rambling. The next COBOL standard does a LOT to address
cross compiler and cross system source incompatibility, anlog with
additions to ensure the same results from the same computations. This
is a good thing, but compiler vendors constantly extending the
language, adding their own proprietary user interfaces, defeat the
standard.
Let's take our favorite whipping boy, C. C has no standard user
interface. You HAVE to make API calls to get the GUI. COBOL can make
these same API calls. There are 3rd party C tools (via CALLS) to make
this API interface easier. Same is true of COBOL. Building the
INTEGRATED user interface into the language is NOT a good thing.
Makes for LACK of portability and ease of platform conversion. That's
ONE reason C is considered more portable than COBOL, even though it is
NOT the case if one were to stick to "Standard" COBOL and not use the
vendor extensions.
Leif Svalgaard
Thane Hubbell wrote in message ...
>Adams) wrote:
>> You've decided that cross-compiler portability is most important to you.
>> Obviously, not everyone has the same requirements, which is why I made
the
>> original post.
>INTEGRATED user interface into the language is NOT a good thing.
>Makes for LACK of portability and ease of platform conversion. That's
>ONE reason C is considered more portable than COBOL, even though it is
>NOT the case if one were to stick to "Standard" COBOL and not use the
>vendor extensions.
>
Even worse: premature STANDARDIZATION. Even Cobol has done that;
there any many examples: DEBUG mode, REPORT Writer, COMMUNICATIONS
division, SCREEN section. These things should not be in the core language,
but handled by an API. Now comes the issue of STANDARD APIs. Ugly.
IBM used to this all the time. I guess that now Bill G is doing it: It is
called
the EXTENDED SUBSET. Not supporting ALL of the standard, but throwing
in some EXTENSIONS to lock the developer in. I have come to believe
that this has to do with human nature, so my ramblings are in vain. (sigh).
The way I deal with all this is to write ALL my stuff in a very small subset
of
Cobol (MOVE, IF, COMPUTE, ADD, SUBTRACT, PERFORM, CALL)
and hide ALL I/O, ALL bit/byte handling, ALL string handling, etc in
subprograms
that are called when needed. Even having a preprocessor to change some
of these calls to EXEC CICS LINKs if needed (e.g. for I/O). This layer of
indirection cost almost nothing (on most systems, AS/400 and MicroFocus
being exceptions - calls are SLOW on these systems) and I'm totally
isolated from compiler vendor's tricks and antics.
My $0.03 worth...
Chris Adams
>As far as I have seen it, under the assumption that plain html is used without all
>those nice embedded java applets or scripts and other "moving" things, .... a
>web-interface basically needs just the same type of pseudo-conversationally
>structured application programs as conventional transactional programs under f.e.
>CICS or IMS. Basically, I repeat. The CGI-type of connection needs some other
>approach then traditional call-interface between program and tp-monitor, but each
>program stays the same in structure: triggered by the data entry (enter), starting
>with the read/in of already transferred data, doing some processing, sending an
>answer, doing some way to keep track of the state of the transaction end then stop
>run/goback.
The problem is that there is no state, so your calls need to pass context back
and forth. It looks something like this (and forgive me if you already knew
this):
1. Browser requests page
2. The CGI program is executed.
a) Initializes
b) Does processing
c) Returns HTML
d) Exits
3. Browser displays page
4. User completes form and submits it
5. Another CGI instance is started
a) Initializes (e.g. reading context item to see what has been done)
b) Processes data
c) Returns HTML
d) Exits
6. Lather
7. Rinse
8. Repeat
You can use a hidden field with a value to determine what stage of the
transaction your program is in. This makes life extremely difficult for
applications that were structured with DISPLAY/ACCEPT pairs throughout the
code...
>> it's much easier to add a web interface to a program that has
>> the backend completely separate from the user interface.
>Sure and very true. Each conversion is simpler and profits from it when the
>original source is structured and modularised.
This is one reason why I'd like a sort of "Zen of Programming" course to be
mandatory for a CS degree. A sort of In the Trenches summary...
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Chris Adams
>>This is often a good idea in any case, simply for the added portability. A
>good
>>example might involve the current focus on internet applications. Since a web
>>interface[1] is a fundamentally different means of interaction than most
>>the backend completely separate from the user interface.
>>
>Since front ends change regularly because of changes in OS/platform interfaces
>or because you may want to run the application on multiple platforms, *not*
<PLUG TYPE="blatant">This is one thing Acucobol makes easier. My GUI programs
run w/o modification in a telnet session to a Unix box as well as on Win31 and
WinNT.</PLUG>
>seperating the backend logic from the front-end interface is a pretty
>shortsighted method of development.
Of course, given the current panic from 2-digit years (even in code less than a
decade old), it's painfully clear that quite a few designs have some rather
unsightly warts. Code that's been hanging around for decades is a lot more
understandable than things that were developed well after some people had
started warning about the problem...
>The same could be said of many areas. eg. File handling which is why I tend to
>use my own file handler. The app just sees a file handler. The file handler
>however could be via SQL, COBOL I/O, on a web server via TCP/IP....
<PLUG TYPE="really blatant">We've done similar things with the COBOL I/O
handler in our runtime to transparently use, say, a relational database.</PLUG>
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Chris Adams
>> You've decided that cross-compiler portability is most important to you.
>> Obviously, not everyone has the same requirements, which is why I made the
>> original post.
>I've been burned before. Imagine purchasing, as an individual, your
>favorite COBOL compliler. It's FAST, it's RELIABLE, maintenance costs
What do you think about things like the source escrow Bob Wolfe mentioned? Or
the Qt foundation that Troll Tech <http://www.troll.no> created to address
concerns about their library being used in GPLed code?
>Anyway, that's one issue. The other, however, is more philisophical.
>Should the different vendors extend the language at all?
>I've run into people who think that MicroFocus EXTENSIONS are
>STANDARD. There's the danger. This is NOT MF's fault - they denote
>their extensions in the language reference.
It was my understanding that many of the current standard features had been
based on extensions made by vendors that proved popular.I would tend to
consider vendor extensions as a good thing because they encourage innovation
and speed the development of the language. However, I very strongly agree that
extensions should be clearly marked as such. Compiling with the appropriate
non-standard exclusion switches (-Rsavir for Acucobol) is a good habit to get
into, even if it's just to make sure you know what won't port easily.
>Let's take our favorite whipping boy, C. C has no standard user
>interface. You HAVE to make API calls to get the GUI. COBOL can make
>these same API calls. There are 3rd party C tools (via CALLS) to make
>this API interface easier. Same is true of COBOL. Building the
>INTEGRATED user interface into the language is NOT a good thing.
>Makes for LACK of portability and ease of platform conversion. That's
I have to disagree somewhat on this count as I've found Acucobol-GT GUIs are
extremely easy to port, usually without even a recompile. I'll add that this is
largely because the GUI syntax is platform neutral and works instead with basic
controls that are found on just about every GUI. After all, those same
complaints could have been leveled against including, say, indexed file support
into the standard.
I'm also interested in seeing what happens when we get a standard OO COBOL.
Hiding the platform specific parts of a GUI is one of the more popular uses for
object orientation in other languages...
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
COBOL Frog (Huib Klink)
> On Wed, 16 Sep 1998 11:27:03, COBOL Frog (Huib Klink) <H.K...@IMN.nl> wrote:
> >As far as I have seen it, under the assumption that plain html is used without all
> >those nice embedded java applets or scripts and other "moving" things, .... a
> >web-interface basically needs just the same type of pseudo-conversationally
> >structured application programs as conventional transactional programs under f.e.
> >CICS or IMS.
8<
> The problem is that there is no state, so your calls need to pass context back
> and forth. It looks something like this (and forgive me if you already knew
> this):
8< [I knew ;) ]
> You can use a hidden field with a value to determine what stage of the
> transaction your program is in. This makes life extremely difficult for
> applications that were structured with DISPLAY/ACCEPT pairs throughout the
> code...
Yep. Solution (just brainstorming): get the IP address or some other unique id of the
connection and use this id as a key to a db-table or indexed file to record state on
the server per user / connection. gives also the possibility to create an extra
TWA/COMM-like area (I assumed you know CICS, TWA=Transaction Work
Area/COMM=communications).
> >> it's much easier to add a web interface to a program that has
> >> the backend completely separate from the user interface.
8<
> >Each conversion is simpler and profits from it when the
> >original source is structured and modularised.
>
> This is one reason why I'd like a sort of "Zen of Programming" course to be
> mandatory for a CS degree. A sort of In the Trenches summary...
Yes. Always separates code for (1) screen i/o, (2) validation logic, (3) business
logic, (4) data file/base i/o. So easy to switch between all 3 (5 if extremes counted)
C/S types. (thin/medium/thick). And a lot easier to port to another platform too.
> ----
> # Chris Adams <cad...@acucorp.com>
> The opinions above are my own and may or may not match those of my employer.
Your employer need not be ashamed for these !!!
Leif Svalgaard
Chris Adams wrote in message ...
>On 16 Sep 98 16:39:01 GMT, Thane Hubbell <red...@ibm.net> wrote:
>>Let's take our favorite whipping boy, C. C has no standard user
>>interface. You HAVE to make API calls to get the GUI. COBOL can make
>>these same API calls. There are 3rd party C tools (via CALLS) to make
>>this API interface easier. Same is true of COBOL. Building the
>>INTEGRATED user interface into the language is NOT a good thing.
>>Makes for LACK of portability and ease of platform conversion. That's
>
>I have to disagree somewhat on this count as I've found Acucobol-GT GUIs
are
>extremely easy to port, usually without even a recompile. I'll add that
this is
>largely because the GUI syntax is platform neutral and works instead with
basic
>controls that are found on just about every GUI.
You are taking a very narrow AcuCobol view here. We are not talking about
porting from AcuCobol on windows to AcuCobol on Unix, but from
AcuCobol to ACME-Cobol.
>After all, those same
>complaints could have been leveled against including, say, indexed file
support
>into the standard.
You are correct here. That is why one should hide all I/O by a second layer
of
indirection (in a called module), because even the standard indexed file
support is not implemented in a standard way be different vendors. The
ASSIGN
clause is a prime example hereof. The ORGANIZATION clause is another.
>
>I'm also interested in seeing what happens when we get a standard OO COBOL.
>Hiding the platform specific parts of a GUI is one of the more popular uses
for
>object orientation in other languages...
You can hide the I/O already now; don't have to wait for OO.
Chris Adams
>> and forth. It looks something like this (and forgive me if you already knew
>> this):
>
>8< [I knew ;) ]
I feared as much... <g>
>> You can use a hidden field with a value to determine what stage of the
>> transaction your program is in. This makes life extremely difficult for
>> applications that were structured with DISPLAY/ACCEPT pairs throughout the
>> code...
>Yep. Solution (just brainstorming): get the IP address or some other unique id of the
>connection and use this id as a key to a db-table or indexed file to record state on
>the server per user / connection. gives also the possibility to create an extra
>TWA/COMM-like area (I assumed you know CICS, TWA=Transaction Work
>Area/COMM=communications).
The IP address won't work because of proxies. A browser cookie is usually the
best choice but there are an astonishing number of otherwise rational
individuals who get phobic about cookies. I think that a hidden value in a form
is probably the most reliable and least likely to provoke complaints.
One other alternative that's a bit buzzword heavy would involve something like
a Java front end, which could dramatically reduce server load. I don't know
about the other COBOL vendors but we've got a product called AcuConnect that
allows you to CALL programs on a remote system. A Java interface to AcuConnect
is in development. This would allow you to have your Java applet do all of the
annoying validation and interface tasks and call the COBOL backend only for the
heavy work.
>> >Each conversion is simpler and profits from it when the
>> >original source is structured and modularised.
>>
>> This is one reason why I'd like a sort of "Zen of Programming" course to be
>> mandatory for a CS degree. A sort of In the Trenches summary...
>Yes. Always separates code for (1) screen i/o, (2) validation logic, (3) business
>logic, (4) data file/base i/o. So easy to switch between all 3 (5 if extremes counted)
>C/S types. (thin/medium/thick). And a lot easier to port to another platform too.
#4 is exactly the sort of thing the AcuConnect product I mentioned was designed
for. As an example, there's no sense in performing a search through an RDBMS
over a network when you can run the search on the server and pass only the
results back. Unless, of course, you're a gigabit ethernet vendor...
I'd also stress that it's a Good Thing not to be afraid of creating general
subprograms. For example, in one project I created a generic routine to get a
filename from the user. When it returns, you get a filename in the passed item.
Other programmers need not care that non-GUI systems will run the code that
uses an ANSI ACCEPT while under Windows the standard File Open dialog is
displayed. Both of those routines are called from the main module which does
things like sanity-checking passed parameters and verifying filenames.
>> # Chris Adams <cad...@acucorp.com>
>> The opinions above are my own and may or may not match those of my employer.
>
>Your employer need not be ashamed for these !!!
Thanks for the kind words. Unfortunately, I think the lawyers sleep easier with
a disclaimer...
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
Chris Adams
>>>this API interface easier. Same is true of COBOL. Building the
>>>INTEGRATED user interface into the language is NOT a good thing.
>>>Makes for LACK of portability and ease of platform conversion. That's
>>I have to disagree somewhat on this count as I've found Acucobol-GT GUIs
>are
>>extremely easy to port, usually without even a recompile. I'll add that
>this is
>>largely because the GUI syntax is platform neutral and works instead with
>basic
>>controls that are found on just about every GUI.
>You are taking a very narrow AcuCobol view here. We are not talking about
>porting from AcuCobol on windows to AcuCobol on Unix, but from
>AcuCobol to ACME-Cobol.
Actually, I was trying to explain why I would consider it a good idea to put
GUI support into the standard. Currently, we are the only ones doing this,
which does cause the problems you've mentioned. Only if it was in the standard
would it become highly portable. However, once that happened it would be very
easy to port GUI apps to wildly different operating systems in the fashion I
described.
>>I'm also interested in seeing what happens when we get a standard OO COBOL.
>>Hiding the platform specific parts of a GUI is one of the more popular uses
>for
>>object orientation in other languages...
>You can hide the I/O already now; don't have to wait for OO.
This is true. However, I think that a well-implemented OO library would be
cleaner, as you could hide a fair bit of the mechanics. In other words, I'm
interested in what we'll get in the future but it's not stopping work in the
mean time...
----
# Chris Adams <cad...@acucorp.com>
The opinions above are my own and may or may not match those of my employer.
paulr
: Chris Adams wrote:
: > ... 8< ... a web
: > interface[1] is a fundamentally different means of interaction than most
: > existing program,
: As far as I have seen it, under the assumption that plain html is used without all
: those nice embedded java applets or scripts and other "moving" things, .... a
: web-interface basically needs just the same type of pseudo-conversationally
: structured application programs as conventional transactional programs under f.e.
: CICS or IMS. Basically, I repeat. The CGI-type of connection needs some other
: approach then traditional call-interface between program and tp-monitor, but each
: program stays the same in structure: triggered by the data entry (enter), starting
: with the read/in of already transferred data, doing some processing, sending an
: answer, doing some way to keep track of the state of the transaction end then stop
: run/goback.
Well, it actually turns out that it is *easier* if you embed some
scripts, because then you can have the browser (client side) do
some data validation. (Is that really a phone number? I'm never
ever going to forget that - even 20 years from now when the web
is a totaly vocal interface with AI agents doing all the work... :)
If that sounds like I am agreeing with you that it is a psudo-conversational
application, you are absolutely right.
On the other hand, the "traditional' CGI approach has a heck of a lot
of steam left in it, especially with COBOL apps that load themselves
and hang around for a bit. (I'm talking about runtime elements.)
William M. Klein
Chris Adams wrote in message ...
>
>Actually, I was trying to explain why I would consider it a good idea to
put
>GUI support into the standard. Currently, we are the only ones doing this,
>which does cause the problems you've mentioned. Only if it was in the
standard
>would it become highly portable. However, once that happened it would be
very
>easy to port GUI apps to wildly different operating systems in the fashion
I
>described.
>
You might be interested in looking at the ANSI/ISO standard for "FIMS"
(Forms Interface Management System) which has an appendix for a COBOL
binding. The COBOL committees (ANSI-J4 and ISO-WG4) looked at adding
"native language" support for this feature (using SEND, RECEIVE, TRANCEIVE,
etc - and not ACCEPT/DISPLAY). However, this was rejected - while I believe
that AcuCOBOL was still a member of the committees. (Check with Gary Henry
of AcuCOBOL for the details of your company's position on this issue - I
don't remember it myself.)
G Moore
wrote:
>If you make one more level on indirection, you can have it both ways.
>That is: put the external calls or the proprietary extensions in a program
>you call, with your linkage section, then everything is still fine.
good idea, except there's 1 problem with this approach...
it requires the programmer to get his extensions
from somewhere other than the manual...
which means some1 will have to rewrite the help files...
gvwm...@ix.spam.netcom.com to reply remove the spam
G Moore
Adams) wrote:
>>Sure and very true. Each conversion is simpler and profits from it when the
>>original source is structured and modularised.
>This is one reason why I'd like a sort of "Zen of Programming" course to be
>mandatory for a CS degree. A sort of In the Trenches summary...
hmm. how about case studies of programming?
speaking of which, i was writing an evaluate section of code,
and instead of writing it in the order which it would probably be
compared, i wrote it backwards. i did this for a few reasons:
1>i didn't know if i changed the variable within the when statement,
after it finished that part, if the next when comparison would be
checked and
2>i didn't want to look it up
3>i figured a few cpu cycles called very infrequently wouldn't
be worth the effort
docd...@clark.net
G Moore <gvwm...@ix.netcom.com> wrote:
[snippage]
>speaking of which, i was writing an evaluate section of code,
>and instead of writing it in the order which it would probably be
>compared, i wrote it backwards. i did this for a few reasons:
>
>1>i didn't know if i changed the variable within the when statement,
>after it finished that part, if the next when comparison would be
>checked and
In other words: 1) Ignorance
>
>2>i didn't want to look it up
In other words: 2) Laziness
>
>3>i figured a few cpu cycles called very infrequently wouldn't
>be worth the effort
In other words: 3) No attention to elegance.
So, let's review: 'I coded in a non-standard manner because of:
1) Ignorance
2) Laziness
3) No attention to elegance.'
Mr Moore, there *are* times when one 'codes backwards', or
'counter-intuitively'... consider the situation of a data-entry screen
into which the operator keys in 25 items. Good Programming Practise has
it that it is a Good Thing to check these fields in *descending* order,
from item 25 to item 01.
Can you see a reason for this?
DD
paulr
If you are checking a whole screen at a time, you
have no idea what the user entered last, so the order
you check the items in will have no signifigance,
as long as you check them all. (And of course,
with relevence to subsequent items. i.e. an
entry of "Producta" in field one may dynamically
define fields 2 - 25, but that would probably
be done in a separate action. Display screen
with 1st field active, check entry in first field,
build screen based upon entry, display screen,
accept screen, validate screen.)
If you are entering stuff a line at a time, then
most folks would check each item as entered, or
when the smallest possible subset of checking
can occur, in the order they are entered.
The *only* time I could see a relevance to this is
if you are displaying a screen of information, yet
processing it field by field, which seems,
inelegant to say the least. :)
-Paul
docd...@clark.net wrote:
: In article <36062bef...@nntp.ix.netcom.com>,
Thane Hubbell
> Even I can't see a valid reason for that one Doc.
> If you are checking a whole screen at a time, you
> have no idea what the user entered last, so the order
> you check the items in will have no signifigance,
> as long as you check them all. (And of course,
> with relevence to subsequent items. i.e. an
> entry of "Producta" in field one may dynamically
> define fields 2 - 25, but that would probably
> be done in a separate action. Display screen
> with 1st field active, check entry in first field,
> build screen based upon entry, display screen,
> accept screen, validate screen.)
You now know the difference between a CICS and a PC programmer. <G>
I know why DD, but I'm not telling.
docd...@clark.net
>Even I can't see a valid reason for that one Doc.
Hey, if it were easy then *everyone* would be doing it, neh?
>If you are checking a whole screen at a time, you
>have no idea what the user entered last, so the order
>you check the items in will have no signifigance,
>as long as you check them all.
Ahhhh, *there's* the rub... 'no significance' to *which* part of the
processing?
>(And of course,
>with relevence to subsequent items. i.e. an
>entry of "Producta" in field one may dynamically
>define fields 2 - 25, but that would probably
>be done in a separate action. Display screen
>with 1st field active, check entry in first field,
>build screen based upon entry, display screen,
>accept screen, validate screen.)
Right out of the textbook, almost sorta kinda. Remember your CICS... SEND
MAP, RECEIVE MAP, then your validate-data rtns.
>
>If you are entering stuff a line at a time, then
>most folks would check each item as entered, or
>when the smallest possible subset of checking
>can occur, in the order they are entered.
An interesting possibility... but not the one here, nope!
>
>The *only* time I could see a relevance to this is
>if you are displaying a screen of information, yet
>processing it field by field, which seems,
>inelegant to say the least. :)
Think in terms of the series of tasks, alternating between the data-entry
clerk and the programmer SEND MAP (programmer), enter data (clerk),
RECEIVE MAP (programmer), validate-data (programmer)... what comes next?
... but I'm *certain* that Mr Moore will be able to see this simple one,
neh?
DD
docd...@clark.net
Thane Hubbell <red...@ibm.net> wrote:
[snippolinio]
>You now know the difference between a CICS and a PC programmer. <G>
'The' difference? You mean there's only one?
>
>I know why DD, but I'm not telling.
Most kind of you to allow Mr Moore his time to shine... in due time we'll
compare answers, I am sure.
DD
Leif Svalgaard
Mike Rochford wrote in message <6tnp6o$e4t$1...@news01.iafrica.com>...
>
>Thane Hubbell wrote in message ...
>>Adams) wrote:
>>
>>> This is definitely a concern when using any vendor's extensions. Of
>course,
>>> we're no different from the GUI libraries on this regard as there is no
>>> standard way to handle a GUI. Since you're looking at non-standard code
>anyway,
>>
>>That's not correct. I can take the code written Realia, Fujitsu,
>>MicroFocus, etc and it's always the same, and it compiles and I still
>>get GUI - by making external calls.
>
>But the external calls are all proprietary and lock you into a single
vendor
>of the GUI interface.
>AcuCobol's extensions lock you into a single vendor as well.
>
I'll make my standard plug here: if you hide either the external calls
or the extensions in an intermediate program that you call from
*your* application, then there is no difference and you are totally
independent and there is no lock-in.
It is amazing how difficult it is to people to see this. (sigh)
COBOL Frog (Huib Klink)
paulr wrote:8< [heavy snip]
> If that sounds like I am agreeing with you that it is a psudo-conversational
> application, you are absolutely right.
Pseudo it is. Like the old days.
> On the other hand, the "traditional' CGI approach has a heck of a lot
> of steam left in it, especially with COBOL apps that load themselves
> and hang around for a bit. (I'm talking about runtime elements.)
Yep. Allthough modern in net-technology (tcp/ip etc) and interface building (html etc.),
the old run-time considerations still apply and probable the solutions will look a lit
like those in classical tp-monitors. Because wether you talk f.e. CICS of some fancy new
on the central machine running serverprogram, both are tp-monitor-like middleware
programs and proven solutions will do. Like the old days. :-)
G Moore
>
>>The *only* time I could see a relevance to this is
>>if you are displaying a screen of information, yet
>>processing it field by field, which seems,
>>inelegant to say the least. :)
>
>Think in terms of the series of tasks, alternating between the data-entry
>clerk and the programmer SEND MAP (programmer), enter data (clerk),
>RECEIVE MAP (programmer), validate-data (programmer)... what comes next?
>
>... but I'm *certain* that Mr Moore will be able to see this simple one,
>neh?
no, i dont think u get it.
pretend you have
evalute var
when 1
perform do-something
move 2 to var
*and right here, i want to drop out of the evaluate
when 2
*instead of going to here
end-evaluate
COBOL Frog (Huib Klink)
8<
> pretend you have
> evalute var
> when 1
> perform do-something
> move 2 to var
> *and right here, i want to drop out of the evaluate
> when 2
> *instead of going to here
>
> end-evaluate
>
> gvwm...@ix.spam.netcom.com to reply remove the spam
That's precisely what an evaluate does or should do according the standard
Perhaps you have a cheap compiler ( F.e. some rewrite of a c-compiler that
thinks evaluate is like switch?)
The COBOL Frog
Leif Svalgaard
COBOL Frog (Huib Klink) wrote in message <35FF8467...@IMN.nl>...
>Chris Adams wrote:
>
>> ... 8< ... a web
>> interface[1] is a fundamentally different means of interaction than most
>> existing program,
>
>As far as I have seen it, under the assumption that plain html is used
without all
>those nice embedded java applets or scripts and other "moving" things, ....
a
>web-interface basically needs just the same type of pseudo-conversationally
>structured application programs as conventional transactional programs
under f.e.
>CICS or IMS.
Not quite. This is only true if the web-enabled program *runs* under a
tp-monitor
already, in which case it is trivially true. The hidden assumption you make
is
that a web-enabled application must use CGI. There are other (better) ways
of doing it, where the program stays in control (runs conversational).
For an example see the web-interface example at http://www.etk.com .
The issue is *not* that web-enabling forces a tp-style program (it does
not),
but that a *multi-user* situation does, as the state for different users
must
be kept separate. The Web-interface is not the determining factor,
multi-user
is.
> Basically, I repeat. The CGI-type of connection needs some other
>approach then traditional call-interface between program and tp-monitor,
but each
>program stays the same in structure: triggered by the data entry (enter),
starting
>with the read/in of already transferred data, doing some processing,
sending an
>answer, doing some way to keep track of the state of the transaction end
then stop
>run/goback.
>
>> it's much easier to add a web interface to a program that has
>> the backend completely separate from the user interface.
>
>Sure and very true. Each conversion is simpler and profits from it when the
>original source is structured and modularised.
>
all programs should have this separation as a matter of course.
paulr
run in conversational mode. To begin with, there is no
connection there to support it.
The very closest you can come is with a Java front end,
or a java based terminal emulator. But those don't use a
WEB connection either.
-Paul
Leif Svalgaard (le...@ibm.net) wrote:
: COBOL Frog (Huib Klink) wrote in message <35FF8467...@IMN.nl>...
paulr
evalaute- the "2" would NOT be checked. (Someone
correct me if I am wrong, but at least in the code
I am looking at right now, a jump table was generated
for the EVALUATE statement. I don't have an LRM
loaded on this system, but I think that only one branch
of any evalaute is ever going to process during a
single execution.
That is also pretty standard behavior across langauges,
in part because it is a very efficient way to generate the
code.
If you mean you want to put a GOTO there, then that is
just - eh - poor design, IMNSHO of course.
If you are saying you want to evalaute a hunk of
screen real estate displayed or received from a user,
then why not do it as a separate transaction. :)
Evaluates are funny in some ways, as are multi-part
if statements. I remember thinking I was pretty
bright once, having tweaked a code generator to
always check the negative branch of an if first
(i.e. it was sign value check) until I ran into
evaluates cousin! :)
-Paul
-Paul
G Moore (gvwm...@ix.netcom.com) wrote:
: On 17 Sep 1998 15:07:09 GMT, docd...@clark.net () wrote:
: >
: >>The *only* time I could see a relevance to this is
: >>if you are displaying a screen of information, yet
: >>processing it field by field, which seems,
: >>inelegant to say the least. :)
: >
: >Think in terms of the series of tasks, alternating between the data-entry
: >clerk and the programmer SEND MAP (programmer), enter data (clerk),
: >RECEIVE MAP (programmer), validate-data (programmer)... what comes next?
: >
: >... but I'm *certain* that Mr Moore will be able to see this simple one,
: >neh?
: no, i dont think u get it.
: pretend you have
Richard Plinston
>
> no, i dont think u get it.
>
> pretend you have
> evalute var
> when 1
> perform do-something
> move 2 to var
> *and right here, i want to drop out of the evaluate
> when 2
> *instead of going to here
>
> end-evaluate
What behaviour do you think Cobol has for this code ?
What research have you done ? What tests have you
performed ?
Arnold Trembley
> Mr Moore, there *are* times when one 'codes backwards', or
> 'counter-intuitively'... consider the situation of a data-entry screen
> into which the operator keys in 25 items. Good Programming Practise has
> it that it is a Good Thing to check these fields in *descending* order,
> from item 25 to item 01.
>
> Can you see a reason for this?
>
> DD
Dammit, DD, I had to wrack my brains for ten full minutes trying to
remember this old trick. I never used it, as I recall. Didn't it have
something to do with moving -1 to an attribute byte?
Of course, I could just be going senile...
--
Arnold Trembley
http://home.att.net/~arnold.trembley/
"Y2K? Because Centuries Happen!"
Leif Svalgaard
Arnold Trembley wrote in message <3601EB04...@worldnet.att.net>...
>docd...@clark.net wrote:
>> Mr Moore, there *are* times when one 'codes backwards', or
>> 'counter-intuitively'... consider the situation of a data-entry screen
>> into which the operator keys in 25 items. Good Programming Practise has
>> it that it is a Good Thing to check these fields in *descending* order,
>> from item 25 to item 01.
>>
>> Can you see a reason for this?
>>
>> DD
>
>Dammit, DD, I had to wrack my brains for ten full minutes trying to
>remember this old trick. I never used it, as I recall. Didn't it have
>something to do with moving -1 to an attribute byte?
If there is more than one error, but you only want to show one error
message, you want to show to error in the line with the smallest
line number, because people read from the top on down, so
checking backwards, you simply move the error message to
the error field as you detect them, the last one moved will
be the first error on the screen if you check from the bottom up.
Arnold Trembley
I *thought* so! And of course, moving -1 to the attribute byte
positions the cursor to the field in error. CICS paints the screen from
the top down, so the first field it finds with the cursor attribute gets
the cursor, even if multiple fields have the cursor attribute set.
Leif Svalgaard
Bob Wolfe wrote in message <35ffadf1...@news.enter.net>...
>You are 100% correct, Mike. That's why we believe that it is
>absolutely essential for us to offer a source code escrow program.
>Many of our customers have signed our 3-way source code escrow
>agreement in order to protect themselves for the future.
>It's not that our customers want to obtain our source code, because
>it's more source code that they will have to maintain. It does
>provide them with that extra bit of protection that we believe is a
>smart move for any business who relies on a specific vendor for a
>proprietary solution.
>
>Now I'm curious...Are we the only COBOL tool vendor who offers such a
>source code escrow contract or do any others offer the same protection
>for their customers? COBOL tool vendors? COBOL compiler vendors?
The ETK tools (http://www.etk.com) subscribes to the "OpenSource"
(http://www.opensource.org) initiative and avoids the cumbersome
escrow procedure by simply delivering the source along with the product,
no questions asked.
You are completely correct that a developer should not be stranded
if his vendor goes belly up or is uncooperative. I'll relay an experience
I had with Realia Cobol some 6 years ago. We got a new PC (a speed
daemon that ran at 33MHz instead of the old's 25 MHz) and all the
sudden the compiler died at the end of every compile. It turned out
that it was computing the number of lines compiled per minute and
that the result was greater than 65,536 so a DIVide overflow resulted.
Now, CA's answer to that was: buy an upgrade for $$$.
Regardless of the $$$ issue, the new version broke many programs
(they were now too big to run under DOS), so an upgrade was not
immediately feasible. I finally ended up breaking the license
agreement's prohibition against disassembling the code and
found the offending DIV instruction and made it a NOP.
But I shouldn't have had to do that.
docd...@clark.net
Arnold Trembley <arnold....@worldnet.att.net> wrote:
>docd...@clark.net wrote:
>> Mr Moore, there *are* times when one 'codes backwards', or
>> 'counter-intuitively'... consider the situation of a data-entry screen
>> into which the operator keys in 25 items. Good Programming Practise has
>> it that it is a Good Thing to check these fields in *descending* order,
>> from item 25 to item 01.
>>
>> Can you see a reason for this?
>>
>> DD
>
>Dammit, DD, I had to wrack my brains for ten full minutes trying to
>remember this old trick. I never used it, as I recall. Didn't it have
>something to do with moving -1 to an attribute byte?
A *very* interesting memory you've dredged up there, Mr Trembley... but
please, let us see how Mr Moore addresses the question, neh? Wouldn't
want to deny him a chance to shine, you know.
>
>Of course, I could just be going senile...
One does not rule out the other, of course.
DD
Bob Wolfe
Whoops! Leif! You let "the cat out of the bag" so to speak.
Don't worry... Charles Wang is a pretty reasonable guy. Now if you
had touched a Microsoft product...Wow! Bill Gates would have
personally had you drawn and quartered on the front lawn of
Microsoft's headquarters in Redmond, WA at dawn!
It's their "eye for an eye" policy. You disassemble code...YOU get
disassembled!
;-)
Bob Wolfe, flexus
Check out The Flexus COBOL Page at http://www.flexus.com
docd...@clark.net
Arnold Trembley <arnold....@worldnet.att.net> wrote:
>Leif Svalgaard wrote:
>>
>> Arnold Trembley wrote in message <3601EB04...@worldnet.att.net>...
>> >> Mr Moore, there *are* times when one 'codes backwards', or
>> >> 'counter-intuitively'... consider the situation of a data-entry screen
>> >> into which the operator keys in 25 items. Good Programming Practise has
>> >> it that it is a Good Thing to check these fields in *descending* order,
>> >> from item 25 to item 01.
>> >>
>> >> Can you see a reason for this?
>> >>
>> >> DD
>> >
>> >Dammit, DD, I had to wrack my brains for ten full minutes trying to
>> >remember this old trick. I never used it, as I recall. Didn't it have
>> >something to do with moving -1 to an attribute byte?
>>
>> message, you want to show to error in the line with the smallest
>> line number, because people read from the top on down, so
>> checking backwards, you simply move the error message to
>> the error field as you detect them, the last one moved will
>> be the first error on the screen if you check from the bottom up.
>
>I *thought* so! And of course, moving -1 to the attribute byte
>positions the cursor to the field in error. CICS paints the screen from
>the top down, so the first field it finds with the cursor attribute gets
>the cursor, even if multiple fields have the cursor attribute set.
Mr Svalgaard, Mr Trembley... for shame, for shame! You've denied Mr Moore
his chance to demonstrate his skills.
Now, Mr Moore... getting back to your 'backwards' EVALUATE... you state
that it is counter-intuitive to code the test for '2' before the test for
'1'. *I* say that this is not the case; that given a rigorous analysis of
the kind of data the system might be processing that this kind of
arrangement might be the most efficient...
... can you see how I come to this conclusion?
DD
Thane Hubbell
> Unless I am very greatly mistaken, no Web application can
> run in conversational mode. To begin with, there is no
> connection there to support it.
>
I think you are mistaken. Form most web based conversational
programs, a direct IP connection is established between the client and
the server. A separate instance of a program services the individual
user. This *is* being done, but it is not the only method.
Thane Hubbell
<arnold....@worldnet.att.net> wrote:
>
> Dammit, DD, I had to wrack my brains for ten full minutes trying to
> remember this old trick. I never used it, as I recall. Didn't it have
> something to do with moving -1 to an attribute byte?
>
> Of course, I could just be going senile...
Nope you are not senile. You are correct. That's the one, and the
root of my "CICS vs PC programmer comment".
Thane Hubbell
>
> Arnold Trembley wrote in message <3601EB04...@worldnet.att.net>...
> >docd...@clark.net wrote:
> >> Mr Moore, there *are* times when one 'codes backwards', or
> >> 'counter-intuitively'... consider the situation of a data-entry screen
> >> into which the operator keys in 25 items. Good Programming Practise has
> >> it that it is a Good Thing to check these fields in *descending* order,
> >> from item 25 to item 01.
> >>
> >> Can you see a reason for this?
> >>
> >> DD
> >
> >Dammit, DD, I had to wrack my brains for ten full minutes trying to
> >remember this old trick. I never used it, as I recall. Didn't it have
> >something to do with moving -1 to an attribute byte?
>
>
> If there is more than one error, but you only want to show one error
> message, you want to show to error in the line with the smallest
> line number, because people read from the top on down, so
> checking backwards, you simply move the error message to
> the error field as you detect them, the last one moved will
> be the first error on the screen if you check from the bottom up.
>
>
Party Pooper.
Leif Svalgaard
docd...@clark.net wrote in message <6ttq7n$it8$1...@callisto.clark.net>...
>>> Arnold Trembley wrote in message <3601EB04...@worldnet.att.net>...
>>> >docd...@clark.net wrote:
>>> >> Mr Moore, there *are* times when one 'codes backwards', or
>his chance to demonstrate his skills.
uh-uh, sorry about that. thought for a second that this was a general
question
to the NG from a bewildered P/A...
that's the problem with instant communications: you just fire it off without
giving it enough thought.
Now, let me see, (60 seconds thought), no, this is OK.
Thane Hubbell
wrote:
> I've looked long & hard at Acucobol and think it looks great.
> I am using Microfocus and Dialog System is their gui answer.
> The problem I have with Acucobol is the run time fees they
> charge. It makes their product excessively expensive.
>
> Interesting that you mention Cobol-WOW. I just discovered it.
> They don't have a MF version ready yet. I may purchase their
> Cobol-cgix product for Web programming.
Alan,
You might want to check out http://www.flexus.com.
They have a simple GUI solution that will work with Net Express
instead of Dialog. I know I "used" to be a Dialog programmer.
You can download an eval version and try it out. I think you will be
pleased with their products - I know I am!
G Moore
<H.K...@IMN.nl> wrote:
>G Moore wrote:
>8<
>
>> pretend you have
>> evalute var
>> when 1
>> perform do-something
>> move 2 to var
>> *and right here, i want to drop out of the evaluate
>> when 2
>> *instead of going to here
>> end-evaluate
>> gvwm...@ix.spam.netcom.com to reply remove the spam
>That's precisely what an evaluate does or should do according the standard
>Perhaps you have a cheap compiler ( F.e. some rewrite of a c-compiler that
>thinks evaluate is like switch?)
i am just paranoid when i write code. after going through multiple
languages, and multiple versions of languages, i write it in a way
that i am sure will work most correctly.
Richard Plinston
> evalaute- the "2" would NOT be checked. (Someone
> correct me if I am wrong, but at least in the code
> I am looking at right now, a jump table was generated
> for the EVALUATE statement. I don't have an LRM
> loaded on this system, but I think that only one branch
> of any evalaute is ever going to process during a
> single execution.
>
> That is also pretty standard behavior across langauges,
> in part because it is a very efficient way to generate the
> code.
In C and derivitives, the switch statement drops through
all subsequent labels. This is somewhat different than
EVALUATE. C provides a 'break' to exit the switch.
The C mechanism is to allow multiple labels to have
the same actions:
switch ( cahracter_in ) {
case '0':
case '1':
this is done when 0 or 1
case '2':
this is done when 2 <<and>> after the action
for 0 and 1
break; /* exits the case */
...
In Cobol the EVALUATE can capture multiple values by
concatenated WHENs so:
EVALUATE character-in
WHEN "0"
WHEN "1"
this is done for 0 and 1
WHEN "2"
this is only done for 2
...
With C you have to take care to add 'break's to stop dropping
through. With Cobol you have to be careful of leaving
enpty action blocks that drop through to the next WHEN.
Richard Plinston
>
> If there is more than one error, but you only want to show one error
> message, you want to show to error in the line with the smallest
> line number, because people read from the top on down, so
> checking backwards, you simply move the error message to
> the error field as you detect them, the last one moved will
> be the first error on the screen if you check from the bottom up.
That is just silly, why not take the more efficient way and
check from the top until an error is found ?
In many cases the checking can't be done backwards, for
example if an early field is, say, a product code, then
this must be checked first and the product read so that
other fields _can_ be checked.
Donald Tees
Richard Plinston wrote in message <3298260.7...@kcbbs.gen.nz>...
>That is just silly, why not take the more efficient way and
>check from the top until an error is found ?
>
And then what, GO TO EXIT-PARAGRAPH? I have always written
code just as stated ... perform check-for-errors until all-errors-corrected.
paulr
either. Perhpas because I decompose my progams to a point
where error checking, display, and business logic is all
a separate function. I also don't overconcern myself
with saving cycles; even PC's have cycles to burn these days.
Especially in some so resource light as error checking a
screen entry. Even on interactive systems with large numbers
of users, the cycles used to handle entry error checking are
not very signifigant. Not signifigant at all in comparison
to eh cycels spent doing the real work, if you get my drift.
I find that I tend to code screens and input in general with the
most critical information - to the program - first.
After a first cut on a screen, I go back and automate / protect
any data entry I can, then reorganize for humans. <grin> Given
that, can you see why checking from the bottom makes little
or no sense?
In *screen* based I/O, I flag all the errors anyway; changing the
color of the input screen, flagging it with some other visual cue,
or whatever the output media allows me to do. So order dependancy
is pretty much a non-issue.
And I would not allow the order I find errors in to dictate the
order I present them to the user in anyway. :)
-Paul
Donald Tees (don...@willmack.com) wrote:
: Richard Plinston wrote in message <3298260.7...@kcbbs.gen.nz>...
Donald Tees
paulr wrote in message <6u0fjs$9...@lotho.delphi.com>...
>After a first cut on a screen, I go back and automate / protect
>any data entry I can, then reorganize for humans. <grin> Given
>that, can you see why checking from the bottom makes little
>or no sense?
What you are forgetting is that the most efficient way for the program
is also the most efficient way for the programmer. Doing something
efficiently does not just save machine cycles. It also saves hours of
writing and debugging code.
Leif Svalgaard
>Unless I am very greatly mistaken, no Web application can
>run in conversational mode. To begin with, there is no
>connection there to support it.
Here is how it is done:
It requires cooperation from the server. There are several
servers that support this. The one we use is the Xitami
server from iMatix. It supports something called a
Long Running Web Protocol, where if a certain URL
are requested the request is sent using TCP/IP to
a port associated with that URL. A constantly running
program (your conversational Cobol program) listens
at this port, get the request, generates the next
HTML page, sends it back to the server, which in
turn sends it to the browser.
This is explaining in detail in the reference below.
paulr
I think it is inefficient to do something in a way that in
contra-intuitive to begin with. To follow up, I tend to
depend upon the compiler to optimize code, which is definately
not the way the world used to work, but is the way it always
should have. And today's compilers are good at optimization! :)
-Paul
Donald Tees (don...@willmack.com) wrote:
: paulr wrote in message <6u0fjs$9...@lotho.delphi.com>...
Donald Tees
>
>I think it is inefficient to do something in a way that in
>contra-intuitive to begin with. To follow up, I tend to
>depend upon the compiler to optimize code, which is definately
>not the way the world used to work, but is the way it always
>should have. And today's compilers are good at optimization! :)
It depends on how good your intuitions are<S>. A compiler will never
change a rats nest of illogical junk into clear precise machine code.
When they do get that good, then I will just switch over to my
psychology degree and keep on telling computers how to work.
The fact is that most *users* cannot specify what they want in a
clear concise manner. Nor is good methodology intuitive. That is
precisely why programmers exist. It is, for example, a major
non-intuitive step from "how much money did I make?" to double
entry book-keeping.
Likewise, to say it is up to the compiler to produce efficient code
is to ignore the basic principal of garbage in garbage out.
Richard Plinston
> Richard Plinston wrote in message <3298260.7...@kcbbs.gen.nz>...
>
> >That is just silly, why not take the more efficient way and
> >check from the top until an error is found ?
> >
> And then what, GO TO EXIT-PARAGRAPH? I have always written
> code just as stated ... perform check-for-errors until all-errors-corrected.
Do you think that 'GO TO Exit-Paragraph' is the only way to
stop processing ?
You could, for example, add an IF ( NOT all-errors-corrected )
to each check so that the check is not done if an earlier
one found an error (and thus set the flag to indicate an
error found).
There are many other ways of short-circuiting, including
nesting IF .. ELSEs right accross the page ;-)
But you didn't answer my real objection to 'doing it from
the bottom' which was that often it is necessary to have
earlier fields correct (such as a valid product or customer)
before other fields can be made sense of.
In fact I dislike the 'ACCEPT all-fields and then validate'
mechanism, I process each field in turn. This gives much
better feed-back to the user and makes corrections easier.
But then some systems, such as mainframe, can't allow
this.
Donald Tees
Richard Plinston wrote in message <3298261.7...@kcbbs.gen.nz>...
>You could, for example, add an IF ( NOT all-errors-corrected )
>to each check so that the check is not done if an earlier
>one found an error (and thus set the flag to indicate an
>error found).
<wait a minute>*That* is exactly what is being argued in favour of,
and what you are disagreeing with! IF you are going to use an "IF"
in that fashion, THEN the order of the "IF" is important. The construct
can go from top to bottom using an "if error then procedure else"
construct, or from bottom to top using an "if ok then procedure else"
construct.
Sometimes one is most effective, and sometimes the other is.
paulr
running a telnet session, though the implementation
seems to be done with threads rather than processes.
(Under NT that is.)
What keeps this from getting very processor intensive
under load?
-Paul
Leif Svalgaard (le...@ibm.net) wrote:
: paulr wrote in message <6tseh4$k...@lotho.delphi.com>...
: >
: >
: >
: >
: >
paulr
so feel free to correct me. I am pretty familar with several
Human Interface Guideline studies, in particuarly Apple's.
I'm also not bad at manging gonzo programmers from Mars. :)
Your absolutely inarguably right, so far as I am concerned,
about a compiler making a rats nest into something elegent.
And you are right about users having trouble specifying
exactly what they want, or rather, specificing their needs
with the necessary clarity. But that is something programmers,
analysts, and software engineers are specifcally trained for.
<grin> Thank goodness, since that is most of what my job is about. :)
However, good progamming methodology *is* intuitive in
every sense. It is litteraly the way people have been
solving problems since sentinence emerged on the planet. :)
Computers, on the other hand, were initially viewed with a
very strange, alien in fact problem solving methodology.
It is not natural for humans to express business problems,
for instance, in octal. (Ever spent a month or so working
with octal dumps to suddenly find you are adding and
subtracting in Octal, in your checkbook?! I and several of
my friends and co-workers have had that annoying experience!)
With the advent of COBOL, and to a lesser extent, FORTRAN,
computer problem solving began to enter the realm where
human problem solving had direct analogy. But we didn't use
it that way at first, because computer programs had to be
concerned with tapes and storage and optimizing processor
cycles. Not *should* have mind you, but had no choice.
Early "mainframe" computers had to read stuff in and write
it to tape not because it was efficient, but because they didn't
have enough memory to do the job in one step.
Heck, the first COBOL compilers used tape, and had to go
through I forget how many stages, but at least 3 or 4,
each on a different tape!
In short, the early programming world had to depend *heavily*
on an intimate knowledge of the machine just to get the
programs to work.
This state of affairs was true even up through the late 1970's,
and persisted up inot the 1990's in a lot of areas. It is, thank
goodness, no longer true in most places.
Computers have plenty of memory and disk to deal with most problems
without the programmer *or* compiler having to give it much or
any attention. I've always loved the Burroughs computers for that
reason, they were the first "mainframe" computers I encountered
that took away worring about memory from the programmers. You asked
for what you want and the machine and O/S went to work and got it
for you. Simple as that. :) I wish to this day I had gotten
to work with them more...
Today, even PC programmers don't worry about memory or disk space;
they simply assume they will have enough. And because of this,
compiler technology has advanced signifigantly. Most compilers
today turn out code comparable with hand coded assembly. Sure, a
programmer can sometimes, mabe even usually do better in some
spots, but overall, the code quality is very high.
So to some degree, yes, the garbage-in / garabage-out princible
has been done away with. As long as the input code works,
the compiler is liable to optimize it into something better.
trashy code will generate much poorer executables than
reaonably well thought out code, but the difference is
probably smaller than you might think.
Yours,
-Paul
Donald Tees (don...@willmack.com) wrote:
: paulr wrote in message <6u0tco$d...@lotho.delphi.com>...
Donald Tees
paulr wrote in message <6u1ujl$c...@lotho.delphi.com>...
>However, good progamming methodology *is* intuitive in
>every sense. It is litteraly the way people have been
>solving problems since sentinence emerged on the planet. :)
>Computers, on the other hand, were initially viewed with a
>very strange, alien in fact problem solving methodology.
>It is not natural for humans to express business problems,
>for instance, in octal. (Ever spent a month or so working
>with octal dumps to suddenly find you are adding and
>subtracting in Octal, in your checkbook?! I and several of
>my friends and co-workers have had that annoying experience!)
Yes, I have.
But that is the exact point. "Intuitive" is just another word
for "the way I am used to doing it". Things become intuitive
because you first learn them, then you practice them. Nobody
thinks in *any* number system the day they are born. You
evolved an intuition for decimal because someone five hundred
years back ignored the fact we have four fingers and a parity
thumb on each hand. It is a historical accident, not "correct".
To say a new way of doing something is wrong because
it is non-intuitive is to say "nothing new".
I play guitar. It is intuitive for me to stay in a specific key,
because I have spent years listening to and playing scales.
Certain oriental music sounds "intuitively" wrong as a result,
because it uses different scales. It is not, though. It is
just new to my ear.
I agree that in an every day working situation that you have
to trust your "intuitions". That is why you develop them. You
do not have time on an every day basis to examine every
belief ... you use what you know. A learning situation, though,
is quite different, as is a research situation. There is often
a better way than the intuitive way, and the purpose of learning
is to evolve new intuitions.
BTW<G>, your intuitions would be quite different if you
learnt on IBM instead of DEC. You would make hex mistakes
instead of octal.
Donald Tees
paulr wrote in message <6u1ujl$c...@lotho.delphi.com>...
BTW, as a secondary to that, I was quite astonished
recently when my seven year old grandchild taught me how
to count to 16 on my four fingers. Seems her intuitions
are evolving differently than mine did.
Chris Westbury
pa...@bix.com (paulr) wrote:
>
> Today, even PC programmers don't worry about memory or disk space; they
> simply assume they will have enough. And because of this, compiler
> technology has advanced signifigantly. Most compilers today turn out
> code comparable with hand coded assembly. Sure, a programmer can
> sometimes, mabe even usually do better in some spots, but overall, the
> code quality is very high.
Gee, and you were doing so well up to here. In almost all cases it is
worth trading hardware for labor, but one shouldn't forget that it is a
tradeoff.
Compiler code is not even in the same ballpark as hand-coded assembly
language, and, far from advancing, compiler technology has never again
come close to the early ForTran code generators. The reason is obvious:
the compiler writer is also trading hardware for software. Think about
it: if the compiler were emitting code comparable to hand-coded assembly
language, you wouldn't _need_ all that memory and disk space!
On the increasingly rare occasions when business reasons justify a
rewrite from CoBOL to Assembler, I get a decrease in chargeback of
90-99%, and, no, that's not a typo. More often, old Assembler programs
are rewritten in CoBOL, and those who have forgotten the basics are
surprised by the magnitude of the chargeback increases, occasionally to
the point of wishing they hadn't done the rewrite.
Again, the cost of CoBOL is almost always worth it, but don't kid
yourself that there is no cost.
--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138
paulr
around today into assmebly would result in that great a savings.
Sure, recoding bottlenecks and time critical passages works
in a lot of cases, but in a lot of other cases, a close examination
of compiler generated code shows some pretty decent code generation.
Chris Westbury (cwes...@giant.intranet.com) wrote:
: In article <6u1ujl$c...@lotho.delphi.com>,
Charles F Hankel
>
> Well, it actually turns out that it is *easier* if you embed some
> scripts, because then you can have the browser (client side) do
> some data validation. (Is that really a phone number? I'm never
> ever going to forget that - even 20 years from now when the web
> is a totaly vocal interface with AI agents doing all the work... :)
Careful, in the UK we are again about to upset the valid phone number
apple-cart as well as the millions of telephone users. A whole new
phone numbering system is being introduced which will, generally add
another digit to most people's telephone numbers.
Where I live, for instance, 0151-555 5555 is to become something like
01151-555 5555.
Y2k, Euro, phone numbers? We've got the lot.
--
Charles F Hankel, Wirral, UK
----------------------------
Charles F Hankel
> into which the operator keys in 25 items. Good Programming Practise has
> it that it is a Good Thing to check these fields in *descending* order,
> from item 25 to item 01.
>
How very CICS. It could also apply to the PC stuff as well if you can
suppress the temptation to be too conversational.
--
Charles who has worked with a CICS Assembler package system with fully
conversational transactions. I decline to name names at this time.
paulr
localized. Throughly! Brit phone numbers already
have a digit too many. ;)
-Paul
Charles F Hankel (cha...@hankel.mersinet.co.uk) wrote:
Thane Hubbell
wrote:
> In message <<3601f...@news1.ibm.net>> "Leif Svalgaard" <le...@ibm.net> writes:
> >
> > If there is more than one error, but you only want to show one error
> > message, you want to show to error in the line with the smallest
> > line number, because people read from the top on down, so
> > checking backwards, you simply move the error message to
> > the error field as you detect them, the last one moved will
> > be the first error on the screen if you check from the bottom up.
>
> That is just silly, why not take the more efficient way and
> check from the top until an error is found ?
It's really not that silly. Consider that the DATA IS GONE after the
return to the program. You need to check all the fields for error the
FIRST TIME through. (Although there are ways around this)
You need to position the cursor on the first one, cause that's the
nice way to do things. You might even have an error message that you
want displayed. You want it to match the top level error.
Lastly, you can set the display attributes to HIGHLIGHT or whatever,
ALL the errors, while positioning the cursor on the FIRST error - the
most common use I know of for scanning backward. One pass through the
data highlights all errors, displays the topmost error message, and
positions the cursor on the first field in error.
(DD- There's my understanding - we talked about comparing answers
later).
docd...@clark.net
Thane Hubbell <red...@ibm.net> wrote:
>On Fri, 18 Sep 1998 20:18:12, rip...@kcbbs.gen.nz (Richard Plinston)
>wrote:
>
>> In message <<3601f...@news1.ibm.net>> "Leif Svalgaard" <le...@ibm.net> writes:
>> >
>> > If there is more than one error, but you only want to show one error
>> > message, you want to show to error in the line with the smallest
>> > line number, because people read from the top on down, so
>> > checking backwards, you simply move the error message to
>> > the error field as you detect them, the last one moved will
>> > be the first error on the screen if you check from the bottom up.
>>
>> That is just silly, why not take the more efficient way and
>> check from the top until an error is found ?
>
>
>It's really not that silly. Consider that the DATA IS GONE after the
>return to the program. You need to check all the fields for error the
>FIRST TIME through. (Although there are ways around this)
There's *always* 'another way to do things', granted... but i was taught
that backwards-checking on screens was a Good Thing To Do.
>
>You need to position the cursor on the first one, cause that's the
>nice way to do things. You might even have an error message that you
>want displayed. You want it to match the top level error.
... and so you go through your items in reverse order... editing, passing
and failing, until you're done... and then...
>
>Lastly, you can set the display attributes to HIGHLIGHT or whatever,
>ALL the errors, while positioning the cursor on the FIRST error - the
>most common use I know of for scanning backward. One pass through the
>data highlights all errors, displays the topmost error message, and
>positions the cursor on the first field in error.
Now *this* one is much more subjective... many Big Thick Books have been
written about Good Screen Design and this is but one technique...
... I remember once asking about how I should flag errors on a screen and
the analyst said 'oh, *you* come up with something, you're a Professional,
that's why you get paid the Big Bucks'... so, when it came time to test,
we sat a data-entry girl (and yes, she was a girl... a tiny slip of a
lass, looked to be about 14 years old) down at a 3270 and had he run
through the screen... and for all errors I set the FAC to inverse blinking
highlight underlined... and the poor child hit Enter , yelped and almost
began to weep.
The moral? The moral is what Folks Are Usually Happier When Everyone Does
Their Own Jobs.
DD
G Moore
Westbury) wrote:
> I get a decrease in chargeback of
>90-99%, and, no, that's not a typo. More often, old Assembler programs
>are rewritten in CoBOL, and those who have forgotten the basics are
>surprised by the magnitude of the chargeback increases, occasionally to
>the point of wishing they hadn't done the rewrite.
hmm. maybe they should rewrite it in C instead. i have heard C only
gives a 50% decrease. since the assembly to cobol
change is made for a better supply of COBOL programmers to asm
programmers, and since C has lots of programmers, it might may sense.
Donald Tees
>
>hmm. maybe they should rewrite it in C instead. i have heard C only
>gives a 50% decrease. since the assembly to cobol
>change is made for a better supply of COBOL programmers to asm
>programmers, and since C has lots of programmers, it might may sense.
>
in computer usage in trade for a 5000% increase is programmers
is not much of a trade ...
G Moore
<don...@willmack.com> wrote:
>
>>hmm. maybe they should rewrite it in C instead. i have heard C only
>>gives a 50% decrease. since the assembly to cobol
>>change is made for a better supply of COBOL programmers to asm
>>programmers, and since C has lots of programmers, it might may sense.
>The keyword here is "C has lots of programmers". A 50% decrease
>in computer usage in trade for a 5000% increase is programmers
>is not much of a trade ...
umm, lets pretend u r a info management dept head. lets further
pretend asm programmers costs go up $10k per year, and
machines go down $1k per year. now lets pretend c programmers
go up $1k per year, due to supply.
simply subtrsact the cost of the extra machine, from the cost of the
amount of years of the C programmers, and wallah, you get the time
it takes to make back your C investment.
Richard Plinston
> Westbury) wrote:
>
> > I get a decrease in chargeback of
> >90-99%, and, no, that's not a typo. More often, old Assembler programs
> >are rewritten in CoBOL, and those who have forgotten the basics are
> >surprised by the magnitude of the chargeback increases, occasionally to
> >the point of wishing they hadn't done the rewrite.
>
> gives a 50% decrease. since the assembly to cobol
You shouldn't be too sure that C will be faster than Cobol.
I have sample code where the Cobol outperforms C. While
C generally is a good performer certain aspects are not
always optimum. One particular case is data formatting
where printf() is often _very_ slow.
In both languages the performance is also going to be
very dependant on the arithmetic library. If Cobol
were to use numbers outside the range of C long and
floating point was inappropriate then C will have to
use functions to deal with extended formats of some
kind - and this may be slower than Cobol's routines.
> change is made for a better supply of COBOL programmers to asm
> programmers, and since C has lots of programmers, it might may sense.
There are still more Cobol programmers than C programmers
working in corporates. In a datamation survey a couple
of years back it found over half of all programmers
worked in Cobol, while about 30% were C/C++.
The total was over 100% (when all languages were counted)
because many worked in more than one language.
Richard Plinston
> paulr wrote in message <6u0fjs$9...@lotho.delphi.com>...
>
> >After a first cut on a screen, I go back and automate / protect
> >any data entry I can, then reorganize for humans. <grin> Given
> >that, can you see why checking from the bottom makes little
> >or no sense?
>
>
> What you are forgetting is that the most efficient way for the program
> is also the most efficient way for the programmer. Doing something
> efficiently does not just save machine cycles. It also saves hours of
> writing and debugging code.
What a load of nonsense you do spout.
For example, for a simple text search task the most efficient
program, saving machine cycles, would be a hand coded one
with an algorithm optimised for the particular search string.
If I wanted to 'save hours of writing and debugging' I would
just use the grep command and would waste huge quantities
of CPU cycles.
While you seem to have a crusade to save a few machine
cycles this is a usually a complete waste of effort,
especially in a program that will spend 99% of the
time waiting for keystrokes (blocked one hopes) and
most of the rest waiting for disk I/O while verifying
that the customer code exists by reading the record.
But then I have seen someone spend an hour or two
optimising a delay loop.
Chris Westbury
pa...@bix.com (paulr) wrote:
>
> In article <1998Sep20.090055.19262@giant>,
> cwes...@intranet.com (Chris Westbury) wrote:
> >
> > In article <6u1ujl$c...@lotho.delphi.com>,
> > pa...@bix.com (paulr) wrote:
> > >
> > > Today, even PC programmers don't worry about memory or disk space;
> > > they simply assume they will have enough. And because of this,
> > > compiler technology has advanced signifigantly. Most compilers
> > > today turn out code comparable with hand coded assembly. Sure, a
> > > programmer can sometimes, mabe even usually do better in some
> > > spots, but overall, the code quality is very high.
> >
[snip my disagreement with a single paragraph from a long article]
> Good points, but I'm not so sure recoding most of the stuff around
> today into assembly would result in that great a savings. Sure,
> recoding bottlenecks and time critical passages works in a lot of
> cases, but in a lot of other cases, a close examination of compiler
> generated code shows some pretty decent code generation.
Again, I am not _recommending_ recoding in assembly language.
What I am trying to say is that we have passed gradually from the true
statement, "The costs of recoding in assembly language almost always
outweigh the savings" to the hopeful but false statement, "There are no
savings to recoding in assembly language".
The fact is that the code compilers turn out today is nowhere near
hand-coded assembly language, and, paradoxically, the best, most
optimized code generators of today are not as good as the run-of-the-mill
code generator of thirty years ago. The reason for this is precisely the
tremendous increase in memory, cycles, and disk space available to the
compiler writer as to any other programer.
I mention also that the typical reason for recoding in Assembler today is
not a bottleneck or a critical section. The biggest reduction in
chargeback cost is storage occupancy and paging (which is, after all, a
form of I/O) and this can be achieved only by rewriting the whole
program.
Chris Westbury
gvwm...@ix.netcom.com (G Moore) wrote:
>
> In article <1998Sep20.090055.19262@giant>,
> cwes...@intranet.com (Chris Westbury) wrote:
> >
> > More often, old Assembler programs are rewritten in CoBOL, and those
> > who have forgotten the basics are surprised by the magnitude of the
> > chargeback increases, occasionally to the point of wishing they
> > hadn't done the rewrite.
>
> hmm. maybe they should rewrite it in C instead.
On the mainframe, there's no point in going from Assembler to C. C has
no fixed-point decimal, no VSAM, does not emit the EDMK or SVC
instructions, &c, &c, and even for the few things C can do more easily
than Assembler it is slower than CoBOL because C I/O has to be converted
interpretively at run time to mainframe I/O and because C wastes so many
run-time cycles stacking and unstacking and mallocing and freeing main
storage.
Robert Ward, founder and editor of the C User's Journal, published an
editorial circa 1989 in which he stated (paraphrased from memory): I live
C, I breathe C, I love C; but the subscription management for this
magazine is done in CoBOL. The last thing I need is a dangling pointer
error on the day that the labels are due at the printer.
paulr
Guess we will just have to disagree then; my expereince and
observations tell me that the code generators today are
producing much better code than 10 years ago. And yes, there
is an awful lot more code, but then again, programs *do* a
lot more today too.
Chris Westbury (cwes...@giant.intranet.com) wrote:
: In article <6u3dod$2...@lotho.delphi.com>,
: pa...@bix.com (paulr) wrote:
: >
: > In article <1998Sep20.090055.19262@giant>,
: > cwes...@intranet.com (Chris Westbury) wrote:
: > >
: > > In article <6u1ujl$c...@lotho.delphi.com>,
: --
G Moore
Westbury) wrote:
>On the mainframe, there's no point in going from Assembler to C. C has
>no fixed-point decimal, no VSAM, does not emit the EDMK or SVC
>instructions, &c, &c, and even for the few things C can do more easily
>than Assembler it is slower than CoBOL
uh-huh. then what is the
decimal (total_places,decimal_points) value;
referenced in the openedition C manual?
Judson McClendon
>
>Robert Ward, founder and editor of the C User's Journal, published an
>editorial circa 1989 in which he stated (paraphrased from memory): I live
>C, I breathe C, I love C; but the subscription management for this
>magazine is done in CoBOL. The last thing I need is a dangling pointer
>error on the day that the labels are due at the printer.
This is exactly why I am distressed at the addition of pointers to COBOL.
--
Judson McClendon judm...@bellsouth.net (remove numbers)
Sun Valley Systems http://personal.bhm.bellsouth.net/~judmc
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Chris Westbury
gvwm...@ix.netcom.com (G Moore) wrote:
>
> In article <1998Sep24.083343.19281@giant>,
> cwes...@intranet.com (Chris Westbury) wrote:
> >
> > On the mainframe, there's no point in going from Assembler to C. C
> > has no fixed-point decimal, no VSAM, does not emit the EDMK or SVC
>
>
> decimal (total_places,decimal_points) value;
>
> referenced in the openedition C manual?
Since you are the one who has the said manual, you are in a much better
position than I am to tell us what it is, but, whatever it is, it isn't
part of the C language, or even of the C++ language. It may be a class
library, or a vendor extension, or a preprocessor like Pro*C, or
something else.
On the mainframe, CoBOL fits the hardware and the OS well, whereas C
doesn't. There are platforms on which it would be preferable to go from
assembly language to C, but the mainframe is not one of them.
Richard Plinston
>
> On the mainframe, CoBOL fits the hardware and the OS well, whereas C
> doesn't. There are platforms on which it would be preferable to go from
> assembly language to C, but the mainframe is not one of them.
It is actually the _applications_ which either go well to
C or to Cobol. Many types of application are not accounting
systems and, for example, use floating point. The absense
of decimal arithmetic is irrelevant to C where it is used
to write programs that don't need it.
paulr
C is designed around the use of multiple stack frames to
handle function calls, recursion, and a half dozen other
little things. The IBM Mainframe architecture doesn't support
memory stacks, and so the C compiler plays a lot of tricks.
I *think* it loads a faked out stack frame pointer in registers
13 and 14, and calculates the offset through register 10.
I'm not expert in IBM mainframe hardware, but this much I'm
pretty sure of. Compilers are kinda my "thing."
-Paul
Richard Plinston (rip...@kcbbs.gen.nz) wrote:
G Moore
Westbury) wrote:
>> decimal (total_places,decimal_points) value;
>> referenced in the openedition C manual?
>Since you are the one who has the said manual, you are in a much better
>position than I am to tell us what it is, but, whatever it is, it isn't
>part of the C language, or even of the C++ language. It may be a class
>library, or a vendor extension, or a preprocessor like Pro*C, or
>something else.
correct. i think it is a class library or extension.
in any case, openedition C found on IBMs website supports packed
decimal.
>On the mainframe, CoBOL fits the hardware and the OS well, whereas C
>doesn't. There are platforms on which it would be preferable to go from
>assembly language to C, but the mainframe is not one of them.
it depends on the program.
for instance, one could port a dev driver in asm to one in C, on a
mainframe, and gain considerable economic advantage in maintaining
that program, with only a loss of 50% speed for the abstraction (or
less). porting a financial package would not be good, but
a financial engine might.
Chris Westbury
> >
> > Robert Ward, founder and editor of the C User's Journal, published an
> > editorial circa 1989 in which he stated (paraphrased from memory): I
> > live C, I breathe C, I love C; but the subscription management for
> > this magazine is done in CoBOL. The last thing I need is a dangling
> > pointer error on the day that the labels are due at the printer.
>
> This is exactly why I am distressed at the addition of pointers to
> COBOL.
I'd like to think that the use of pointers will take as long to spread as
the use of good features like the intrinsic functions. After all, I've
still got _two_ clients on CoBOL 68. But, realistically speaking, I have
to admit that pointers are, to borrow a legal term, an "attractive
nuisance".
Chris Westbury
gvwm...@ix.netcom.com (G Moore) wrote:
>
> In article <1998Sep26.085240.19287@giant>,
> cwes...@intranet.com (Chris Westbury) wrote:
> >
> > On the mainframe, CoBOL fits the hardware and the OS well, whereas C
> > doesn't. There are platforms on which it would be preferable to go
> > from assembly language to C, but the mainframe is not one of them.
>
> it depends on the program.
>
> for instance, one could port a dev driver in asm to one in C, on a
> mainframe, and gain considerable economic advantage in maintaining that
> program, with only a loss of 50% speed for the abstraction (or less).
> porting a financial package would not be good, but a financial engine
> might.
I think you've lost the context here. Many large corporations have one
or two old Assembler applications, emphasis on "old", and every so often
some hotshot PHM decides for no particular reason that an Assembler
application will be rewritten in Cobol "to improve maintainability" of a
program that has not needed modification in ten years. Mind you, there
are times when this is a good idea, but such a decision ought to be based
on costs and benefits, not on wishful thinking.
Because of the widespread misconception that today's compilers can
approach the quality of hand-coded assembly language (a misconception
that is not limited to CoBOL) the company is then surprised at the
thumping great increase in monthly chargeback for the CoBOL program,
occasionally to the point that they wish they hadn't done the rewrite.
You suggested that the company could get the same improvement in
maintainability without as large an increase in chargeback if they
rewrote in C instead of in CoBOL. This is a reasonable suggestion on
many platforms, but not on the mainframe, despite the fact that the very
first port of PDP-11 C was to a 360 at Princeton.
There is an impedance mismatch between the minicomputer-style C abstract
machine and the mainframe hardware. This shows up especially in I/O,
where only the simplest I/O is built in, and that slow because
interpretative. The built-in C I/O can not do what the Assembler
application does, and if you use non-built-in I/O, you lose
maintainability compared to CoBOL, which can do with built-in I/O what
the Assembler application does. Even in compute-bound programs, C wastes
many run-time cycles stacking and unstacking, mallocing and freeing,
pointing and dereferencing.
PL/S is the language that is to mainframe operating systems as C is to
UNIX and BLISS is to VMS.
Judson McClendon
>
>PL/S is the language that is to mainframe operating systems as C is to
>UNIX and BLISS is to VMS.
The Unisys A Series, like it's antecedents back to the B5000 series, have
no assembly compilers, and all system software is written in specialized
dialects of ALGOL. The B1000 series had no assembly compiler either, but
could have had several, because it was a soft machine. The microcode was
actually loadable files, and (as I recall) there was one for COBOL, one
for FORTRAN, one for RPG, etc., each with a machine language tailored to
the task. When task switching, the microcode was also switched if it was
different, and this turned into a bottleneck. The B1000 was also unusual
in that there were no hardware instructions for basic arithmetic. You
placed the operands in special registers, and at every machine cycle the
sum, difference, product, quotient, etc. were available in other registers.
baloo...@gmail.com
http://www.acucobol.comyr.com
Best Regards !
German Lopez
Mentor Cobol Senior
gel...@hotmail.com
Pereira - Colombia
El jueves, 10 de septiembre de 1998, 2:00:00 (UTC-5), Gordon & Gotch Publishing Limited escribió:
> We are looking to put a GUI front end on our main application packages.
> They are written in RM/COBOL and consist of a large number of programs.
>
> We are currently looking at two main options:
>
> using COBOL-WOW
> or moving to ACUCOBOL
>
> Our programs do not use screen sections, are fairly well structured using
> sections.
>
> Your comments most welcome!
>
> Thanks
>
> Graham