× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.