|
CORE_VALUE FOR COLUMN PKCORV DECIMAL(9,2) NOT NULL DEFAULT 0 ,
SHIPPER_NUMBER FOR COLUMN PKSHP# CHAR(9) NOT NULL DEFAULT ' ' ,
receive_date for column rcvdate date,
counter_person_name for column ctrpsnname varchar(20)
allocate(20) not null default ' ')
DSPFFD shows
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
PKCORV PACKED 9 2 5 297 Both Core Value
PKSHP# CHAR 9 9 302 Both Packing
Slip
RCVDATE DATE 10 10 311 Both Receive
Date
CTRPSNNAME CHAR 20 22 321 Both Counter
Person Name
select column_name, ordinal_position, data_type, length, numeric_scale,
storage
from qsys2.syscolumns col
CORE_VALUE 35 DECIMAL 9 2 5
SHIPPER_NUMBER 36 CHAR 9 9
RECEIVE_DATE 37 DATE 4 4
COUNTER_PERSON_NAME 38 VARCHAR 20 22
I'm well aware that Db2 stores a date internally as 4-bytes but surfaces it
outside the DB as 10-bytes.
I expected the ENTRY_DATA blob from DISPLAY_JOURNAL() to be the internal
4-byte format which could then be INTERPRET( as DATE). As pointed out in
the post by Darren, INTERPRET() is documented as expecting 4 bytes for a
date.
https://www.ibm.com/docs/en/i/7.4?topic=functions-interpret
I suspect I'll need to ask IBM ... but I thought I'd throw this out here in
case somebody else has already asked. And to maybe help the next guy.
Charles
On Mon, May 9, 2022 at 1:19 PM Peter Dow<petercdow@xxxxxxxxx> wrote:
Hi Charles,
What are the field definitions for the file whose journal entries you
are looking at? At least the RECEIVE_DATE definition plus the fields
before and after it. What does DSPFFD show for their buffer positions?
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx /
On 5/9/2022 9:53 AM, Charles Wilt wrote:
on a v7.4 box that's reasonably current on PTFs...for a
Using the QSYS2.DISPLAY_JOURNAL() UDTF to look at the journal entries
specific table...--
I expected this to work..
, interpret(substr(entry_data, 297, 5)as DECIMAL(9,2)) as CORE_VALUE
, interpret(substr(entry_data, 302, 9)as CHAR(9)) as SHIPPER_NUMBER
, interpret(substr(entry_data, 311, 4)as DATE) as RECEIVE_DATE
, interpret(substr(entry_data, 315, 22)as VARCHAR(20)) as
COUNTER_PERSON_NAME
However, I get a cast error... looking at the entry data from pos 311 on,
, substr(entry_data, 311) as hmm
I see
F0F0F0F160F0F160F0F100014040404040404040404040404040404040404040
So it seems the date data type is surfaced as a CHAR(10) in ENTRY_DATA as
this works
, interpret(substr(entry_data, 297, 5)as DECIMAL(9,2)) as CORE_VALUE
, interpret(substr(entry_data, 302, 9)as CHAR(9)) as SHIPPER_NUMBER
, interpret(substr(entry_data, 311, 10)as char(10)) as RECEIVE_DATE
, interpret(substr(entry_data, 321, 22)as VARCHAR(20)) as
COUNTER_PERSON_NAME
Am I missing something?
Thanks!
Charles
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email:MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/midrange-l
or email:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/midrange-l.
Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link:https://amazon.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.