Anyone else notice that if you have a HTML Select box with Options from a HOLD file and the number of Options is more than 280, the rest of the options and the rest of the html is all on one line?

This is causing some weird javascript error for me because I have a lot of html after the select box. It happens on Windows and UNIX.

Example below. Run the code and then View Source.


DEFINE FILE CASHFLOW
CAL_DT1/A8YYMD=CASH_DATE;
VAL_DATE/A21=EDIT(CAL_DT1, '9999') | '/' | EDIT(CAL_DT1, '$$$$99') | '/' |
EDIT(CAL_DT1, '$$$$$$99') | '-' | EDIT(CAL_DT1, '9999') | '/' |
EDIT(CAL_DT1, '$$$$99') | '/' | EDIT(CAL_DT1, '$$$$$$99');
SH_DATE/A10 =EDIT(CAL_DT1, '9999') | '/' | EDIT(CAL_DT1, '$$$$99') | '/' |
EDIT(CAL_DT1, '$$$$$$99');
OPT/A60='' | SH_DATE | '';
END
TABLE FILE CASHFLOW
PRINT
OPT
ON TABLE HOLD AS HDAT FORMAT ALPHA
END
-RUN
-HTMLFORM BEGIN



!IBI.FIL.HDAT;



-HTMLFORM END

This message has been edited. Last edited by: <Mabel>,

I ran your code, and every option was on its own line, all the way to the end. This was both in the drop-down box and in the HTML source.
We are on 5.21

Pietro,

Add the first line to the report:
-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=OFF
and it should work as expected.

Regards
Grzegorz

N. Selph, as you found out, this works in WebFOCUS 5.2.1.

Grzegorz, where is this documented, and what does it mean?

quote:

-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=OFF

Grzegorz posted this for a graph error which had the WF_BURST_OUTPUT option... so you can find it there

quote:

If you are using 5.3, there are various new CGI parameters that affects graphing.

You could try for instance add the following line to the beginning of your GRAPH report
-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPUT=OFF
The WF_BURST_OUTPUT set to ON (default setting), caused some of the graphs not being display at all (but only some of them).
There can be other parameters that affects graphing in your case. You can open the web console: http://.../ibi_html/wfconsole.htm, browse through the parameters trying to guess if they can affect your graph, and change their values just for the particular report with -TYPE WEBFOCUS CGIVAR. You can also open the case - IBI support were very responsive and fast solving the WF_BURST_OUTPUT problem .

Hope this (somehow) helps
Grzegorz

Thanks everyone.

My impression is that the IO this parameter is supposed to save on is so slight, that I will change the setting to OFF on the Admin Console instead of adding the setting override to the programs I think will need it.

The parameter doesn't make any sense to me.

According to the Help information from the Admin Console:

WF_BURST_OUTPUT

Enables the WFServlet to send simple HTML reports to the WebFOCUS Client faster. If the request is being redirected, or if it is a complex ODP or OLAP report or a report with frames, this option should be turned off.

It appears if you are creating the options for a drop-down box and there are several hundred values, or if you are creating a graph or an OLAP report then you have to turn the command OFF.

What's left? Simple HTML reports. Why would simple HTML reports need a performance boost?

I conclude that if, upon installation of WebFOCUS 5.3.2, the default is set to ON, and you have reports that use OLAP, create graphs, create large drop-down boxes, none of these will work very well. Why isn't the default OFF?

Yeah it does seem really odd.. you would have thought the performance boost would of been trying to help large requests... although it may be possible that the way it was intended to be used might not be how we think it should be used. At the same time... how much of a performance boost would it actually get in a smaller "simple" html page?


But I agree with you, it should be defaulted off.

I have been following this thread with great interest. At our site, we never change cgivars.wfs; we change site.wfs instead.

Putting:

WF_BURST_OUTPTUT=OFF

into site.wfs and recycling tomcat made no difference

Putting:

-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=OFF

into a fex that gets run before any user code doesn't make any difference.

Putting:

-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=OFF

into a specific focexec that includes the html code to launch the page of pick lists was the only thing that seemed to work.

Do you folks have any more info on how/where we might set this problematic new parameter so that it is always in effect?

Thanks. Suzy

The first question we should all ask is:

Why is the -TYPE command used to alter the WebFOCUS environment?

Just noticed a bad typo throughout all my tests (copy/paste), so I'll go through them again.

Sure hope site.wfs works.

Dear Focal Pointers,

First of all, let me say that, your active participations on this forum are very appreciated.

Nonetheless, the topic title is not quite appropriate. This forum should be mainly for sharing quick tips and techniques. If this is a bug or something really serious, please contact IBI Technical Support and open a case to report the issue. The phone number is 1-800-736-6130, and the website is http://techsupport.informationbuilders.com
If anyone needs help in getting in contact with Tech Support, please let me know or email me.

Pietro - after posting this message, I will change the topic title to something more specific. This will also make it easier for others to search.

To all - Again, your participation on the forum is always highly appreciated, so please keep staying active here!

Cheers,
Kerry

