Re: SQL SP - Using Decimal (8,6) for Parameters

[Michael Ryan <michaelrtr@xxxxxxxxx>]

That's the entry PI for WSV350R. There's also an associated prototype in
the same member.


On Fri, Jul 12, 2013 at 11:59 AM, <rob@xxxxxxxxx> wrote:

> Is the following in NEWSYS/GETTAX010R, NEWSYS/TAX010R or WSV350R?
>
>      D Wsv350R         PI
>      D  pInPostalCode                 6A
>      D  pInCityName                  25A
>      D  pOtGST                        8  6
>      D  pOtPST                        8  6
>      D  pOtHST                        8  6
>      D  pOtStTax                      8  6
>      D  pOtCnTax                      8  6
>      D  pOtCtyTax                     8  6
>      D  pOtTotTax                     8  6
>      D  pOtNFErr                      2A
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Michael Ryan <michaelrtr@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
> Date:   07/12/2013 10:52 AM
> Subject:        Re: SQL SP - Using Decimal (8,6) for Parameters
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> Thanks Jon...I wonder if DECIMAL in SQL is different than packed (parm
> list
> - right?) in RPG...
>
> Here's the stored procedure Generate SQL:
>
> CREATE PROCEDURE NEWSYS/GETTAX010R (
> IN INZIP CHAR(6) ,
> OUT OTCITY CHAR(25) ,
> OUT OTGST DECIMAL(8, 6) ,
> OUT OTPST DECIMAL(8, 6) ,
> OUT OTHST DECIMAL(8, 6) ,
> OUT OTSTTAX DECIMAL(8, 6) ,
> OUT OTCNTAX DECIMAL(8, 6) ,
> OUT OTCTYTAX DECIMAL(8, 6) ,
> OUT OTTOTTAX DECIMAL(8, 6) ,
> OUT OTNFERR CHAR(2) )
> LANGUAGE RPGLE
> SPECIFIC NEWSYS/GETTAX010R
> NOT DETERMINISTIC
> READS SQL DATA
> CALLED ON NULL INPUT
> EXTERNAL NAME 'NEWSYS/TAX010R'
> PARAMETER STYLE GENERAL ;
>
> And the parms in the RPG:
>
>      D Wsv350R         PI
>      D  pInPostalCode                 6A
>      D  pInCityName                  25A
>      D  pOtGST                        8  6
>      D  pOtPST                        8  6
>      D  pOtHST                        8  6
>      D  pOtStTax                      8  6
>      D  pOtCnTax                      8  6
>      D  pOtCtyTax                     8  6
>      D  pOtTotTax                     8  6
>      D  pOtNFErr                      2A
>
> and the embedded SQL Call (WSV350R calls the SQL):
>
>      Exec Sql
>        Call NEWSYS.GETTAX010R(:pInPostalCode,
>                               :pInCityName,
>                               :pOtGST,
>                               :pOtPST,
>                               :pOtHST,
>                               :pOtStTax,
>                               :pOtCnTax,
>                               :pOtCtyTax,
>                               :pOtTotTax,
>                               :pOtNFErr);
>
>
> On Fri, Jul 12, 2013 at 10:44 AM, Jon Paris
> <jon.paris@xxxxxxxxxxxxxx>wrote:
>
> > Michael - saying "decimal parameters" is only part of the picture. Can
> you
> > show us the definition and the call?  It sounds like a signature error
> so
> > I'm guessing that something you think is packed is actually zoned or
> > vice-versa.
> >
> >
> > On 2013-07-12, at 9:40 AM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:
> >
> > > I'm having trouble calling a stored procedure (i to i) that's using
> > decimal
> > > parameters. I'm getting an SQL0204 - Not Found - when it's clearly
> > there. I
> > > can call another SP that's defined the same way (calling a different
> > > program with all character parms), and that works fine. I know that if
> an
> > > SP won't be found if it isn't called with the right parms, and I'm
> > thinking
> > > I'm running into that for some reason. Anyone have any ideas why (or
> if)
> > > specifying decimal parms would matter? Thanks!
> > > --
> > > 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.
> >
> > Jon Paris
> >
> > www.partner400.com
> > www.SystemiDeveloper.com
> >
> >
> >
> >
> > --
> > 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.
> --
> 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.
>
>
> --
> 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.