IBM Mainframe Forum

[jazzb1]

Hello, Please look at the following info and see if you can see what I am doing wrong

Fields used in after-break are defined like this:

Select all

DEFINE WS-BUS-DATE      W  10 A      HEADING('BUSINESS' 'DATE    ')   
DEFINE WS-CLM-ISS-A     W  6  P  2   +                               
          HEADING('CLAIM' 'ISSUANCE') +                               
                                     MASK('---,---,--9.99')           
DEFINE WS-CLM-REV-V-A   W  6  P  2 +                                 
          HEADING('CLAIM' 'REVERSAL-VOID') +                         
                                     MASK('---,---,--9.99')           
DEFINE WS-CLM-REV-S-A   W  6  P  2  +                                 
          HEADING('CLAIM' 'REVERSAL-STOP') +                         
                                     MASK('---,---,--9.99')           
DEFINE WS-NET-CLM-A     W  6  P  2  +                                 
          HEADING('NET' 'CLAIM') +                                   
                                     MASK('---,---,--9.99')           
DEFINE WS-LPI-ISS-A     W  6  P  2 +                                 
          HEADING('LPI' 'ISSUANCE') +                                 
                                     MASK('---,---,--9.99')           
DEFINE WS-LPI-REV-V-A   W  6  P  2  HEADING('LPI' 'REVERSAL-VOID') + 
                                     MASK('---,---,--9.99')           
DEFINE WS-LPI-REV-S-A   W  6  P  2  HEADING('LPI' 'REVERSAL-STOP') + 
                                     MASK('---,---,--9.99')           
DEFINE WS-NET-LPI-A     W  6  P  2   HEADING('LPI' 'CLAIM') +         
                                     MASK('---,---,--9.99')           
DEFINE WS2-CLM-ISS-A     W  6  P  2   +                               
          HEADING('CLAIM' 'ISSUANCE') +                               
                                     MASK('---,---,--9.99')           
DEFINE WS2-CLM-REV-V-A   W  6  P  2 +                                 
          HEADING('CLAIM' 'REVERSAL-VOID') +                         
                                     MASK('---,---,--9.99')           
DEFINE WS2-CLM-REV-S-A   W  6  P  2  +                               
          HEADING('CLAIM' 'REVERSAL-STOP') +                         
                                     MASK('---,---,--9.99')           
DEFINE WS2-NET-CLM-A     W  6  P  2  +                               
          HEADING('NET' 'CLAIM') +                                   
                                     MASK('---,---,--9.99')           
DEFINE WS2-LPI-ISS-A     W  6  P  2 +                                 
          HEADING('LPI' 'ISSUANCE') +                                 
                                     MASK('---,---,--9.99')           
DEFINE WS2-LPI-REV-V-A   W  6  P  2  HEADING('LPI' 'REVERSAL-VOID') +
                                     MASK('---,---,--9.99')           
DEFINE WS2-LPI-REV-S-A   W  6  P  2  HEADING('LPI' 'REVERSAL-STOP') +
                                     MASK('---,---,--9.99')           
DEFINE WS2-NET-LPI-A     W  6  P  2   HEADING('LPI' 'CLAIM') +       
                                     MASK('---,---,--9.99')           

After-Break logic says:

Select all

AFTER-BREAK. PROC                                                     
WS-1ST-BEFORE-BREAK-SW = 'N'                                         
IF LEVEL EQ 2                                                         
   IF WS-PFFS-SW = '1'                                               
      IF WS-INDIV-FLD NE 'IVDPPO'                                     
          DISPLAY ' '                                                 
          DISPLAY 'TOTAL NONMG   ' +                                 
                  WS-CLM-ISS-A WS-CLM-REV-V-A WS-CLM-REV-S-A +       
                  WS-NET-CLM-A WS-LPI-ISS-A WS-LPI-REV-V-A +         
                  WS-LPI-REV-S-A WS-NET-LPI-A                         
                                                                     
          DISPLAY ' '                                                 
          DISPLAY '  NON-MEDICARE - INDIVIDUAL'             

When I run this I get a user abend:
IEF450I G396JB GXQD860E - ABEND=S000 U0016 REASON=00000000 173

When I change the after-break logic to display two lines it works:

