Question about BIS aborting due to invalid numeric data

Using BIS 9.1 under Windows, using a standard BREAD function, if the client attempts to add a record and includes invalid data in a numeric field, the BIS process aborts with an error.  Since we will (or hope to) allow third-party apps from our customers to access certain web services, it would be better (more graceful) if we handled invalid data within our program, and returned a meaningful message to the client.  However, the current behaviour causes BIS to raise an error (a generic one) and doesn't even call our BREAD program.

Is there any way for BIS to allow our program to do the validation?



  • Tony,

    In general, the answer to your question is that BIS is just a transport mechanism, and doesn't care that much about the contents of the payload that it is delivering.  So, I agree that your program should be performing the validation.  What is most likely happening is that the style sheet that is transforming the payload for storage into your COBOL program specifies that the element is numeric, and thus the transformation fails, but that is a guess on my part.  I would need to see a complete example, or a copy of the error message that you get back.

    Let's start with a BIS trace file containing the error and send it to us?  If you don't know how to turn on tracing, I can get you in contact with someone to assist you.  Hmmm, I don't see a way to attach a file to this conversation, so if the trace log is small, just insert it into your reply.

  • The attached archive contains a modified version of the XBIS Sample 4 program that demonstrates how you could return a response that reports an invalid
  • Thanks for the reply - I have yet to try it, but hopefully this week.

    On a slightly separate note - we're continuing to test our web services, with web pages on different browsers, etc - we find that when we try to access the same service from multiple computers, we encounter error 403, access forbidden.  Is this just a limitation with number of concurrent users on the version of BIS installed using the development system?  (The error occurs on different computers, and seems to be on the second and subsequent computers that access the service).  The web pages render okay, the failure is when accessing our login service.  We don't see this issue when we use SOAP from multiple computers to test the service, however...........

  • The BIS trace should indicate exactly what happened.  BIS itself doesn’t impose a limit on concurrent users, but the COBOL runtime does.  BIS for Windows attempts to return a 500.13 (Server too Busy) but the error path is complicated and it could turn into something else. Regardless, if this is the problem, on Windows the BIS trace should contain a line like this:

     Use count exceeded (10 of 10): throwing "server too busy" exception!

    How many users is your runtime licensed for?

  • There actually is no trace file generated by BIS when I get this error - at first I thought it was being generated by ISS, but the web form does appear fine - only when we click the login button, which invokes a call to our login.srf script, which in turn launches login.acu, do we get the error 403.  

    The developer runtime is a 4-user, and the GT runtime a 5-user, we get the error on the second attempt to access (regardless of the sequence of connecting with different computers).

  • A couple of other questions .. what type of server is BIS running on (Windows or Unix) .. is the web service running in a LAN or is it running in a WAN .. as the WAN type of implementation uses an additional type of runtime license.

  • I didn't notice IIS till now, so this is on Windows. If there is no trace file then the request is not reaching BIS.  

    Does the “login.srf” file contain a {{Trace(ON,FILE)}} tag?  If so, the web services request issued by the “login” button should produce a trace file.  That should show if it’s launching login.acu, if there’s a licensing problem (or an I/O error).

    If no trace file appears, then the request is not reaching BIS.  Is it possible the login button is broken or pointing at the wrong URL?  

    If there is not an obvious problem with the login button, I suggest looking at the IIS log file and see if the request is even reaching IIS.

    A 403/forbidden error can also be produced if the login.srf file is inaccessible due to permissions, or if there is a configuration problem in that virtual directory that is preventing the login.srf file from being served (for example, no association between .SRF files and BISISAPI.DLL in that virtual directory).