Re: Strange problem calling QSYGETPH

["Charles Wilt" <charles.wilt@xxxxxxxxx>]

Password not correct....

Which explains why it worked from the command line.  Since the command
interpreter allocates 32 chars for a literal, there were spaces in
bytes 11-16.  Thus: the check was ok.

When called from another CLP, who knows what could be found in the
area of memory after the 10 charactor password.

Charles

On Thu, Sep 25, 2008 at 1:35 PM, Mark S. Waterbury
<mark.s.waterbury@xxxxxxx> wrote:
> Exactly how does it fail? What error messages do you see in the job log?
>
>  > Charles Wilt wrote:
> > All,
> >
> > We've got a CL program (CF2220C) that calls QSYGETPH that we are
> > having trouble with.  In preperation for moving from v5r2 to v5r3, we
> > added two more parms to the call.  The parms are defined:
> >
> >   DCL  VAR(&PWDLEN) TYPE(*CHAR) LEN(4) VALUE(X'00000010')
> >   DCL  VAR(&PWDCCSID) TYPE(*CHAR) LEN(4) VALUE(X'FFFFFFFF')
> >
> > When we call it from a command line it works.
> >
> > When we call it from another CL program, it fails _UNLESS_ the two
> > above parms are defined as integer
> >   DCL  VAR(&PWDLEN) TYPE(*INT) LEN(4) VALUE(10)
> >   DCL  VAR(&PWDCCSID) TYPE(*INT) LEN(4) VALUE(-1)
> >
> >
> > Does this make sense to anybody?
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.