× 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.



Hans,

Thank you very much for the timely reply. This does indeed work as you
specified.

However, if you say ' coding LIKE on a D-Spec defines the field with the
same format as the original', does this refer to the field when that is
defined in the DDS as zoned, or to the field as defined internally in the
program (packed), in case such a field is not defined as a data structure
subfield?

Kind regards,

Loek Maartens
Veracity Software Consultancy BV
The Netherlands

----- Original Message -----
From: "Hans Boldt" <boldt@ca.ibm.com>
Newsgroups: gmane.comp.lang.as400.rpg
To: <rpg400-l@midrange.com>
Sent: Thursday, May 16, 2002 3:19 PM
Subject: Re: Different results *like define opcode RPG/400 versus RPG/IV


> L. Maartens wrote:
> > I have different results using the *LIKE DEFINE opcode in RPG/400 and,
after
> > converting, in RPG/IV.
> >
> > For example in program A:
> > - file TEST is used, which contains a field named NUMB: Zoned 8,0
> > - there is a datastructure where the record format of TEST is externally
> > described (field NUMB = Zoned 8,0)
> > - there is *like define opcode, where field PGNUMB is defined like field
> > NUMB
> > - program B is called
> >
> >
> > RPG/400:
> > -------
> > FBGFIATL2  UF   E           K DISK
> > IDSTEST    EIDSTEST
> > C           *LIKE     DEFN NUMB      PGNUMB
> >
> > When looking at the Field references in the compiler listing, I see
that:
> > - field NUMB is Zoned decimal 8,0
> > - field PGNUMB is Packed decimal 8,0
> >
> >
> >
> > After coverting to RPG/IV:
> > -------------------------
> > FTEST      UF   E           K DISK
> > D DSTEST        E DS                  EXTNAME(TEST) INZ
> > D PGNUMB          S                   LIKE(NUMB)
> >
> > When looking at the Field references in the compiler listing, I see
that:
> > - field NUMB is Zoned decimal 8,0
> > - field PGNUMB is also Zoned decimal 8,0 and not packed as in RPG/400.
> >
> > In program B:
> > PGNUMB is also defined via *LIKE DEFINE, but without datastructure
DSTEST,
> > PGNUMB is Packed 8,0, both in RPG/400 and in RPG/IV (as RPG converts
Zoned
> > to Packed for internal usage).
> >
> > When RPG/400 program A calls RPG/400 B there is no problem.
> > When ILE program A calls ILE program B, I get a decimal data error on
PGNUMB
> > as the two field formats PGNUMB differ.
> >
> > Is this a known problem ? Is there maybe a PTF which solves this?
>
> Loek:  Regarding LIKE definitions, this is working as designed as a
> result of customer requests for a LIKE function where the field being
> defined should have the same format as the original.  *LIKE DEFINE will
> define numeric fields with packed format,  but coding LIKE on a D-Spec
> defines the field with the same format as the original.
>
> Some 3rd party conversion tools are a little too aggressive in their
> conversions, and although they may improve the "style" of the program,
> the resulting program may not work quite the same way as the original.
> If you use CVTRPGSRC (which comes with the RPG IV compiler, the
> semantics of the program should remain largely the same.
>
> (One common possibly incompatible conversion of the 3rd party tools is
> to convert the old style fixed format arithmetic operations to
> expressions.  This is usually a good thing, since it will clearly
> identify bugs in your code where numeric overflow occurs.)
>
> This also raises the frequently asked question of how RPG defines the
> format of numeric fields.  First, when the format entry is blank for
> numeric fields, the default is packed decimal for standalone fields and
> fields defined on C-Specs and I-Specs that don't have an explicit
> definition on a D-Spec.  For subfields, the default numeric format is
> zoned decimal.  Furthermore, numeric subfields defined in externally
> described data structures are defined using the format defined in the DDS.
>
> What can you do?  First, you could continue to use *LIKE DEFINE to
> define that particular numeric field.  Second, you could look at how
> that particular numeric value is used when passed to the other program.
>   If program B does not change the value of the numeric variable, you
> could pass it as a CONST parameter, and in that case, RPG will convert
> the numeric parameter value to the proper format.
>
> Cheers!  Hans
>
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.