fpCGI failure, part 2

[Bruce Easton]

(Inline responses - Bruce Easton, STN, Inc.)

Nancy Palmquist wrote Wednesday, March 19, 2008 2:36 PM:
>
> Tyler wrote:
> > Just in case anyone's still interested in my fpcgi saga, here's
> an update.
> >
> > Adding an entry to the submitted forms for the nohtmlreturn
> field didn't
> > resolve the issue.  There were minor bomb outs (meaning the filepro
> > processing didn't run and no output was produced) throughout testing,
> > but after about 5 days it stopped outputting anything for any report.
> >
> > Working with fptech on the issue, so may have more to follow up with
> > after speaking with them.
> >
>
> Tyler,
>
> I have to say that you are giving fpCGI too much credit.  All it
> does is act as
> a go-between.   It grabs form data send via POST or GET methods
> and writes it to
> a file and then it executes a filePro application passing the
> name of that data
> file, which is responsible to grab the data via an IMPORT of some
> kind.  Process
> the data and generate output.
>
> The output is then dragged back to the Browser that made the request.
>
> It should be very easy to verify if the filePro application ran
> and generated
> output.

True enough - the basic job fpCGI or OneGate should be doing
should not have to be viewed by the person using it as
rocket science.

>
> If it did, it must be where and what the fpCGI was told it would be.
>
> Also, you can tell it to leave the IMPORT file so you can test or
> see what you
> got from the form submit.
>
> Field_removeflat=NO
>
> Since you keep saying you are getting no output, I would suggest that the
> filePro part is not running correctly.
>
> add some lines to do the following:
>
> putenv "LOGFILE", "Somefilename"
> logtext @td<@tm<"Starting my file"
>
> add a few logtext commands at critical places.  I might write the
> filename I
> will be generating, put one at the every end - put one at the
> very beginning.
> See what it posts.

Yeah - that's all good stuff - I find it easier to debug under
OneGate because of the organizational structure imposed by
OneGate.  I can set up testing more quickly and I just seem to
be able to remember set names, etc. which help point me in
the right place to set up tests and check for intermediate
file contents, etc.
>
> I think Mark's suggestion that onegate would solve your problem
> is wrong,

I wouldn't say wrong.  Yes switching tools in mid-stream will
always cost a bit of time.  And yes, there may very well be
problems in your filepro code that will not fix everything until
you fix them, but I would not say considering a switch to
OneGate as wrong.  You should consider what may be good reasons
for doing so besides your current problems, like your possible
AJAX needs or if you see your system security needs being
bumped up in the near future - you might see yourself looking
seriously at OneBridge before too long, so why not think about
these things now while squandering away time trying to get
things working under fpCGI?

> it
> will give you different errors and recovery capabilities.  If you
> are getting
> filePro errors, or not generating any output, or reading the input file
> incorrectly, you will have the same issue with onegate.
>

Agreed.

> I use them both.  They both work.

Agreed BUT only to a degree for me for fpCGI. Let's say after
a ridiculous number of hours trying to get fpCGI working
under IIS and even some Linux issues that could have been
avoided had the documentation been clearer for that platform.
We gave up on the IIS/fpCGI combo, but more importantly you
need to consider the features difference and the ideas I
mentioned above about considering future needs.

Also, I have to say, in the xx (I forget) number of years
of working with the two versions of fpCGI, there was quite
a bit of headache along the way, although I certainly can't
fault anyone for getting it started - something like it was
desperately needed for filepro.  But now, there are still only
two versions?  And I don't know what's shipping now, but
last I checked there still was no accurate documentation
for the IIS or Apache2 - not that I could use - there was
even obvious incorrect pasting of documentation in one version
from the wrong platform.  Just not kept up to date.

I have had virtually no issues with Onegate, and in fact
needed only one enhancement request which was implemented
in surprisingly good time.

So in that light, depending on what may be ahead of you
that might not be a filepro problem, and in consideration
of your future needs, I would give a good look at OneGate
now.

But I do agree with Nancy that you should resolve what
could be obvious filepro programming problems asap.

Bruce

Issues with your report
> generation sounds
> like where the problem can be found.
>
> Nancy
>