If P0SEQ# is one value prior to the call and a different value immediately (and I stress the word immediately) following the call, then you have a bug in the parameter list. Carefully examine the definitions of your CALL result field definitions (size and type) and compare them to the *ENTRY PLIST PARM list of UTWIPT. There is most likely a discrepancy which is causing UTWIPT to think there is more storage associated with one of the fields being passed then the calling program has allocated. UTWIPT is most likely setting one of this mis-defined field to a new value and this new value is overflowing into the allocation of P0SEQ# in the caller. Note that it could be ANY of the fields associated with the PLIST. The actual bug may be something more subtle than what I describe above, but the vast majority of the time it's an inconsistent parameter field defintion between the caller and called program. Bruce Vining <a href="http://www.brucevining.com/">http://www.brucevining.com/</a> Providing integrated solutions for the System i user community In such a case, using Protyped call may be the ultimate safe solution to secure Call consistency at compile time. And this case, also doucle-check that P0Seq# does not overlay any parameter of the current call. TSchmitz

If P0SEQ# is one value prior to the call and a different value immediately (and I stress the word immediately) following the call, then you have a bug in the parameter list. Carefully examine the definitions of your CALL result field definitions (size and type) and compare them to the *ENTRY PLIST PARM list of UTWIPT. There is most likely a discrepancy which is causing UTWIPT to think there is more storage associated with one of the fields being passed then the calling program has allocated. UTWIPT is most likely setting one of this mis-defined field to a new value and this new value is overflowing into the allocation of P0SEQ# in the caller. Note that it could be ANY of the fields associated with the PLIST. The actual bug may be something more subtle than what I describe above, but the vast majority of the time it's an inconsistent parameter field defintion between the caller and called program. Bruce Vining <a href="http://www.brucevining.com/">http://www.brucevining.com/</a> Providing integrated solutions for the System i user community In such a case, using Protyped call may be the ultimate safe solution to secure Call consistency at compile time. And this case, also doucle-check that P0Seq# does not overlay any parameter of the current call. TSchmitz