VMS 7.3-2 giving error with too many symbols on f$search

[Layne Burleson_1]

I have VMS 7.3-2 running on Alpha DS10. Prior to upgrade to 7.3-2, was running 7.3-1. I have a detached process that is doing an f$search with wildcards checking a specific directory for files to be processed by this procedure. Every few days, the process appears to hang. When looking at the log file, the directory clearly has files in it yet the f$search is erroring out with a status %X00038138 which is %DCL-W-SYMOVF, no room for symbol definitions - delete some symbols. sysgen parameter CLISYMTBL is set to 1024.

Has anyone else seen this problem?

[John Abbott_2]

Also recently upgraded several systems from 7.3-1 to 7.3-2, but haven't seen what you describe.

Could it be that you have an abnormally large no. of files in the directory ? a back log to clear ? I guess your routine creates one or many symbols per file match and from the DCL warning, you run out of room.

Perhaps some symbols are left lying around and not re-used and you accumalate lots over time.

Upon failure or infrequently you could add a $ SHOW SYM/LOCAL/ALL (/GLOBAL) may shed some light.

Have you up to date on patching ?

Kind Regards
John.

[Layne Burleson_1]

I'm sure it is simple, I just can't find it... usually there are less than 10 files in the directory at a given time. There are a good number of global symbols. I see this with the command you suggested. IS there a way to tell how much I'm using of the clisymtbl from dcl? Does f$search keep the results from each loop thru the directory and perhaps that is where I'm running over? Has this changed? I didn't have the problem on 7.3-1.

[Joseph Huber_1]

Maybe You just were near the margin , and now with the new system You cross it .

CLISYMTBL is a dynamic system parameter: change it for testing to a higher value, logout/login and see if the situation changes.

[Layne Burleson_1]

Joseph, The value is set to 1024 for clisymtbl. That's the max isn't it?

[Joseph Huber_1]

Oh yes, sorry, 1024 is max.
That is half a MByte space for symbol definitions.

Maybe test the space by using the following procedure:

$ n=1000
$ if p1.nes."" then n=f$integer(p1)
$ i=0
$ on warning then goto done
$loop:
$ testsym'i'="This is testsym''i'"
$ i = i+1
$ if i .lt. n then goto loop
$done:
$ write sys$output "End at testsym",i

Adapt the testsym symbol name and string to the length You use in Your procedure to see the number of symbols You can produce.

[Ian Miller.]

has the DCL changed? Could it be calling a DCL procedure recursivly?

Could you include SHOW SYMBOL * in the DCL as a debugging aid to see what symbols there are?

[Jim_McKinney]

Do you specify a new stream-id argument value for each directory pass? If so, try changing the code so that it uses either no stream-id or the same one each time through.

