We are in the process of upgrading from 4.3.6 to 5.3.3 and in a simple test where we had two htmtable holds
table file xxx
print x y z
...on table hold as 'item01' format htmtable
end
table file xxx
print x y z
...on table hold as 'item02' format htmtable
end
-HTMLFORM BEGIN
...
!IBI.FIL.item1;
!IBI.FIL.item2;
...
-HTMLFORM END
we are getting a java error

An error has been detected during server to client data transfer.
ERROR: -12: Pcb2.: java.io.EOFException If I comment out one of the !IBI files it works.

is there a setting on the reporting server or the web server that needs changed to handle this?
We are on Sun Solaris/unix/apache web server against an mvs-scctl reporting server.

Ah, the joys of conversion. Sometimes this error is due to the way the code is now interpretted. For example we query DB2 tables. We had a line
WHERE XYZ EQ 1 OR MISSING, worked fine in 4.3.6
generated a really strange error from DB2 in this case. Had to change it to
WHERE XYZ EQ 1 OR XYZ EQ MISSING and it worked. Check you don't have some focus error that the 4.3.6 let you get away with, but 5.3.x won't.
We even had a problem with &variable names that when decoded has a '1' as the last digit when the next thing on the line was a double quote mark.

I believe IB calls it tightening the code. So check to see if you do have some 'now caught error'.

However one issue that does occur that the just plain left out was in Report Assistant, they did not provide for the 'contains' selection that the 4.3.6 had in it. It's my understanding it isn't in version 7 either.

Mchuss, i don't think you have to put the table name in quotes, but in your example your table names are different from the htmlform tablenames; Could that be the problem?
print x y z
...on table hold as item01 format htmtable
end
table file xxx
print x y z
...on table hold as item02 format htmtable
end
-HTMLFORM BEGIN
...
!IBI.FIL.item01;
!IBI.FIL.item02;
...
-HTMLFORM END

Well, I think equal to Sussanah (Nice name ), the quotes on the holds seems to be a problem, you better quit them.What I dont know is because a Java Error where it souhld be a Focus error The code in 4.3.6 and 5.3.3 works fine:
TABLE FILE CAR<br />PRINT
IF RECORDLIMIT EQ 10<br />ON TABLE
HOLD AS INFORM1 FORMAT HTMTABLE<br />
END<br />-RUN<br /><br />TABLE FILE GGORDER<br />PRINT *<br />IF RECORDLIMIT EQ 10
ON TABLE HOLD AS INFORM2 FORMAT HTMTABLE
END<br />-RUN<br /><br />In html code:

-HTMLFORM BEGIN<br />
!IBI.FIL.INFORM1;<br />!IBI.FIL.INFORM2;
-HTMLFORM END

And there's no error, here a screenshot: <br /><br />Look your code if you wrote everything ok

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

thanks to all who have replied, however...
I cut and pasted the last suggestion that had the table file car and gorders from this forum into a fex and ran it and got the same error message
"An error has been detected during server to client data transfer.
ERROR: -12: Pcb2.: java.io.EOFException "
Now I can comment out either of the two !BI.FIL. lines in the html code and get each one of the reports to display alone...

I tested the code and it works fine with WebFOCUS 7.1. I'm using Tomcat under IIS. I have seen that error message either in some other posts or on tech support. Do a search on tech support for the error message. You might find some useful information.

mchuss
is it possible that one of your tables has multiple choice drilldowns in it?
if so, ON TABLE HOLD AS whatever FORMAT HTML
you can't use format HTMTABLE with multichoice drills. That might cause this prob.
or..
try
<!-- WEBFOCUS TABLE ITEM01 -->
<!-- WEBFOCUS TABLE ITEM02 -->
its the old syntax, but worth a try

Tried the old format as suggested but same results,still get java error. I assume that it is related to a variable setting on the webserver side related to the servlet, which I failed to mention before this, we are converting from CGI to servlet. It appears that when you use the servlet it calls some server side java includes, which at this point aren't handling the second report leaving off some java eof marker. To those who have gotten this to function are you using CGI or servlet?