User error here--typos are so embarrassing. I guess bugs are embarrassing, too.

WF_BURST_OUTPUT=OFF

in site.wfs works just fine.

Kerry, it was only after discussing the issue here that it was determined that WF_BURST_OUTPTUT was the cause of what I assumed was a bug.

Suzy, what's the difference between modifying site.wfs rather than cgivars.wfs? Why are there two config files that can have this setting?

And, where is it documented that
-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=OFF
alters the configured setting?

Pietro, it seems that I found a good title for this thread. All right, sharing and discussing among developers are the main targets on this forum, and I'm more than happy to see everyone trying to help each other out.

To all -- please keep that interaction going!

Cheers,

Kerry

Pietro,

We are using servlet on tomcat (unix), so I don't know how this affects other platforms. I read somewhere in the IBI doc that the WF Client first looks at what is in cgivars.wfs, then looks at what is in site.wfs to get its behavior. So, in order to not mess up cgivars.wfs, I chose to put all cgivars-type commands that we wanted to change into site.wfs. That way, we have a history of what is different from the default cgivars.wfs settings.

Tomcat has to be re-cycled to get the new values in site.wfs to take effect.

WRT the -TYPE statement that SENDS COMMANDS TO WEBFOCUS, we have just encountered some endless loop situations in code that we are converting that contains -TYPE. Haven't fully tracked down which statement. Might be just -TYPE (to display a blank line in Focus for Unix), or it might be a -TYPE with a string after it.

In any case, the report request runs, and runs, and runs.... until you kill the session. It appears to branch back to some point in the program and want to run it again.

Haven't been able to repro it yet.

Suzy

Check for dialog manager -GOTO's and duplicate labels.

Not a problem with -TYPE after all (I was too quick to blame the most recent "thing").

The difficulty with this kind of "thing" is that the program has been running for years in FOCUS for Unix, yet it self-destructs in WebFOCUS. We already have a Perl script that "converts" programs to WebFOCUS, based on dissimilarities that we have encountered so far.

Guess we haven't discovered every last wrinkle yet.

Some remarks about -TYPE WEBFOCUS, and WF_BURST_OUTPUT:

1. -TYPE WEBFOCUS CGIVAR variable=value

• -TYPE WEBFOCUS CGIVAR command sets the value of the CGI variable (or "proprietary" WFServlet variable, which act as an equivalent of the *.wfs or CGI setting), which is sent to the WebFOCUS Client (WFServlet) along with the report results. The variable affects the final processing of the report request on the web server site.
  
• The command is convenient in cases when we want to ignore or alter the settings provided by the web server configuration (servlet container, WFServlet *.wfs, etc.) , or sent as the request parameter from the client browser.
  
• The syntax is strange and may be misleading (-TYPE is usually used for debug messages), but the funcionality is valuable.
  
• If memory serves me, I have seen the -TYPE WEBFOCUS CGIVAR syntax within the "Summary of New Features" manual for 4.3.1, so it probably exists in WebFOCUS since that release. There is a mention about the syntax within "Developing Reporting Applications" manual 5.3 (chapter 9.), but it is not explained too much thoroughly.
  

2. WF_BURST_OUTPUT

As Pietro and Leo already posted - the parameter does not make much sense with the currently provided functionality, and should be set to OFF (WF 5.3.2).

I hope that someone from IBI will correct me if the remarks above are wrong

Regards
Grzegorz

Grzegorz

Thanks (again) for your explanation of a function of WF that is initially pretty unusual. I understand the functionality--the method chosen to implement it is just a bit odd. I see how it could be quite useful to temporarily discover the effect of a change, without needing to add it into cgivars.wfs or site.wfs and then recycle tomcat.

With clear explanations like yours, this FOCUS oldie and WebFOCUS newbie may eventually learn how to use this product!

Suzy

After following this discussion, we decided to add:
WF_BURST_OUTPTUT=OFF
into site.wfs.

After following this discussion, we decided to add:
WF_BURST_OUTPTUT=OFF
into site.wfs. It appeared to be a pretty benign change.

Since then, we have been noticing that tomcat runs away more frequently--edging up to using 2 complete CPUs (out of 4) on our sun box when the request should just crash an agent (or end with errors).

So putting:
-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=ON

After following this discussion, we decided to add:
WF_BURST_OUTPTUT=OFF
into site.wfs. It appeared to be a pretty benign change.

Since then, we have been noticing that tomcat runs away more frequently--edging up to using 2 complete CPUs (out of 4) on our sun box when the request should just crash an agent (or end with errors).

So putting:
-TYPE WEBFOCUS CGIVAR WF_BURST_OUTPTUT=ON
into one of these requests that was known to be a runaway, fixed the runaway problem.

The second part of the runaway was to have the "correct" error message output begin to loop, with the server sending more and more duplicate output to IE, causing virtual memory to be depleted and everything to slow to a crawl. The most expedient way we found to correct this was to pull out the ethernet cable to the PC for a minute or so until things calmed down.

Any one seen anything like this before?

Suzy