× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: STRDBG giving wrong data
  • From: Gary Guthrie <GaryGuthrie@xxxxxxxx>
  • Date: Wed, 09 Feb 2000 14:08:26 -0600

Let me guess. You're submitting the job like this...

Sbmjob ....Cmd(Call Pgm(YourPgm) Parm('Parm1' 'Parm2')) ...

and one or more of your parameters do not fill the entire length they
are defined at. Correct?

When using Call on the submit job command, character parameters default
to a length of 32 bytes. The default for numeric parameters is 15 with 5
decimal positions. When using SbmJob Cmd(Call...) character paramters
are only padded with trailing blanks to the 32nd character, their
default length. This means that after byte 32, any trailing blanks can
,and almost always do, contain garbage.

There are a couple of ways to get around the problem.

1) Make sure there are no trailing blanks in the parameters. You can do
this by defining them one larger than they really are and using the
substring function to place a dummy character in the last position.

2) Define a command front-end to the program that has the parameter
definitions (no need to be one larger here) and submit the command on
the SbmJob command.

Of the two methods, my vote goes to option 2.

Gary Guthrie




> Rajeev Asthana wrote:
> 
> Hi All,
> 
> I'm back again on this wonderful list.
> This question is about STRDBG.
> I have a RPGLE program with 2 *entry parameters with lengths 256 and
> 512 respectively.
> I'm debugging it to see their contents after the proper values are
> moved into these *entry parms, .
> Now weird thing is happening.
> When I see Parm1 (by F11) it shows the correct value. Now some value
> is moved into Parm2.
> I see Parm2 now (by F11). It's Okay. But if I see Parm1 again, it's
> NOT okay. It shows a value which is a overlap of Parm2 on it.
> Why?
> Now if I see these values in a CL which is calling this RPGLE,
> everything is OK.
> So, where is the problem?
> 
> Any help is appreciated.
> 
> Thanks
> 
> Rajeev.
>
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.