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
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
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
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 !
National Oilwell Varco
Mono Pumps Limited
Tel. (44) (0)161 214 2142
Fax. (44) (0)161 214 2344
From: 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
Ha ha ha, I like it! Change BPCS to use commit control.......!!! Rewrite
it from the bottom up......a simple solution???! If only....
----- 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
> 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
> 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
>>> 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
>>> 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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.