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



Barbara,

I guess it's the explicit part I'm having trouble with.  To me, I don't see 
where I have explicitly defined anything.  The qualified DS is defined based on 
the physical file and the logical files used in the program are externally 
described without any redefinition in the logical DDS.  Again, taking it's 
definition from the physical file.  If everything is being defined in terms of 
the physical file why are the defined differently in the program?  That's what 
is confusing me.

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx
[mailto:wdsci-l-bounces@xxxxxxxxxxxx]On Behalf Of Barbara Morris
Sent: Thursday, March 02, 2006 2:21 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] Field interpreted differently
betweenphysicalandlogical


Rick.Chevalier@xxxxxxxxxxxxxxx wrote:
> <snip>
> If you don't explicitly define the field with a D spec, the compiler will 
> assign a default definition for the field.
> </snip>
>
> The I spec is created from an externally defined file.  Are you saying I need 
> to go backwards and define the file internally?  That doesn't make any sense.

No, making it program-described wouldn't help.  If you have a zoned
field on a program-described I spec, it would default to being packed in
the program same as an externally-described I spec.

>
> <snip>
> To get all your input fields to be defined internally the same way they are 
> defined in the file, use an externally-described data structure in your 
> calling program:
>    D               e ds                  extname(ISFQE201:ISFQE2R)
> </snip>
>
> How does this fit into the program though?  Is it merely to set the field 
> definitions?  The data structure in the copybook is defined as externally 
> described so aren't I already doing that?

Indeed, the external DS is merely to set the field definitions.  The one
in the copybook is setting a different set of fields (DS.X and DS.Y vs X
and Y).

>
> In reference to Matt's post, is it the QUALIFIED keyword that is causing the 
> problem?  I wanted the DS from the copybook qualified to avoid confusion 
> between actual file fields and DS fields in bound programs that use the 
> copybook for prototypes.
>

I think that was a good decision.  You are right to use QUALIFIED in the
copy file, because of potential conflict with programs it's copied
into.  If a particular program wants to get explicit definitions for the
unqualified names, it should define its own external ds.

This whole external-format vs internal-format is basic to RPG; it's in
RPG II and RPG III too.  Since an I spec doesn't define the field, you
can have the same field appearing on different I specs with different
numeric types:

IFILE1
I              1    5S 0        FIELD1
IFILE2
I              1    3P 0        FIELD1
IFILE3
I              1    2I 0        FIELD1

If FIELD1 is not defined explicitly, it would be packed(5,0) in the
program.  If it was defined explicitly, any of zoned(5,0), packed(5,0)
or integer(5,0) would be valid.


Privileged and Confidential.  This e-mail, and any attachments there to, is 
intended only for use by the addressee(s) named herein and may contain 
privileged or confidential information.  If you have received this e-mail in 
error, please notify me immediately by a return e-mail and delete this e-mail.  
You are hereby notified that any dissemination, distribution or copying of this 
e-mail and/or any attachments thereto, is strictly prohibited.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.