Re:

[e.klaasse@xxxxxxxx]

Sender: e.klaasse@xxxxxxxx

Bob,

Thanks for your reply.

In our situation the request is done interactively by the user. During
testing  there is only one request and the As/400 is busy with other tasks.
So i think it can not be a problem of overwriting the previous files.
Besides each request will lead to an unique file name.

It seems that I'am no the only one who has this problem, see the mail of
Aaron Bartell.

Somebody else with a possible solution?

Thanks in advance,

Eric Klaasse




----- Doorgestuurd door Eric Klaasse/Kaert op 26-08-2003 19:18 -----
                                                                                                                                       
                      "Bob Wharton"            Aan:      ftpapi@xxxxxxxxxxxxx                                                          
                      <bobwharton@xxxxx        cc:       ftpapi@xxxxxxxxxxxxx                                                          
                      dLife.com>        Onderwerp:       Re:                                                                           
                      Verzonden door:                                                                                                  
                      owner-ftpapi@xxxx                                                                                                
                      e.ods.net                                                                                                        
                                                                                                                                       
                                                                                                                                       
                      26-08-2003 18:31                                                                                                 
                      Antwoord a.u.b.                                                                                                  
                      aan ftpapi                                                                                                       
                                                                                                                                       
                                                                                                                                       




Sender: "Bob Wharton" <bobwharton@xxxxxxxxxxxxxx>

ftpapi@xxxxxxxxxxxxx writes:
>I use http-url_post  (SSL) for posting a xml-request (stock). The receiver
>sends directly a reply with the current stock of the requested product.
>This xml-file (reply) is written to the IFS.
>
>When the AS/400 is very busy, something strange happens. The XML file on
>the IFS is truncated, so a part of the file is missing. It feels like a
>timeout, but the default of 300 seconds is used and the program ends
>within
>1 minute as if everything is ok. Under normal circumstances the xml-file
>will be received complete.
>
>Is there anybody ho have some suggestions to solve this problem.
>
>I use version 1.6.

Eric,
I had something similar to this with an EPOS interface for a 2,500+ retail
store chain.  But the truncation occurred writing data to a dB2/400 PF;
may be similar to what you're experiencing.

An online monitor would "wake-up" every 15 secs and check if any store
bags were transmitted to the server farm;  if so the online monitor would
then parse/edit check (w/ 300+ business rules) the store bags.  As shifts
ended in the stores across time zones, a "backlog" occur and we'd begin to
see the truncation.

What was going on was the online monitor would kick off the parse, then go
back to sleep.  Then it would wake up, see more store bags, kick off the
parse, then go back to sleep.  We tried increasing the snooze time, but
then store bags would begin to back up and parse/edit check times took
longer and the truncation would still occur.  What I found after some late
night debugging was that the first parsing was not done and was
subsequently overwritten by the second.  The analyst designed the output
from the parser/edit check to go to a single member dB2/400 PF.  I
redesigned it to o/p to a multi-member PF;  simply appended a timestamp
value to a member name prefix (i.e. SBHHMMSS).

HTH!!

Bob Wharton, Jr.
Supervisor - Life Systems Programming
Oxford Life Insurance Company
Information Services
2721 N. Central Avenue
Phoenix, AZ  85004

eMail: BobWharton@xxxxxxxxxxxxxx
vMail: 602.287.7892
  iNet: www.OxfordLife.com

"A good scare is worth more to a man than good advice."

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All communications, information and data contained herein and/or
attached hereto are deemed confidential, privileged and/or proprietary.  It
is not intended for transmission to, or receipt by, anyone other than the
named addressee.  It should not be copied or forwarded to any other
persons.  If you have received this electronic mail transmission in error,
please delete it from your system without copying or forwarding it.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------




-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------