Erratic QTP

george.j.wen@us.abb.com george.j.wen@us.abb.com
Mon, 27 Jan 2003 09:06:12 -0600


--0__=aBYsdQgq09hP3mQBHGigFwBoDMVkVfeUbq3HNdMQiKyiY6KTMsIyX5nT
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Rick,
I tried the commit for the heck of and it didn't work but noticed
another oddity while doing so.
The routine's statistics say 13 records were updated (in this case) but
when I search for non-
zero values of the subfile  in quiz I only get 12 records.  The record
in question has a zero
value - very peculiar?
Thanks for your help.
George


|------------->
|(Embedded    |
|image moved  |
|to file:     |
|pic18365.pcx)|
|             |
|------------->
  >--------------------------------------------------------------------|
  |"Rick Hill" <rmhill@core.com>                                       |
  |01/24/2003 06:11 PM                                                 |
  >--------------------------------------------------------------------|



To:   George J. Wen/NB/USFAC/ABB@ABB_US01, powerh-l@lists.swau.edu
cc:
Subject:  RE: Erratic QTP

Security Level:?         Internal



Is the data needed in *QTEMP/T5731011 at all dependent on earlier
requests?  It could be that running this as two separate programs fixes
the problem because the data is getting committed by default at the end
of the RUN in the first one - hence the 2nd program with the code that
writes the rec can now see the data it needs.

If this could be it, try putting "COMMIT AT REQUEST" at the top of your
original version with the multiple requests.

good luck!

Rick Hill

>
>
> Well Chris the "item d-qty-issue subtotal glu reset at sort-field"
> statement didn't
> work either.  I split the routine out into its own program and that
> works so I have a solution albeit not
> a clean one.  Sure is peculiar.
> Thanks to all for the help.  This list is a great resource!
> George
>
>
> |------------->
> |(Embedded    |
> |image moved  |
> |to file:     |
> |pic07933.pcx)|
> |             |
> |------------->
>   >-------------------------------------------------------------------
-|
>   |"Chris Sharman"
<chris.sharman@ccagroup.co.uk>                      |
>   |01/24/2003 03:05
AM                                                 |
>   >-------------------------------------------------------------------
-|
>
>
>
> To:   George J. Wen/NB/USFAC/ABB@ABB_US01, powerh-l@lists.swau.edu
> cc:
> Subject:  RE: Erratic QTP
>
> Security Level:?         Internal
>
>
>
>
> > A QTP program I have has multiple requests.  I have one request from
> > within the program that
> > produces different results when run separately by itself.  A user
> > brought to my attention that a
> > particular record was not updated (via a subsequent report).  So I
ran
> > the program in session
> > and sure enought the record in question was not being updated but
when
> I
> > split the request out
> > to isolate the code so only the request in question here would run
it
> > ran correctly and updated
> > the record the user called about .  Any ideas?
> > I'm on 6.07 as/400 and that may or may not matter.  I can try
> splitting
> > out the programs so this
> > request is on it's own but I wonder if there's another answer?
> Here's
> > the code:
> >
> > Request GetQtyIssued
> >
> >
> >
> > Access *QTEMP/T5731011 &
> >    link QAOMCU, "II", QALITM viaindex F0911L1 &
> >       to GLMCU, GLDCT, GLEXR of I0911
> >
> >
> > define SORT-FIELD char*50 = QAOMCU + GLDCT + QALITM
> > Sort on SORT-FIELD
> >
> > temp D-QTY-ISSUE float*8
> > item D-QTY-ISSUE = D-QTY-ISSUE + GLU
> >
> > Output T5731011 Update at SORT-FIELD on Errors Report
> >    item ISSUE-NBR  final GLDOC
> >    item QTY-ISSUED final D-QTY-ISSUE
> >    item D-QTY-ISSUE reset at SORT-FIELD
> >    item PO-TYPE    final GLDCT
> > Go
>
> Is the output the same file as the primary input, or not ?
> I guess not, since there's no "*".
>
> Your d-qty-issue statements are a little odd - the 'normal' syntax
would
> be:
>
> item d-qty-issue subtotal glu reset at sort-field
> although I've no reason to think the construct you have is faulty.
> You've got "on errors report". Does it report errors ?
>
> To diagnose, trying keeping the subfile, and checking it, to see
whether
> the
> record in question is included, or omitted by some problem with an
> earlier
> request.
>
> Chris
>
>
>
> ----------------------------------------------------------------------
-
>
> Any views expressed in this message are those of the sender and not
> necessarily those of CCA Group.  The unauthorized use, disclosure,
> copying or alteration of this message is forbidden.  The contents of
> this message may be confidential and/or privileged, copyright CCA
Group
> and are intended solely for the use of the individual or entity to
whom
> they are addressed.  Whilst this message has been scanned, CCA Group
> cannot guarantee that it is virus free or compatible with your systems
> and accepts no responsibility for any loss or damage arising from its
> use. The recipient is advised to run their own anti-virus software. If
> you receive this message in error please contact
> postmaster@ccagroup.co.uk immediately, destroy any copies and delete
it
> from your computer systems.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to
> powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
> powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a
subscriber.
>
>
>
>

