RE: CPF0808 - Error in compiler-created code.

Ok, learned something about CPF0808 - cause was me: probably broke a basic rule about CALLSUBR/SUBR
when I added a label after the second/last SUBR, just before ENDPGM . . . Foolish habit of mine to get a 'clean' compile.

Removing that label solved CPF0808
- another hint was the label was not recognized: still got CPD0791 - No labels used in program.

From: Gary Thompson
Sent: Thursday, November 13, 2014 1:49 PM
To: 'Midrange Systems Technical Discussion'
Subject: CPF0808 - Error in compiler-created code.

Ok, I thought CPF7E56 was mysterious, but CPF0808 trumps that.

Same program as discussed for CPF7E56 last week on this list, and while making final changes in for move to
production, I started getting CPF0808 . . . and I'm stuck . . .

Got hits on midrange and web but main hit seems related to CALLSUBR/SUBR, of which this program has two.

This program is based on one in production, running almost 24/7 for two years. Tried removing changes one by
one to get a compile, but gave up, made fresh copy of production pgm and am now re-applying changes.

I plan to avoid use of DCL that use "stg(*defined) defvar(. . .)" which caused CPF7E56 which
was discussed last week (not that I see a connection, but I really need this running).

Any clues to avoid/fix CPF0808 ?

The core of this program is a loop controlled by a data area and system date-time info, so I don't want to lose CALLSUBR/SUBR . . .