Re: Date performance

Hello Luc (or Brigitte ??) and others,

You are seeing the difference between the number of bytes used internally to 
store the field versus the 
number of character positions required in a buffer to present the field. 

The V3 DDS Reference showed the internal sizes of Date, Time, and Timestamp 
fields.  The V4 manuals show the 
buffer sizes of these fields.

Dates occupy 4 bytes on disk; Times occupy 3 bytes; Timestamps occupy 10 bytes. 
 The buffer sizes for dates 
may be 6, 8, or 10 bytes (depending on format), times are 8 bytes, and 
timestamps are 26 bytes.

The buffer size is used to calculate the record length for a file because that 
is what a program sees.  You 
can dump the file if you want to see the internal record length.

Although the original intent of DSPPFM was to display the unformatted data 
space of a physical file member,
(though DSPPFM was really a by-product of displaying a network file space) the 
date, time, and timestamp data 
types have caused a deviation from that intent.  For usability reasons, the 
positions of data on the screen 
must match the positions indicated by external functions (particularly DSPFFD). 
 Any external functions for 
these new data types show the presentation length instead of the internal 
storage length.  This decision was 
made to ensure that positioning to the offsets described by DSPFFD worked the 
same way on files which have 
these data types (compared with those that don't).

Specific comments embedded in the attached note:

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Microsoft Outlook Express 4.71.1712.3
> Date: Sun, 25 Oct 98 22:06:54 +0100
> From: "Brigitte Caura" <Caura@club.innet.be>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Re: Date performance

> 
> Hi Doug,
> 
> Thanks for the Info.
> Sounds great to me
> (not that in short term we will change a working system, other priorities).
> 
> >So using any L-type date really only occupies 4 bytes of data each --
> >the same as your current 7,0 packed fields (plus it carries the
> >century info at the same time).
> >
> 
> So finally the AS400 does support unsigned packed decimal (at least under
> the cover).
> That is something we have been asking ever since 86
> (since it's indeed the ideal format for storing date fields :-) .

Not really.

> Only, this looks like the work of a lousy programmer: defining something as
> 1 format (4bytes), but showing it as something totally different (10bytes)
> ...
> Secondly, editing is not something that is done on physical files, but on
> output operations, no?

See usability reasoning described above -- nothing to do with the programmer, 
besides, DSPPFM performs an 
output operation when it puts the record on the screen.  Actually database does 
the date/time formatting so 
it is not possible for anything above DB (including DSPPFM) to see the raw 
internal format.

> When i got it right: if I define a PF with p.e. 10 date fields it shows up
> as a file with recordlength of 100, but actually it has a recordlength of
> 40?

No, it may have a record length of 100 because that is what your program sees.  
However, each record will not 
occupy 100 bytes of disk; It may occupy 100 bytes of program storage -- the 
date format affects the buffer 
size.

> Anyway, where does this Info come from?
> The books clearly state a date field occupies 10 characters in storage?

Yes, in *program* storage.

> from theOS 400 DDS Reference V4R2:

------ Stuff snipped ------------

> 
> Note: The system performs arithmetic operations more efficiently for a
> packed decimal than for a zoned decimal data type.

Actually the system doesn't care about packed vs. zoned.  Certain HLL compilers 
(RPG and COBOL) do care 
because they convert non-packed numeric data types to packed before performing 
arithmetic and convert back to 
the original data type afterwards.  That is really a compiler design decision.  
The conversion is the 
efficiency issue.
 
> Has it always been that a date field takes 4 bytes?
> If so, this means we even can't trust the IBM manuals anymore?

Yes, it has always been so (well, since date support was provided) and was 
explained in the manuals and much 
other information at the time.  The current manual is accurate in as much as it 
has been altered to match 
what DSPFFD shows.
 
> Luc
> 

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