Re: SQL null indicators when not all columns are null capable

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

On May 9, 2010, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

> RPG itself always converts the date value into a character  
> presentation
> depending on the date format either specified in the D- or H-specs  
> (or if
> neither specified it uses ISO) and reconverts it immediately before  
> writing
> into a table. That's why you won't see the binary value even in  
> debugging an
> displaying the Hex-Values and that's why RPG may get an overflow  
> when using
> date formats with a 2 digit year.

Not quite true Birgitta - although it does appear to work this way. It  
is not RPG but the underlying system I/O APIs that make the conversion  
- in other words by the time RPG even sees a record it is already  
converted to character form. It is true that the H-spec etc. have an  
impact - but only in determining what the internal format of a date  
field is. It will be presented in the buffer to RPG in the form that  
it is specified on the DB. The H-spec entry may cause it to be  
reconverted as it is moved from the buffer to the field.

RPG presents to the I/O layer a character string for any date being  
written - it is converted by the system to binary completely separate  
from the RPG routines. RPG in fact has no way to override this  
behavior - SQL goes in lower down and obviously has the ability to  
take the data in raw form.

It is because it is the underlying I/O that does the conversion that  
you always see a character formatted date in DFU, or for that matter  
in COBOL or C which simply map their record buffers directly to the  
system supplied buffer.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com