Re: Opinions on approach, please...

<all previous parts of the thread are snipped>

Pete,
I the reason that I mentioned "locks" is that I am familiar with applications
that INTENTIONALLY used "locks" (of one sort or another) to serialize specific
steps. They didn't use them to "protect" from data corruption. Rather they
would use a "control" record to be "locked" when one
user/part-of-the-application/whatever was doing something to insure that other
parts/users didn't "start" a new process.

Micro Focus and the '02 Standard have "wait" syntax (within READ processing -
and as a separate statement). I couldn't find this in my Fujitsu dox, so this
may not be a problem there. (They do have file status codes for accessing
locked records).

As I say, this is not a question of 'accidentally" having two processing
attempting to update the same record; rather it is the use of specific records
(or files) to serialize processing.

***

I also wanted to explain (a bit) about the "multiple positioning" point that I
tried to make earlier. I don't know if this is used with non-IBM mainframe
COBOLs - or even if it is still used (much) on IBM mainframes.

The techniques was where you had two (or more) File-Control entries - pointing
to the same physical (VSAM) file - one via its "primary" key and one via an
alternate key (or possibly both via separate alternate keys). Using START and
READ NEXT processing, you could then process "simultaneously" through the same
physical file in two different sequences. I could be mistaken, but I don't
think that SQL can (easily) do this via two "simultaneous" cursors for the same
database. However, if this isn't something that you have run into, then it may
well be a non-issue with the types of applications that you would want to
convert.

--
Bill Klein
wmklein <at> ix.netcom.com


.

Relevant Pages

  • Re: Opinions on approach, please...
    ... applications that INTENTIONALLY used "locks" to ... records to serialize processing. ... non-issue with the types of applications that you would want to convert. ... The data for the cursor is fetched into an internal result set at the time ...
    (comp.lang.cobol)
  • Re: How to set LOCKIDTBL?
    ... Hoff Hoffman wrote: ... Databases and a few applications can require great huge piles of locks. ... A MicroVAX 3100 running some applications will churn along with minimal locking activity, while a clustered MicroVAX 3100 running Oracle Rdb will require rather more locks; it's the application load and not the system model that tends to be key here. ...
    (comp.os.vms)
  • Re: How to set LOCKIDTBL?
    ... Databases and a few applications can require great huge piles of locks. ... A MicroVAX 3100 running some applications will churn along with minimal locking activity, while a clustered MicroVAX 3100 running Oracle Rdb will require rather more locks; it's the application load and not the system model that tends to be key here. ...
    (comp.os.vms)
  • Re: Lockfree or not to lockfree thats the question !
    ... but IMO the ideal implementation would not. ... 'technical' notions of fairness to threads may not make applications ... Lockfree algorithms tend to be less predictable than locks. ...
    (comp.programming.threads)