As Robbie the robot might say:
Danger! Danger, Will Robinson!
At least on our level of version 6... Commitment control will break BPCS.
There are so many sub-program calls that start new threads that you will
very quickly end up with programs trying to update un-committed records,
and they either hang the program, and the calling program stack, or fail
(and then don't alert the calling stack...)

My best advice is "don't go there!"



"Clare Holtham" <Clare.Holtham@xxxxxxxxxxxxxx>
Sent by: bpcs-l-bounces+phil.catlin=formica.com@xxxxxxxxxxxx
04/10/2007 03:36 AM
Please respond to
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>, "SSA's
BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
cc

Subject
Re: [BPCS-L] Is there a way to prevent iSeries Access exit before 5250
sessionlogoff?






Ha ha ha, I like it! Change BPCS to use commit control.......!!! Rewrite
it
from the bottom up......a simple solution???! If only....

cheers,

Clare

----- Original Message -----
From: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, April 09, 2007 4:04 PM
Subject: Re: Is there a way to prevent iSeries Access exit before 5250
sessionlogoff?


Hi, Al:

Here is a simple "solution" -- change this application to use Commitment
Control.

When the application completes "normally" and the user exits the
screen(s) properly, the programs will issue a COMMIT, and life is good,
as far as the database is concerned.

However, as in your case, if you have some users who insist on "clicking
on the little red X" the job will end abnormally and without issuing a
COMMIT, so the system will automatically do a "ROLLBACK" and the
database will revert to the last "known good" position (before the
changes.)

Plus, another "benefit" of this approach is, perhaps if that same user
has to re-key the same data a few times, then they will "learn" NOT to
"click on the little red X" (because they will have to do that work all
over again).

All the best,

Mark S. Waterbury

Al Mac wrote:
There is a related problem if they doing some interactive update to
corporate records ... THEY may be done with the input, the the program
may
be written such that it expects a normal end-of-job, not a user
initiated
crash. Since the user not think of this as being a crash, no one is
told
they just crashed their job, no one knows it until we find out that the
data has been scrambled. We get this all the time with "in use" flags
needing to be reset, where one of the last closure steps is the program
says this or that is no longer "in use" except by using the red X, the
program never gets to that reset point.


Does anyone know if there is a way to ensure a user actually logs off
their iSeries 5250 session before they click on the (windows) red X to
close the 5250 emulation window? We have "untrainable" users who
instead
of logging off their session, just click on the red X to 'end' the
session, thinking that it doesn't matter.

The big problem is if they are in an interactive session, and do a
request
that may take a short time (ie build a subfile that uses a dynamic
SQL)
and if the session doesn't return 'quickly enough' they just end the
session without a proper signoff. Then the program continues to run,
logging display file i/o errors, and it starts to hog the cpu. I'd
like
to
disable the red X until they actually log off.

Is that possible?

Regards, Jerry

Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of

the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this
message.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.