Re: PGM assist?

[DennisLovelady@xxxxxxxxx (Dennis Lovelady)]

Hi, John:

I also prefer the SQL option (call me biased), but long-term locks held
by other users are going to be in the way.  Also, in a high-usage or 
commitment-control environment, the UPDATE statement may have a lot of 
difficulty traversing the file.

(This is not meant to take away from Walden's very nice suggestion; just
to clarify the reason for my approach.)

I don't know what I misstated in my previous message to make this so
confusing, but the only potential conflicts that would be caused by the 
approach presented by the approach presented there, would be when the 
CHAIN is executed.  (If using commitment control, COMIT would immediately
release that lock; otherwise, it will automatically be released.)

I don't have the original message anymore, but the way I _should_have_
presented it is basically as follows:
  LOOP
    READ (INPUT ONLY) the file
    TEST to determine if row needs to be updated.  IF yes, then
        CHAIN (I/O to the same record
        SET UP the fields for update
        Update the record
        (COMIT) - I know I didn't include this before
    End-if
  UNTIL end of file

I don't see a lot of conflict possibility here, unless we are going to
be changing a large percent of the rows.  In any case, there are less
here than the SQL UPDATE will confront.

Read again, below, where the major complaint is that the process is "a
really quick way to read the file."  If the *real* problem is that it is
too fast, maybe the UPDATE statement would better suit the need.

(running, ducking, hiding)


  (The following signature looks right only with a fixed-pitch font)
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
*      _                                                      _       *
*     / )                                                    ( \      *
*  _ / /                  Dennis Lovelady                     \ \ _   *
* ( ( ()    _      Unix / AIX System Administrator       _    () ) )  *
*( \ \ \)  / )             Oracle D.B.A.                ( \  (/ / / ) *
( \ \ \ \_/ /                                            \ \_/ / / / )*
*\         /            Dennis@Lovelady.com               \         / *
* \       /          Dennis.Lovelady@KEMET.com             \       /  *
/~~\     /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\     /~/\* 
   [[[|]]]               Simpsonville, SC.                  [[[|]]](  *
\__[[[|]]]__________________________________________________[[[|]]]_\/





John Carr <74711.77@compuserve.com> on 10/12/97 11:37:36 PM
To: INTERNET:MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com> @ INTERNET
cc:  
Subject: Re: PGM assist?

Message text written by INTERNET:MIDRANGE-L@midrange.com
>37 AM 10/10/97 -0400, Booth Martin wrote:

>on 10/10/97at 08, the Great and Grand  Wazir DennisLovelady@kemet.com

>(Dennis Lovelady) said:

>

>Since the

>possibility (however slight) exists that the record changed, I
personally

>prefer the "read into DS" option.

>

>Isn't the possibility far greater than slight?  Tim said this is a
heavily

>used file.  The idea of reading a record, testing it, and if chosen,

>rereading the record and updating it is a really quick way to read a
file. 

>The chances are very good that it will arrive at almost every single

>record that is already out on other workstations and read it.  This
could

>lead to a lot of conflicts I think.


This, IMO, really pushes me toward Walden's solution of using SQL. That's
a really nice use of the update statement. Tim, if you don't have the SQL
licensed product installed, you can still do this by creating a query
management (*QMQRY) and then execute STRQMQRY from a CL or whatever.
Here's how to do it so that you don't even have to hard-code the file and
field names:

<SNIP>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---