Named Indicators vs. Numbered Indicators

[Scott Klement]

I did not post that in an attempt to upset you, so please accept my apologies.

I was trying to find a clear way of explaining that I was looking for something different. A way that would not be misinterpreted, because I know there was another time when I asked for a simple program to illustrate your point, and you sent us several save files with your whole application. At that time, we simply worked with what you sent. This time, I wanted to find a way to be more clear that I wasn't looking for your application, I was looking just for a simple test case.

I'm sorry that it came across as mean, and I agree that your phrasing was better than mine. Unfortunately, it did not occur to me to phrase it that way. I was just trying to explain what I wanted so that it was clear, and I probably over-explained it.

[DaveLClarkI]

As is often the case -- and is again the situation in this case -- simple test code may work fine but the actual application code does not. If all of the variables present in the actual situation are not replicated in the test case scenario then what you're testing is often more a waste of time and not helping to get any closer to an actual resolution at all.

[Scott Klement]

Yes, that sometimes happens. In that case, I would suggest adding in just enough code to make it fail.

This is a very useful diagnostic, because it focuses in on exactly what's needed to create the problem.

[DaveLClarkI]

Sorry, but I don't have time to play this game. *ON fails in a condition test with PUI named indicators while my iON constant works perfectly. So, I'll go with that. Thanks for your time -- and I mean that sincerely.

[Scott Klement]

Perhaps when you have more time we can pursue this further?

Have a great day!

[DaveLClarkI]

OK, I found the real source of the problem with this (and you might want to file this one away in your memory banks in case it comes up again)...

Somehow the bound field for the "selection field" attribute got changed to a 10-character field instead of being defined as an indicator field (which would be a single-character field in DDS). Apparently, RPG will perform a "correct" comparison of the *ON and *OFF special constants to a single-byte character field but will not compare "correctly" to a multi-byte character field.

Note that I use "correct" and "correctly" only from the standpoint that RPG normally blank pads the shorter field when comparing two character fields and that is why my single-byte constant works where *ON and *OFF don't.

[Scott Klement]

*ON will fill the field with ones, and *OFF will fill the field with zeros. So if you have a 10A field, to compare it against *ON, RPG expects the field to be '1111111111', and *OFF would be '0000000000'.

If the field just contained a single '1' or '0', that would explain why a constant worked but *ON/*OFF did not.

[David]

This is good to know, I was really scratching my head on this one...

[DaveLClarkI]

If the field just contained a single '1' or '0', that would explain why a constant worked but *ON/*OFF did not.

That's the way it came from the Profound UI, yes.

[Scott Klement]

Is it possible that the data type for your 'selection field' is set to "character" instead of "indicator", somehow? If so, then you can change 'selection value' to '1111111111' if you want to compare it to *ON.

If it's indicator, I wonder how it got a definition of 10A? If that's the case, then please provide the display file source code so we can have a look.