Re: Passing unwanted parameters

David,

I just hit this 'problem' recently...

Your test program IN's the data area (implicitly, because of the UDS) and
locks it. You then do an explicit IN (which you don't need to do). When you
OUT it, you unlock it.

When myPgm is called, because it's a UDS, it's implicitly locked, but
because you don't exit mypgm with *INLR on, the data area is never unlocked,
so it's still locked on return to your test program.

If you run debug and check for object locks on the data area after pretty
much evetry statement, you'll see this is the case.

If you need it unlocked on return to your test program, either set on *INLR
in MYPGM or don't define it as a UDS and do an explicit IN and OUT in MYPGM.

Rory

On Thu, Jan 29, 2009 at 9:09 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx>wrote:

Rory et Al,

Having a problem with this, hope you can help.

My test program :
D AParms UDS
D Parm1 LIKE ( REF_Parm )

C *DTAARA DEFINE MyDtaAra AParms
C IN AParms
C EVAL Parm1 = 'test'
C OUT AParms

C CALL 'Mypgm'

/FREE

DSPLY %SUBST ( GetMyPgmError ( ) : 1 : 52 );
RETURN;

/END-FREE



In mypgm:
D AParms UDS DTAARA ( NPA010 )
D Parm1 LIKE ( REF_Parm )

No operations on the data area

P GetMyPgmError...
P B EXPORT
D PI LIKE ( REF_ERRMSG )

/FREE

RETURN globalErrorMessage;

/END-FREE

P GetMyPgmError...
P E


When my test program goes back to get the error message, with DSPLY %SUBST
( GetMyPgmError ( ) : 1 : 52 ), why is the data area locked?

Thanks