Select all

   IF WS-PFFS-SW = '1'                                               
      IF WS-INDIV-FLD NE 'IVDPPO'                                     
          DISPLAY ' '                                                 
          DISPLAY 'TOTAL NONMG   '                                   
          DISPLAY WS-CLM-ISS-A WS-CLM-REV-V-A WS-CLM-REV-S-A +       
                       WS-NET-CLM-A WS-LPI-ISS-A WS-LPI-REV-V-A +         
                       WS-LPI-REV-S-A WS-NET-LPI-A                         
                                                                     
          DISPLAY ' '                                                 
          DISPLAY '  NON-MEDICARE - INDIVIDUAL'                       

what is wrong with the original display?

Select all

DISPLAY 'TOTAL NONMG   ' +                                 
                  WS-CLM-ISS-A WS-CLM-REV-V-A WS-CLM-REV-S-A +       
                  WS-NET-CLM-A WS-LPI-ISS-A WS-LPI-REV-V-A +         
                  WS-LPI-REV-S-A WS-NET-LPI-A   

Thanks,
JB

[dick scherrer]

Hello,

The duplicate entry has been deleted and a new topic has been created for your question. When posting a question, a New Topic should be started (rather than posting a reply to some existing topic).

Also, when posting info that needs to be aligned to be easier read, use the "Code" tag - your info has been Code'd. This should be used for code, jcl, data, info from a screen, etc.

There may be more diagnostic info available somewhere in the output. It will help if this is posted.

Which release of Easytrieve is bding used? Does this run access ims or db2 or. . .?

[BillyBoyo]

Is your report SEQUENCED? If so, you are using the system-default sort program. Syncsort puts up lots of U0016's. If in your new AFTER-BREAK you have removed fields which are either defined as "W" or from a file, then they are included in the file which is being sorted for you, to create the sequenced report.

My suggestion, without you having provided the additional information that you have been asked, is that your sort has run out of space, either on the sort work files, or on Easytrieve Plus's "Virtual" file.

A tip. You are using

WS-1ST-BEFORE-BREAK-SW

and

WS-PFFS-SW

in your AFTER-BREAK. PROC

If there is anything that you are calculating or assiging a value in a report procedure, then you should define your data-item as type "S", not "W". When you issue a PRINT in your program, most of the time what ETP does is take each FILE field and each "W" field and puts them all together into a record and writes them to a file (a "VIRTUAL" file) which it will then sort, with system default sort program and then read sequentially to produce the report. Try

Select all

DEFINE W-COUNT W 3 P 0
DEFINE S-COUNT S 3 P 0
W-COUNT = W-COUNT + 1
S-COUNT = S-COUNT + 1
DISPLAY ">" W-COUNT  "<>" S-COUNT "<"

in a report procedure for a sequenced report (or any but the first report in a program producing multiple reports).

The exception to ETP writing to this file, is for the first report in a program and only if that report is not sequenced. Try the above code in that situation and it "works", but it doesn't work really, someone will come along, clone the program, stick on a SEQUENCE and then complain that it doesn't work and all they did is SEQUENCE it. Or even to put another report in front of it.

To repeat, don't try to change the value of a "W" or file field in a report procedure. It isn't doing what you thing. Use an "S" field, it will always work how you imagine.

[Zio69]

To implement BillyBoyo's answer, "W" fields in report have the value they had at the time the PRINT statement occurred, while "S" or static fields are... well, static! So you'd better not mess with them in report procedures, unless your 120% sure what you're doing.

