Re: Re: MVT COBOL under MVS3.8j.

Hi Peppe,

I'm running a number of days behind.  What is the status of the XREF 
problem?  Does the "hack" work or do we need to explore it further?

Gary

On 9/17/19 4:19 AM, Giuseppe Vitillaro giuseppe-yuD/ahkh7LvrZ44/[email protected] [H390-MVS] 
wrote:
>
> On Tue, 16 Sep 2019, [email protected] [H390-MVS] wrote:
>
> > Pepe,
> >
> >
> > I've used something like code below after the READ. I wouldn't use 
> the INTO clause of READ but rather access data using definitions under 
> the FD.
> >
> >
> > VB-LRECL is actually 4 bytes larger than the COBOL record size since 
> COBOL excludes the RDW from the record size. For example a 1 byte 
> record in COBOL is really physically 5 bytes. So the BLOCK CONTAINS of 
> 32760 is the max you can specify in COBOL and the 32752 is the largest 
> RECORD you can define because the RDW length isn't included in the 
> record size.
> >
> >
> > FD VB-IN
> > RECORDING MODE IS V
> > LABEL RECORDS ARE STANDARD
> > BLOCK CONTAINS 32760 CHARACTERS.
> > 01 VB-IN-REC.
> > 05 VB-IN-SIZE OCCURS 2 TIMES
> > PIC S9(4) COMP.
> > 01 VB-IN-REC1.
> > 05 VB-IN-REC-BYT OCCURS 32752 TIMES
> > PIC X.
> > 77 SUB1 PIC S9(8) COMP.
> > 77 VB-LRECL PIC S9(8) COMP.
> > READ VB-IN AT END...
> > MOVE -1 TO SUB1.
> > MOVE VB-IN-SIZE (SUB1) TO VB-LRECL.
> >
> >
> > Working with the data is up to you.
> >
> >
> > I think you might be able to use a PIC X OCCURS 1 TO 32752 TIMES 
> DEPENDING ON VB-LRECL so you could copy a VB file with WRITE after 
> subtracting 4 from VB-FIELD. You would have to play with that, I 
> haven't tried that that I can remember.
> >
> >
> > Dave
> >
> >
>
> Yep, Dave! Exactly what I had in mind, a negative index
> stored in an index variable fool the compiler.
>
> It can't check that ;-)
>
> Peppe.
>
>