×
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.
Seems that at least since v6r1, what was previously diagnosed with
CPD0858 "Variable or data area &1 declared previously.", may no longer
get diagnosed. Seems the intention, since some compiler change
[probably in support of the Include CL Source (INCLUDE) CL command as
compiler directive available starting with IBM i 6.1], is to operate
quite literally, according to the implication of the Recovery text,
whereby either action of "Remove one of the conflicting declarations or
change the attributes on both declarations so they are the same" should
suffice to allow the compile. Thus the Control Language compiler [for
any of: Create Bound CL Program (CRTBNDCL), Create CL Module (CRTCLMOD),
Create CL Program (CRTCLPGM)] now just ignores a duplicate-named
declarative, without any indication(s) being logged, given each of the
same-named variable has [exactly] matching attributes.
As late as v5r3, the CL compiler was [still; ¿and AFaIK, had always
been, since the S/38?] diagnosing the condition of a duplicate CL
Variable Name (VAR) of a Declare Variable (DCL) with the sev-30 failure
msgCPD0858, despite matching attributes across the multiply-declared
variable name; i.e. any duplicate-named declarative was being diagnosed,
*irrespective the attributes*. Given the recovery text has not changed
between those releases, I suppose that the error was being diagnosed on
v5r3 could have been a defect on that release; and any other [earlier]
releases exhibiting the same behavior.?
I felt the need to investigate after I stupidly had coded an Initial
Value (VALUE) on the Declare Variable (DCL) for a Parameter (PARM), but
having left the correct\proper DCL in the source, quite conspicuously,
on the next line of source. The incorrectly coded declarative with the
initialization was properly diagnosed with the sev-20 msg CPD0702
"Initial value not allowed for variable passed into program." Because
the VALUE() specification was disallowed and essentially ignored by the
compiler [though oddly, the recovery text for that non-terminating error
suggests deleting and re-creating the program? As if!], that
conspicuous _mismatch_ of initializations between the two declares, was
undetected and thus [not surprisingly] also not diagnosed with CPD0858 :-)
Only thing left to do, is find that darned Declare Data Area
(DCLDTAARA) command ;-) FWiW, the command is for the S38 environment
and thus only [in\available-from QSYS38] and thus Source Type (SRCTYPE)
of CLP38 is all that can use the feature for which there are also both
of Receive Data Area (RCVDTAARA) and Send Data Area (SNDDTAARA). The
implementation\effects for the feature, are much like what occurs for
the Declare File (DCLF), Send File (SNDF) and Receive File (RCVF)
whereby the variable generated for the declare can be read and written.
The message probably should have been modified long ago, to remove the
"or data area" from the first level text; leaving reference in the
second-level text and late in the recovery text.
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.