There are problems using commitment control in a browser environment. Each
program on the server will "end" after all data has been sent to the browser
even if you don't specifically end it. The program will still be open with
all its resources and will be listening for a connection from a client.
However, that client could be any client, not necessarily the same client it
just sent data to. Each browser request will connect to any available job on
the server, or even start a new one.
HTTP sessions are not usually persistent, so unless you have persistent
sessions (i.e. one client per server job and the client always connects to
the same job with every request), commitment control (as performed on the
green screen) is very tricky.
Leaving files open between client requests can also be problematic. Some
files may end up being open for hours, days, or even weeks on end and this
can result serious problems for back up, and other maintenance requirements.
Again, unless you know you have persistence, and that the end user will
finish the transaction and not leave in the middle (eg. browse to a
different page or web site), it is better to open and close files in every
browser request unless you know it will not cause you problems.
One of your biggest problems will be when to do a ROLLBACK - you won't know
if the client browser has gone away.
If you do not have persistence, other features such as library QTEMP are not
usable between different browser requests. Each request is likely to give a
different QTEMP.
The best way handle database updates is to gather all the information first,
validate it and issue any required error messages. At this stage you do not
update any files. Then, when all is ready, in a single transaction (browser
request) perform all your DB updates. Now, if required, you can use
commitment control to ensure everything updates correctly.
The information you gather for your updates might require several browser
displays and you will need to store the collected data for each request.
This can be achieved in a number of ways. It can be stored on the client in
HTML hidden fields, or in JavaScript fields. To store the data on the server
you will need access to your session and you should be able to store
variables there.
Hope this helps
Syd Nicholson
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of hrabar@xxxxxxxxxxxxxxxxx
Sent: 11 July 2008 16:59
To: web400@xxxxxxxxxxxx
Subject: [WEB400] RPG-CGI using commitment control
We are running into a problem trying to use commitment control in web based
programs.
We are in the process of porting are "green screen" programs to our web. In
the old 5250 world, we created our files with share(*yes) and all of the
"important" files
were opened with commitment control.
Most of our early web based programs were used to just display data to the
users. We are now starting to bring our maintenance/updating programs over
and are running into
problems. The HTTP server job(s) keep files open after the rpg has ended.
This was causing open errors when we tried to open a file with commitment
control and the job had
the file open without it. We got around this by using user open/ovrdbf
share(*no) in the rpg.
As we expand and are adding calls to existing programs(Printing forms for
example) we are having the same open problems. We do not want to recreate
these programs just to add/remove the commitment control.
Anyone have any advice on how to get around this?
Should we start the programs running in different activation groups
(New/Caller/Default)?
2008 Excellence Awards for Stroke, Gastrointestinal and Pulmonary
Care, HealthGrades
2006 & 2007 Awards for Emergency, Outpatient and Inpatient Service
Excellence, J.D. Power
Primary Stroke Center Designation, The Joint Commission
Chest Pain Center Accreditation , Society of Chest Pain Centers
2006, 2007 & 2008 Best Places to Work in New Jersey, NJBIZ
The information contained in this message is privileged and CONFIDENTIAL
and is intended only for the use of the addressee above. If you are not
the intended recipient, you are hereby notified that any disclosure,
copying, distribution or taking of any action in reliance on the content of
this message is strictly prohibited.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
