× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.