Thanks for the reply Tony.

Tigerlogic are looking into the problem but it seems that it is more
easily replicated than I had first thought (a depth of 4 subroutine
calls).

I hit the same error again with a 'simple' single call from a mainline
program.

After further investigation and a little tweaking, I have come to the
conclusion that the issue is to do with the NUMBER of calls to the
subroutine and not the complexity of the subroutine.

Unfortunately for me, I will now have to postpone the upgrade until I
have tested all the 'major' processing programs on the system. This
just isn't 'fun' anymore, especially since the programs ran fine under
version 7.3.6.

I have pared down my samples and the following code will reproduce the
error :

Main program :

NH1
*
* Test for large number of subroutine calls to see
* if it will create ERRMSG 33
*
$INCLUDE INCLUDE-FILE COST-TYPE-TABLE (Just does a dim, equate and
open of this file)
MATREAD COST.TYPE.TABLE.ITEM FROM COST.TYPE.TABLE.FILE, "E" END ELSE
MAT COST.TYPE.TABLE.ITEM = ''

FOR I = 1 TO 17500
CALL NH2(MAT COST.TYPE.TABLE.ITEM)
NEXT I

NH2

SUBROUTINE NH2(MAT COST.TYPE.TABLE.ITEM)
*
$INCLUDE INCLUDE-FILE STD.EQUATES
*
$INCLUDE INCLUDE-FILE COST.TYPE.TABLE.DIM
$INCLUDE INCLUDE-FILE COST.TYPE.TABLE.EQUATE
*
*****************
RETURN

The includes are :

STD.EQUATES

$OPTIONS EXT
PROMPT ""
*
EQU TRUE TO 1
EQU FALSE TO 0
*
$INCLUDE INCLUDE-FILE D3.SCREEN.EQUATES
$INCLUDE INCLUDE-FILE D3.SPOOLER.EQUATES
*
EQU ATTRIBUTE.MARK TO CHAR(254)
EQU VALUE.MARK TO CHAR(253)
EQU SUB.VALUE.MARK TO CHAR(252)
*
EQUATE AM TO CHAR(254)
EQUATE VM TO CHAR(253)
EQUATE SVM TO CHAR(252)
*
* GET.INPUT RETURN STATUS DEFINITIONS:
*
EQU NORMAL TO 1
EQU PREVIOUS.FIELD TO 2
EQU CANCEL TO 3
EQU LIST TO 4
EQU REPAINT TO 5
STATUS = "No help available"
*
PORT.NUMBER = OCONV("","U50BB")
PORT.NUMBER.ACCOUNT = FIELD(PORT.NUMBER,' ',2)
PORT.NUMBER = FIELD(PORT.NUMBER,' ',1)
PORT.NUMBER.USER = @USER
PROC_PORT_NUMBER = PORT.NUMBER ; *GJ
IF PROC_PORT_NUMBER LT 10 THEN ; *GJ
PROC_PORT_NUMBER = PROC_PORT_NUMBER 'R%2' ; *GJ
END ; *GJ
*
COMSTART = CHAR(27):CHAR(1)
COMEND = CHAR(13)
CASING ON
*
SCRIPT.DIR = "C:\GGG\SCRIPTS\"
REPORT.DIR = "C:\GGG\REPORT\"
*
Err_Msg = ''
err_title = ''

D3.SCREEN.EQUATES

CLEAR.SCREEN = @(-1)
CLEAR.REST.OF.SCREEN = @(-3)
CLEAR.REST.OF.LINE = @(-4)
CROS = CLEAR.REST.OF.SCREEN
CROL = CLEAR.REST.OF.LINE
*
BOTTOM = @(0,23)
ERROR.POSITION = BOTTOM : CLEAR.REST.OF.SCREEN
*
FLASH.ON = @(-5)
FLASH.OFF = @(-6)
*
TAG.ON = @(-100)
TAG.OFF = @(-101)
*
LEFT = @(-9)
UP = @(-10)
DOWN = @(-20)
RIGHT = @(-19)
*
REV.ON = @(-13)
REV.OFF = @(-14)
*
DIM.ON = TAG.ON
DIM.OFF = TAG.OFF
*
CLEAR.LINE = @(0):CLEAR.REST.OF.LINE
EQU BELL TO CHAR(7)

D3.SPOOLER.EQUATES

EQU START.PRINTER TO 'STARTPTR '
EQU STOP.PRINTER TO 'STOPPTR '
EQU SP.ASSIGN TO 'SP-ASSIGN '
EQU SP.OPEN TO 'SP-OPEN '
EQU SP.CLOSE TO 'SP-CLOSE '
EQU SP.LISTPEQS TO 'LISTPEQS '
EQU SP.EDIT TO 'SP-EDIT '
EQU SP.LISTLPTR TO 'LISTPTR '
EQU SP.STATUS TO 'SP-STATUS '

Regards,


Niall

On Feb 24, 9:15*am, "ni... (AT) removethisgreatgulfhomes (DOT) com"
<chicod... (AT) gmail (DOT) com> wrote:

How does that line even compile?

Bonus points for overly long variable names.

--
Kevin Powick

On Feb 24, 9:15*am, "ni... (AT) removethisgreatgulfhomes (DOT) com"
<chicod... (AT) gmail (DOT) com> wrote:

