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



So, three possibilities come immediately to mind, Buzz:

1. You're only reading one vendor
2. You're only calling the procedure for the last vendor
3. You're opening, writing, and closing the file for each vendor (wiping out the previous)

It looks like you've checked this, but just put a breakpoint inside the subprocedure and see if it's called over and over.  If it is, then the next thing to check is whether it's creating the IFS file over and over.  Break inside the procedure, step out, see if there's an IFS file with the current vendor's data.  Cycle again and see if there's a file with a different vendor's information.

If there's no file between steps, it's a different issue.



On 12/18/2018 9:10 AM, Buzz Fenner wrote:
All,

Pardon me if this sort of drags on; I figure when I get (or figure out) the answer to this it'll be a great teaching moment.

I have an RPGIV program that reads invoices and writes checks; a logic cycle program breaking on vendor number. Simple enough. It needed to be modified to produce a text file that our bank will use to prevent check fraud (we got hit recently).

I've used Scott Klement's wrappers (i.e. "RPG And the IFS") to read/write to the IFS and never had a problem - they're wonderful. I convert the source to ILE-RPG, get it into freeform, and remove the logic cycle processing. The code that executed on the vendor break I put into a local subprocedure.

However, after executing the program, the text file on the IFS had only one record in it, which corresponded to the last vendor in the input file. I put it into debug to prove the write statement in the procedure executed for each vendor break. Spent days trying to figure it out to no avail. In an act of desperation, I tested putting the code into a subroutine and moved the local declarations back into the main procedure. It worked like a charm; all records were written. It was as if when the code was in a subprocedure, all the writes were stomping on the data that was already there with the next write to the text file overwriting what was written previously.

So, what's the explanation for the difference?

--
Buzz Fenner, Analyst/Systems Administrator
+1 (870) 930.3374 bfenner@xxxxxxxxxxxxxxxx<mailto:bfenner@xxxxxxxxxxxxxxxx>

City Water and Light of Jonesboro
Office: +1 (870) 935.5581 / Fax: +1 (870) 930.3301
Physical: 400 East Monroe Ave., Jonesboro, AR 72401
Mailing: PO Box 1289, Jonesboro, AR 72403-1289

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. City Water and Light of Jonesboro is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.



________________________________

This electronic mail transmission may contain confidential or privileged information. If you believe that you have received this message in error, please notify the sender by reply transmission and delete the message without copying or disclosing it.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.