× 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.



Well, the reason I did this is I am getting this data directly from a
data queue, then I just directly pass this information to another
program to process. I didn't want to have this first program be overly
complicated because it is running in QINTER, so didn't want to take up
a lot of CPU. I guess, that sort of bit me. I will have to figure out
how I will handle this then.

On Mon, 28 Jun 2004 11:22:39 -0500 (CDT), Scott Klement wrote:
> Hi Mike,
> 
> > I have this program that was worked flawlessly for a long time.
> 
> You got lucky. :)
> 
> 
> >  /free
> >   Cmd = 'SBMJOB CMD(CALL PGM(CUGPRCSMON) PARM(''' + DataQueue + ''')) ' +
> >          'JOB(PROCESSMON) JOBD(MONPDFJOBD) JOBQ(' + SBMJOBQ + ')';
> >
> 
> When you submit a command in this manner, you have to understand that the
> entire command string will be assembled into one string, that string will
> be copied to the new job and then executed as if it had been typed at the
> command-line.  This means:
> 
> 1) Quotes must be doubled up.
> 2) Parameters over 32-bytes long have to be treated in a special way.
> 3) Numeric parameters will be treated as 15,5
> 4) Special literals like x'010203' will be converted to hex bytes and
> passed.
> 
> And so on.
> 
> This is ONLY a problem when working with either QCMDEXC, SBMJOB, or the
> command-line.  It is not a concern when calling another program directly.
> 
> > D  SplfNumber                    8B 0
> >     Spool File Number
> 
> I could go into a whole diatribe about why you should never use the 'B'
> data type, but it's irrelevant to the problem you're experiencing, so I'll
> spare you.
> 
> But what you do have to consider is what that 'B' means.  It means that
> your number will be stored according to it's binary representation.  If
> you pass the decimal number 125, then the physical bits of storage will be
> 01111101, which is the binary representation of that number.
> 
> So you have to ask yourself, how will the command-line interpret that
> byte?  It will try to interpret it as a character typed on the command
> line... which brings me to the next point:
> 
> > Note the " ' " in the middle of the parm. Like I said this has worked
> > flawlessly for almost 2 years, what is the corralation between the 125
> > and the single quote?
> 
> That correlation is called "EBCDIC."  Look up 125 on your EBCDIC chart...
> 
> > Could I define 'SplfNumber' as alpha and not have a problem when my
> > called program is recieving the exact same defined DS?
> 
> Bingo.  That would solve this problem.  There are other problems,
> however... for one, since your parm is > 32 bytes long, there's the chance
> for garbage characters appearing at the end of the data structure.  You
> also should make certain that everything else in the DS can be safely
> parsed by the command-line.
> 
> Personally, I'd avoid all of that and use a different method to pass the
> data to the other application.
> 
> 

-- 
Mike Wills
iSeries Programmer/Lawson Administrator
koldark@xxxxxxxxx
http://www.koldark.net

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.