Tricky task - possibly a macro loop question

[Vince28_Statcan]

Hrm,

Reading a bit about proc model, the fit /options appear to be printing to the ods as well. You may or may not have handled that when checking for ods capacities. If not, I suggest adding a noprint option to the fit statement and to the proc model statement just to be safe.

You could also attempt a diagnosis with memoryuse printing option if it appears to be one particular step (although you've stated otherwise) that bottlenecks.

I've read through my program again and can't seem to find any specific issue and memory crashes are significantly harder to fix with no error reports in the log

How long does it take in "real time" before the bottle neck? (approx is in days, hours, minutes)

*edit

Look for PROC PRINTTO

and move both the log and the ods results to 2 different files like

proc printto log='c:\logfile.txt' print='c:\printfile.txt' new;

run;

and then execute the code. It should also allow you to go check the log/ods files after the crash to help target crash patterns.

Vince

[AllSoEasy]

Thank you very much for your continued response! I will add that and check the results momentarily -- I did not previously specify noprint in proc model or any of the options.

-As for memory diagnosis, I didn't do anything very complex, just viewed my performance monitor via windows taskmanager, but RAM usage was very low and CPU usage was <20% So I'm not sure how much insight could be gained from further diagnosis.

-Also another frustrating thing is that there isn't much consistency in when the bottleneck occurrs, sometimes it has happens when running the first 100 models, sometimes after 2000. But in general it is always a matter of minutes, probably 10-15 minutes maximum, 1-2 minutes minimum.

Also, here is a detailed description I get from a "SAS 9.2 Windows Error Message" stating that "SAS 9.2 for Windows has encoutnered a problem and needs to close"

Under technical error report contents:

Exception Information:

Code: 0xc000005          Flags: 0x00000000

Record: 0x0000000000000000   Address: 0x000000007c919af2

System Information:

Windows NT 5.1     Build: 2600

Doesn't seem to be much useful information, but perhaps that can be of some indication to a specific issue?

Thanks!!

-Ryan

[Vince28_Statcan]

Well, very often, softwares (sas included) have preset memory allocation which you cannot go beyond for certain components. The reason why I've been bugging a lot about ods&log is because they each have their own "capacity". For similar reasons, even if you had a server computer with hundreds of GB ram, hash tables and arrays would still be limited far below this. I trust that proc model exists when a value diverges but there could also be some models with a given parameter with extreme slow convergence that looks like a bottle neck but would eventually resolve if you get it a lot of time.

Also, and this may be me, again, being clueless about your specific model, but there are certain model statement that create multiple new variables like a proc logistic breaking down a class variable into multiple variables for computation. If you have, say a numeric variable stored as character that enters a model and such a class is created for all distinct numeric value, it can create such bottle neck. Although this would be causing systematic bottlenecks and not random bottlenecks at different steps of the iteration.

But anyway, at this point I'm mostly putting ideas out there. It's hard to debug without loged errors, even more so without hands on the program and data

Last but not least, if you look back at the original program I gave you, the workdone2() macro actually parses all of the code generated by the macro in a file so you could actually break down the job into many files and run files one by one (well in a macro loop) to see if it solves your memory issue.

Vince

[AllSoEasy]

Agreed it is hard enough for me to debug WITH the program & data at my disposal, so I certainly don't expect you to be able debug the thing, but you've already given me so much help I think I may have it to a point where it is at least run-able.

The workdone2() macro was useful as I used this to verify all model forms being executed were syntactically correct (which they are), and I know have the proc model process broken down into 16 macros, doing 1000 observations at time, and with your suggestions of specifying noprint it has, so far, run each batch without freezing, although a minute or so in I get a message saying (results are getting very large, do you want to keep adding them to the project?) but I just click yes and it finished.

-Also, interestingly, I was already using proc printo to specify the log output to a text file, but when I tried your suggestion of print='c:\printfile.txt' new; the program ran extremely quickly (<1 minute) however no results were appending to the aggregating dataset, I'm guessing that is an intended function of the procedure though (I haven't read a bunch into it, just tried it based on suggestion).

But thank you again for the help!! I'm going to continue and try to look for optimizations to reduce the memory usage, because as you have suggested, I do agree that it seems to definitely be a memory issue. Thanks!!

[Vince28_Statcan]

I believe your issues are mostly due to SAS EG. It attempts to open all the datasets through and though for the output data tab. I don't know enough of SAS e.g. to remove this behavior. Anything that would normally have been put in the "Results" tab went in proc printto location instead hence the efficiency gain. Although I am not sure if .txt extension is appropriate for a print location I would guess it may have to be one of the valid print devices instead. The point is, EG even beyond SAS has a lot of added baseline features like opening datasets created which takes up a lot of memory if you were piling thousands of DS. Same if the results kept being appended, esp since the baseline graph destination is activex so any graph produced by proc model would've used a small chunk of availible memory  (it doesn't just load an image - it'S a dynamic object). There is also the default report of data with ODS tagsets.sasreport12 piling up etc. This is why I still run in base SAS. If you need specific help on how to remove each of these default component from EG, you might need to create a new thread as I am of no help. Vince

[AllSoEasy]

Vince, you have been of more help to me than you could know and I truly appreciate it; without your help I more than likely wouldn't even have the logic for permuting the equation forms down yet! I have messed around with some options in EG to disable the auto-opening of SAS datasets. While it is *functional* now (I have to run it in 1000 observation batches, and have to wait for the message to come up asking if I'm sure that I want to keep data to the project to click yes after every batch), but this is good enough to get some results, and I will look further into running in base SAS - that may be my best bet.

Many thanks for all of your help, best regards,

-Ryan

[Vince28_Statcan]

Alright, last stab at figuring out how to fix the issue within sas EG as a self learning experience today.

In Tools->Options->Results there are quite a few things which you can uncheck to both improve the processing and *possibly* to kill that message asking if you want to keep data to the project. Apparently, projects save the datasets they generate, probably via a view as availible.

If you want to remove the prompt each batch, you can simply change

Managing results -> replace results -> promt before replacing

to either the other 2 options in the scroll down menu. Since you don't need those results directly and rather will use the datasets generated, you can select replace without prompting.

If you uncheck all results format up top (default is SAS report), unmark "automatically add output data to the project tree", unmark "Generate ODS statements" and finally set the maximum number of output datasets to 0, I would expect that you can run the entire program, not broken down and not have to manually handle any prompt. This basically removes most EG features that you would otherwise not have in base SAS if you simply executed the program.

[AllSoEasy]

Vince - Thank you so much for your continued assistance. I've addressed all of the above mentioned option changes, and in fact the program is running very well now! (that and I also dropped a variable, so it is doing 16,384 / 2 now, lessening the workload a bit), but I can run it all in one batch, without any prompts, and the entire program executes in <5 minutes!

Thanks again!!!

-Ryan