Do you want to remove the prompt because it’s always the same company? It looks like you want company 10 from your DCL statements… you can change the setvar to use the &COMP# rather than the &OSCOMP variable.
You have &OSCOMP declared as a *CHAR — is oscomp in the table a CHAR or is it a numeric data type? From there, you have this line in your query:
<pre>and &OSCOMP = oscomp</pre>
That relates to this in your CL:
<pre>CHGVAR VAR(&OSCOMP) VALUE(10) </pre>
<pre>SETVAR((‘OSCOMP’ &OSCOMP)) </pre>
When the value  gets substituted into the query, the query clause becomes:
<pre>and 10 = oscomp</pre>
Now, when SQL sees that, it interprets it as “…and when numeric 10 equals the value in the OSCOMP column”. If oscomp is a character column and may contain any non-digit characters, then the numeric 10 won’t compare properly. You would need to specify “character” 10. You would need to put quotes around it.
Unfortunately, you can’t simply put quotes around your substitution variable name because that would make QM think the name was a literal that it should ignore. Instead, you would have to add the quotes to the  that you pass into the query.
But that shouldn’t give the behavior that you report. If oscomp is CHAR in the table and only contains digits, the query should work. I <i>think</i> it will try to cast oscomp as an INT(4).
What you say is that the OSCOMP substitution variable is prompted even though you correctly pass the variable name as ‘OSCOMP’ using all upper-case and your substitution variable name is &OSCOMP which is also all upper-case. The two should match.
It’s a little odd that you’re using a literal value  in the table-1 position of a JOIN clause join condition, though, rather than naming the column from nshpmnt that the join should be over.
Also, the naming convention of your columns makes it look as if osctnid is a column from o3oput01 and o3casn is a column from nshpmnt. I don’t think it’s wrong, just a little misleading — unless, of course, that’s how the relationships go. Which is perhaps misleading in the other direction.
I can’t see anything actually “wrong”. Just oddities. Maybe all together they add up to confusion for QM.
I think I would run under debug to see what shows up in the joblog that is related to the issue. I’ve never debugged a QM query, but SQL is pretty good at it.