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