×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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 . . .
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
