Fujitsu Cobol & Windows mobile
Euromercante
arrange an application that runs in windows mobile but work with index
Fujitsu COBOL files.
Thanks.
JM
Frederico Fonseca
Do you need to transfer files from the PC to the CE mobile, or do you
need to have the file stored on the Mobile and then have the
application using the file directly?
If the first then Pervasive database format (as I mentioned on another
post of yours) will be a solution, as one of the ways of converting
other formats to the CE format (either with ADOCE or SQL server
format.
There are limits though, and CE is obviously not suitable for LARGE
files, so a possible intermediary solution may be required.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
Euromercante
example.
Many thanks
"Frederico Fonseca" <real-email-...@email.com> wrote in message
news:h5rnh21vjculg9cfv...@4ax.com...
Richard
Euromercante wrote:
> Validate/write registers that would be in a server, acceded by Hi-Fi for
> example.
You won't be able to write a program that directly accesses data files
that are on the server. You probably need to write a web application
in Cobol that runs on the server as a web CGI program running under
Apache, or as a web service, that takes some posted data and returns a
result.
Euromercante
I do not have experience to program with cgi.
has some example?
Many thanks for your reply
"Richard" <rip...@Azonic.co.nz> wrote in message
news:1159646687....@b28g2000cwb.googlegroups.com...
Richard
Euromercante wrote:
> It could be.
> I do not have experience to program with cgi.
> has some example?
http://www.adtools.com/download/v8manuals/NetCOBWinWebGuide.pdf
http://www.adtools.com/download/v8manuals/NetCOBWinWebDevTools.pdf
http://www.adtools.com/download/v8manuals/NetCOBWinCGISubGuide.pdf
http://www.adtools.com/download/v7manuals/NetCOBLinuxWebGuide.zip
cobol_rasurop
Richard wrote:
> You won't be able to write a program that directly accesses data files
> that are on the server. You probably need to write a web application
> in Cobol that runs on the server as a web CGI program running under
> Apache, or as a web service, that takes some posted data and returns a
> result.
Yes, CGI program is one solution for a Windows Mobile (using mobile
browser). But remember that CGI program are not re-entrant, meaning the
system will have to "open" the program and execute the commands... and
then "close" them after use. Using this programming procedure, your
application will definitely slowdown (even considering multi-user
access).
I suggest you create a Cobol COM object(server-side)/IIS/ASP (pages for
mobile). Microfocus NetExpress is very excellent at this. Cobol codes
will eventually do the same functions... but this time quicker and
portable to any Mobile apps. You could use even Pocket PC OS XDA IIi.
Richard
cobol_rasurop wrote:
> Yes, CGI program is one solution for a Windows Mobile (using mobile
> browser).
It doesn't have to be only a browser, in general one can write your own
client programs using the http protocol to access a CGI service.
> But remember that CGI program are not re-entrant, meaning the
> system will have to "open" the program and execute the commands... and
> then "close" them after use.
There are mecahanisms for 'fast-CGI' where the program remains
resident. They don't have to be re-entrant, merely serially reusable.
> Using this programming procedure, your
> application will definitely slowdown (even considering multi-user
> access).
What do you mean 'slowdown' - compared to what ?
> I suggest you create a Cobol COM object(server-side)/IIS/ASP (pages for
> mobile). Microfocus NetExpress is very excellent at this. Cobol codes
> will eventually do the same functions... but this time quicker and
> portable to any Mobile apps. You could use even Pocket PC OS XDA IIi.
In what way is this any different in practice from what CGI does except
for buzzword compliance ?
cobol_rasurop
> It doesn't have to be only a browser, in general one can write your own
> client programs using the http protocol to access a CGI service.
COM+ object can also be packaged and automatically transferred to
client before execution so it could also be used in client-side
processing.
> What do you mean 'slowdown' - compared to what ?
Because of the term "re-entrant", the process of opening and closing
server-side CGI programs will consume processor time and.... if your
system involves Online transactions (via http) then you have to
consider multi-user access. One or two users accessing a single
CGI-program is quite acceptable, but if we are talking of hundreds of
users.... then the slowdown.
> In what way is this any different in practice from what CGI does except
> for buzzword compliance ?
Both technology (CGI and COM objects) represents componentiation....
and that is a very excellent solutions in business industry aside from
it has coding re-use advantage. I advocate cross-platform scenario and
I admit both technology works and it is not just a "buzzword
compliance".
The bottom line is..... as IT professionals, we have to really choose
and even combined different technologies together to come up with
effective business solutions.
Richard
cobol_rasurop wrote:
> Richard wrote:
> > It doesn't have to be only a browser, in general one can write your own
> > client programs using the http protocol to access a CGI service.
>
> COM+ object can also be packaged and automatically transferred to
> client before execution so it could also be used in client-side
> processing.
Which isn't particularly useful when the point of the exercise is to
access data files on the server.
> > What do you mean 'slowdown' - compared to what ?
>
> Because of the term "re-entrant", the process of opening and closing
> server-side CGI programs will consume processor time and.... if your
> system involves Online transactions (via http) then you have to
> consider multi-user access. One or two users accessing a single
> CGI-program is quite acceptable, but if we are talking of hundreds of
> users.... then the slowdown.
Which is why Fast-CGI does not 'open and close' the CGI program which
remains resident and processes each access without 'opening and
closing'.
I think that you are confused between re-entrant and serially-reusable.
cobol_rasurop
Richard wrote:
> I think that you are confused between re-entrant and serially-reusable.
Nope. Initial perception is the "old" way of CGI business processing
nature, which is NOT re-entrant.... well, now that you have fast-CGI as
you put it (serially-reusable) then for sure that fast-CGI application
you're referring to is the same as COM object which is server-side
memory resident.
But the method you used in CGI-application is POST. If you used POST as
your method in handling page information (http), in return the entire
page (HTML-output) will have to "refresh" again. It will slow down
client page refreshing process.
Have you heard of AJAX? Well you could view it anytime here on the net.
You could still use your Cobol code (except of course preferably COM
objects)... and combine it with ASP, AJAX (javascripting). The good
thing about this is... it's free! You could code it in any notepad that
you wish, or download the free HTML-Kit editor.
Well the nature of this AJAX technology is far from the old technique,
it will process your business data via COM objects (instead of CGI)....
WITHOUT refreshing entirely the page you're into. All it has to do is
refresh the "data portion" which is under process. And that makes the
entire business solution faster.
Like I said, it is best to evaluate new technologies.... most
importantly combine the old with the new ones. It will make life easier
for us..
Richard
cobol_rasurop wrote:
> Richard wrote:
> > I think that you are confused between re-entrant and serially-reusable.
>
> Nope. Initial perception is the "old" way of CGI business processing
> nature, which is NOT re-entrant.... well, now that you have fast-CGI
What do you mean by 'now', it has been available and used for a decade
or more. I used it under OS/2 and Windows 95.
> But the method you used in CGI-application is POST. If you used POST as
> your method in handling page information (http), in return the entire
> page (HTML-output) will have to "refresh" again. It will slow down
> client page refreshing process.
Why do you think that it _have_to_ refresh the whole page ? POST (or
GET) is a mechanism for getting data into the program over the HTTP
protocol and is independant of what needs to go out. You are obviously
stuck on what the usual browers may do with particular http messages,
but that doesn't constrain what an application may do.
> Have you heard of AJAX?
Yes of course, and used it. It uses http protocol and works well to
CGI/FastCGI.
> Well you could view it anytime here on the net.
> You could still use your Cobol code (except of course preferably COM
> objects)... and combine it with ASP, AJAX (javascripting). The good
> thing about this is... it's free! You could code it in any notepad that
> you wish, or download the free HTML-Kit editor.
It doesn't need COM, it doesn't need ASP, it work in a browser. It
works to http protocol to Java application servers or CGI, well
anything really.
> Well the nature of this AJAX technology is far from the old technique,
> it will process your business data via COM objects (instead of CGI)....
No, it works to CGI or mod_perl or Tomcat or anything.
> WITHOUT refreshing entirely the page you're into.
Which can be done other ways too.
> All it has to do is
> refresh the "data portion" which is under process. And that makes the
> entire business solution faster.
You are stuck on the idea of using forms in a browser as a client.
Using you own program as a client means that it need not do what a
browser does. AJAX is just a way of implement a JavaScript client but
one could write in Basic or Perl or Python and use the http protocol
any way one likes.
> Like I said, it is best to evaluate new technologies.... most
> importantly combine the old with the new ones. It will make life easier
> for us..
Yeah, but you seem very narrow in your views about what is avilable.
Euromercante
It can be a way?
Thanks
"Richard" <rip...@Azonic.co.nz> wrote in message
news:1160333516.5...@c28g2000cwb.googlegroups.com...
cobol_rasurop
Richard wrote:
> Yeah, but you seem very narrow in your views about what is avilable.
I guess so.... But the point that we are driving at is application
dedicated for Mobile apps (PDAs and the like) right? As pointed out by
Euromercante, he is basically more interested in how mobile apps works.
Euromercante, since most mobile/PDAs (HP iPAQ, Pocket PCs) nowadays
uses Windows CE, Internet Explorer.... you're left with no choice but
to use what is most accessible. Remember that when you deal with Mobile
apps, you're targeting wider customer based.... and that what's matter.
Of course I couldn't suggest CGI, ISAPI is also a better solution
though. Well to tap it all, you could try the site below. Try using an
Internet Explorer Window (without Yahoo tabs) and see the difference.
It may have delay on its first access, but once you've tried querying
one account it will do it a bit quicker. Try type a name directly into
the "Account name" field and see what will happen.
http://infowaters.infodynamicsconsult.com
The site is made up of Cobol COM+, AJAX and ASP page. This is just a
sample full browser apps.... but you could improve it into a Mobile app
(PDAs).
There's a lot of technology out there. As Richard may use CGI.... I
would rather choose AJAX, ASP and COM (or even ISAPI) for Mobile apps.