It's been a while since I've seen this one. IIRC in our case it was actually
a problem with the data, there were control characters or something in it.
The other problem I just ran across Monday was a non-SB program (through a
number of twists and turns) calling a program that made a veiled reference
to one of the SB+ common variables - which weren't set when called from
outside - but were when I ran my test routine.... It was looking at
something in a dimensioned array which was coming across as 0 instead of "".
In my case it was using the variable to determine the mv position and the 0
was pulling back the whole attribute instead of just the correct mv.

You may also want to check your SB+ files.opened variables.

Good luck
Colin Alfke
Calgary, Canada

-----Original Message-----
From: Israel, John R.

The new stand-alone program is truly a program.  It loops through the
records, and for each record, populates the arguments as if it were called
via the subroutine behind the web page, then calls the shared subroutine.

I don't think it would be hitting the MAX_OPEN_FILE limit, though that is a
thought.  How would I actually capture the number of files that are open?  I
could throw a CRT into my stand-along program if I know that info.

This thing is so obscure that I am not even sure what program is doing the
calling to SB.PROCESS, though obviously it must be somewhere in the chain of
subroutines called in the SB account.  It works fine for 1500+ records
before blowing up.


John Israel
Senior Programmer/Analyst
Dayton Superior Corporation
1125 Byers Road
Miamisburg, OH  45342


-----Original Message-----
From: Israel, John R.

Let me answer this way: my new stand-alone program selects all the parts,
loops through them, and for each part, calls the same subroutines that the
web site does (thus ensuring that I am running the same logic).  One of
these subroutines calls another subroutine that "lives" in an SB account.
It obviously is not a common condition because we just recently encountered
this problem for the first time.  My new stand-alone program gets about 1500
records into the loop before hitting the error below (which is NOT the error
I was actually trying to solve).


John Israel

-----Original Message-----
From: Dave Davis

Does the web side make use of SB+ at all?  Through a derived field or
indexed field or trigger?  If you can, I would step through all the files in
the /FC table to make sure they can be opened.  This may not be a complete
list of the files the app opens but it would be a place to start.  Is the
web interface run through the same account as the SB+ side?  If not, are all
those files in the other account's VOC?

-----Original Message-----
From: Israel, John R.

We are using Avanté w/ SB and a web interface for customers.

On rare occasions, a web page is blowing up due to an error that is cleanly
detected in Avanté/SB, but that the web side is clueless about.  I am
working on a pro-active program to detect these conditions, but after a
while, it is blowing up with the following:

In /usr/igi/sb54/SB.DEFN/DM/_SB.PROCESS at line 76 Can not access unopened
file.
  File variable not used in file operation
In /usr/igi/sb54/SB.DEFN/DM/_SB.PROCESS at line 76 Fatal error: READ error

Obviously I do not have the source code for SB, so I can not see what file
it trying to access.  Does anyone have a clue as to what I need to open
OUTSIDE of SB so that I can call SB.PROCESS?

John Israel


_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to