Problem Running SQLRPGLE program with one parameter in Batch: Works Fine Interactively

55 pts.
Tags:
SQLRPGLE
Hi, i have problems with calling an SQLRPGLE program with only one parameter. an alphanumeric field length 40. the SQLRPGLE is running fine interactively but in batch mode, the parameter is right filled with packed caracters and it causes problems in my procedure. i’ve verified calling program, called program, the length is the same. i’ve tested in DEBUG mode ti see if there is a message in the JOBLOG but nothing… i add a SNDMSG to QSYSOPR with the value of the parameter in the calling CLP (value OK) and i add a SNDMSG to QSYSOPR with the value of the parameter just after the *entry instructions…the value of the parameter has changed with packed caracters on the right (7 caracters exactly) my question is the same as Dave : why does it work interactively and not in batch? thanks in advance for your helps or comments regards Laurent

Software/Hardware used:
SQLRPGLE
ASKED: November 25, 2009  7:59 AM
UPDATED: November 29, 2009  12:04 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.

Are you calling the SQLRPGLE program when you do it interactively and calling a CLP program when you are running in batch?

Discuss This Question: 12  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Laurentjudic
    Hi, My CLP does a SBMJOB with the SQLRPGLE program - When I do it interactively with a single CALL, it runs fine, then I replace the CALL in the CLP with a SBMJOB and it does not run correctly.
    55 pointsBadges:
    report
  • CharlieBrowne
    would you either post the CL source here or send it to charlieb@themembersgroup.com
    39,815 pointsBadges:
    report
  • Laurentjudic
    PGM DCL &ORDRE *CHAR 6 DCL &MAIL *CHAR 10 CALL VISART02A (&ORDRE &MAIL) IF (&ORDRE *EQ 'VALIDE') THEN(DO) SBMJOB CMD(CALL PGM(VISART02B) PARM(&MAIL)) ENDDO ENDPGM
    55 pointsBadges:
    report
  • TomLiotta
    ...calling an SQLRPGLE program with only one parameter. an alphanumeric field length 40. In the example CL that you posted, where's the *CHAR 40 parm? As for your problem, it is most likely because you're using SBMJOB incorrectly. You're using the CMD() parm for a CALL command when you should be using the RQSDTA() parm. The CMD() parm is intended for prompting support of commands that have properly typed parms. The CALL command has no typing of parms. Parms are interpreted by rules of default for CALL. The CL manuals have explicit explanations of what those defaults are and what the potential risks are. As for why it works interactively but not batch, it's sheer luck. Given the right circumstances, it'll fail the same way interactively. Note that you aren't actusally running "the same way" interactively. When you CALL the program interactively, you aren't allowing SBMJOB the process the CALL command via CMD(). Tom Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    DCL &MAIL *CHAR 40 CALL VISART02A (&ORDRE &MAIL) SBMJOB CMD(CALL PGM(VISART02B) PARM(&MAIL)) VIsART02A, VISART02B and this CL should descibe MAIL the same, as 40A or 10A. Phil
    48,565 pointsBadges:
    report
  • Laurentjudic
    Hi, Thank you very much Tom. here is my new CL program, and now it runs correctly in batch PGM DCL &ORDRE *CHAR 6 DCL &MAIL *CHAR 40 DCL &TEXTE *CHAR 80 CALL TEST03A (&ORDRE &MAIL) IF (&ORDRE *EQ 'VALIDE') THEN(DO) CHGVAR &TEXTE ('CALL TEST03B' *BCAT 'PARM(''' *CAT &MAIL *CAT ''')') SBMJOB RQSDTA(&TEXTE) ARRETMSG 'Analyse envoyée en file d''attente. Merci de patienter...' ENDDO ENDPGM For Phil : the length is 10 because i tryied to change the length. The length in the caller and the called program was exactly the same I'm surprised because it is the first time i have this king of problem calling a program in batch mode. do you think it is because the program is SQLRPGLE ? Laurent
    55 pointsBadges:
    report
  • philpl1jb
    OS/400 stores character fields as 32 long unless they are more than 32 long, so you can get by with inconsistiancies with shorter definition. Remember, programs don't actually pass the values they pass the addresses where the values start. Your CL declared &Mail as 10 so the CL populated/used 10 characters..but got a blank space to work with 32 long. Perhaps the address was 5000. So we know postions 5000-5031 start blank .. unless you have a values clause on the DCL. The second program was passed the address 5000 and since it needed to use 40 characters used 5000-5039. Positions 5032-5039 could have had any data in them. Phil
    48,565 pointsBadges:
    report
  • philpl1jb
    This isn't the statement you showed us before when &Mail is 10 long it puts the value of &MAIL into a new unnammed field 32 long, as discussed above. CHGVAR &TEXTE (’CALL TEST03B’ *BCAT ‘PARM(”’ *CAT &MAIL *CAT ”’)') With this method your second program will not be able to pass back changes to the value, if that's ever important. Phil
    48,565 pointsBadges:
    report
  • TomLiotta
    @Laurentjudic: There are two 'correct' ways to use SBMJOB to execute a program in batch that must receive parameter values. One is to create a *CMD command object that defines how parm values are to be passed. The SBMJOB CMD() parm handles these well. The RQSDTA() parameter can also be used, but CMD() is simply easier; it won't apply default handling rules to parm values for a structured *CMD. The *CMD acts like a prototype for the CALL to the command-processing program. The other is to construct the request message yourself and pass it through the RQSDTA() parameter directly. The RQSDTA() is what actually gets passed as the request message even if you use the CMD() parameter. The default is RQSDTA(*CMD) which indicates that the output from processing the CMD() parm becomes the request data. If you create it yourself, the default handling is bypassed. For long character parms, this means that you can concatenate CL variables into the string and retain trailing blanks. Default handling of character variables when passed as parms to CALL is that values are stored in memory with a minimum length of 32 bytes. A 10-character variable is stored in 32 bytes that are initialized with blanks. When variables are longer than 32 characters, the values are stored in memory that is allocated the same length as the value -- and the value does not include trailing blanks. It's important to remeber that it's the length of the value rather than the length of the variable; this is a result of how CALL parms are structured, combined with how SBMJOB CMD() works. So, a 40-byte variable that holds a 35-character value will be stored in 35 bytes of memory. The trailing blanks are lost. The five bytes at the end hold whatever was in them before the 35 bytes at the beginning are stored. When the CALLed program runs, it receives 40 bytes of data from memory that has had 35 bytes initialized. The trailing bytes are (probably) garbage. If the 40-byte variable contains a value with less than 32 significant characters, the default 32 bytes are initialized and the trailing eight bytes are not. When the CALLed program runs, it receives 40 bytes of data from memory that has had 32 bytes initialized -- with the beginning significant characters, plus initialized blanks to fill in 32 bytes; the trailing eight bytes still contain their previous values. Notice that when you concatenate a 40-byte variable into RQSDTA(), you take care not to truncate trailing blanks. Those blanks are stored as part of the value. Some people will continue to use the CMD() parameter. They get around default handling by passing a 41-byte variable that has some character like "X" in the last byte. The calling CL program will have some code to add that extra non-blank byte onto the end. That extra byte creates a value that doesn't have any 'trailing blanks', so they don't get truncated. Personally, if I have to use CALL, I create the request data myself. I want to know exactly what will be submitted to the job queue. I don't rely on default handling. I expect that values may have trailing blanks. Often, I don't have to use CALL. I'm allowed to create a *CMD. I prefer commands because they help document the parameter structures. Further, if the CALLed program changes, I can often simply change and recompile the *CMD. None of the calling programs need to be changed nor recompiled. That becomes especially important when you run into the next problem concerning SBMJOB and CALL -- numeric parms. But that's for another question. Tom
    125,585 pointsBadges:
    report
  • Laurentjudic
    Hi Phil and Tom, Thanks for all this explanations. The length of 10 is just my last test but in the initial program the lnegth was 40 caracters I will use the RQSDTA() method because in the SBMJOB, i do not wait for any return value, but i will test the *CMD method because as says Tom, we often have problems with numerical parameters. Usually i put numericals parameters in character fields before the CALL and i put caracter fields in numerical fields in the CALLed program. thanks for all Laurent
    55 pointsBadges:
    report
  • philpl1jb
    If &MAIL was 40 char then this should work CHGVAR &TEXTE (’CALL TEST03B’ *BCAT ‘PARM(”’ *CAT &MAIL *CAT ”’)’) but change it to *TCAT and have a value shorter than 40 characters in &MAIL and it won't work. CHGVAR &TEXTE (’CALL TEST03B’ *BCAT ‘PARM(”’ *CAT &MAIL *TCAT ”’)’) when you issue the cmd Decimal fields in CL will be packed in RPG and if you want to call the program from the command line it will assume than numeric unquoted values are 15P 5. Phil
    48,565 pointsBadges:
    report
  • TomLiotta
    when you issue the cmd Decimal fields in CL will be packed in RPG It's not clear if "cmd" refers to a *CMD object that might be created in order to 'prototype' a CALL. If it does, then a CL *DEC variable will be passed into RPG in whatever numeric form is desired. E.g., it might be *DEC (3 0) in CL, but 5u 0 in RPG. There does need to be compatibility. A *DEC (5 3) isn't appropriate to pass into an integer command parameter. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following