Problems with C*

, ,
1

Hi,

I am a rookie in Natural (and in English). I have a problem with C*.
In a LDA i have define a PeriodGroup and a multiple Field

C 2 GERUFEN_JOB····················· · ·········· ··························
P 2 GERUFEN_JOB····················· · ·········· ··························
· 3 GERUFEN_TSN····················· A 4 (1:191) /* FIELD IN PE·····
· 3 GERUFEN_SKZ····················· A 1 (1:191) /* FIELD IN PE·····
· 3 GERUFEN_TSA····················· A 1 (1:191) /* FIELD IN PE·····
· 3 ABGERECHNET····················· A 1 (1:191) /* FIELD IN PE·····

C 2 TEST
M 2 TEST···························· A 3 (1:191) /* MU-FIELD·

If i have no values in the periodgroup and in the multiple field, ctest have the value 0, but cgerufen_job have the value 191.
if i have one value for each element in the periodgroup and one value in the multiple field, ctest is 1 but cgerufen_job is 191
Why give c*gerufen_job the bad value

2

Hi Jörg,

Part of this response is simply an educated guess.

First, however, I will presume that if you are a Natural rookie, you are also an Adabas rookie. Therefore, you might not be aware of the significance of “null suppression” as it relates to MUs and PEs.

Lets start with MUs.

  1. you have a null suppressed MU field. you have a view with MU(1:5). You add a record with a value for MU(4) but null values for the rest. Adabas (this all about Adabas, not Natural) will “slide” the fourth occurrence down so it is the first occurrence. When you do a READ, c*MU will be 1, not four.

  2. you have a not null suppressed MU field same view, MU(1:5). You add a record with a value for MU(4) but null values for the rest. Adabas will NOT slide anything anywhere. When you do a READ, c*MU will be 5. The data value will be in MU(4). However, “not null suppressed” means that a null value is as good as any other value. Hence, the null value in the fifth occurrence is as “good” a value as the “real value” in MU(4).

Now PE’s. These are a bit trickier than MUs. There is no such thing as a null suppressed, or not null suppressed, PE. Instead, we will be talking about PEs in which ALL of the fields are null suppressed, versus PEs where at least one field is not null suppressed.

  1. We have a PE group where all the fields are null suppressed. We have a view with PE (1:10). We add a record. There is “real” data for at least one field in PE(3) and PE(5), the rest of the data is null. The c*PE will be 5. As far as Adabas is concerned, trailing occurrences where all the data is null, is not worth considering (that is really what “null suppressed” means). However, leading null occurrences “exist” since with a PE when I say something is in PE(3), it stays there, there is no “sliding” as there would be with an MU. Note that the count of a PE where all the fields are null suppressed, simply tells you that there is data in that occurrence, and no higher.

  2. We have a PE group where at least one field is not null suppressed. Again, we have a view with PE(1:10). We add a record. There is “real” data (meaning non null data) only in PE(3). HOWEVER, since there is a not null suppressed field in the PE, a null value is “real”. Hence the count of the PE will be 10, not 3.

I am attaching an old issue of Inside Natural that deals with this topic in more depth.

steve

Whoops. I cannot find the attach button. must have done a quick reply. will send another response and attach there.

3

Here is the attachment mentioned above

steve
In Vol 15 No 1.pdf (172 KB)

4

Thank you for the information.
I will read the paper and learn.

5

In a paper from the Boston conference 2005 is an example for using periodic-group.
The ADABAS-Definition:

0010 DB: 002 FILE: 004 - MU-PE-PLAY DEFAULT SEQUENCE:
0020 TYPE: ADABAS
0030
0040 T L DB Name F Leng S D
0050 - - – -------------------------------- - ---- - -
0060 M 1 AA MU-NOT-NULL A 3 D
0070 M 1 BB MU-NULL A 3 N D
0080 P 1 CC PE-ONE-NOT-NULL
0090 2 DD NOT-NULL-1 A 3 D
0100 2 EE NOT-NULL-2 A 3 N D
0110 2 FF NOT-NULL-3 A 3 N D
0120 P 1 GG PE-ALL-NULL
0130 2 HH ALL-NULL-1 A 3 N D
0140 2 II ALL-NULL-2 A 3 N D
0150 2 JJ ALL-NULL-3 A 3 N D
0160 DDM OUTPUT TERMINATED

In my project I have also an ADABAS-Definition. This is the part with the periodic group:

PE 1 GERUFEN_JOB AO
2 GERUFEN_TSN A 4.0 AP N
2 GERUFEN_SKZ A 1.0 AQ N
2 GERUFEN_TSA A 1.0 AR N
2 GERUFEN_ABGER A 1.0 AS N

1 GERUFEN_ANZAHL I 2.0 AT

Gerufen_anzahl is not in the periodic group.
My ADABAS-File named acdaten-tgl
and the DDM acdaten-tgl-ddm

In the example is a program, which uses the ADABAS -file.
0010 DEFINE DATA LOCAL
0020 1 CREATER VIEW OF MU-PE-PLAY
0030 2 CPE-ALL-NULL
0040 2 PE-ALL-NULL (1:191) / I changed to 191
0050 3 ALL-NULL-1
0060 3 ALL-NULL-2
0070 3 ALL-NULL-3
0080 1 SHOW VIEW OF MU-PE-PLAY
0090 2 C*PE-ALL-NULL
0100 2 PE-ALL-NULL (1:191)
0110 3 ALL-NULL-1
0120 3 ALL-NULL-2
0130 3 ALL-NULL-3
0140 END-DEFINE
0150 *
0160 INCLUDE AATITLER
0170 INCLUDE AASETCR
0180 *
0190 ***************************
0200 * INITIALIZE PE OCCURRENCES
0210 *
0220 MOVE ‘A2A’ TO CREATER.ALL-NULL-1 (2)
0230 MOVE ‘A3A’ TO CREATER.ALL-NULL-1 (3)
0240 MOVE ‘B2B’ TO CREATER.ALL-NULL-2 (2)
0250 MOVE ‘B3B’ TO CREATER.ALL-NULL-2 (3)
0260 MOVE ‘C2C’ TO CREATER.ALL-NULL-3 (2)
0270 MOVE ‘C3C’ TO CREATER.ALL-NULL-3 (3)
0280 *
0290 CRT. STORE CREATER
0300 *
0310 GETR. GET SHOW *ISN (CRT.)
0320 *
0330 DISPLAY ISN (GETR.) CPE-ALL-NULL PE-ALL-NULL (1:4)
0340 *
0350 BACKOUT TRANSACTION
0360 *
0370 END

The output is

PAGE # 1 DATE: Apr 04, 2005
PROGRAM: PE02 LIBRARY: INSIDE
ISN PE-ALL-NULL PE-ALL-NULL
ALL-NULL-1 ALL-NULL-2 ALL-NULL-3
10 3
A2A B2B C2C
A3A B3B C3C

Important is the value 3 for c*PE-ALL-NULL

In my project I use a LDA. The part with the periodic group:

C 2 GERUFEN_JOB
P 2 GERUFEN_JOB
3 GERUFEN_TSN A 4 (1:191) /* FIELD IN PE
3 GERUFEN_SKZ A 3 (1:191) /* FIELD IN PE
3 GERUFEN_TSA A 3 (1:191) /* FIELD IN PE
3 GERUFEN_ABGER A 3 (1:191) /* FIELD IN PE
2 GERUFEN_ANZAHL I 2

The code in the LDA was generated by Natural with
.V(acdaten-tgl-ddm)

I use the following code:
000030 #ANZAHL_TSN := C*GERUFEN_JOB
000040 WRITE ‘BISHER SIND ’ #ANZAHL_TSN ’ UNTERDATENSäTZE IN DER DB’

But the output is

BISHER SIND 191 UNTERDATENSäTZE IN DER DB•

Can you help me?
Thank you

6

I have a word-document with font corier new for code.
I think, you can better read this.
In a paper from the Boston conference 2005 is an example for using periodic.doc (30 KB)

7

You can also use code-tags for this.
Like that:

[code]This is my code[/code]
8

Hi Jorg

Some questions:

Corresponding to my sample program:

Could we see your code that puts data in the fields of the PE.

The STORE statement

The GET statement

The portion of the View that pertains to the PE

The portion of the FDT that pertains to the PE (or is it just as in your posting)

steve

9

Please add a DISPLAY statement so that we can see the contents of the 191st entry:

WRITE 'BISHER SIND ' #ANZAHL_TSN ' UNTERDATENSäTZE IN DER DB'
DISPLAY GERUFEN_JOB (191)   /* <-- new line
10

I have a for-loop in my program

 
FOR #LAUF 1 to #ANZAHL_TSN 
  WRITE GERUFEN_TSN (#LAUF) 
END-FOR

In the output-file I see 191 empty lines. No char -empty.

In my Project I add values in the periodic group. If I use the program-code, i have nothing make with the periodic group.
The code is in a copytext. By the first use of the copytext, i have the loop and 191 empty lines in the output-file.

(I have a solution for my project. I use a int-variable and count the occurrence self. This is OK. But I am a rookie in Natural, and I will understand why I have this problem)

Jörg

11

Hi Jörg

After the WRITE , as shown in your FOR loop above, could you add , for each of the variables in the PE a Hex edit mask, z.b. ,

WRITE GERUFEN_TSN () (EM=HHHH) GERUFEN_SKZ () (EM=HHH) usw.

Just because you do not see anything in a WRITE does not mean the value is all blanks; it simply could be unprintable characters (H’00’ for example).

Finally, we need to see the information in my earlier post; for example, we need to see where the PE group gets values.

steve

12

Hi,

i have insert:

 WRITE GERUFEN_TSN (*) (EM=HHHH) GERUFEN_SKZ (*) (EM=HHH)

Now i can see 191 Lines with
40404040 40

I think 4 blanks for GERUFEN_TSN and one blank for GERUFEN_SKZ.
Now I musst find, why are the blank into the fields.

Who can this define?

I will post all files and the importend location
The ADABAS-Definition-File: ACDATEN-TGL.txt :Lines 46 - 53
the DDM : ACDATEN-tgl-ddm.txt :Lines 46 - 53
the LDA : ACLDADAT.txt :Lines 21 - 26
the program : ACJOBSP.txt :Lines 129 and 143
the copytext : ACDBUPDJ.txt :Lines all
the outputfile : ACCAUSW.OUT.txt :Lines 50 -271
the Natural-View of Data : ACView_ACDATEN-TGL-DDM

In the copytext is the one and only access of the elemnts of the periodic group.

For the Natural-View of Data I make in Natural the following steps and see.
1 NATURAL - Development Functions
2 VIEWS - Definition, content of NATURAL Views
3 b ACDATEN-TGL-DDM
4 Select BENUTZER und GERUFEN_JOBS

Than I can see “Benutzer” and “GERUFEN_JOBS”
You can see it in the file ACView_ACDATEN-TGL-DDM

But in the Outputfile I see 191 Lines
ACC-ZIP.zip (6.85 KB)

13

I will be busy most of today, so will not get to the attachment until tomorrow.

HOWEVER, something is certainly messed up.

WRITE GERUFEN_TSN () (EM=HHHH) GERUFEN_SKZ () (EM=HHH)

Now i can see 191 Lines with
40404040 40

I think 4 blanks for GERUFEN_TSN and one blank for GERUFEN_SKZ.

BUT GERUFEN_SKZ should be 404040 not just 40 (format is A3)

steve

14

Hi,

no GERUFEN_SKZ is A1, on last week I test with A3 because I think, a field from lenght 1 is not good for “null suppression”. Sorry.

15

null suppression even on a length 1 field can be beneficial: multiple contiguous null suppressed fields are represented by a single null fields count.

There are also reasons to use null suppression on any length of field: if you want the null value omitted from indexes. One example of this: a record is stored or updated with a flag field (called “ATTENTION-NEEDED”) set to “Y” and set to blank (null) when attention is no longer needed. The processing program needs only to read by the flag field as a descriptor (or, more likely, a super-descriptor) and update the flag. With the flag null-suppressed, the record drops off of that index when the flag is set to a null value. This type of processing logic makes it easier to restart a job and efficient to process as only items needing attention are included in the descriptor index.