Re: [open-cobol-list] To correct OpenCOBOL 1.1 Programmers Guide page 5-2 ?

[Fred Mobach]

On Wednesday 07 March 2012 23:51:16 vince wrote:

> Right now back to your problem:
> > > the recordarea of the source they are specified as :
> > >        fd  outfile
> > >
> > >            record is varying in size
> > >            from 4 to 256 characters
> > >            depending on rec-length-out.
> > >
> > >        01  rec-out-record.
> > >
> > >            03  rec-out-byte            pic x(0001) occurs 256.
>
> First off, the varying statement , like ODO's (occurs depending on)
> is also a frig, ie, the size is always the maximum, in your case
> always 256. This is because for whatever reason the compiler writer
> does not put in the very much extra code to cope due to the design of
> the CPU which often cannot handle placing such on secondary stacks as
> most have a limit of such even if they can handle more than one!
>
> One small point, this size is only the size of the data the
> programmer has declared and NOT the real size, there is one or more
> bytes added on at the end, eg, null (x'00') on LS files and some
> other types so always check the last few byes of a record to see what
> your compiler does!

Yes, that's why I frequently use hexdump -C in GNU/Linux environments.

> > > Corresponding specifications without the  from 4 to 256
> > > characters results in the errors indicated. However, Gary
> > > informed me that the presence of the OCCURS...DEPENDING ON can
> > > also result in this error.
>
> Ok, a possible problem could result from what version of the compiler
> you are using. If you are using v1.0 upgrade it asap, if you are
> using v1.1 check what build it is.

From the output of the with -t generated listing:
# Generated by OpenCOBOL 1.1.0
# Built        Feb 19 2012 22:24:40
# Packaged     Feb 06 2009 10:30:55 CET

> > I listed the program lenseqx.cob and don't understand one piece
> > of it. You read a record from infile into rec-out-record and later
> > move rec-in-record to rec-out-record. Isn't the move redundant?

You are of course correct.

> Again as I have not seen the code and assuming that the organisation
> type works, set the file type as Line Sequential and retest, as LS
> will produce the right EOR (End of Record) byte sequence. If that
> works then you must check how the original file was defined.
>
> Variable records can be a right pain and sometimes it is easier to
> use basic file processing to handle heavy variable length records
> (Not IS) and this works for me on LS format files. [Done as block
> processing where the programmer is responsible for all deblocking and
> record processing etc], There is an example in the FAQ near the end,
> that I posted a few years ago that might help but this was done for a
> special purpose i.e., for LS files, eg Cobol source code.

I was just looking for the pain of variable records. After found out 
(with OCCURS...DEPENDING ON) how it works hexdump shows me exactly what 
was supposed to be there:
address@hidden:~/cob/variablerecordlengthsequential> hexdump -C outfile
00000000  00 33 00 00 30 31 20 30  31 32 33 34 35 36 37 38  |.3..01 
012345678|
00000010  39 20 61 62 63 64 65 66  67 68 69 6a 6b 6c 6d 6e  |9 
abcdefghijklmn|
00000020  6f 70 71 72 73 74 75 76  77 78 79 7a 20 30 31 32  |
opqrstuvwxyz 012|
00000030  33 34 35 36 37 38 39 00  33 00 00 30 32 20 30 31  |
3456789.3..02 01|
e.g, a record length field of 4 bytes in front of the record with the 
actual record length in the first two positions.

Thank you for your support.
-- 
Fred Mobach
website : https://fred.mobach.nl
 .... In God we trust ....
 .. The rest we monitor ..