Re: RPG II Question

[John McKay <jmckay@xxxxxxxxxxxxxxxx>]

My experience with legacy stock is that a healthy scepticism regarding 
the source code being the correct match for the object code is often useful.

I would rename the source program and compile it, or compile it into a 
different location, and run / debug it.

Regards,
John McKay


Booth Martin wrote:
> I wonder if the key being used is really in either of those positions.  
> My memory is that at that time the files were built with all the keys at 
> the end of the file.  In other words, your file LISTCONS may really be 
> 28 long, with the key foiund in position 28.
>
> That is my memory.  It might be right, partially right, or entirely 
> wrong but it may trigger more complete answers.
>
>
>
>
>
> Jerry Adams wrote:
>   
> > I really don't expect an answer.  In fact most people will probably just 
> > delete this when they see the subject line.  But this is puzzling the 
> > heck out of me.
> >
> > I went in to an RPG II program (old package) to do some simple 
> > maintenance changes.  I noticed that one of the files was defined as:
> >
> > FFilenameIPEAFBlenRlenLK1AIOvKlocEDevice+
> > FLISTCONSIF         27  1AI     1 DISK  
> >
> > Well, the key length is '1' but the key actually starts in position '2' 
> > of the record.  The purpose of the file is to validate a code entered on 
> > a panel:
> >
> > C           WRCONS    CHAINLISTCONS             54
> > C   54                SETON                     99
> > C   54      *ZEROS    ADD  23        $            
> > C   54                GOTO X2A                    
> >
> > The first position of LISTCONS is a status byte.  Currently every record 
> > has an 'A' in position 1.  The program has been successfully validating 
> > these codes for years.  How is that possible?  I even put the program 
> > under debug (ISDB) and verified the codes entered (WRCONS) and in the 
> > file (ABCONS) are the same after the chain, and that indicator 54 is 
> > turned *Off.
> >
> > It has been awhile since I programmed on a S/36, but I'm pretty sure 
> > that, first, when the program started up it would give me a file 
> > mismatch error.  Is the i5 really smart enough to say, "Well, he botched 
> > that.  Let's just use what is really in the file."?
> >
> > Thanks.
> >
> >   
> >     
>
>