rag2000
asked on
Acucobol application to be web-enabled
I have an AcuCobol database and application on a SCO UNIX server, which I want to web-enable. I am looking for advises on what would be the best approach for doing this. I have my own ideas, which I would like to build upon. This is just to see what the other experts have to say.
ASKER
Hi Cd&,
Sorry for the incomplete information. The details are as follows:
The application and database is currently only for the Intranet, but one particular module needs to be accessible thru the Internet for everybody.
Currently, the app is only on the local server and used on any pc on the Intranet using a terminal emulator.
My question is how do I access, read and write to the acucobol database. Is the above info OK or you need to know more? Let me know.
Sorry for the incomplete information. The details are as follows:
The application and database is currently only for the Intranet, but one particular module needs to be accessible thru the Internet for everybody.
Currently, the app is only on the local server and used on any pc on the Intranet using a terminal emulator.
My question is how do I access, read and write to the acucobol database. Is the above info OK or you need to know more? Let me know.
You could start by doing a web search for ODBC drivers and Accucobol, as you might well need this kind of functionality to get at the database from a web-enabled application.
My thought about the architecture is that you will need 3 new components:
A new 'presentation layer', i.e. a set of html forms that allow people to interact with the database from a web browser. These pages might be 'standard' flat html, or maybe something generated by server-side scripts.
A new server-side business-rules layer, which consists of a set of scripts to communicate between the presentation layer and the database middleware layer. These scripts control what queries and updates people are allowed to carry out from the presentation layer.
A new database middleware layer (ODBC) to allow the scripts to query and update the database.
The particular technologies to be used will vary depending on requirements, but under Unix, maybe you want to look at perl, which would be able to handle the presentation and business-rule layers. Perl can talk 'ODBC' so as long as you can get an ODBC driver for the database it should be doable.
If you can't find any way to do this, there are some specialised middleware products such as APILink, which are designed for exposing legacy databases to web applications - let me know if you need more help. jmoore@payperpage.com
Finally, you could be really unsafe, and allow people to telnet to your server through a firewall, and access the application the same way you do over the intranet. I wouldn't recommend this though AT ALL.
My thought about the architecture is that you will need 3 new components:
A new 'presentation layer', i.e. a set of html forms that allow people to interact with the database from a web browser. These pages might be 'standard' flat html, or maybe something generated by server-side scripts.
A new server-side business-rules layer, which consists of a set of scripts to communicate between the presentation layer and the database middleware layer. These scripts control what queries and updates people are allowed to carry out from the presentation layer.
A new database middleware layer (ODBC) to allow the scripts to query and update the database.
The particular technologies to be used will vary depending on requirements, but under Unix, maybe you want to look at perl, which would be able to handle the presentation and business-rule layers. Perl can talk 'ODBC' so as long as you can get an ODBC driver for the database it should be doable.
If you can't find any way to do this, there are some specialised middleware products such as APILink, which are designed for exposing legacy databases to web applications - let me know if you need more help. jmoore@payperpage.com
Finally, you could be really unsafe, and allow people to telnet to your server through a firewall, and access the application the same way you do over the intranet. I wouldn't recommend this though AT ALL.
I assume you already have the server side processing working as this is
an existing application. The task is to preserve that processing and
break out the client side functionality.
The COBOL on the backend expects a formatted message layout. In order
to retain the current database process from COBOL, either the COBOL
program must be converted to process the string that get sent from
a browser client, or an intermediate script must do a conversion
between the formats.
The choice of options is dependent on the server side environment, and
what you actually have available.
The client side changes are straight forward in terms of presentation
the screen for the terminal emulation has to be coded as a HTML form for
submission to the server side script for processing.
The this that will likely geive you the most trouble is data validation.
The browser is not able to do automatic type checking or format/content
validation. The validation will have to be done using JavaScript on the
client side or moved into the backend. If you are doing terminal emulation,
you probably are not doing any local processing, so that should not be an
issue.
So the presentation should be relatively simple, the database access is
already in place, and the place to start to put it together is to determine
if the browser can come across to the COBOL backend using http, or is
a script necessary or desirable.
Cd&
an existing application. The task is to preserve that processing and
break out the client side functionality.
The COBOL on the backend expects a formatted message layout. In order
to retain the current database process from COBOL, either the COBOL
program must be converted to process the string that get sent from
a browser client, or an intermediate script must do a conversion
between the formats.
The choice of options is dependent on the server side environment, and
what you actually have available.
The client side changes are straight forward in terms of presentation
the screen for the terminal emulation has to be coded as a HTML form for
submission to the server side script for processing.
The this that will likely geive you the most trouble is data validation.
The browser is not able to do automatic type checking or format/content
validation. The validation will have to be done using JavaScript on the
client side or moved into the backend. If you are doing terminal emulation,
you probably are not doing any local processing, so that should not be an
issue.
So the presentation should be relatively simple, the database access is
already in place, and the place to start to put it together is to determine
if the browser can come across to the COBOL backend using http, or is
a script necessary or desirable.
Cd&
ASKER
Hi Cd&,
Yes, the server application is complete and works perfectly.
My idea is to host the Internet application along with the website on a different server, which will have html pages, etc. We can validate either client-side or server-side on this server. The use Perl/CGI to interact with the acucobol database. Can you provide any ideas or resources on how this can be done. Data will be required to be read and written in realtime with the acucobol database.
Yes, the server application is complete and works perfectly.
My idea is to host the Internet application along with the website on a different server, which will have html pages, etc. We can validate either client-side or server-side on this server. The use Perl/CGI to interact with the acucobol database. Can you provide any ideas or resources on how this can be done. Data will be required to be read and written in realtime with the acucobol database.
My idea is to host the Internet application along with the website on a different server, which will
have html pages, etc. We can validate either client-side or server-side on this server. The use Perl/CGI
to interact with the acucobol database. Can you provide any ideas or resources on how this can be done.
Data will be required to be read and written in realtime with the acucobol database.
Doing the queries and updates realtime requires continuous availability of
the COBOL program. I haven't used acucobol for that but I have used
COBOL II and COBOL85 for exactly that. Here are the options on the methods
you can use. Which you use will depend on what the environment is capable
of.
The delivery of the transaction and the respones can use:
1. A comm process which is defined like a file in the program (a common
method in UNIX and TANDEM environments) is used to route the traffic.
The program just sits on a READ listening. The comm process receives the
transaction from the script or web server. After processing the program
sends back the response with a WRITE.
2. <not a good method> The program receives and responds on it's terminal
interface via an ACCEPT/DISPLAY dialog. The script must act like a
terminal emulator. This method is a real resource hog and is difficult
to manage if there is a lot of traffic.
3. A token file is created when there is a message. The message is put
into a text file and the token is created by the script. Once every
second the program checks for the token. When the token exits, it
reads the file and processes the information. Then deletes the token.
The response is done the same way except the rolls of the program
and script are reversed.
HTH
Cd&
have html pages, etc. We can validate either client-side or server-side on this server. The use Perl/CGI
to interact with the acucobol database. Can you provide any ideas or resources on how this can be done.
Data will be required to be read and written in realtime with the acucobol database.
Doing the queries and updates realtime requires continuous availability of
the COBOL program. I haven't used acucobol for that but I have used
COBOL II and COBOL85 for exactly that. Here are the options on the methods
you can use. Which you use will depend on what the environment is capable
of.
The delivery of the transaction and the respones can use:
1. A comm process which is defined like a file in the program (a common
method in UNIX and TANDEM environments) is used to route the traffic.
The program just sits on a READ listening. The comm process receives the
transaction from the script or web server. After processing the program
sends back the response with a WRITE.
2. <not a good method> The program receives and responds on it's terminal
interface via an ACCEPT/DISPLAY dialog. The script must act like a
terminal emulator. This method is a real resource hog and is difficult
to manage if there is a lot of traffic.
3. A token file is created when there is a message. The message is put
into a text file and the token is created by the script. Once every
second the program checks for the token. When the token exits, it
reads the file and processes the information. Then deletes the token.
The response is done the same way except the rolls of the program
and script are reversed.
HTH
Cd&
ASKER
Ok, Cd&... thanks for the information till now. Let me set up the pages, scripts, etc and then will be back here, till then, see you. I should be back in a couple of days.
ASKER
Ok, I am back after a long wait....
Now, what is need to know is how do I get or where can I get the ODBC drivers to connect from my web application, which is being scripted in ASP to connect to the Acucobol database and retrieve and push data to it.
Now, what is need to know is how do I get or where can I get the ODBC drivers to connect from my web application, which is being scripted in ASP to connect to the Acucobol database and retrieve and push data to it.
You're going love this link. A page of ODBC drivers and the first on listed is for Acucorp, and there is a whole bunch of drivers:
http://ourworld.compuserve.com/homepages/Ken_North/odbcvend.htm
Cd&
http://ourworld.compuserve.com/homepages/Ken_North/odbcvend.htm
Cd&
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Just the last bit, could you help me with the Data Dictionaries on the Cobol front.... the ODBC driver is in place... the final part needs to be done... connecting to the Cobol database.
What is it you need?
Cd&
Cd&
ASKER
Hi Cd&,
We want to retrieve data from the cobol dat files, using our asp pages and the odbc driver.
We want to retrieve data from the cobol dat files, using our asp pages and the odbc driver.
I don't know ASP. I have never used it. However I would think that
there must be some method for it to import the data definitions, so that
it knows what the data looks like.
Cd&
there must be some method for it to import the data definitions, so that
it knows what the data looks like.
Cd&
ASKER
could you guide me into creating data dictionaries on the cobol database and app.
What data definition language are you using? Can ASP not understand
table defintion and column definitions from the database to build a
data dictionary?
I don't know what a data dictionary has to look like for ASP.
Cd&
table defintion and column definitions from the database to build a
data dictionary?
I don't know what a data dictionary has to look like for ASP.
Cd&
ASKER
"... However I would think that there must be some method for it to import the data definitions, so that it knows what the data looks like ..."
is what I trying to find out, how do I do this?
is what I trying to find out, how do I do this?
I don't know ASP, so I don't know how it brings the definitions in or even how it types the data. I don't know how to help you with taht part.
Cd&
Cd&
for advises on what would be the best approach for doing this. I have my own ideas, which I would like
to build upon. This is just to see what the other experts have to say.
That is a pretty broad general question. I think you will have to give us
a little more detail to get intelligent responses. What kind of application?
How heavy is the client side? What functionality is being done client side?
What browsers and version does it need to support? Is it targetted for
the Internet or a local intranet?
There is a lot of GUI functionality that is not easily implemented with the
capabilities of a browser. Tell us more.
Cd&