Re: [open-cobol-list] User interaction preference.

[Wim Niemans]

We used to call the COMMUNICATIONS a TP-monitor.
The interface offered in Cobol is similar to the SORT facility.
Since TP-monitors and Databases were often integrated, we needed the 
ROLLBACK and GOBACK. But nowadays terminal sessions are stateless.

Basicly, what we do is 'read' a terminalFILE en write the response back 
onto it. This FILE cannot be rewound etc. which makes it very 
implementator dependent. Mostly the RECORD to be obtained went thru an 
intelligent middleware-resident remapping of the screen. So, Cobol is 
intended to be record oriented: get one, process some, put one (or more).

Similar, using http or cgi, this record could be seen as a FORM. The 
intelligent re-mapping is than server side, *and* (as has been) 
implementor dependant.
Now, what to do if there is no implementor? Have a preprocessor (tcl/tk), 
a postprocessor (perl/php) or something entirely new?

AcuCobol designed a nice interface, using the IS EXTERNAL FORM clauses.
ACCEPT INPUTFORM gives you the formfields remapped on your record.
DISPLAY OUTPUTFORM can use a template to remap the record on a page.
However, it is not intelligent. No filters, no numerical checks, no data 
formatting, etc.

A pretty important constraint on using such Cobol compilers is the license 
managers they all use. Since a website can have hundreds of simultaneous 
users, the cost for licenses raises into the sky.

I'm using a webfacilty with forminputs and output templates.
All in Cobol, and it runs astonishly fast. Like my oldish menuing system 
there is even an actioncontroller in Cobol. Likewise, I'm routing services 
(aka web services) through the same system, written in Cobol.
Beware. It *is* file based. A big surprise was that I do not need 
interactive statements at all. This system reduces the code to about 30% 
of what is needed for an interactive application using a (graphical) 
screen with positioning effects.

Well, the implementation is like html/php/perl/cgi........ Every request 
reloads the software, including the runtime libraries.
What one needs is an implementator that keeps the cgi/http peculiarities 
away and the system in memory. Only in that case the COMMUNICATIONS 
section could be revived. All other scenario's are pointing to a file 
mechanism, which could be an in-memory filesystem or inter-process comms.
In order to implement features like EXTERNAL FORM or ASSIGN TO CGI 
(example), the compiler has to be able to compile some dictionary 
information (read: mappings) and embed that in the compiled program. The 
main problem here is STANDARDS.

I've tried before to code called routines to gather CGI variables and/or 
Forms. That was not very hard. The next problem was the specification how 
to handle this data and hand it over to the calling Cobol programs.
FI. CALL 'myCGI' using formID, formRecord (a 01-level record).
Than 'myCGI' gets it all, and doesn't know how to map these individual 
items onto the 01-level record and/or what to do with exceptions.

Anyway, this would be a very interesting discussion.

Cheers,
wim niemans



On 25 Jun 2006 at 9:17, John R. Culleton wrote:

> Most modern business programming starts out with user
> interaction. In the old days an order was received and it went to
> keypunch for preparation of cards. Then the process was from then
> on batch. That was yesterday.
> 
> In some of today's world at least the order is entered online and
> iinteracts with the customer file, the inventory file etc. in
> more or less real time. 
> 
> So we need an on line interactive face for whatever language we
> choose. Let's assume right now Open Cobol. We can either have a
> one-language system or a two language system. For the
> one-language solution we have the SCREEN SECTION or the
> positioned ACCEPT and DISPLAY statements as in e.g., Ryan McFarland or many
> other variants. At this point Open Cobol doesn't provide either
> (or did I miss something?) And even the SCREEN SECTION doesn't do
> all that needs to be done, such as radio button selection. 
> 
> The two (or more) language solution offers many choices. Here are
> some I am considering, based mainly on previous knowledge of
> the languages:
> 1. Tcl/Tk
> 2. HTML
> 3. Perl/Tk
> etc.
> 
> At first blush Tcl/Tk seems to have all the features needed. But
> it wants to be on top, and not a called program. And passing data
> back and forth would be through files accessed by both languages. It
> might be necessary to establish a small work file and reread it
> with each action by the user, passing information back and forth.
> Not wonderful. Or messaging could perhaps be done. Where is the
> COMMUNICATIONS SECTION now when we finally (after all these
> decades) need one? 
> 
> HTML has of couse that kookie cgi interface with messages sent
> back and forth. But it is possible to have what looks like a
> single interactive program at work using said cgi interface.
> 
> To get down to cases, what facilities do we have right now for
> communicating between Open Cobol and other programing languages?
> And which of the many interactive languages offers the most hope?
> Waht exactly is the syntax for calling an external program such
> as a Tcl script? Can we use Open Cobol as a cgi program? Is
> anyone actually doing it? 
> 
> I use Linux. 
>  
> -- 
> John Culleton
> 
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list