× 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.



Jim,

Thanks that did it (factor 1 entry and indicator in positions 71 and 72). 
The other ones worked the other way because of the chain, I guess.

Thanks to everyone else for the responses.

Thanks,
  Ted

>>> Jim Langston <jimlangston@conexfreight.com> 01/29/01 01:26pm
>>>
Ted,

<Quote>
If factor 1 has an entry, positions 71 and 72 can contain an indicator that
is set on if the record to be deleted is not found in the file. If factor 1
does not have an
entry, leave these positions blank. This information can also be obtained
from the %FOUND built-in function, which returns '0' if no record is
found, and '1' if a
record is found. 
</Quote>

Note, "If factor 1 has an entry... If factor 1 does not have 
an entry, leave these positions blank..."

Basically, if you give the DELETE instruction the KEY to delete 
(Factor 1) it will search for it and delete it, setting on the
indicator in positions 71 and 72, and setting the %Found condition.

If you do NOT give the DELETE instruction, it is not going to 
set the indicators right, and will probably set them to '0' for all
cases.

Regards,

Jim Langston

Ted Barry wrote:
> 
> Jim, I looked it up online
>
(http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AGZ03/4.4.24) and it 
treats it as '1' if a record is found, but somehow the status of my
> main read (SB220AP) is getting lost in the shuffle.
> 
> >>> Jim Langston <jimlangston@conexfreight.com> 01/26/01 03:46pm
> >>>
> Your code is looking at the %found condition returned by the
> DELETE op code, not the CHAIN or READE op codes.  DELETE also
> changes the %Found condition (no idea what it changes it to,
> *ON if another record exists with same key?  *OFF if it successfully
> deleted the record?  The DELETE help doesn't specify how it changes
> it).
> 
> If you are trying to condition on the CHAIN and READE statements, then
> move your if statements up before the DELETE op codes.  If you are
> trying
> to condition on the DELETE op code, I don't know what it changes the
> %FOUND
> to.
> 
> Regards,
> 
> Jim Langston
> 
> 4.1.1.15 %FOUND (Return Found Condition)
> 
>      %FOUND{(file_name)}
> 
> %FOUND returns '1' if the most recent relevant file operation found a
> record, a string operation found a match, or a search operation found
an
> element. Otherwise,
> this function returns '0'.
> 
> The operations that set %FOUND are:
> 
>      File operations:
> 
>           "CHAIN (Random Retrieval from a File)" in topic 4.4.15
> 
>           "DELETE (Delete Record)" in topic 4.4.24
> 
>           "SETGT (Set Greater Than)" in topic 4.4.85
> 
>           "SETLL (Set Lower Limit)" in topic 4.4.86
> 
> Ted Barry wrote:
> >
> > I'm not getting a hit (%found) on the main read (SB220AP), but all
other
> > related records are reporting (exsr wrtmsg) fine.  All records are
being
> > deleted, any clues?
> >
> > 0101.00 c     LocationId    chain     SB510AF                            40
> > 0102.00 c                   dow       not *in40
> > 0103.00 c                   delete    SB510AP                              
>99
> > 0104.00 c                   if        %found
> > 0105.00 c                   eval      FileName =    'SB510AP'
> > 0106.00 c                   exsr      wrtmsg
> > 0107.00 c                   endif
> > 0108.00 c     LocationId    reade     SB510AF                               
> 40
> > 0109.00 c                   enddo
> > 0110.00
> > 0111.00 c                   delete    SB220AP                              
>99
> > 0112.00 c                   if        %found
> > 0113.00 c                   eval      FileName =    'SB220AP'
> > 0114.00 c                   exsr      wrtmsg
> > 0115.00 c                   endif
> > 0116.00 c                   endif
> > 0117.00
> > 0118.00 c                   read      SB220AF                               
> LR
> > 0119.00 c                   enddo
> >
> > Thanks,
> >   Ted
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to
> RPG400-L@midrange.com.
> > | To subscribe to this list send email to
RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to
RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to
RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.