Re: Passing CL variables to rpgle

I wonder if this would help: Instead of making the value in &IFSDIR an
initialized value, use CHGVAR in the code. I dunno if it would make a
difference or not.

On 11/24/06, Jerry Draper <midrangel@xxxxxxxxxxxxx> wrote:

I'm ok about going the *CMD route.  I just want to understand why the
Call from CL doesn't work.

Jerry

SFTP2UPS.CLP

  /*  Declare variables                                                */

               DCL        VAR(&IFSDIR) TYPE(*CHAR) LEN(40) +
                            VALUE('/xfer/Tst/Out/UPSscs/PickTicket/')
               DCL        VAR(&IFSFIL) TYPE(*CHAR) LEN(40)

/*  Build output file specification variables                        */

              CHGVAR     VAR(&IFSFIL) VALUE('TSTBR' *TCAT +
                           (%SST(&DATETIME 1 14)) *TCAT '.I1INPT00')

/*  call pgm to create customer sFTP script                          */

              CALL       PGM(SFTP2UPS) PARM(&IFSDIR &IFSFIL)


SFTP2UPS.RPGLE

  D  Pgmprm1        S             40A
  D  Pgmprm2        S             40A
   *
   ********************************************************************
   *          MAINLINE PROCESSING
   *

   ********************************************************************
  C     *Entry        Plist

  C                   PARM                    Pgmprm1

  C                   PARM                    Pgmprm2









Michael Ryan wrote:
> Agreed...that should work. Show the DCL statements in the CL, the CALL
to
> the RPG, and the *ENTRY PLIST (or PR) in the RPG.
>
> On 11/24/06, Jerry Draper <midrangel@xxxxxxxxxxxxx> wrote:
>> Vernon Hamberg wrote:
>>> You have to pass the entire 40 characters all the time - that is why
>>> the suggestion to use a CMD front end works so well - it takes care of
>> this.
>>> You do not say how you are calling it
>> example is shown below;
>>
>>    if directly from a cmd line with padded parms it works
>>
>>    if a call from my cl with variables it fails.
>>
>> if a straight call then how do I pad the variables with chgvar?
>>
>> Jerry
>>
>>
>> - is it in a sbmjob or what -
>>> it sounds as if you might have a literal value instead of a variable
>>> in the parameters. When literals are used in a call, there is padding
>>> up to the first 32 characters - everything after that is whatever
>>> happened to be in memory at the time. So use variables in direct
>>> calls, or pad out the literal just as you did on the command line.
>>>
>>> It can be instructive to put your RPG into debug and see what is
>>> coming in from various contexts.
>>>
>>> HTH
>>> Vern
>>>
>>> At 02:07 PM 11/24/2006, you wrote:
>>>
>>>> I have a CL pgm calling an RPGLE pgm that expects two variables.
>>>>
>>>> CALL       PGM(SFTP2UPS) PARM(&IFSDIR &IFSFIL)
>>>>
>>>> The two variables created in the CL are defined as *char and len=40
>>>> which is the same as in the RPGLE pgm.
>>>>
>>>> I know this works as the CL dump shows the variables at len 40 padded
>>>> with blanks on the right.
>>>>
>>>> &IFSDIR                  *CHAR           40
>>>> '/xfer/Tst/Out/UPSscs/Pick'
>>>> 61A786859961E3A2A361D6A4A361E4D7E2A283A261D78983
>>>> +26           'Ticket/        '
>>>> E389839285A3614040404040404040
>>>>
>>>> &IFSFIL                  *CHAR           40
>>>> 'TSTBR20061124114711.I1INP'
>>>> E3E2E3C2D9F2F0F0F6F1F1F2F4F1F1F4F7F1F14BC9F1C9D5
>>>> +26           'T00            '
>>>> E3F0F0404040404040404040404040
>>>>
>>>> When I run the pgm from the command line with variables padded with
>>>> blanks the pgm works fine.
>>>>
>>>> CALL PGM(SFTP2UPS) PARM('TEST1                                   '
>>>> 'TEST1                                   '
>>>>
>>>> When I run the pgm from my CL it fails.
>>>>
>>>> Parameters passed on CALL do not match those required.
>>>> Error found on CALL command.
>>>> CPF0001 received by SFTP2UPS at 5500. (C D I R)
>>>> D
>>>> Function check. CPF0001 unmonitored by SFTP2UPS at statement 5500,
>>>> instruction X'003B'.
>>>>
>>>> Jerry Draper
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jerome Draper, Trilobyte Software Systems, since 1976
>>>> iSeries, Network, and Connectivity Specialists -- iSeries,
LAN/WAN/VPN
>>>> Representing WinTronix, Synapse, Netopia, HiT, and others .....
>>>> (415) 457-3431; www.trilosoft.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.
>>
>> --
>> Jerome Draper, Trilobyte Software Systems, since 1976
>> iSeries, Network, and Connectivity Specialists -- iSeries, LAN/WAN/VPN
>> Representing WinTronix, Synapse, Netopia, HiT, and others .....
>> (415) 457-3431; www.trilosoft.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.
>>
>>


--
Jerome Draper, Trilobyte Software Systems, since 1976
iSeries, Network, and Connectivity Specialists -- iSeries, LAN/WAN/VPN
Representing WinTronix, Synapse, Netopia, HiT, and others .....
(415) 457-3431; www.trilosoft.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.