Data mapping errors when reading records with time fields…

pts.
Tags:
Application development
DB2 Universal Database
RPGLE
I'm trying to access records from a file that has eight fields defined with the time attibute. When I examine the data held in these fields they are mostly set to *LOVAL i.e. 00.00.00 in *ISO format which according to the RPGLE reference manual is an allowable value. However, when my program attempts to read a record, I get a data mapping error for each of the time fields that has a value of 00.00.00. The error code associated with the mapping error is "An unexpected null field was found.". The program is compiled with ALWNULL(*YES). Can someone please tell me why this is happening and what I need to do to resolve this issue. Many thanks, Jon Gobbett

Answer Wiki

Thanks. We'll let you know when a new response is added.

I had to convert some data from a SQL server data file and using ALWNULL(*YES) would not work. I compiled the program using ALWULL(*USRCTL) and had no problem. Try this and see if it solves your problem.

Discuss This Question: 1  Reply

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Can someone please tell me why this is happening and what I need to do to resolve this issue. Not without seeing field descriptions, field values and related program code and program attributes. For comparison, I'll show a trivial working example. The RPG program:
          *  CRTBNDRPG PGM( mylib/DEMTIME1 )
          *            SRCFILE( mylib/QRPGLESRC )
          *            SRCMBR( DEMTIME1 )
          *            ALWNULL( *YES )
    
         FDemTime   IPE  E             DISK    rename(Demtime:DemTimeR)
         D tm              s               t
         C                   eval      tm  =  t1
         C                   eval      tm  =  t2
         c                   eval      *inlr  = *on
    The program reads a simple table with two TIME columns, t1 and t2. It uses EVAL to copy both t1 and t2 into a D-spec TIME field, tm. The read of the primary file (DemTime) succeeds and both EVALs succeed. The ALWNULL(*YES) compile parm is sufficient to cover both cases. The field descriptions of DemTime are:
     Field Level Information
                  Data        Field  Buffer    Buffer        Field    Column
       Field      Type       Length  Length  Position        Usage    Heading
       C1         BINARY       9  0       4         1        Both     C1
         Default value . . . . . . . . . . . . . . :  None
       T1         TIME            8       8         5        Both     T1
         Time Format . . . . . . . . . . . . . . . :  *ISO
         Coded Character Set Identifier  . . . . . :     37
       T2         TIME            8       8        13        Both     T2
         Time Format . . . . . . . . . . . . . . . :  *ISO
         Allows the null value
         Default value . . . . . . . . . . . . . . :
             *NULL
         Coded Character Set Identifier  . . . . . :     37
    T1 does not allow nulls while T2 does. RUNQRY shows the values as:
     Line   ....+....1....+....2....+....3..
                     C1   T1        T2
     000001           1   00.00.00  -
     ****** ********  End of report  ********
    Even though T1 has the value "00.00.00", it is not null. It was assigned the "00.00.00" value. T2 actually is null, so it shows just a hyphen for the output value. DSPPFM shows the row as:
     *...+....1....+....2
         00.00.0000.00.00
                               ****** END OF DATA ******
    In hex, the row looks like:
     * . . .  + . . .  . 1 . .  . . + .  . . . 2
     00000001 F0F04BF0 F04BF0F0 F0F04BF0 F04BF0F0
                               ****** END OF DATA ******
    The INTEGER value in C1 shows up in hex as the binary value (1). So, both null and non-null times can come into the program and be handled without errors. Why yours is throwing an error can't be determined from a description. The specifications need to be shown. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following