So what I have working already is to get say 10,000 records from QSYS2.DISPLAY_JOURNAL, then for every record subsequently calling QSYS2.DISPLAY_JOURNAL_ENTRY_INFO, but it is so darn slow. And I already received the 10,000 records and corresponding data anyways, so it will be much more efficient to just parse out the ENTRY_DATA myself and display on a web page in a grid. I just needed the appropriate pointers to where one column ends, and the other begins, which I can now get from QSYS2.SYSCOLUMNS but with some small fixes to the field lengths defined there for a few of the data types (see CASE statement in previous email where I already figured out the adjustments necessary to convert to the actual occupied space in ENTRY_DATA)
-----Original Message-----
From: Rob Berendt <rob@xxxxxxxxx>
Sent: Thursday, October 10, 2019 1:10 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Question on buffer lengths vs SQL reported lengths
I suspect that if you created a table with 100 date columns, and then created a loop which initialized 1,000,000 rows into that table, you would end up with an object size closer to 4 byte columns than 10 byte columns. Not forgetting the additional overhead stored with a table object like descriptions, etc.
But let's assume your problem is that you are trying to create a function like the undocumented view qsys2.journal_view (which you may want to look at) and you need the 10 byte offset, not the 4 byte offset. I believe that SYSCOLUMNS is built off of QADBIFLD. However that uses the 4 byte definition also.
Good luck, or try the journal_view function.
call qsys2.display_journal_entry_info(2, --not sure what 2 means 'journal_library', 'journal name', Sequence_number, 'receiver library', 'receiver name', 'journal code (aka PT, DL, etc)';
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Matt Olson via MIDRANGE-L
Sent: Thursday, October 10, 2019 1:50 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: Matt Olson <Matt.Olson@xxxxxxxx>
Subject: RE: Question on buffer lengths vs SQL reported lengths
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Is there a SQL view that shows the DSPFFD field lengths and buffer lengths? When I pull the actual binary data using DISPLAY_JOURNAL it is infact 10 bytes.
-----Original Message-----
From: Carel <coteijgeler@xxxxxxxxx>
Sent: Thursday, October 10, 2019 12:22 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Question on buffer lengths vs SQL reported lengths
The 4 with SQL is storage size in bytes.
The 10 in DSPFFD is display size in bytes.
Kind regards,
Carel Teijgeler
Op 10-10-2019 om 19:18 schreef Matt Olson via MIDRANGE-L:
Anyone have any ideas why if I do a "select * from qsys2.syscolumns where table_schema='yourschema' and table_name='tablename'" and you look at the STORAGE or LENGTH columns for a DATE field it says "4"
But when you do a DSPFFD against the same file you will see the field length is 10.
I've noticed a discprency on TIME fields as well. Where the
qsys2.syscolumns STORAGE and LENGTH columns say "3", but DSPFFD shows
8
--
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 at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
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
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
