Re: Problem with Option(*SRCSTMT)

Thanks for the suggestion Martin, but I'm afraid that isn't the problem.
The binding directory only has one service program listed and I am the
only one using it. I can repeat this problem ad finitum.

I should have included the message from the job log though.

It is MCH4227, which says

    01/09/00   10:32:29   VOXERROR                   0016B4  
QBNCRTMD     QSY 
To module . . . . . . . . . :  
QBNCRTMD                                       
To procedure  . . . . . . . :  
main_module                                    
Statement . . . . . . . . . :  
472                                            
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
12.   
  The current instruction count is 6700.  The offset to the instruction
stream 
  data that is not valid is 70080 bytes.  The offset to the
current            
  instruction is 70068 bytes and the operation code of the current
instruction 
  is X'00000025'.  The current statement number is 41004900.  The VLIC
log     
  note ID is
2601B643.                                                         

Because of the compiler problem, I thought it might have something to do
with a PTF.

Paul Tuohy

"McCallion, Martin" wrote:

> >
> 
> I think the OPTION(*SRCSTMT) thing may be a red herring.  In my
> experience you get that message if a required object is locked during
> compilation.  I think it usually happened to us when we had all our
> modules listed on a binding directory, and someone was compiling a
> module at the time someone else tried to compile a program (and the
> first module was included on the binding directory).  The program
> compiler requires a lock on _all_ objects on the binding directory
> (whether the program being created needs them or not, which seems like a
> bug to me).
> 
> Are other compiles happening in parallel with yours?  If so, they may
> just have finished while you were removing OPTION(*SRCSTMT), so that
> when you resubmitted your compile, you didn't get the locking problem.
> 
> Check the job log: it has more useful messages than the compiler listing
> for program creates.
> 
> HTH.
> 
> Cheers,
> 
> Martin.
> 
> --
> Martin McCallion
> Midas-Kapiti International
> Work:  mccallim@midas-kapiti.com
> Home: martin.mccallion@ukonline.co.uk
> 
> Apologies for the length of this sig, but company policy says:
> This email message is intended for the named recipient only.  It may be
> privileged and/or confidential.  If you are not the intended named
> recipient of this email then you should not copy it or use it for any
> purpose, nor disclose its contents to any other person.  You should
> contact Midas-Kapiti International as shown below so that we can take
> appropriate action at no cost to yourself.
> 
> Midas-Kapiti International Ltd, 1 St George's Road, Wimbledon, London,
> SW19 4DR, UK
> Email: Postmaster@midas-kapiti.com Tel: +44 (0)208 879 1188 Fax: +44
> (0)208 947 3373
> Midas-Kapiti International Ltd is registered in England and Wales under
> company no. 971479
> +---
> | 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
> +---

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