I just ran a simple set of tests calling a subroutine up to 20,000
times without any problems on D3/NT 7.5.3

In one test, I passed a file variable to the subroutine which was used
by the subroutine to read an item from the associated file.

In a second test, I actually opened the file each time within the
subroutine and read an item.

No problems in either situation.

--
Kevin Powick

On Feb 24, 12:09*pm, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:
Hi Kevin,

It was just my cut and paste of the MATREAD line of code.

Glad to hear that you can run a test with no errors.

Did you try to cut & paste my samples ?
The COST-TYPE file can be made to be any file.

You'll notice that the subroutine called does very little : just
dims the opened file and equates to variables in that opened item.

So, I took out the INCLUDE of STD.EQUATES, and, you guessed it,
the program runs without an error.

I then put back in the INCLUDE of STD.EQUATES, turned the loop
from 1 to 17500 down to 1 to 15000 and it ran without error... If this
isn't an OS bug then I'll be damned ....

My guess is that it must be related to the number of iterations in
that loop. And, naturally, the STD.EQUATES is in 99.9% of all the
programs on the system.....
As you can see from my sample, a single file is opened once before
the loop is entered, so D3 is doing something funky or the error
message is just a fall-through error.

My version of D3/NT is 7.5.6

Niall

(just those simple includes).
Unfortunately that STD.EQUATES include is in every one of the
programs on the system

Hi Again,

Well it must be the stubborn Irish in me, but I can now reproduce
the error with a couple of lines of code :

NH1

$INCLUDE INCLUDE-FILE COST-TYPE-TABLE
MATREAD COST.TYPE.TABLE.ITEM FROM COST.TYPE.TABLE.FILE, "E" THEN
NULL
END ELSE
MAT COST.TYPE.TABLE.ITEM = ''
END

FOR I = 1 TO 17500
CALL NH2(MAT COST.TYPE.TABLE.ITEM)
NEXT I


NH2

SUBROUTINE NH2(MAT COST.TYPE.TABLE.ITEM)
*
$INCLUDE INCLUDE-FILE COST.TYPE.TABLE.DIM
$INCLUDE INCLUDE-FILE COST.TYPE.TABLE.EQUATE

XX = @USER

RETURN


Something with @USER is the problem !!!

Do I get a prize ?

Niall

On Feb 24, 1:47*pm, "ni... (AT) removethisgreatgulfhomes (DOT) com"
<chicod... (AT) gmail (DOT) com> wrote:
Hi Niall,

Why not just post a straight code sample that causes the problem
without any $INCLUDE statements so that others can simply copy/paste
your example? As you know, $INCLUDE serves no runtime purpose.

--
Kevin Powick

Hi Kevin,

It's not the INCLUDE that's the problem : the following straight
open and read produces the same error :


NH1

OPEN ' ','COST-TYPE-TABLE' TO CTT.FILE ELSE STOP 401, "CTT FILE"

READ CTTREC FROM CTT.FILE, "E" ELSE CRT " NO RECORD " ; STOP


FOR I = 1 TO 17500
CALL NH2(CTTREC)
NEXT I

NH2

SUBROUTINE NH2(PASSEDREC)
*

XX = @USER

RETURN


Regards,

Niall


On Feb 24, 1:53*pm, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:

Hi Niall,

On Feb 24, 2:09*pm, "ni... (AT) removethisgreatgulfhomes (DOT) com"
<chicod... (AT) gmail (DOT) com> wrote:

I figured that. I was just suggesting that you provide the simplest
code example possible for others to test, as you have now done.

I have tried your code on D3/NT 7.5.3 and no errors are raised for
me. I ran the loop at different max iterations:

10,000
17,500
20,000

However, on D3/NT 7.5.5, I was able to reproduce the error.

It's clearly to do with the subroutine code XX = @USER. Removing that
code stopped the error. I don't know how @Functions are resolved
internally to D3, but something has gone wonky between releases.

--
Kevin Powick

Niall,

It's not subroutine related at all. You can see by the following that
the same error, plus a new one, is raised. This is on D3/NT 7.5.5

001 FOR ZZ = 1 TO 17500
002 XX = @USER
003 NEXT ZZ
eoi 003

:RUN BP TEST
[33] in program "TEST", Exceeded the maximum number of 32767 file
opens !
[257] in program "TEST", Item already exists.

--
Kevin Powick

Kevin Powick wrote:
Dude, didn't you read my last blog?
nospamNebula-RnD.com/blog/tech/mv/d3/2010/02/d3shell2.html

Seriously, I think this catch is important and you guys have done a
lot of people a service by finding this. Thanks.

This provides a bit of insight into how D3 processes @USER - it's read
each time, not stored in workspace. This might point to a general
issue with @vars, or OSFI, or maybe something specific to the dm,var,
file. (Read the blog if that doesn't make sense.)

Now that I think about it, this might be the issue I reported in the
7.5 beta. I think I opened an OSFI file 300 times and got the max
files issue. Looks like they just increased the limit.

My recommendation for this specific issue until it's fixed:
Put @USER and other "constants" in common and then reference the
common var ... or just take @User out of the loop because it's not
going to change.

That said, I believe in D3 v7.5 you can Logto from Execute and change
accounts _and_ User. I doubt anyone is using that feature yet but if
someone is then loading @User to common may not be a solution.

T