Since you didn't provide the report statement, I'm not sure I can answer your original question, but since it occurs in a DISPLAY in the report (which is surely sequenced, since you're using BREAK procedures) my guess is: you might have exceeded the printline size. Since these are DISPLAYs, not LINE statements, EZT cannot check if what you're displaying fits the LINESIZE. Then, in a sequenced report, whatever you do happens in a SORT exit-routine... which explains the U0016.

The pertinent argument here is LINESIZE in the report statement (if present) or the LINESIZE your system guys defined in the EZOPTBL. If it's a "regular" 132 line, then I'm afraid the single display is too large to fit the line: there are 8 fields (which I assume have the same MASK!!!) with a 14 char MASK and a 14 char literal. So 8 * 14 + 8 blanks (assuming SPACE 1) + 14 = 134... so I guess you may try removing a couple of blanks from the literal.

If you coded the blanks after "NONMG" to adjust the position of the other fields, try:

DISPLAY 'TOTAL NONMG' +
POS 2 WS-CLM-ISS-A +
WS-CLM-REV-V-A WS-CLM-REV-S-A +
WS-NET-CLM-A WS-LPI-ISS-A WS-LPI-REV-V-A +
WS-LPI-REV-S-A WS-NET-LPI-A

Please note: POS can only be used in displays in REPORT procedures, it won't work in "normal" displays

I guess I'm a little late for the party, but let me know if this worked....

[BillyBoyo]

To implement BillyBoyo's answer, "W" fields in report have the value they had at the time the PRINT statement occurred, while "S" or static fields are... well, static! So you'd better not mess with them in report procedures, unless your 120% sure what you're doing.

Put all the following in a little test program, sequenced report. Put them in each report procedure. Look at the results. Then you'll understand the difference between "W" and "S" fields. Very small input data (say three print statements), breaks can be simple, line can be simple.

Select all

These will have a default intial value of zero.

DEFINE W-COUNT W 3 P 0
DEFINE S-COUNT S 3 P 0

Good idea to put in a display of the procedure name, so you can see how it goes.
W-COUNT = W-COUNT + 1
S-COUNT = S-COUNT + 1
DISPLAY ">" W-COUNT  "<>" S-COUNT "<"

Count up the number of times a procedure name was displayed. Look at the last value of S-COUNT displayed, and the last value of W-COUNT displayed, and this will tell you what type of fields you should use if you want to amend fields in an Easytrieve report procedure.

Now take the SEQUENCE statement off the report. Run again. Fun, isn't it.

[Zio69]

Absolutely... but that's exactly how it's meant to be. Or at least that what EZT developers used to say 10-15 years ago.
The main "structural" difference between "straight" and sequenced report is the work file that Easytrieve uses to build sequenced reports, which doesn't exist for non-sorted reports. Since EZT will need to order the output according to the SEQUENCE statements, it will use a work file containing all the fields used on LINE statements. Therefore in the report W fields will contain the value they had at PRINT time, while S fields will contain the last valued assigned at the moment they are PRINTed/DISPLAYed. I'm pretty sure I've got a nice paper that I got at CA-World '95 about this very subject. If there aren't copyright issues, it would be nice to publish it.... to educate young easytrievers

[BillyBoyo]

Absolutely... but that's exactly how it's meant to be.

OK, so what is exactly how it is meant to be? If you do the code I suggested, you will get different answers for the sequenced report than for the non-sequenced report for the W type fields. The S type fields will give you the same answers.

What I am suggesting is that this is not such a good thing. If you have a report that is working, you don't want it to suddely stop working just because you had a requirement to sequence it.

As well, this is just an example to show that W fields behave the way they do. Which is, as you say, when you issue the "PRINT" statement all W and FILE fields are resolved at that point. Type S fields are only resolved when the report is produced. Which leads to my statement that if you want to change anything in a report procedure, you should use an S type field.

Please try out the code and let me know what you see. If W-COUNT and S-COUNT have the same values when you display them, then you are right. If they have different values, then try to explain how it is OK to amend W fields in report procedures.

[Zio69]

I don't need to try it.... I KNOW that what you're saying is true. I'm not questioning that. (besides the client I'm currently working for hasn't got EZT.... )

As I already told you, in REPORTS (and only in reports) W fields have the value they had at the time the PRINT statement occurred. S fields have the value you last put into them. Now, if a report is not SEQUENCED AND it is the only report for the PRINTER then W fields may appear to behave like S fields. But if you send two or more reports to the same output, then you'll see that even if there is no sequencing W fields will be acting "weird". On a general basis, whenever EZT has to resort to a work file for the report, you will see the effect we're talking about.

Before I look up the manuals and paste the section where CA explains this, let's have a "philosophical" look at how EZT works.

Although it may be not common, you can have more than ONE JOB/ONE (set of) REPORT in an EZT program. You may have multiple JOBS, some SORTS, REPORTS and so on. Each one of these is an ACTIVITY. The basic difference between W(orking storage) and S(tatic) fields is: W fields are reset between activities; S fields are not. If you assigned a VALUE to a W field, that's the value it will have at the beginning of the next activity. There's more.... if you code "RESET" after the fields declaration, its value will be reset every time you explicitly/implicitly "go to job".
I.E.
QUANTITY W 3 P 2 VALUE 0 RESET
JOB INPUT ....

every time a new record is read, the variable will be reset to 0.

Now, when you have a sequenced REPORT, that's how it pans out:
1) EZT executes the JOB activity: an EZTRxxxx file is created - records contain the values of ALL fields referenced on LINE / TITLE / SEQUENCE / CONTROL lines.
2) Files involved in the JOB activity are CLOSED
3) REPORT activity is processed (therefore W fields are reset)
4) if SEQUENCE is coded, the report file is sorted
5) Fields are moved back from the report file to their counterparts (both from the files read and W)
6) Line is printed; in case of a "new page" TITLEs / HEADINGs are printed too
Therefore, in a BEFORE-BREAK / AFTER-BREAK procedure, the W field has the value it has in the following/preceeding LINE.

