Error in Total Report

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi,

My report is showing wrong total. Pls help to resolve this error.

I appreciate it.

dbzTHEdinosauer · Posted: Tue Aug 09, 2011 2:36 pm

what does your input file look like?

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi,

Pls find details of my Input file.

PeterHolland · Posted: Tue Aug 09, 2011 3:06 pm

Good luck Dick.

dbzTHEdinosauer · Posted: Tue Aug 09, 2011 3:35 pm

Thx Peter,

I am not an ezytrieve specialist.
was not even trying to help the TS.
was trying to have the TS supply enough info for someone who could help him.

i am out of this......
should not have entered in the first place.

Anuj Dhawan · Posted: Tue Aug 09, 2011 3:42 pm

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi Anuj,

I did not get what you want to say here.

Could you pls elaborate?

I appreciate it.

Thanks.

dbzTHEdinosauer · Posted: Tue Aug 09, 2011 4:20 pm

ibmmainframe1,

you are doing something during the control break that causes WS-5017-TOT-REJECTED
to be reset to zero.

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi dick,

yes during control break its resetting. I would like to know where I am making mistake.

Thanks.

Bill Woodger · Posted: Tue Aug 09, 2011 5:49 pm

You are SEQUENCEing the report.

The value in your WS-5017-TOT-REJECTED for the record which appears last in sequence.

To put it another way, if you look at the last record printed, you will find that it was the 8th record on your input file.

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi Bill,

Good Catch.

Now I am getting the right total.

However the sequence got changed. Pls let me know how to show the report in the sorted order.

Bill Woodger · Posted: Tue Aug 09, 2011 6:51 pm

OK, 9th record.

What you are effectively doing is adding a sequence number to your report file. The sequence number starts from zero, so sequence number 8 is the 9th record.

There are a number of ways to avoid this, but first you have to understand what has happened.

In your manual, look up how a report file is built when you issue a PRINT. Note especially the important difference between file fields and "W" working storage on the on one hand and "S" working storage on the other.

If you don't fully understand, come back with what you think and we'll get you there.

Bill Woodger · Posted: Tue Aug 09, 2011 6:54 pm

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi Bill,

Thanks for appreciating my suprise answers.

well I did not understand regarding the sequence.

Pls advise. Thanks.

Bill Woodger · Posted: Tue Aug 09, 2011 8:34 pm

Fuller explanation later. Off to the beach now.

For now, define your count as type "S", not "W".

Bill Woodger · Posted: Tue Aug 09, 2011 8:52 pm

Not so easy to organise...

Just to suggest changing the prefix from WS to something else, so that by looking at the name you know if it is W or S field.

I just used W- or S- for prefixes.

Ah... seems we are going, after all...

Bill Woodger · Posted: Wed Aug 10, 2011 4:03 am

When you define an Easytrieve Plus report there is an important difference between different types of data as to how fields are sourced for the report.

Easytrieve has fields from files. It also has two different types of "working storage" fields. Type W and Type S.

Typically, when you issue a PRINT statement, what happens at that point is that Easytrieve creates a file from which it is going to later produce the report (look for references to EZTRxxxx files).

What goes onto the report files are those fields mentioned anywhere in the report, including in report procedures, titles and lines, but only those fields which are file fields, or Type W fields. Type S fields never end up on a report file.

When the report file is processed to produce the report, all references to file fields and Type W fields are sourced from the report file, Type S fields are sourced from "working storage".

If we follow the case of a count, in a Type W field, which is referenced in the report, like in the TERMINATION proc, it goes like this.

All file data refereced in the report is written to the report file. All Type W data reference in the report is written to the report file. So the "total" is written to the report file along with all the other data, but with only its "current" value at that time.

Instead of being a "total" it is effectively a sequence number.

The report file is sorted (according to the SEQUENCE required) and processed, each item from the report, except for Type S, being sourced from the report file.

The "total" printed in the TERMINATION is just the "sequence number" (offset by one, because the PRINT is before the addition) of the record which has turned up last from the sort.

I said "typically" above for the PRINT statement, so exactly when is the report file not used?

If the (physically) first REPORT in the Easytrieve Plus JOB (not JCL) is not sequenced, then that report, and that report alone for that JOB, will not be written to a report file, but will be produced "as you go along". Any subsequent reports in the JOB will be written to report files.

If the (physically) first REPORT in the Easytrieve Plus JOB (not JCL) is sequenced, then that report and all the subsequent reports in the JOB will be written to report files.

What this means is that the only time your current arrangement of code will work is if the REPORT is the first, physically, in the JOB, and if it is not sequenced.

There are many ways around your problem. If you make the field Type S is one of them.

This leads naturally to another point. Don't try to change the value of a Type W field (or file field) in a report procedure. If you need to change the value of something, do it to a Type S. It will "work" most of the time, by which I mean it'll look like it is working. With a Type S field it will always work in a report procedure.

I made two other changes to your total field.

I gave it 0 decimal places. This is how to get a signed number in Easytrieve Plus (search the forum/look at the manual for more details).

I also took off your initial VALUE statement. Easytrieve Plus initialises fields in "working storage". Numerics to zero, alphanumerics to space. You should decide for your site standards whether to code the VALUE anyway, but it is not necessary (so, to me, confusing when done).

ibmmainframe1 · New User Joined: 26 Jul 2005 Posts: 64 Location: India

Hi Bill,

Amazing. Taking such a pain in giving this elaborate explanation.

I really appreciate it.

Bill Woodger · Posted: Wed Aug 10, 2011 2:50 pm

No problem.

It is a very common error. I feel it is a deficiency in the manual, as it is not set out clearly enough.

Now it is here, it should cut down on the repeat questions.

dick scherrer · Posted: Wed Aug 10, 2011 3:37 pm

Hi Bill,

Bill Woodger · Posted: Wed Aug 10, 2011 3:44 pm

Hi Dick,

Yes, you are probably right. Cut down on the repeat answers, then. We just moan about them not searching, not Coding, and post the link :-)

dick scherrer · Posted: Wed Aug 10, 2011 3:54 pm

Hi Bill,

Unless the searcher thinks using the same words as the original topic(s), they will be frustrated even if they do try to search. We have a very significant lack of communication.

Helping people learn how to search would probably be quite valuable to many.

I guess i don't really mind the "same" question most of the time. . .

d

Bill Woodger · Posted: Wed Aug 10, 2011 4:15 pm

Hi Dick,

Yes, to an extent - but we are "lucky" with the "little" things that someone can potentially work out how to list all Easytrieve stuff and look at a reasonable amount of it. Similar with other products outside the "volume" queries.

I was also thinking of your regular comment that "it might help someone else some day". There do seem to be many people who come here, judging by the number of guests who far outweigh members who are ever logged-on at the time, so hopefully, somehow, others are getting something from all this.

I'm not even sure the search is working properly, judging by my attempts over the last few weeks. I end up browsing anyway.

dick scherrer · Posted: Thu Aug 11, 2011 12:07 am

Hi Bill,

lee_issc · New User Joined: 11 Dec 2008 Posts: 33 Location: China

thanks Bill Woodger. It works.

You will explain now,right?