ga wrote:
> ...
> One option obviously would be to rewrite the rpg II program into RPG
> IV or something else that can handle null date fields. It's weird
> though because you would think, since RPG II has the fields program
> defined, and this is not even included, it wouldn't cause a problem???
>

The data mapping error happens at the database level; the database
doesn't know anything about the program-described RPG II fields.

> The temporary workaround was to create a logical file and only specify
> the key fields and the field we need to reference, and change the
> program to chain to that file. That resolved the problem, but wonder
> if anyone knows a way to work around the issue in rpg II?????

There isn't any way to work around this in RPG II; even the primitive
"tolerate null-values" support that RPG/400 has was never added to the
RPG II compiler.

If you don't want to convert the entire RPG II program to RPG III or IV,
you might be able to offload the reading of that particular file to
another program; where your program reads the file, have it call an RPG
IV program instead. But that would probably be a more intrusive change
than the one you have already done with the logical file.

il 31/07/2007 18.38, Scrive ga 38277048:
> Yes, you read it right.
>
> We have some custom code we use to read/chain data of some dds files.
> One of the files now has a date field in *ISO format (0001-01-01) with
> some null values.
>
> These programs were written using rpg II. With a new release of the
> vendor software they added the *ISO date field. We recompiled the RPG
> II program but we get a mapping data field error RPG 9998 when we run
> the program, even though that field isn't referenced in the rpg II
> program.
>
> One option obviously would be to rewrite the rpg II program into RPG
> IV or something else that can handle null date fields. It's weird
> though because you would think, since RPG II has the fields program
> defined, and this is not even included, it wouldn't cause a problem???
>
> The temporary workaround was to create a logical file and only specify
> the key fields and the field we need to reference, and change the
> program to chain to that file. That resolved the problem, but wonder
> if anyone knows a way to work around the issue in rpg II?????
>
> thanks,
> ga
> ga
> nospam@nospam.fmctc.com
In rpgiii to make DATE fields available to the program as character
fields you have to CRTRPGPGM CVTOPT(*DATETIME) ALWNULL(*YES) but I do
not know if the same options are available for s36 too.

--
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

The "temporary workaround" of using a logical file is IMO *the*
appropriate "permanent solution" to avoid having to use a /newer/
language that can appropriately process the /newer/ database features.
If the permanent object is an issue for the relationship [LF and PF],
then instead create only a physical file [as part of the app, but not a
relation] to be used on the FORMAT parameter of an OPNQRYF, and have the
program refer to the open query file ODP [open data path] by use of a
shared open.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer

ga wrote:
> Yes, you read it right.
>
> We have some custom code we use to read/chain data of some dds files.
> One of the files now has a date field in *ISO format (0001-01-01) with
> some null values.
>
> These programs were written using rpg II. With a new release of the
> vendor software they added the *ISO date field. We recompiled the RPG
> II program but we get a mapping data field error RPG 9998 when we run
> the program, even though that field isn't referenced in the rpg II
> program.
>
> One option obviously would be to rewrite the rpg II program into RPG
> IV or something else that can handle null date fields. It's weird
> though because you would think, since RPG II has the fields program
> defined, and this is not even included, it wouldn't cause a problem???
>
> The temporary workaround was to create a logical file and only specify
> the key fields and the field we need to reference, and change the
> program to chain to that file. That resolved the problem, but wonder
> if anyone knows a way to work around the issue in rpg II?????

On Jul 31, 3:06 pm, CRPence wrote:
> The "temporary workaround" of using a logical file is IMO *the*
> appropriate "permanent solution" to avoid having to use a /newer/
> language that can appropriately process the /newer/ database features.
> If the permanent object is an issue for the relationship [LF and PF],
> then instead create only a physical file [as part of the app, but not a
> relation] to be used on the FORMAT parameter of an OPNQRYF, and have the
> program refer to the open query file ODP [open data path] by use of a
> shared open.
>
> Regards, Chuck
> --
> All comments provided "as is" with no warranties of any kind
> whatsoever and may not represent positions, strategies, nor views of my
> employer
>
>
>
> ga wrote:
> > Yes, you read it right.
>
> > We have some custom code we use to read/chain data of some dds files.
> > One of the files now has a date field in *ISO format (0001-01-01) with
> > some null values.
>
> > These programs were written using rpg II. With a new release of the
> > vendor software they added the *ISO date field. We recompiled the RPG
> > II program but we get a mapping data field error RPG 9998 when we run
> > the program, even though that field isn't referenced in the rpg II
> > program.
>
> > One option obviously would be to rewrite the rpg II program into RPG
> > IV or something else that can handle null date fields. It's weird
> > though because you would think, since RPG II has the fields program
> > defined, and this is not even included, it wouldn't cause a problem???
>
> > The temporary workaround was to create a logical file and only specify
> > the key fields and the field we need to reference, and change the
> > program to chain to that file. That resolved the problem, but wonder
> > if anyone knows a way to work around the issue in rpg II?????- Hide quoted text -
>
> - Show quoted text -

An easy solution would be to run cvtrpgsrc to convert it to ILE and
recompile with no changes.

il 01/08/2007 20.05, Scrive Alida0731@aol.com 36782424:
> On Jul 31, 3:06 pm, CRPence wrote:
>> The "temporary workaround" of using a logical file is IMO *the*
>> appropriate "permanent solution" to avoid having to use a /newer/
>> language that can appropriately process the /newer/ database features.
>> If the permanent object is an issue for the relationship [LF and PF],
>> then instead create only a physical file [as part of the app, but not a
>> relation] to be used on the FORMAT parameter of an OPNQRYF, and have the
>> program refer to the open query file ODP [open data path] by use of a
>> shared open.
>>
>> Regards, Chuck
>> --
>> All comments provided "as is" with no warranties of any kind
>> whatsoever and may not represent positions, strategies, nor views of my
>> employer
>>
>>
>>
>> ga wrote:
>>> Yes, you read it right.
>>> We have some custom code we use to read/chain data of some dds files.
>>> One of the files now has a date field in *ISO format (0001-01-01) with
>>> some null values.
>>> These programs were written using rpg II. With a new release of the
>>> vendor software they added the *ISO date field. We recompiled the RPG
>>> II program but we get a mapping data field error RPG 9998 when we run
>>> the program, even though that field isn't referenced in the rpg II
>>> program.
>>> One option obviously would be to rewrite the rpg II program into RPG
>>> IV or something else that can handle null date fields. It's weird
>>> though because you would think, since RPG II has the fields program
>>> defined, and this is not even included, it wouldn't cause a problem???
>>> The temporary workaround was to create a logical file and only specify
>>> the key fields and the field we need to reference, and change the
>>> program to chain to that file. That resolved the problem, but wonder
>>> if anyone knows a way to work around the issue in rpg II?????- Hide quoted text -
>> - Show quoted text -
>
> An easy solution would be to run cvtrpgsrc to convert it to ILE and
> recompile with no changes.
>
I was aware that cvtrpgsrc converts rpgiii-like (rpg400 too) specs to
rpgiv not rpgii, to covert rpgii I remind that SS1 option 4 (migration
utilities) was needed, isnt't?

--
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

That is correct about CVTRPGSRC. I wrote a utility many years ago
that converted RPG-II to RPG-III (and have since lost) and several 3rd
party products are out there. However, for a single program, its not
that hard. There are a few places where you may have to use a format
name instead of a file name, but for the most part the syntax and
spacing is the same when using pgm-described files. The just run the
CVTRPGSRC to get it in RPG-IV.

The other option is to change the file to NOT allow nulls in this
field, using *LOVAL (0001-01-01) when the field would otherwise be
null.