Problem Running SQLRPGLE program in Batch: Works Fine Interactively

465 pts.
Tags:
Batch job
Error Messages
iSeries RPG programming
SQLRPGLE
V5R4
Hello all, We currently have a program that runs in batch. Last night, we had the following error occur: RNQ0103: The target for a numeric operation is too small to hold the result. The program works perfectly when run interactively. When the program was originially written, I compensated for the fact that it may be too small to hold the result. My question is, why does it work interactively and not in batch? Thank you, Dave

Software/Hardware used:
iSeries with v5r4
ASKED: October 6, 2009  6:27 PM
UPDATED: January 7, 2011  12:22 PM

Answer Wiki

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

When I get something like this, I go through a checklist similiar to what I have below:

Are you sure the program is running over the exact same dataset?
Is it using some variables that would cause it to select different records if ran last nignt in batch and today interactively?
Did you take a dump when it failed to help you diagnose the problem?
Have you tried to run it in DEBUG both in Batch and Interactively?

Discuss This Question: 16  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
  • Dcantwell
    I've found a way to fix it programming-wise. But, I still don't understand why it would work one way and not the other. Here's answers to your questions CharlieBrowne: Are you sure the program is running over the exact same dataset? - Yes Is it using some variables that would cause it to select different records if ran last nignt in batch and today interactively? - No. I've actually set up a test environment and call the CL program that runs it. I use the SBMJOB command to run it, it produces an error. I prompt the SBMJOB command, removing EVERYTHING but the call to the CL and it runs fine. Did you take a dump when it failed to help you diagnose the problem? - Yes. I have the relative record number, the line at which it happened. Everything. Have you tried to run it in DEBUG both in Batch and Interactively? - Debugged interactively, saw no problems. Didn't actually debug in batch (not really sure how to) but checked the dump for the values and line numbers. I know what caused it. I had a really low value and didn't program for it.
    465 pointsBadges:
    report
  • Finkpad
    when you say 'setup a test environment' are you sure that there is nothing in your interactive jobs QTEMP thats being used. Obviously the batch job has its own one...
    115 pointsBadges:
    report
  • Ferneyhough
    what error are you actually getting ?
    10 pointsBadges:
    report
  • TomLiotta
    You say "...call the CL program that runs it. I use the SBMJOB command to run it, it produces an error." It's not clear what that means. Does it mean that when the program is run interactively, it is called by a CL program? And, rather than submitting the CL program to batch, you submit the CALL that the CL program normally makes? If so, are there parameters supplied for the CALL?
    125,585 pointsBadges:
    report
  • graybeard52
    I have been bitten by this before. SBMJOB can be tricky. The library list used for SBMJOB when called interactively (or sumbit immediate) is NOT the same as the library list when the job is submitted by the scheduler. Check for sure that the library list is still the same.
    3,115 pointsBadges:
    report
  • Dcantwell
    Ok. From the command line, here's the commands I use: Interactive: CALL PGM(RPC971) PARM('01' '01' '200901' '200909' ' ' ' ') Batch: SBMJOB CMD(CALL PGM(RPC971) PARM('01' '01' '200901' '200909' ' ' ' ')) RPC971 is a CLP program. Hopefully that clarifies how I'm calling the program. Checked the library lists. The only difference I noticed was that the library QPDA was at the top right below the system libraries when calling interactively. Could there be something in that library causing the issue? QPDA is definitely not a library listed in my interactive library list. Nor are there any files similar to the ones my process uses. The process I created uses only user defined files/libraries. Anyone know about this QPDA library? It looks like it contains IBM programs/commands/files. Thank you, Dave
    465 pointsBadges:
    report
  • Splat
    QPDA is the PDM library. If you're doing a DSPLIBL, you'll see the type as PRD indicating that it's a product library. Take a look at the dump and locate the variables that go into the failing operation. You'll probably find that some variable contains more than you were expecting. Not knowing what variables (or their contents) are involved I can't offer much more than that.
    6,255 pointsBadges:
    report
  • Dcantwell
    Well the program's problem was that I wasn't compensating for a really low number: I originally had this:
    IF wtemplr > 999999.999;
    and changed it to this:
    IF wtemplr > 999999.999 OR wtemplr < -999999.999;
    now everything works fine! BUT, I mentioned I fixed it before. Therefore, I'm not worried about fixing my program. I'm just really curious why with the first statement (over the same data set with matching librarylists besides the QPDA library) it'll work interactively but not in batch. Could it have something to do with the activation group?
    465 pointsBadges:
    report
  • TomLiotta
    Dave, > RPC971 is a CLP program. Hopefully that clarifies how I’m calling the program. Very much so. That gives a solid foundation and clarifies the original. Naturally, without seeing any programming, it's near total guesswork. Still, there are things different between calling a program interactively and calling the same program, same parms, over the same data, with the same library list, via an identical CALL with SBMJOB. Very first difference would involve what was previously done in the interactive job. A SBMJOB comes close to having a pristine job environment. An interactive job might have had any number of commands run before calling the program being tested. Apparently in this case, at least one PDM-related command has been run; and the command line is executing inside of a PDM function. That means that bytes in the memory that is used to hold the command string from the command line will possibly have values in the bytes beyond the end of the command string. Without any clue about definitions of the six parms to RPC971, it's merely a chance that it makes a difference. Can you show the DCLs for the six parms? That should begin to eliminate a definite potential problem. Tom
    125,585 pointsBadges:
    report
  • Dcantwell
    Thanks Everyone for their insightful answers. Tom, here's the DCL's for the CLP:
    DCL        VAR(&LCO)      TYPE(*CHAR) LEN(2) 
    DCL        VAR(&MCO)      TYPE(*CHAR) LEN(2) 
    DCL        VAR(&CYTDBEG)  TYPE(*CHAR) LEN(6) 
    DCL        VAR(&CYTDEND)  TYPE(*CHAR) LEN(6) 
    DCL        VAR(&HDG)      TYPE(*CHAR) LEN(32)
    DCL        VAR(&HDG2)     TYPE(*CHAR) LEN(16)
    There's more to the story. The CLP actually calls an SQLRPGLE program that builds the data. The SQLRPGLE program is the program that caused the error. The SQLRPGLE program calculates the value wtemplr like so:
    EVAL(H) wtemplr = (value1/value2);
    wtemplr is a ratio calculated and multiplied by 100 for display purposes. Because it can be very low or very high, I check using the following code:
    IF wtemplr > 999999.999 OR wtemplr < -999999.999;
      ratio= 99999999.99;                           
    ELSE;                                            
      ratio= wtemplr * 100;                 
    ENDIF;        
    When the program received the error, the code looked like this:
    IF wtemplr > 999999.999
      ratio= 99999999.99;                           
    ELSE;                                            
      ratio= wtemplr * 100;  //Here's the error. Had a really low (negative) number and ratio couldn't hold it               
    ENDIF;        
    wtemplr is a program defined field:
    D wtemplr         S             11S 3 INZ(0)     
    The fields ratio, value1, and value2 are defined under different names in a PF:
    A            RATIO        10S 1       
    A            VALUE1        11S 2    
    A            VALUE2        11S 2    
    I just noticed that RATIO only has 1 decimal place. I hope that wasn't a factor. Though I don't think it would be. I apologize for forgetting these details in prior posts. If there's anything else, please let me know. Thank you, Dave
    465 pointsBadges:
    report
  • BigKat
    SQL programs get certain operational parameters from the QAQ....INI (can't remember the name) It is possible that there are different values for batch and interactive, and in batch that is a hard (stop) error, while interactively it is a soft (continue) error. Try doing a STRDBG UPDPROD(*YES) and then call your (old version of the) program. This will put more SQL messages into your joblog. Check through the joblog, and you might see more information.
    7,585 pointsBadges:
    report
  • BigKat
    QAQQINI in library QUSRSYS
    7,585 pointsBadges:
    report
  • TomLiotta
    Dave: The parameters look like they'll be sufficient. The direct CALL and the SBMJOB should both handle those properly. Are you definitely interested in tracking down how this manages to give different results? It may take some digging with the easy area gone. BigKat mentions QAQQINI, and it's possible that a different one could get assigned to a different job. I don't know of a particular way that this would give what you see, but it has to be on the list. If you ran CHGQRYA in your interactive job before the CALL (perhaps in your initial program or as an unintended result of some previous CALL), the options might be different. Or a routing program in either interactive or batch subsystem might make the change. This could be tested by explicitly running CHGQRYA to establish the same QAQQINI in both batch and interactive. A new CL could do both CHGQRYA and the CALL. That would ensure that both pointed to the same QAQQINI. Because it's easy to test, it's worth doing early. Either the CL or the RPG could run RTVJOBA or call QUSRJOBI to detect running batch or interactive; the run characteristics might change by programming. The defaults for SBMJOB might be changed from what IBM supplies; attributes of the interactive job might not be replicated to the batch job. Since libraries are the same, it seems unlikely to make a difference. The RNQ0103 is an inquiry message with replies that have slightly different effects. If either the interactive or batch job was set for the system reply list, or a default inquiry message handler exists in your system, then interactive and batch could react differently. However, the differences between the possible replies to RNQ0103 don't match with your case. It might be visible in batch and handled invisibly in interactive; it just shouldn't end up working correctly either way. Your interactive job could execute a different copy than batch would. If you called it interactively more than once, intermixed with one or more compiles, you could have been getting the version from QRPLOBJ because of the resolved pointer. The batch job would always get the newly compiled copy from the library. Similarly, you might have been calling a version before a compile and kept the activation group interactively. The batch job would again get the newly compiled program object. If I understand correctly, those possibilities shouldn't explain why batch failed consistently while interactive didn't. It would seem that the opposite should happen. Still, they are among reasons why interactive tests should include signing off and starting a new, fresh session. You checked library lists for both jobs and believe they match. With that, different versions of file data, etc., shouldn't come into it. However, you say you have a "test environment". Is your test environment used by the programs because of your library list? Is there a chance that the CL or RPG explicitly accesses data rather than uses the library list? Finally for now, can you describe the general processing done by the CL and the RPG? Tom
    125,585 pointsBadges:
    report
  • Laurentjudic
    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
    55 pointsBadges:
    report
  • JohnK
    My question would be whether the CL is ILE or OPM. What we found in the past is that the AS/400 command line editor will parse the parameters being passed into an OPM CL program and will replace the empty alphanumeric parameters (those passed in as '') with spaces--it will also correctly pad a numeric field as long as it is defined as 15 5.. The SBMJOB command does not do the same parsing and will send in whatever garbage it finds in the memory area allocated. In order for the SBMJOB to work correctly you need to pass in the correct number of alphanumeric characters to match the declare statement in the CL. We had mixed results with ILE CL programs.
    10 pointsBadges:
    report
  • philpl1jb
    The systems default char length is 32 So SBMJOB CMD(CALL MyPgm Parm('HI') will pass 'HI' in a 32 character field If program MyPgm's input parameter is *char 40 the last 8 positions can be anything. To correct this SBMJOB CMD(CALL MyPgm Parm('HI ') The calling parameter must be 40 long. Phil
    48,575 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