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


  • Subject: Re: Internal numeric variable defined with LIKE Keyword offofexternal files
  • From: "Denis Robitaille" <DRobitaille@xxxxxxxxxxxx>
  • Date: Tue, 07 Dec 1999 17:14:06 -0500

Here is how it works (at least as far as I know):

When you compile a program, it creates an internal buffer to hold the values of 
a file. in that buffer, all numeric are converted to packed if they are not 
already. When you define a variable as like one from a file, the compiler uses 
the variable from the internal buffer, not the file itself, as a model to 
define the new variable. That's why the variable is defined as packed even if 
you based it on a zone variable.

Their is a workaround that we use extensively here. 
- We define an external data structure in the program.
- This data structure is based on the file that we are using.
- We use the PREFIX keyword to diferentiate the data structure fields from the 
file's fields.
- The work variable is defined like the one in the data structure
EX:
...
F myfile ....
...
D             E DS        EXTNAME(myfile) PREFIX(d_)
...
D Workfield       S    LIKE(d_field)
....

This way, workfield is exactly like d_field which is exactly like field in the 
external file.

This work because when you define an external data structure, the internal 
buffer that the compiler creates is exactly the same as the file it is based 
on.(zoned stay zoned, packed stay packed)

I hope this is not too confusing.

Denis Robitaille
Directeur service technique
Cascades Inc
819 363 5187
fax 819 363 5177


>>> <bellis@ORIENTAL.COM> 12/07 2:05 PM >>>


We are running into problems where we define an internal field (PRNM) using the
LIKE keyword over a field defined in an externally described file (ODTRNM).
Below is the D-Spec.
D PRnm            S                   LIKE(ODTRNM)

The field in the file (ODTRNM) is 2,0 Signed.
Below is the results for DSPFFD:
Field      Type       Length  Length  Position
ODTRNM     ZONED        2  0       2        12

The compile listing shows that the internal field  (PRNM) is getting defined as
2,0 Packed.
Below is the results from the compile listing.
PRNM              P(2,0)

However, in the compile listing the field from the external files shows as being
defined as  2,0 Signed in one place and 2,0 P in another.
Below is the results from the compile listing on field ODTRNM.
I                 S   12   13 0ODTRNM
O                 ODTRNM              13S ZONE      2,0
ODTRNM            ZONE      2,0 SIGNED
ODTRNM            P(2,0)

Does anyone have any input on why these field are getting defined with different
types that what they are in the database files?
We have had similar results from fields defined in the files as binary.
Thanks in advance.





+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com 
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.