After recently upgrading to version 8.5 I have discovered a behavior in using the sort function that is causing me some problems. In version 8.0.3 all was okay, I think.
The problem I'm encountering is when I sort a record that has fields using REFFLD, it is filling in the Field length, data type, and decimal positions where those positions were previously blank so that properties of the referenced field would be in effect.
The values it fills in are correct, but they are causing it to ignore the EDTCDE of the reference field when I was not using one specifically. This is mostly problematic for numeric fields, but I can see it causing problems down the road if the properties of the referenced field change.
Is there a way to turn off this behavior when sorting the fields in a record?
Notice: We have upgraded developerWorks Community to the latest version of IBM Connections. For more information, read our upgrade FAQ.
Re: Issue with sort function in 8.52012-11-02T12:12:49ZThis is the accepted answer. This is the accepted answer.Thought I should mention that this is happening when using the screen designer in design mode and you right click on a field to get the context menu and select sort to sort the source lines by screen position.
Before the sort they look like this:
A YSODTE R O 7 10REFFLD(WYR070S/YSODTE *LIBL/WYP070S) A EDTCDE(Y) After the sort they look like this: A YSODTE R 6S 0 7 10REFFLD(WYR070S/YSODTE *LIBL/WYP070S) A EDTCDE(Y)
I did not enter the "6S 0" or remove the "O", that was done "for me".
It only seems to happen to fields that were actually moved within the sources as a result of the sort.
Re: Issue with sort function in 8.52012-11-06T14:53:05ZThis is the accepted answer. This is the accepted answer.I see that a number of folks have read my post, but the only reply is mine.
Either nobody else is seeing this behavior, or they don't use the sort option, or they don't see it as a problem.
To me, using this sort function should not have an effect on the behavior of the screen. Or on future behavior of the screen. It should do nothing more than shuffle the source lines as expected, not modify the source lines themselves.
The example I presented was perhaps not the best. It actually included an EDTCDE keyword so the effect on the screen was minimal. Both before and after it would be using that same EDTCDE.
In the example that prompted my original post, the screen DDS did not have an EDTCDE keyword, but the field it was referencing DID have one (4 actually). By having it fill in the length and decimal points, it caused the compiled screen to ignore that referenced edit code altogether and fell back to using the default numeric one. Several fields on the screen would no longer accept entry of the decimal point and now had a apace to show the minus sign on the right where before there was no sign.
The other effect of this is that having the length and decimals filled in the screen DDS makes it no longer sensitive to future changes to the underlying referenced field. Instead of just being able to recompile the screen I will have to find and change all occurrences of the field. I would have need to look at affected screens to see if the new length would still fit where it was, the screen length would be already changed and visually I could see what the situation was. Now the screen length will not automatically change, it will continue to use whatever it was when I used the sort command until I manually change it.
Am I the only one who sees these as problems?
Re: Issue with sort function in 8.52012-11-06T15:34:41ZThis is the accepted answer. This is the accepted answer.In other testing I found that having it fill in the length and decimal points also prevents it from using the validation keywords from the referenced field.
This behavior is consistent with what I found in the manual:
When you override some specifications, others are also affected:
- If you specify keyboard shift attribute, field length, or decimal positions for the field you are defining, neither editing nor validity checking keywords are copied from the referenced field.
So the compiler is behaving properly, but the sort function should not be making these changes to the source.
Re: Issue with sort function in 8.52012-11-07T15:01:56ZThis is the accepted answer. This is the accepted answer.Me again. Further research has found similar problems that went unnoticed in production display files that I had used the sort option on before I updated to 8.5, so I'm not sure how long the issue has been present.
Re: Issue with sort function in 8.52012-11-29T17:50:37ZThis is the accepted answer. This is the accepted answer.After upgrading to 8.5.1 I was hoping it may have been fixed, alas the problem is still happening.
Before, note Y7ENDS field is out of sequence, it should be listed before the 'Dyelot' text constant:
A Y7YREQ R O 9 18REFFLD(FIR870/Y7YREQ *LIBL/FIP870) A 9 23 'Cones:' A DSPATR(HI) A 9 37 'Dyelot:' A DSPATR(HI) A Y7ENDS R O 9 30REFFLD(FIR870/Y7ENDS *LIBL/FIP870) A X1DLOT R B 9 45REFFLD(FIR870/Y7DLOT *LIBL/FIP870)
After, Y7ENDS is now where it should be, but has unwanted information filled in:
A Y7YREQ R O 9 18REFFLD(FIR870/Y7YREQ *LIBL/FIP870) A 9 23 'Cones:' A DSPATR(HI) A Y7ENDS R 5S 0 9 30REFFLD(FIR870/Y7ENDS *LIBL/FIP870) A 9 37 'Dyelot:' A DSPATR(HI) A X1DLOT R B 9 45REFFLD(FIR870/Y7DLOT *LIBL/FIP870)
Other lines which did not need to move have not been changed.
I didn't really expect it to be fixed since the issue was not mentioned in the list of stuff that was addressed, but I was hopeful.