[QUOTE]Originally posted by Mickey Grackin:
... I'm using Tomcat under IIS. ...
Mickie,
are you using the servlet then with Tomcat? so far my searches of the IB site have been dry, there are similar references to the error I'm getting but under unrelated circumstances.

Yes, I ran it in Servlet mode. Sorry you didn't find anything related to your situation on tech support.

i'm running 533 in servlet on win2003, and i just tested your code in mre and it works fine.
maybe there's something goofy in your -HTMLFORM other than just the tables, some other html code ;
but 534 is out...why not just go right to 4. 3 is really buggy.

well here's a bit of a interesting note I changed the ON TABLE HOLD's to ON TABLE PCHOLD's and both reports displayed, however when I tried to put some comments in the HTML page around the !IBI.FIL's they were stuck under the reports in the browser rather than around the reports so the PCHOLD displayed but not as a !IBI.FIL but more like an ONLINE-FMT HTML display.... To really understand what I'm dealing with here is my hard and soft ware configuration WebFOCUS on HP-UX going through Apache on SunSolaris Unix web server being secured by SITEMINDER passing through TOMCAT on a HP-UX server going against a MVS-SCCTL reporting server on a IBM ZOS.

just thinking again and thought I would update this post. We have continued to have issues with this format. I can maek one of the hold files HTML and one HTMTABLE and they both will display, I can switch who is first and who is second and they both display but when I put two format htmtable in the report they produce this java eof error. any thoughts are welcome my case is in IBI researching status

We are using 5.3.2 on Sun with Apache and Tomcat all on the same box.

Part of our effort is to "convert" 200+ parameter-driven web (html) reports from FOCUS to WebFOCUS (we have used a home-grown cgi here since 1997). Each of these 200+ reports can have up to 3 outputs:

1. --report from FOCUS (rpt1)
2. --standard message confirming an e-mail enclosure sent to the user (rpt2)
3. --chart created on-the-fly using SAS on another server (rpt3).

To mimic our current reports, we have a "standard" output template that can use up to 3 of the .html files that may be produced in a single request.

So we have 3 "!IBI.FIL" statements in the template; each of the 3 components are always named rpt1.htm and/or rpt2.htm and/or rpt3.htm. We always have a rpt1.htm, but the other 2 are user options.

Early testing indicated that we can use all 3 "!IBI.FIL" statements in the template and WebFOCUS would ignore the case where not all 3 .htm files were available.

But now that we're pushing to get all 200 reports converted, the java error has reared its ugly head again.

We are starting to see the dreaded Java io EOFException--sometimes, not always, and usually when the request outputs more than 1 of our components. Five minutes later, everything works fine.

Of course, with our own cgi, we never had this problem, because IBI's java servlet wasn't a black box in the middle of everything.

Since these reports are intended for self-serve, we are using the normal edatemp directories. We have also set AGENT_REFRESH to 1 (instead of the default 100) which seemed to help when we first encountered the java error many months ago.

I do not even want to consider the alternatives that IBI may suggest:

a. write the .htm files to a specific directory in the file system (and figure out how to clean it up at the end of a request)
b. make a tailored template for each kind of report.

If anyone (including IBI) can ever figure out what causes this java exception, I think a great sign of relief would resonate throughout the IBI world.

Bugs are bugs, but I don't want to be the one who has to tell users to try running the request again in half an hour and maybe it will work correctly then.

Suzy

Hi,
We experienced somewhat the same problem not with html tables but graph files
we solved it by putting
-HTMLFORM BEGIN...
....
....

-HTMLFORM BEGIN...
!IBI.FIL.item01;
-HTMLFORM END

-HTMLFORM BEGIN
!IBI.FIL.item02;
-HTMLFORM END
.....
.....

