On Fri, Dec 16, 2016 at 12:17 PM, Bill Woodger <[email protected]>
wrote:
> If I remember correctly, John, you are on an Enterprise COBOL V3 compiler,
> which has a 16MB size-limit for tables (V4 upped that to 134MB, V5+ even
> more).
>
> Just to check, the compression is only for DASD saving?
yes. Not for use in-memory. E.g. read compressed record; uncompress;
process; repeat until EOF
> There's a slight possibility it also used for getting around that limit.
> Assuming the former, it really is not needed. For the latter, it is
> unlikely that a (presumably) modern COBOL under Windows has such a limit,
> but any programs using the routine would have to be "simplified" to
> no-longer need to use it - which may mean retaining the compression in the
> interim, depending on resources, planning, and all that type of stuff. Not
> common, but I am aware of "compression" to live within compiler limits, so
> just sayin'.
>
> Otherwise, just let the storage people take care of it. They may
> appreciate knowing there are a shed-load of trailing blanks, because they
> will not be used to that ("strings" don't have trailing blanks).
>
Checking the doc on MicroFocus COBOL, it said that for "line sequential"
files, the run time automatically removes trailing blanks. I am really
wondering how much reading people have been doing about what the Windows
system & MicroFocus environment can do all on its own. I'm getting the
impression that they basically are thinking "Works exactly like the
mainframe, so don't bother reading."
--
Heisenberg may have been here.
http://xkcd.com/1770/
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
