Re: PGM assist?

[DennisLovelady@xxxxxxxxx (Dennis Lovelady)]

Hi, Mark:

Thanks for the nice words.

That would compile and might be OK _if_ you provided input specs for 
UXSRCHM, but in my example, that wasn't done.

The problem is that, in the event that (between the time we first
read the record, and the time the CHAIN completes) someone changed
the data.  Then, their changes would be lost 'cuz we didn't save
those values... only the values on the (no-lock) read.  Since the
possibility (however slight) exists that the record changed, I
personally prefer the "read into DS" option.

Your mileage may vary.  :^)

HTH

  (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.                  [[[|]]](  *
\__[[[|]]]__________________________________________________[[[|]]]_\/



Mark Lazarus <mlazarus@ttec.com> on 10/10/97 04:57:59 AM
To: MIDRANGE-L <MIDRANGE-L@midrange.com> @ INTERNET
cc:  
Subject: Re: PGM assist?

Dennis,

 I like the technique.  BTW, wouldn't it make more sense not to put RECDS
on the CHAIN line?
>      C           GETRRN    CHAINUXSRCHM   RECDS      60 
         ^^^^^
 Then it won't overlay the fields from the original file.  You could then
do the UPDAT w/ RECDS and the fields would update properly.  Am I missing
something?


>Another way, is to:
> o 'program describe' the UXSRCHM, with a really big record size, and
>   define some extra information for processing USSRCHM, as follows:
>      FUSSRCHM IP  E                    DISK         KINFDS FILEDS
>      FUXSRCHM UF  F    9999            DISK 
>      F                                              KRECNO GETRRN
>       (you won't need input specs for this file, and I'll discuss the
>        RECNO line shortly and the INFDS shortly)
> o Put an externally-described data structure into your program, such as:
>      IRECDS     E DSUSSRCHM
> o Define the file data structure that you promised RPG, like:
>      IFILEDS      DS                                      
>      I                                    B 397 4000$REC#    
> o Define GETRRN (or some field name, matching the RECNO line from above)
>   (numeric, 8,0)
> o When you find a record that you want to update, $REC# will contain the
>   Relative Record Number within the physical file.  We can use that to
>   retrieve the record for update, as follows:
>      C                     Z-ADD$REC#     GETRRN
>      C           GETRRN    CHAINUXSRCHM   RECDS      60    (or whatever
indic you want)
>   (This will retrieve the record for update, and put its data into your
>    data structure RECDS.  After populating/changing the fields you want
>    to effect, simply do the following:
>      C                     UPDATUXSRCHM   RECDS
>
>No extra files needed, no extra compile wrappers needed.  The only two
>ill effects of this approach are:
>  o If your filesize ever actually exceeds 9999 bytes, (God forbid!),
>    this approach will not work
>  o You will get a "Buffer size longer than record size" message in the
>    joblog when the file is opened (severity 10, no big deal).

 -mark

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