True, repeated use of the data structure would need a clear or reset (to be in good form - not exactly necessary to clear out a field that isn't used every time).
The reason why I said to make Inz a default via H-Spec was so it was optional, so you (Terry) could have it your way, and I could have it my way. ;) I am curious about when one might want a numeric subfield to be blank. Possibly if you have another alpha subfield overlaying the number and you may want that alpha field to be blank instead of 0. Not something I would do, personally.
I was mainly trying to stress that use of INZ isn't a workaround. It's a valid approach to the situation. Performing a clear is a valid approach as well. I suppose when I responded earlier my viewpoint was restricted to how I perceived RPGLIST was using the data structure. As you noted, we didn't have much to go on.
After I hit the 10-year mark as a RPG programmer, I stopped counting. I no longer want to know how far past being a YIP I've become.
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Terry Nonamaker
Sent: Wednesday, April 10, 2013 12:02 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Strange issue maybe you can help me with Mark
The *inz only applies on the 1st cycle
If the ds is for some reason being cleared for other purposes ....every person has their own logic of how to do things ....and especially if they cleared it with blanks .....then reset would fix it
And, there may be something more going on here .....as we do not necessarily see the whole picture .....despite how it is described
Sometimes, that supposed extra step is worth it
You are correct, that the program using the read, which had the problem ....should only require the *inz ....but I would definitely recommend this on the program that does the write
Also, at the moment I cannot supply the scenario ......but it would not be good to have the *inz of ds's as a default ......I assure you, that will bite you
You may have been doing this for a long time ....but so have I, possibly longer than you ....and I have seen many strange things that just don't seem right
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Wednesday, April 10, 2013 9:15 AM
To: Midrange Systems Technical Discussion
Subject: RE: Strange issue maybe you can help me with Mark
Why require the extra step? I see no reason why putting Inz on the data
structure isn't a valid solution. I see no reason why all data structures shouldn't have Inz on them. In that regard, I'd love an H-spec to force that to happen under the covers. I've never had a need for a data structure's numeric subfield to contain non-numeric values, and have only ever been bit by it.
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Terry Nonamaker
Sent: Wednesday, April 10, 2013 10:53 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Strange issue maybe you can help me with Mark
This may not really have anything to do with your problem
But what you are describing is what happens when you move *blanks into a packed field
So, instead of clearing your data structure field with *blanks ....use the reset opcode ....this should clear things up ....also make sure your field in the ds is defined properly compared to the actual field ........especially if it is an overlay
Again, maybe this does not apply
....but it sure sounds like what used to happen in the old days
TN
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Wednesday, April 10, 2013 8:42 AM
To: Midrange Systems Technical Discussion
Subject: RE: Strange issue maybe you can help me with Mark
I believe his reference to 0404 is not the error given, but what the field contents look like.
In debug, I verified that the contents of the subfield appear to be a slight variation on the hex value (x'40').
D ds_test DS
D subfield 6p 0
SUBFIELD = 040404.
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, April 10, 2013 10:30 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Strange issue maybe you can help me with Mark
If that understanding is correct, then using SQL DDL to create the file being written-to would /fix/ the issue with the "second program that is reading this file" and thus getting an error, and thus would suffice to "avoid this issue" with the 2nd program getting an error ;-)
I am still wondering what a "0404" error is. Seems nobody has ever mentioned "0404" on the RPG list... according to search results. The OP said that "I added a new field", but no mention was made of the data type of the field. Odd how often so little is offered-up about failing scenarios people are having, when they come asking for help :-( And such informative subject lines too; those going to the archives for help on similar issues sure are hopeful they have found an appropriate message thread when they read those titles!
I think Rob's second point was his primary impetus in replying, but I may be wrong about that.
Regards, Chuck
On 10 Apr 2013 07:57, Anderson, Kurt wrote:
If I understand correctly, using DDL would have caused the program to
blow up on the write instead of writing junk. I'm not saying that's
bad, but I will say that doesn't fix the issue he's having.
rob@xxxxxxxxx on Wednesday, April 10, 2013 9:44 AM wrote:
My initial suggestion would be to stop using DDS to define files and
you'll stop getting X'4040' crap into numeric columns. DDL defined
files will stop that, unlike DDS defined files. Failing that, then
take your question to the RPG list for further breakdown.
"RPGLIST" on 04/10/2013 10:22 AM wrote:
<<SNIP>> I have a second program that is reading this file and it's
reading it into a data structure, but it's throwing a 0404 error on
the new field.
I found a workaround of INZ'ng the file when I write but is that
really necessary?
How do I avoid this issue?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
