Re: Passing unwanted parameters

[Rory Hewitt <roryhewitt@xxxxxxxxx>]

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