Re: Is there a way to prevent iSeries Access exit before 5250 session logoff?

Jerry,

I don't know of a way to disable the red X.

Perhaps your best bet would be to make life difficult for the people who
continually shortcut the proper signoff by making them ring the IT
department before they can get into BPCS again ! We did something
similar once to restrict users to a single BPCS session at any one time.


I don't know the details of how you run your system, particularly how
many BPCS sessions a user is allowed to have open at any one time. Also
don't know what version of BPCS you are running. We are running V6.04.

Assuming you want to restrict to only one session at a time :

Amend the Initial Program for BPCS signon (from BPCSMENU ?) to one of
your own.

In this program, run something to count the number of BPCS sessions open
for the user. You could do this by WRKACTJOB to *PRINT, CPYSPLF the
QPDSPAJB report to a file and write a program to analyse the file to
count the number of BPCS sessions open for the user (count the jobs with
the User Id and "PGM-xxxxxxxxxx" (your Initial Program) in the
appropriate positions in the file). Depending on your level of O/S you
may need to play around with this to get it right. Or you may have a
better way of determining. If the user already has a session open (which
he would if he'd red-X'd) then display a screen telling him he already
has a session open and asking him to contact IT. Then sign him off. If
he doesn't have a session open, continue by calling BPCSMENU to get him
into BPCS.

If you want your users to be allowed more than one session at a time,
you just change the check for the number of sessions open.

If you want the number of sessions allowed to vary by user, you could
set up a file keyed on user name with the number of sessions allowed,
read that file in your checking program and check against that number of
sessions. You could default to (eg) 3 sessions if a user isn't set up on
the file, so you only need to set up exceptions. This would give you
freedom to tie down persistent offenders while leaving "good" users
unaffected.

It's not the perfect answer, but may make people think twice about
red-X'ing. If this is of interest and you'd like more info, e:mail me
offline. Whatever you do, THOROUGHLY TEST IT FIRST !

Cheers.

Tom Molyneux

National Oilwell Varco
Mono Pumps Limited
MIS Department

Tel. (44) (0)161 214 2142
Fax. (44) (0)161 214 2344
E:mail Tom.Molyneux@xxxxxxx
tmolyneux@xxxxxxxxxxxxxx


-----Original Message-----
From: bpcs-l-bounces+tmolyneux=mono-pumps.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+tmolyneux=mono-pumps.com@xxxxxxxxxxxx] On Behalf
Of Clare Holtham
Sent: 10 April 2007 08: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.

--
This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a
message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.

Delivered-To: tmolyneux@xxxxxxxxxxxxxx