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