Re: Alternative COBOL "telco" source program

From: Jeffery Swagger (jeffos2_at_adelphia.net)
Date: 05/30/04 

Date: Sun, 30 May 2004 15:16:41 -0400

WTF does *any* of this have to do with PL/I?
(Followup set to comp.lang.cobol) 

----
Jeff
"Robert Wagner" <robert.deletethis@wagner.net> wrote in message news:40b9c05d.136840610@news.optonline.net...
> LX-i <lxi0007@netscape.net> wrote:
> 
> > when I 
> >discovered that I could put a value clause on a group item, it changed 
> >the way I defined tables (and other 01-level items).  With my compiler, 
> >there is a caveat (not sure if it's standard-imposed or not) - you can't 
> >use a usage clause under a group level item with a value clause.  So, 
> >for my bit-switches, I can't say...
> >
> >01  MySwitches value zeroes.
> >     12  pic 1 binary-1.
> >
> >...which kind of stinks, but I can understand the limitation as well.
> 
> Group names are implicitly pic x. It's an error to initialize bit/binary/packed
> variables with F0 (EBCDIC) or 30 (ASCII). It's common for compilers to disallow
> that value while permitting 'move zeroes to MySwitches'. Go figure.
> 
> I use Value only to initialize constants i.e. fields that will never change.
> With regular variables, there are at least two potential bugtraps. One is the
> Initialize verb which, according to the '85 Standard, does not use your Values.
> The other is the operating system or Cobol runtime handling of called programs. 
> If the caller does a Cancel, Values will be there on the next Call. But if the
> caller forgets or abends or someone else calls your .dll, they probably won't
> be. 
> 
> A third, less common, problem is Local-Storage. As discussed here, Micro Focus
> used to leave it uninitialized. It didn't issue a warning about Value clauses,
> as it would in Linkage-Section,  it just didn't use them. That's now fixed, but
> there's a chance the shop's production compiler is older than its development
> version, or another shop is using an old one.
> 
> For these reasons, I put 'individual' variables under a group name (rather than
> using 77 or 01) and initialize it with 'move low-values to
> unqualified-variables'.
> 
> FWIW, 'pic 1' seems like sufficient information for the compiler to define one
> bit. It is on the AS/400. If your compiler makes you also write 'binary-1', that
> seems redundant.

Relevant Pages

  • Re: Best way to implement default parameters
    ... initialize with default values first ... compiler keeps track of whether to insert code to initialize to default ... which allocates and returns an activation record ... The advantage is that even if the caller isn't *aware* of the ...
    (comp.lang.misc)
  • Re: Best way to implement default parameters
    ... Default parameters where the caller knows not just which arguments ... In other words the callee can change the ... initialize, ... If the compiler knows about the defaults it can ...
    (comp.lang.misc)
  • Re: Alternative COBOL "telco" source program
    ... >use a usage clause under a group level item with a value clause. ... I use Value only to initialize constants i.e. fields that will never change. ... If the caller does a Cancel, Values will be there on the next Call. ... 'pic 1' seems like sufficient information for the compiler to define one ...
    (comp.lang.cobol)
  • Re: abstract sub programs overriding
    ... >>compiler can determine that Object is never referenced before it is ... >>implicit Finalize. ... >>the Initialize is user defined. ... > if that initial value is an aggregate, it has to be built directly in the ...
    (comp.lang.ada)
  • Re: compiler bugs
    ... In a language like C, the behavior of programs that reference ... Not if the unoptimizing compiler initializes all variables to some ... portion of the array in your algorithhm. ... that one actually does not need to initialize all variables (unlike ...
    (comp.compilers)