Hey guys, has anyone ever come across this error message? "Reporting Server Error - Too many messages" We have a few procedures that run by pulling some financial transaction data for a day or two (which is quite a bit) and it will run successfully, but if we expand the date range out past a certain point, we no longer get results and get the Reporting Server Error message.
Has anyone else ever run across this? Is there a setting somewhere that caps the returned results? I couldn't even find exactly what this error message referenced, so I am kind of in the dark as where to start. Any help would be greatly appreciated!
Thanks again,
LB
**We run 8.1.05M and on a windows OS

This message has been edited. Last edited by: FP Mod Chuck,

Try adding

-SET &ECHO = OFF;

at the beginning of your fex.

It's the first step

This can occur when you have -SET &ECHO=ALL; or when a lot of error messages are generated - typically when data format error messages are generated.

Run the procedure for a day or two. If you're not generating an Excel or PDF file, then you should be able to View Source from your web browser. Look for any error messages. If there aren't any, increase the number of days by 1, try again, until you see errors in the "view source" results...

Okay, good tips so far!
If I put -SET &ECHO = OFF for my first line in the code, I get the following error message, regardless of the date range I put in;
'0 ERROR AT OR NEAR LINE 5 IN PROCEDURE ADHOCRQ FOCEXEC *
(FOC224) SYNTAX ERROR: PROMPT'

Here is part of the underlying code;
1. -SET &ECHO = OFF
2. -PROMPT &START_DTE.Start Date MMDDYYYY:.;
3. -PROMPT &END_DTE.End Date MMDDYYYY:.;
4. -*-PROMPT &DEP_AMT.Minimum Deposit Amount:.,
5. -*-PROMPT &WITH_AMT.Minimum Withdrawal Amount:.,
6. -*-PROMPT &NUM_DEPOSITS.Number of Deposits:.;
7. -*-PROMPT &NUM_WITHDRAWALS.Number of Withdrawals:.;
8. -*-PROMPT &TTL_DEP_AMT.Total Deposit Amount:.;
9. -*-PROMPT &TTL_WITH_AMT.Total Withdrawal Amount:.;
10. -DEFAULT &START_DTE ='0212017';
11. -DEFAULT &END_DTE ='02282017';
12. -DEFAULT &DEP_AMT = 150;
13. -DEFAULT &WITH_AMT = 150;
14. -DEFAULT &NUM_DEPOSITS = 2;
15. -DEFAULT &NUM_WITHDRAWALS = 2;
16. -DEFAULT &TTL_DEP_AMT = 300;
17. -DEFAULT &TTL_WITH_AMT = 300;
18. -SET &START_TRAN_DTE = EDIT(&START_DTE, '$$$$9999') | EDIT(&START_DTE, '99') | EDIT(&START_DTE, '$$99');
19. -SET &END_TRAN_DTE = EDIT(&END_DTE, '$$$$9999') | EDIT(&END_DTE, '99') | EDIT(&END_DTE, '$$99');
20. TABLE FILE A_TRANS_DLY
21. PRINT

The user who wrote this procedure has an output of xlsx open on the first report and then an xlsx close on the second report, I was unsuccessful at getting a final output in html to get the source code. I'd include the entire segment of code, but it's huge and probably not helpful for anyone else to see!

If I comment out the
-*-SET &ECHO = OFF
Then I get successful results with the above date range, file size about 17KB, if I update the date range to 02112017 - 02282017 (one additional day) that's when I am getting the "too many messages" error.

Comment out the ON TABLE PCHOLD FORMAT XLSX OPEN and CLOSE so that you can see the source.

I have worked with WF for ages and have never used -PROMPT. I don't know why you're getting that error. Temporarily comment out these PROMPT commands and add -SET to set your start and end dates.

What's huge about the source code?

-SET &ECHO=OFF; will reduce the output to nothing...

-PROMPT is Mainframe green screen way of populating variables. WebFOCUS uses either HTML launch pages you have to create with App Studio Composer or let it Auto Prompt users to do the same thing. Are you porting this application from Mainframe?

The -SET always needs to end with a ; to end the line

Hence why it is complaining about the next line since it isn't expecting another - command. So there isn't really an error on the -PROMPT.

Also, as Francis said is good to stop before the PCHOLD if still get the message error to see what messages it is adding.

Thank you all for the support, a lot of these options have been really helpful in further troubleshooting this issue.

Here is the base of what error is generating;
On one of the joins within this procedure, it is set to join on an inner one-to-many. This is creating a lot of duplicates, and I think the reporting server can only handle so many of those 'duplicates in join' error messages. I am having our report writer go back and see if we can correct that join with a one-to-one, but still get valid results returned.
I have multiple lines of errors that return something similar to this (at least 100 rows of varying account #'s);
(FOC1072) DUPLICATES IN JOIN 'FROM' FIELD : EMPACCTS/1000020063

We are now focusing on trying to correct that join piece, so if anyone has further suggestions for that, I'll take whatever I can get!

Thanks again for being so responsive to this string!

We may be able to help if you post the join...

Hi LarissaB

My suggestion for using ECHO is to set it to OFF in a PROD environment, but for Development turn on ON, not ALL, unless you have problems tracking down an error.

ON will echo FOCUS commands, not Dialog Manager commands (- commands).

We have a bit of code here that detects which environment and sets the &ECHO appropriately.

You can also use
SET MESSAGE = OFF

I've had to use that when I was creating several thousand files in one report run.

Have a great day,
Emily

quote:

We have a bit of code here that detects which environment and sets the &ECHO appropriately.

You could always use SET DEFECHO = OFF in your Prod environment edasprof.prf.

T

quote:

DEFECHO

That's a new one for me! Thanks.

This message has been edited. Last edited by: Francis Mariani,

Larissa,

There is a setting within the admin console for Maximum Messages - which is normally 20000.

However, I would suggest finding out why you're getting so many messages and eradicate the cause rather than extend the max messages.

Keeping the date range (that fails) in place but limiting the recordset returned (using IF RECORDLIMIT EQ nnn) you may be able to see some of the messages being produced which may help.

T

quote:

DEFECHO

Nice, and useful.

I agree with T. [well, I could just put that line on a t-shirt!]
I up my max messages b/c I've got a big caster jcl , but I made sure there were not unneeded statements in that jcl, like ?FF or CHECK FILE or random -TYPE that I only need during development.

quote:

I could just put that line on a t-shirt!

I hope NOT to see that at summit this year! (you have to understand the context!)

Yes DHagen, that was this years first hint that I will again be presenting at Summit 2017 in Dallas - the unashamed plug will come later Any chance that you will be there? It would be good to catch up.

T

This message has been edited. Last edited by: Tony A,

As for DEFECHO, it's one setting that I suggest to Customers, especially those that have disparate development groups that are geographically separated with different techniques and discipline in removing unnecessary -SET &ECHO = ALL; within their promoted code!

T