|
Michael,
D Year DS Qualified Dim(2) Inz D Location LikeDS(Variables) DIM(4) Inz
I find it confusing when you specify that the same fields should be initialized over and over again. I find it less confusing if you only tell it how to initialize the fields in one place!
The above definition tells it to initialize the fields twice, once on the "whole DS" level, and then again on the subfield level. Which one takes precedence? It's confusing. Instead, do this:
D Year DS Qualified Dim(2) D Location LikeDS(Variables) DIM(4) D INZ(*LIKEDS)Notice there's only one INZ statement. Since LOCATION is the only field in the DS, the one INZ statement applies to everything. Also, instead of saying "initialize to blanks or zeroes" I told it to initialize it to the value of the DS that it comes from. That way you don't have to initialize it separately here from in the Variables DS.
Speaking of the Variables DS... you did the same thing. You told it in TWO places to initialize it, both at the "all-ds" level, and on each individual field:
D Variables DS Qualified Inz D Terms Like(HTOTOT) Inz D ServiceA Like(HTOSVA) Inz D ServiceB Like(HTOSVB) Inz D ServiceC Like(HTOSVC) Inz D ServiceD Like(HTOSVD) Inz D ServiceE Like(HTOSVE) Inz D ServiceH Like(HTOSVH) Inz D FTTerms Like(HTOFT) Inz D PBTerms Like(HTOPB) Inz D PTTerms Like(HTOPT) Inz D Active Like(HTOACT) Inz D FTActive Like(HTOAFT) Inz D PBActive Like(HTOAPB) Inz D PTActive Like(HTOAPT) Inz D TOP 4 1 Inz D TOPB 4 1 Inz D FTTOP 4 1 Inz D PBTOP 4 1 Inz D PTTOP 4 1 Inz D UMAMT 17 2 Inz
This drives me nuts. Instead, unless each subfield is to be initialized differently (like if some are to have values other than blanks or zeroes) just tell it once:
D Variables DS Qualified Inz D Terms Like(HTOTOT) D ServiceA Like(HTOSVA) D ServiceB Like(HTOSVB) D ServiceC Like(HTOSVC) D ServiceD Like(HTOSVD) D ServiceE Like(HTOSVE) D ServiceH Like(HTOSVH) D FTTerms Like(HTOFT) D PBTerms Like(HTOPB) D PTTerms Like(HTOPT) D Active Like(HTOACT) D FTActive Like(HTOAFT) D PBActive Like(HTOAPB) D PTActive Like(HTOAPT) D TOP 4 1 D TOPB 4 1 D FTTOP 4 1 D PBTOP 4 1 D PTTOP 4 1 D UMAMT 17 2I think that's just much cleaner, because you've only specified one initialization for every subfield (by specifying INZ at the DS level, you tell it to initialize every subfield to it's default value of either blanks or zeroes.)
Specifying it in two places is just confusing. Then, to make matters worse, you also specify it in the calcs!
Year(TY).Location(Unit) = *Zeros; Year(LY).Location(Unit) = *Zeros;
That's nice -- and it'll work, provided everything in the DS is a zoned decimal field. But if you have any packed fields (for example, those that you're using external definitions on might be packed) then you'll have a mess because packed values can't have x'F0F0F0F0' in them. Why initialize it a 3rd time? Just use the INZ from the D-spec to initialize it!
The more complicated you make your code, the harder it is to determine why it's not working.
midrange.com
Year(TY).Location(Unit).Terms += HTOTOT; // Errors Here
Is it possible that HTOTOT is defined as a packed field in the database? This would give you a DDE for sure because you just set it to x'F0F0F0F0' which isn't a valid packed value.
When it gets to this point, I get the error. Trying to Add HTOTOT to blanks. Can you see what I'm missing? I thought on the very first line, I set everything to *Zeros. NOTE: that I also tried changing that to *ALL'0'
*ALL'0' does exactly the same thing as *Zeros, so I dont see how that'd help. Just use INZ on the D-spec, don't try setting the whole thing to *Zeros, that only makes the problem harder to spot.
Run the program in debug, type
eval Years:x
to see the hex values for the fields. When the calc specs start, the
zoned fields should be x'F0F0F0F0', the packed fields should be x'000000F'
and the character fields should be x'40404040'.
As an Amazon Associate we earn from qualifying purchases.
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.