-HTMLFORM END

We work on 5.3.3

Hope it helps

Peter

Thanks Peter--your solution sounds promising. I'll give it a try tomorrow when I get back to work.

Suzy

Hi Peter

I decided to log in from home to try the multiple -HTMLFORM BEGIN/END bookends around !IBI.FIL components of the page and have had marginal success. Some of the failing reports worked, some still gave the java error.

Since 2 of our 3 components may be omitted by the user (user doesn't want to see a chart, for example), we get a "No HTML Output" message when the component isn't chosen. I suppose we could always branch around in the template, based on whether the component has been chosen or not. The template itself in dash INCLUDEd in the fex, and we have a flag in the "home" fex that can be queried, so I'll try this approach.

It does appear, though, that a second !IBI.FIL causes WebFOCUS problems.

Using iframes is not an option because the number of lines of report output varies widely and scroll bars are a hindrance to both viewing and printing.

We just want to reliably get the 3 pieces of simple output that we have been providing our users for the past 8 years.

Any other suggestions greatly appreciated.

Suzy

Suzy, I just wanted to ask if you verified that the files are created when you get this JAVA error. Just wanted to see if the problem is with the !IBI.FIL statements or sooner in the process.

If you decide to go down the route of putting stuff into a temp directory, I have a technique that I use to do this very thing but leverages the WebFOCUS Client automatic clean up of its own temp directory so I don't have to worry about cleaning them up.

Add the following to the WebFOCUS Client SITE.WFS file. I assume the WebFOCUS Client and Server pieces are on the same machine.

<SENDVAR>
IBITMP=&CGI_TEMP_DIR
<ENDSENDVAR>

The CGI_TEMP_DIR variable contains the WebFOCUS Client temp directoy. In my case it is "D:/ibi/WebFOCUS71/temp" being on Win 2k. I then do the following in the application profile focexec on the WebFOCUS Server side to translate the "/" to "\" so that my code works properly.

-SET &IBITMP = CTRAN(&IBITMP.LENGTH,&IBITMP,47,92,'A&IBITMP.LENGTH');


After creating all my files necessary for the report, I using the following command to copy the files to the WebFOCUS temp directory.

-WINNT COPY *.* &IBITMP

In order to then reference these files via a URL in your browser, add a virtual directory to your web server that points to the temp directory for the WebFOCUS Client. I have "IBI_TEMP" pointing to "D:\ibi\WebFOCUS71\temp" so I can get to the files using the URL in my browser similar to the following.

http://www.webserver.com/ibi_temp/filename.

I mainly use this technique for GIF images of graphs.

I think I have found the answers to OUR CURRENT problems that yield the generic Java IO EOFException. In the conversion from FOCUS to WebFOCUS, TABLE statements like:

ON TABLE SET STYLEMODE FIXED
ON TABLE SET STYLESHEET OFF

were placed after a FOOTING statement, and before the actual footing text. This occurred in a couple of programs. In one case, the footing was skipped, based on an input parameter, so it looked as though the request worked part of the time.

In another program, adding a -RUN after several -SET statements far down in the code got the program to work.

Thanks all for listening. I long for the days of FOCUS errors, instead of these generic Java IO EOFException.

Suzy

P.S. Mickey--your scheme for using your own "edatemp" directories sounds intriguing. We may try using it--just so we can track what gets put into the black box.

suzy pete and mickey,
I appreciate you keeping the thread going for me and I've tried the majority of the suggestions as well, We have been informed by IB that there is an issue as well with an APP ENABLED server on MVS that is fixed in the 5.3.4 patch/version. We are investigating that path as a resolution in order to possibly avoid rewriting hundreds of fexs to work around something that should be transparent

UPDATE 5.3.4 appears to have eliminated the issue for us at UP. THe multiple !ibi.fil's are now rendering as expected in the browser for our selfservice apps. with many pages of fixes listed I think it really is a must upgrade from 533.