Virtual Memory Issue on opening a dcube via a macro

[mgzryq]

We use Analyst for our ETL process, as part of a multi-nested series of macros (which is kicked off by a scheduled CONNECTION JOB) that runs ODBC dlinks from published tables, opens various (4) large dcubes (37 m cells), runs various dlinks and DCUBE Export commands etc there is 1 step where a dcube is opened (the 2nd in a series of 4 large dcubes)  to run the DCUBE Export command but we hit the following error...

2009-12-06 22:10:21 Opening D-Cube AFS_DP_LedgerDataStore.Data_OpEX_REVISED...
2009-12-06 22:10:21 Reading file...
2009-12-06 22:10:21 Expected prompt:
2009-12-06 22:10:21 Received prompt:  20   [W] WINDOWS VIRTUAL MEMORY FULL.  CLOSE OTHER APPLICATIONS AND TRY AGAIN
2009-12-06 22:10:21 Return code set to 9999 Response out of sequence

The dcube is about 37 millions cells, when I try to open it (outside of the macro) it opens just fine & I can manually run the open & export commands. We recently increased the virtual memory on the App server to 150% of RAM (ie 12 Gb). We re-booted the server but still get the same error. This error has only recently started to come up, our ETL macro (this part of it, anyway) has worked just fine for the last 2-3 years.

Any suggestions?

[mizu]

- are you running planning under a service account or some special account && which version are you running?
- have there been made some changes to the server (hw change, sw change)/ it infrastructure (security policies) / cognos itself (service pack)?
- anything in the windows event viewer?

[mgzryq]

We are using a service account which has adm rights. We are on EP V8.3 SP 2

No hardware changes recently. Only S/w changes was .NET 3.5 was recently installed. Nothing unusual in  the Windows Event Viewer and no changes to security policies and no new service packs installed.

[mizu]

- what about workspace setting in analyst? what amount is it set to?
- is the shadow copy enabled for that cube?
- what are the steps included in your macro?


just to be perfectly sure i would double check wheter there is enough space on the system partition,..

and just to clarify - you use a scheduled job on connection portal running an analyst macro throught contributor macro, right? can you simulate a scheduled run by manually firing the published job and monitor the ram usage through task manager on the server? you should check for a process called dyalog32.exe..

btw, have this problem appeared before the 3.5 version of .net? i found some articles pointing out that it can cause some memory leaks,..

[mgzryq]

Thanks Mizu for your assistance.

It appears the issue is with contiguous memory not being available for the dcube to be opened. We tried increasing the server's VM further but it didn't seem to fix the problem, so instead we have split out our ETL macro into 2 separate sub-macros whereby the service account now logs into Analyst twice, 1st time it does half the original macro then logs out and then the 2nd time it logs in again and does the rest of the steps. By splitting the steps in the nested macro over 2 Analyst sessions it appears to get around the issue.