S fields, on the other hand, are initialized only before the first activity, so they keep their value between activities. Which is why they have the value you expect. If you wish, S fields behave like "usual" COBOL Working Storage.

(quoting Easytrieve Plus 6.4 User Manual)

"Static working storage fields are necessary because of the way reports are processed. In the first reading of the “Activity Section: Input and Output” chapter, we describe the PRINT statement and the process that occurs when reports are sequenced (through the SEQUENCE statement) or are multiple in one JOB activity (more than one REPORT statement is used). In both cases, data is output to an intermediary file called a work file or spool file. (See the examples in the “Activity Section: Input and Output” chapter.) Work files do not get formatted into reports (through report definition statements) until they are first sequenced or until the system printer becomes available.
It is due to the use of intermediary work files that a need for two different types of working storage fields arises. To understand the need for these two field types and the differences between them, the following description provides a contrast that sheds light on the use of both.
Static Versus Non-Static
Unlike static working storage fields (type S), non-static working storage fields (type W) are output to work files for every record in the input file. This is done
whenever the non-static working storage field is referenced in a REPORT subactivity. If such a field accumulates values during the processing of an entire file, its value, at the time each record is output to the work file, appears on the record in the work file. If the file is then sequenced, the non-static working storage fields are sequenced with the rest of the fields on the record. This means that accumulated results do not appear, either internally or when printed (if printed), in the order they were accumulated."

[Zio69]

Append....
I managed to install my own copy of EZT Workstation: unfortunately on PC there is no difference between SEQUENCED and "straight" report. However, earlier this morning I forgot to mention one detail which is hinted at in EZT manuals, but is never clearly explained..... EZT will NOT use an intermediary file if there is just one report AND it is not sequenced. Although my work experience stops at rel 6.4, the behaviour you hint at is consistent with that; you can verify this looking at the job statistics in SYSPRINT: when report is sequenced there stats for an EZTR0001 file; when it isn't, there's no EZTRxxxx. That's because, in this peculiar case (and only in this case), EZT prints "live"... without using any work file. This implies that in report procedures you access the "real" variables, not their alter-egos in the work-file.

So, in your example, removing the sequence will cause the W field to retain their values, just like the S field. I understand that it looks inconsistent (it was often mentioned at CA-Worlds), but developers always insisted that one shouldn't use a W field in report procedures for counting/tallying: we should use the facilities provided by EZT (tally, control totals, etc) or use S fields.

I guess you may try and open a support call for that.... but I think you won't go any further than the very first support level. IMHO they will dismiss your case as "by design".

[BillyBoyo]

developers always insisted that one shouldn't use a W field in report procedures for counting/tallying: we should use the facilities provided by EZT (tally, control totals, etc) or use S fields

I don't understand where the confusion arose. I was saying, "if you want to change a field in a report procedure, use an S field, not a W or file field". This is what I'd recommend for any sort of change to a field. If you want a fun effect, change a W field in a "BEFORE-BREAK" , display it, and then display it in an "AFTER-BREAK". I don't know if that still causes a problem, but if it does, it screws up your report in a very subtle way.