× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Clare,

I have half a day of free time, so we can drive BPCS or LX to COMMIT/ROLLBACK
way.
Want you help me in this "little" game? :-))

Seriously.
Mark, on this topic the solution I can foresee is to play around with the
SYSVAL about inactive time of session to force LOGOFF by the system.

This has to be done according to your company business policy, for backup and
all your environment consideration.

As far I can see there is no way to prevent "X" misuse ...

Regards
Davide


-----Original Message-----
From: bpcs-l-bounces+davide.roveda=infor.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+davide.roveda=infor.com@xxxxxxxxxxxx] On Behalf Of Clare
Holtham
Sent: martedì 10 aprile 2007 9.36
To: Midrange Systems Technical Discussion; SSA's BPCS ERP System
Subject: Re: [BPCS-L] Is there a way to prevent iSeries Access exit before5250
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 ...

Replies:

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

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.