--
CoreComm Webmail.
http://home.core.com

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to
powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.




--0__=aBYsdQgq09hP3mQBHGigFwBoDMVkVfeUbq3HNdMQiKyiY6KTMsIyX5nT
Content-type: application/octet-stream; 
	name="pic18365.pcx"
Content-Disposition: attachment; filename="pic18365.pcx"
Content-transfer-encoding: base64

CgUBCAAAAABQAB4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABUQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADpD9UPyg/FD8MPD8sPxQkPxQnMD8kJD8UJyA/KCQ/FCcUPwg8Pyw/FCQ/F
CcwPyQkPxwnGD8oJD8cJxA/CD8oPxgkPxgnLD8kJD8gJxQ/KCQ/HCQnDD8IPyg/GCQ/GCcsPyQkP
yQnED8oJD8cJwgnDDw/KD8YJD8YJyw/JCQ/JCcQPygkPxwnCCcMPD8kPxwkPxwnKD8kJD8kJxA/K
CQ/HCcIJww8PyQ/HCQ/HCcoPyQkPygnDD8oJD8cJwwnCDw/JD8cJD8cJyg/JCQ/KCcMPygkPxwnD
CcIPD8gPyAkPyAnJD8kJD8oJww/KCQ/HCcMJwg8PyA/ICQ/ICckPyQkPyQnED8oJD8cJwgnDDw/I
D8gJD8gJyQ/JCQ/JCcQPygkPxwnCCcMPD8cPyQkPyQnID8kJD8gJxQ/KCQ/HCQnDD8IPxw/JCQ/J
CcgPyQkPxwnGD8oJD8cJxA/CD8YPygkPygnHD8kJD8kJxA/KCQ/HCcIJww8P6Q/VD8oPxQ/DDw/F
D8sJD8sJxg/JCQ/KCcMPygkPxwnDCcIPD8UPywkPywnGD8kJD8sJwg/KCQ/HCcQJwg/ED8wJD8wJ
xQ/JCQ/MCQ/KCQ/HCcQJCQ/ED8wJD8wJxQ/JCQ/MCQ/KCQ/HCcQJCQ/ED8wJD8wJxQ/JCQ/MCQ/K
CQ/HCcQJCQ/DD80JD80JxA/JCQ/MCQ/KCQ/HCcQJCQ/DD80JD80JxA/JCQ/MCQ/KCQ/HCcQJCQ/C
D84JD84Jww/JCQ/MCQ/KCQ/HCcQJCQ/CD8kJyw/JCcMPyQkPywnCD8oJD8cJxAnCD8IPyQnLD8kJ
ww/JCQ/LCcIPygkPxwnECcIPD8kJzQ/JCcIPyQkPygnDD8oJD8cJwwnCDw8PyQnND8kJwg/JCQ/J
CcQPygkPxwnCCcMPDw/JCc0PyQnCD8kJD8cJxg/KCQ/HCcQPwg/JCc8PyQkPyQkPxAnJD8oJD8QJ
xQ/DDw/pD9UPyg/FD8MPDwwAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//
AP8A//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

--0__=aBYsdQgq09hP3mQBHGigFwBoDMVkVfeUbq3HNdMQiKyiY6KTMsIyX5nT--