RE: Record Locks -- SYSTEM21

There is probably not a way out of record locks with JBA software due to

System Manager, the architecture of the package, and the way JBA has bolted
on so many functions.  What would be appropriate is that the record lock
dependencies be documented, and an official acknowledgment that they
happen.  I don't think JBA is going to retrofit the product to use
commitment control, however, they are considering it (because of pressure
form customers) in the future.  I wouldn't hold my breath.

I also agree with the individual that said if all the users figure out a
way to DFU or automatically remove the record locks, it will not improve
the product, nor help other users who are unaware of the issues.  I would
say most of the record locks occur when a users ends their session
incorrectly, or a program that was modified dumps.  Neither case is a
natural one for the software, and you would have a hard time convincing JBA
that something is wrong with their software.  (Although there are many
things not right with it, in many users opinions.)   If Standard
non-modified software dumps, it is certainly JBA's responsibility to
expedite and ship a PTF.  What I don't appreciate is that in a regular days
work, things happen and record locks are left out there, and even if the
programs had been modified, there ought to be a sensitivity from JBA
support to help.
The programs were modified because the Standard product simply did not meet
the needs of the customer(s).  I think if all the customers shared their
requirements for modifications,  you might see a large common thread that
JBA may not be addressing because of the cost of development and change to
the base architecture of the software.

Randy Smith





I agree that this is a painstaking task.  If a program has dumped is it not
JBA's responsibility to find the route of the problem and fix it?  It seems
to me (my only experience is with PRMS, System 21 and MAPICS on a 36) that
the vendors on the AS/400 platform create these applications that are
functionally robust, but error prone.  It seems that this is acceptable on
this platform but would never be allowed on other platforms (NT, Unix).  Am
I alone in this feeling?
Back to your problem.  If a dump is produced then JBA should fix it so the
fix can be included in the next PTF or how ever they actually create fixes.
 If the fix is made locally, by the client or a regional JBA office, and
never reported and fixed in the UK the bug will continue to exist
throughout the development of System21.
-----Original Message-----
From:     Jim Sehi
Yes, we have thought of this.... But I don't have a clue how a staff of 4
people are going to address record locks for up to 400+ users... ouch!
Maybe we'll be ok...
At 07:12 PM 6/11/98 -0400, you wrote:
Jim, I see you have had a good response to this.  One point that I would
like to make (I'm sure that you have considered this but...) normally a
record lock remains because some program at some point dumped.  Make sure
that when a record lock exists a reasonable effort is make to distinguish
what caused the record lock in the first place.  If the original program
which caused the lock is fixed then eventually you will get a lot less
records left locked.

Rob Rogerson

-----Original Message-----
From:     Jim Sehi

Has anyone else had problems with record lock issues besides us?

I have found many files such as SLP99 that contain record lock
information,
but have also found "active" flags within order entry that indicate the
order is in use (ACTF40 in file OEP40), but don't provide any further
information in regards to who owns the lock.

What solutions have others standardized on for resolving record lock
issues when the system goes down, etc?





+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---