MCH4227 rc22 (was: CPF4227 Reason 22 on Program Call)

[CRPence <CRPbottle@xxxxxxxxx>]

  The opening and next post of this thread seem not to have been 
received via NNTP.  Hopefully the above correction to the subject line 
appears in the archives as it would in NNTP threading... and along with 
that, the following information may assist someone in the future.

  Anyhow the error was in symptom keyword string format: msgMCH4227 
RC22; per lack of a joblog, the context of the error with regard to 
messaging is not available, and the description of the scenario [also] 
does not include the request [message] being made; the subject said 
"program call", but the "resolution" would imply possibly a "procedure 
call" from a service program.  Apparently, per the description of 
"resolved", the error was manifest when the system was trying to 
re-translate the referenced down-level IBM service program... but the 
joblog was not given, so that is not obvious, if in fact that was the case.

  As Jon suggests in another reply, copying IBM code to a user library 
is generally inappropriate [and often unsupported].  Yet like all 
/changes/ to a system [i.e. customizations], when doing so is supported 
and\or functional, one must remember also to implement proper System 
Change Management, to ensure that the same copy\change activity is 
repeated again after every upgrade and after any maintenance that might 
have replaced\updated that copied code.  Unlike user code for which the 
system intends the code to remain functional on a later release than 
where the code was compiled, the IBM code often does not effect that 
same support for itself; i.e. unless explicitly designed to enable 
/skip-ship/ support, IBM code is expected to be replaced by an 
install\upgrade, to match the current release that is installed. 
Down-level IBM code is necessarily expected to fail re-translation.

Regards, Chuck

On 20-Feb-2014 08:56 -0800, Michael Ryan wrote:
> Problem resolved. Here's the issue. I had an old copy of
> QHTTPSVR/QZHBCGI in a user library. The QHTTPSVR version of QZHBCGI
> had this:
>
> Conversion required  . . . . . . . . . . . . . . :   *NO
> Conversion detail  . . . . . . . . . . . . . . . :   *COMMON
>
> The copy I had in my user library had this:
>
> Conversion required  . . . . . . . . . . . . . . :   *YES
> Conversion detail  . . . . . . . . . . . . . . . :   *FORMAT
>
> so it was in the wrong format for my version of the OS. I put
> QHTTPSVR higher in my library list so the IBM object would be
> grabbed. Program created fine and executed fine.
>
> On Thu, Feb 20, 2014 at 11:05 AM, Michael Ryan wrote:
>
> > Ok...I wonder if it's combining an old service program with newer
> > techniques like like_ds. The service program is from 2008...didn't
> > have that then, right?
> >
> > On Thu, Feb 20, 2014 at 10:16 AM, steveg wrote:
> >
> > > I think I had this once before. It was because I was compiling a
> > > program back-level and something on a D or C spec wasn't
> > > supported in that release.
> > >
> > > Jon Paris on 20/02/2014 14:51 wrote:
> > > > Usually it means what it says Michael - this is a compiler
> > > > problem and you have either discovered a new problem or are a
> > > > few PTFs short of a full load.
> > > >
> > > > There is rarely anything a mere user can do that would throw an
> > > > error of this type.
> > > >
> > > > On 2014-02-20, at 9:28 AM, Michael Ryan wrote:
> > > >
> > > > > And here's the error message:
> > > > >
> > > > > Message ID . . :   MCH4227       Severity . . :   40
> > > > > Message type . :   Escape
> > > > > Date sent  . . :   02/20/14      Time sent  . : 09:11:18
> > > > > Message . . . . :   Instruction stream not valid.
> > > > > Cause . . . . . : The object was not created because the
> > > > >  sequence of instruction stream objects is not valid.
> > > > > Recovery . . . : There is a problem in the compiler. Report
> > > > > this problem to the supplier of the compiler.
> > > > > Technical description . . . : The reason code is 22.
> > > > > The current instruction count is 75. The offset to the
> > > > > instruction stream data that is not valid is 660 bytes.
> > > > > The offset to the current instruction is 640 bytes and the
> > > > > operation code of the current instruction is X'00000061'.
> > > > > The current statement number is 23. The LIC log note ID is
> > > > > 01003648.
> >>>> On Thu, Feb 20, 2014 at 9:27 AM, Michael Ryan wrote:
> > > > > > I did some Googling on this, but I'm not sure how to find
> > > > > > out the problem. I think it's a mismatch with an old
> > > > > > version of a service program (old code) and new code, but
> > > > > > I'm not sure how to determine where I'm having the problem.
> > > > > > Any ideas on how to research this?