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



Are you talking about a data area or a data queue?  With a data queue you don't 
have to worry about unique entries.  They are placed on the queue in the order 
written even if they have identical information.  If you replace the file this 
would be my choice for a replacement.

You mentioned not reinventing the wheel in your first post.  Using a data queue 
means changing every program that currently writes to the work file.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Mike Wills
Sent: Monday, September 13, 2004 11:45 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Seeking adivce


Hmm.. .I never thought of that... maybe use their username and the
time to create the data area. I was thinking a file, but that is hard
to do dynamic. I will have to look more into reading and writing to a
data area, but I think that would work. Thanks for the suggestion.

I am still open if you feel there is a better way!


On Mon, 13 Sep 2004 12:12:42 -0400, wayne.james@xxxxxxxxxxxx
<wayne.james@xxxxxxxxxxxx> wrote:
> May I suggest creating a *DTAQ in QTEMP?  If you were to created the *DTAQ
> with a unique name, you would also be "guaranteed" no duplicate PO's. Were
> I in your shoes, I would fear the overrides required to access the member
> containing the PO's to be created.  It sounds as though one of them is not
> succeeding occasionally.
> 
> Hope this helps.
> 
> L. Wayne James

> 
> Mike Wills 
> >>> See below...
> 
> On Mon, 13 Sep 2004 08:39:19 -0700, Tony Carolla wrote:
> > Are you copying from the application's file into the one in QTEMP?
> 
> >>> Yes, basically, when they do a write to their file, I also do a
> write to mine.
> 
> > In my experience, I find it best to go against the actual data files,
> > and build your own report based on that.  Sometimes, since we rarely
> > have source code for vendor's products, it is unclear exactly how they
> > handle work files.  If you can get at the data directly, and do the
> > calcs in your program, you might have more luck with the problem.
> 
> >>> I know, but the problem here is, there is a number of ways this
> program could be run, I didn't want to have to "reinvent the wheel"
> just to print the exact same thing. This work file told me exacty what
> POs to print, I just wrote the logic to print them at this point then.
> Luckly, I do have access to the source, we just don't get support for
> modifying it... imagine that... :-)
> 
> > a file in QTEMP is a solution that works well, but sometimes it is
> > better to use an array (depending on the number of records/size of
> > each element) for the sake of speed.
> 
> >>> I thought about an array, but I don't know how many POs might be
> processed. It might be one, it might be hundreds. Maybe a data area
> would be better, or maybe there is something I don't know about that I
> could use. I am up to try anything, I just want to try an eliminate
> this problem we have now (and maybe learn something as well).


-- 
Mike Wills
iSeries Programmer/Lawson Administrator
koldark@xxxxxxxxx
http://www.koldark.net
Want Gmail? Email koldark+gmail@xxxxxxxxx to get on my waiting list.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.