gary@fairlight.oz (Gary Evesson) (03/07/88)
For all those UNIFY 3.2 people out there..... Has anyone ever had a problem with lockrec never returning if a record is locked by another process? If so, how did you get around it? I would love to know because it is driving me crazy killing off hung processes. gary@fairlight.oz munnari!fairlight.oz!gary@uunet.UU.NET Gary Evesson.
crash@tsc3b21.UUCP (Frank "crash" Edwards) (03/14/88)
From article <316@fairlight.oz>, by gary@fairlight.oz (Gary Evesson): > For all those UNIFY 3.2 people out there..... > > Has anyone ever had a problem with lockrec never returning if a record is > locked by another process? If so, how did you get around it? I would love > to know because it is driving me crazy killing off hung processes. > > gary@fairlight.oz > munnari!fairlight.oz!gary@uunet.UU.NET > Gary Evesson. Sorry Gary, we haven't had that problem. Actually, I'm not that sorry ;-). What system are you running Unify on? We ran for about a year and a half on an old Momentum box (68000) with Ver7 UNIX with no problems. And after that, about 2 years on an AT&T 3B2/310. Again, with no problems. The Unify documentation says that the implmentation of the locking mechanism is system dependent based on what services are intrinsic to the OS. Frank (crash) Edwards ...!codas!usfvax2!{pdn,jc3b21}!tsc3b21!crash TSC in Palm Harbor, FL Phone: (813) 785-0583 (voice) The Sweat Shop These opinions belong to no one. ----- "This message brought to you by ... Bang-Bang! Makers of the sweetest little automatic in the world!" Radio commercial on Star Trek: "A Piece of the Action"
wayne@charlie.OZ (Ian Jennings) (03/18/88)
In article <316@fairlight.oz> gary@fairlight.oz (Gary Evesson) writes: >For all those UNIFY 3.2 people out there..... > >Has anyone ever had a problem with lockrec never returning if a record is >locked by another process? If so, how did you get around it? I would love >to know because it is driving me crazy killing off hung processes. > We have experienced this here as well. We are running ACCELL/Unify3.2 on our Gould PN6040. Within the Accell scripts we carry out locking. We also have a UNIFY 'C' program that runs simultaneously performing inquiries on related records and updates on non-related records. i.e. (that is related to those of the Accell scripts). We have found here that everything runs O.K. until we get about 8-10 users running our Accell application whereupon the same problem arises. Our easier solution is to kill this background Unify 'C' program which then lets the Accell users keep going. We have never had any problems with Accell, only when Unify 'C' is used as well. Will be interested to hear anything about this!!!! Wayne Jennings Computing Services, Deakin University, Victoria, 3217. Australia. UUCP: ..!uunet!munnari!charlie.oz!wayne
rickers@drexel.UUCP (Rick Wargo) (03/22/88)
In article <6656@charlie.OZ>, wayne@charlie.OZ (Ian Jennings) writes: >We have experienced this here as well. We are running ACCELL/Unify3.2 on >our Gould PN6040. Within the Accell scripts we carry out locking. We also >have a UNIFY 'C' program that runs simultaneously performing inquiries on >related records and updates on non-related records. i.e. (that is related >to those of the Accell scripts). We have found here that everything runs >O.K. until we get about 8-10 users running our Accell application >whereupon the same problem arises. I have had the same problem. We had been working on a large ACCELL project for a while (ACCELL/Unify 3.2 on a Compact 386 running uPort 286/AT-U2.2) with a few background daemons running that had to access the database. We found that we had two large problems. One was t whenever the ACCELL code l was accessing the record I wanted (the HLI daemon) ACCELL would let me use it. As a matter a fact, it would let me use it ever after that until the user went back to the initial screen and committed the transaction. What a bad workaround. We waited for the new realease of ACCELL/Unify and our new uPort operating system, but we haven't given it a try. The other problem was that these daemons couldn't access the database while they were running in the background. When they ran in the foreground they worked fine. This was a while ago. I was on the phone with Unify Tech Support and had managed to figure out why this happened, but for the life of me, I just can't remember the explanation on we had decided. Sorry. Maybe it will hit me sooner or later, probably later when we restart the project. Rickers ..!drexel!rickers
gary@fairlight.oz (Gary Evesson) (03/28/88)
A hint(?) which I forgot to include in my original posting was that sometimes a "kill -CONT <pid> will get them going again. We run BSD4.2 on a 68k10 box. gary@fairlight.oz Gary Evesson.