If you determine that this isn't a coding bug that is resulting in the symbol table overflow, and you don't mind living in the land of the unsupported, then you could use either the DELTA debugger or a small program to raise the roof a bit higher than SYSGEN permits (the system stores SYSGEN's CLISYMTBL value at the location exe$gl_clitabl).

$ create clisymtbl_2048.mar
.psect code exe,nowrt,shr,long
.entry clisymtbl_2048,^m<>

$cmkrnl_s routin=sysgen_plus ; jump into kernel mode
ret

.call_entry label=sysgen_plus
movab g^exe$sigtoret,(fp) ; establish exception handler
movl #2048,exe$gl_clitabl ; set clisymtbl to 2048
movl #1, r0
ret

.end clisymtbl_2048
^Z
$ macro clisymtbl_2048
$ link/sysexe clisymtbl_2048
$ analyze/system
SDA> eva @exe$gl_clitabl
Hex = 00000000.000002EE Decimal = 750 PSBRB$K_RINGBUFFER_RECORDS
SDA> spawn run clisymtbl_2048
SDA> eva @exe$gl_clitabl
Hex = 00000000.00000800 Decimal = 2048 ABLK$Q_ADRQ_Q_HD

[Jim_McKinney]

Sorry about the formatting in the prior post - see the attachment here for a clearer picture.

[Hein van den Heuvel]

Maybe SHOW PROC/MEMORY can give you a clue?

Hein.

[Layne Burleson_1]

The output from sho sym/global/all and sho sym/local/all only shows about 60 symbols. Some of these I can delete and will. I can write a procedure like above and generate 5000 symbols before the overflow. The program is the same program that runs at many other locations except this is on 7.3-2. All other locations running 7.3-1.

I've talked with HP and they are wondering if the symbol name that I'm using for the results from f$search in the loop searching thru a directory is not being released from the symbol table and therefore creating a new symbol everytime rather than replacing what was there already.

I'm unclear how show proc/mem will help. Is there a way to look at what is in the symbol table for a particular process?

[John Gillings]

Layne,

Does your F$SEARCH loop always run to completion? (ie: you get a null string returned). What is the exact file specification? Does it contain a search list logical name? Are you using search streams?

I'd also be searching for unbalanced IF-THEN-ELSE-ENDIF or SUBROUTINE-ENDSUBROUTINE blocks.

SHOW PROC/MEM shows the process dynamic memory area. It contains symbols and other DCL context. Filling it up with other stuff consumes space for new symbols. Don't forget each command level has its own symbol table. How deep is the procedure? See F$ENVIRONMENT("DEPTH"). Recursion can be accidental.

Something else to check - SHOW RMS. Look for any non-zero values other than "MULTI-BLOCK-COUNT" and "NETWORK BLOCK COUNT". In particular a non-zero value for "Sequential Disk" will cause process permanent files (ie: anything OPENed from DCL) to consume process pool space.

[Layne Burleson_1]

John,
Yes, it appears that the f$search will run to completion and give the null string. It will find files as they are populated and follow-through with the null string when it has looked at all of them - just as designed. Occasionally, we see the command file=f$search("nodetemp_rpt:*.*;*") generate the $status value of %x00038138 indicating a symbol table overflow.

We are using the logical nodetemp_rpt in the file spec for the f$search command. It is not in a search list.

We have other f$search's in the command procedure that look for specific file names. At one point we put a stream identifier on the f$search but we still get the symbol overflow error.

All of the IF-THEN structures look like they are matched up appropriately.

The SHOW RMS command does not show any of the non-zero values other than those you mentioned should be non-zero.

I'm having the application person clean up some of the symbols in the command procedure that are not necessary for the loop. We will resubmit the detached process after she is finished with the changes. I have a feeling that will just prolong the problem.

[John Gillings]

Layne,

Trimming symbols from a "reasonably sized" procedure should not be necessary.

This may be an obscure bug in your procedure, but it's beginning to sound like you've found something wrong in DCL (maybe a result of the extended DCL work added in V7.3-2).

Please log a case with your local customer support centre to analyze your procedure.

Note that the last thing you want to do is extend the time before failure. It may be more prudent to CREATE a large number of symbols in your procedure prologue to induce the problem faster, (minutes instead of days) then start to carve up the logic to isolate the cause.

[Robert_Boyd]

Just for grins you might get a copy of DCL_CHECK.COM and have it analyze the procedure to see what it might report.

I have had some times where I was staring at code and couldn't figure out what was wrong, but DCL_CHECK narrowed it down quickly.

Robert

[Layne Burleson_1]

John, I've already logged a case with HP. The last report was they were trying to replicate the problem and it may need to go to engineering.

Thanks for your input.

[Thomas Ritter]

Layne, may we request you post your procedure ?
We are running 7.3-2 and have directories with over 100,000s files. Lots of f$search() being performed all the item. You may have discovered and interesting problem.
Tom

[Wim Van den Wyngaert]

Had the same problem once.

Not in all cases context was cancelled when using f$context not until the end.

As Hein suggest, I did a show proc/mem and watched the "free space" value. If it drops below 5000 I give an alarm and I know something is wrong that needs investigating.

Or may be the procedure is generating symbols. Try sh symb * to see if unexpected symbols are seen.

Wim

[Jan van den Ende]

Re Wim:

SHOW SYMBOL may reveal something, but the same space is also used to store LABEL info.
That is not so easily visible, but, if you have some dynamic label activity, that also may keep growing.

Extremely simplified reproducer:
.
$ cnt = cnt + 1
$lab_'cnt':
.
$ goto lab_'cnt
.
If cnt grows to big values, you are pretty much guaranteed to hit the ceiling sometime!

Hth

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Jan,

I would suspect that too but just tested it. Free space doesn't decrease (7.3). But I get the message "no room for symbol definition" when reaching count 6540.

???

Wim

[Wim Van den Wyngaert]

I also tested the process context case. Not cancelling the context is no longer punished : no process memory stays allocated.
Did the test on 6.2 1h3 with the same result.

Was it only VMS 5.5 ?

Wim

[Layne Burleson_1]

I can now reproduce the error on any 7.3-2 system. Here's the code I'm running. There are a few conditions that I found from the log files of the actual program: 1) delay_logical is not defined 2) noproc1.com and noproc2.com do not exist 3)pgm$debug is not defined.

When I run thru this procedure on a 7.3-2 system with clisymtbl set to 512, it runs thru the loop 61 times. On a 7.3-2 system with clisymtbl set to 1024, it runs thru the loop 124 times. I've been running the procedure all a.m. on a 7.3-1 box and have yet to get an error:

$ set noon
$ set ver
$ counter = 0
$ myPath := "csd$user:[csmlf.test]"
$!
$Holdit:
$ counter = counter + 1
$ delay := 'f$trnlnm("DELAY_LOGICAL")'
$ if delay .eqs. "" then delay:=00:00:02
$ wait 'DELAY'
$!
$ if f$trnlnm("DIRECTORY_RD1") .nes. "" then @CSD$USER:[CSMLF]NOPROC1.COM
$ sv$status = $status
$ show symbol sv$status
$ if sv$status .eqs. "%X00038138" then goto exitt
$!
$ if f$trnlnm("PGM$DEBUG") .eq. debug then goto seek
$ sv$status = $status
$ show symbol sv$status
$ if sv$status .eqs. "%X00038138" then goto exitt
$!
$Seek:
$ show time
$ dir/date/sec 'mypath'*.*;*
$ file==f$search("''myPath'*.*;*",1)
$ sv$status = $status
$ show symbol sv$status
$ if sv$status .eqs. "%X00038138" then goto exitt
$ sho sym file
$ if file .eqs. "" then goto bottom
$!
$ @CSD$USER:[CSMLF]NOPROC2 'file'
$!
$Bottom:
$ goto Holdit
$exitt:
$ write sys$output "number times thru loop ''counter'"
$ exit(sv$status)

[Layne Burleson_1]

After more testing... it appears that when a command procedure calls another command procedure that does not exist, it eats away at the symbol table space. I've tested it on 3 7.3-2 systems with the same results. On 7.3-1 it does not appear to cause a problem.

[Ian Miller. · Accepted solution]

You are right - this DCL fails with %DCL-W-SYMOVF

$ SET NOON
$L1:
$ @ZYAAZ.COM
$ GOTO L1

[Ian Miller.]

On alpha VMS V7.3-2 the DCL I posted fails and returns to the $ prompt. On Alpha and I64 V8.2 it reports %DCL-W-SYMOVF and continues constantly reporting the same error.