Re: Seeking adivce

[Mike Wills <koldark@xxxxxxxxx>]

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.