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

We have dealt with this several ways.

First, the job description of IT is not to educate the end users, although we do on occasion. It is not to make the job of IT easier, although we do that also. The name of our game here is to keep the system running, resolve problems that threaten the integrity of overall data quality, and to do so with minimum disruption to the business.

In communicating with a higher level management, I liken myself to a train engineer. Our company is on a train taking us to more profitable business. My job is to keep that train running smoothly, help it go faster and faster. Occasionally we have some problem, like a train derailment. My job is to get it back on the tracks, get all implications repaired, and get it running again as rapidly as possible.

This scenario is one of many that threaten to wreck the train.

The problem happens for us in job responsibilities where there is a high degree of turn-over, with new staff entering high volumes of data. When I discover that it has happened, I notify the person supposed to be training the new user, and the manager of the application, of the importance of learning how to sign off properly, because of the nature of how their application data can get messed up, if this is not done properly.

I have taught a handful of co-workers how to repair the flag in-use scenario, at the superficial level. This means the IT job is to get the train back on its journey, then the buck is passed to application management to audit the orders hit by the crash, from a list provided to them by IT.

ie. When it is reported to you from end users that SOMEONE cannot get into something because of in-use flag, determine if this is customer order, PO order, or whatever

If PO, I have never seen an incident with more than a tiny # of orders in this condition, and I believe our people know whether or not they doing something that would update an PO, which includes Pur Managers by facility, Inventory Receiving, and Payables entry. Just get all those people to return to a menu, then manually (via DFU), fix that flag, while they are not in the middle of any updating.

If CO, it could be one order or many orders. We have many people who update COs who apparently are oblviious to the notion that they are updating COs. If we ask that EVERYONE who is updating COs to get off the system during repairs, there will be many relevant people who don't, because they don't realize this also applies to them.

Our normal solution is to get EVERYONE in the whole company, at all physical locations, to sign off BPCS during the repairs. It usually takes 1/2 an hour to accomplish this, because some people are slow to respond, while others think it must of been fixed, and sign back on without waiting for the word. Then it takes like 2 minutes to implement the fix, then we tell everyone they can get back on. When this sort of thing happens several times in a month, or even in a day, you can be sure there is enormous peer pressure to find what is messing us up, and put a stop to it.

We have a menu of fixes, where we can get a list of COs / RMAs in-use.
Late nite, after everyone supposedly off the system, I run these reports to see if there have been any crashes of that kind not yet reported to IT.

We have a program modification to blanket clear all in-use flags.

After this exercise, people are able to access the orders again.

Usually, most everyone in the company knows how come we got into this mess.
If it is anything other than a hardware error, there is peer pressure on source of human error, not to have this happen again.

However, I take the attitude that if some task abnormally ended the updating of some order, that the data in that order may not be correct, so its contents need to be audited, unless we have a clear understanding of how the crash occurred, and what's going on in those circumstances. So a list of the orders that had to be corrected is delivered to the management of that application with suggestion that they all be audited for accuracy.

Depending on the type of application that a person is Xing out of, we might not have crash debris evidence that is simple to find. Over time, I have added to a collection of lists I run on a regular basis, to try to locate any such debris, so that if we have had a crash, its consequences hopefully fixed before we have a cascade of other related problems.

you wrote:

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: 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

<snip>