When you define the parameters, you have the option to set parameter groups in EG -- each parameter group gets it's own "tab" in the interface in EG and MS Office. So if you consider each "tab" to be like a screen, then you don't have to worry about coding the screens -- just make logical parameter groups and put parameters into them. In EG you can make the parameters and then make the groups and drag and drop the parameters into groups. In SAS Mgt Console, you have to define the groups first and then place the parameters in the right group when you click to create it.
I would not try to have a stored process call another stored process. If I had code that needed to be executed conditionally, I would put the conditional code into macro programs that lived in an AUTOCALL library.
So let's assume that I have some weekly report code and some daily report code and based on a parameter value in the SP, the users can choose whether to run the weekly report or the daily report. I can make a macro program (a black box right now) called %weekly; for the weekly report and %daily; for the daily report -- and in my main SP, I'm going to define a parameter called REPTYPE that will allow them to select either WEEKLY or DAILY
Assuming that those macro programs are stored in the AUTOCALL macro location that my BI Platform installation knows about, then I can do this in my SP:
**** start of SP program code -- call this DOREPT.SAS;
**** register as DOREPT stored process with 1 parameter REPTYPE;
**** Output type is STREAMING;
The macro program that is INSIDE my DOREPT.SAS program is defined "in-stream" but, it too could be an AUTOCALL macro. I didn't want to make too many black boxes! I generally keep my macro definitions (%macro/%mend) outside of
%stpbegin/%stpend -- just to keep my housekeeping and debugging easier to keep track of.
Only the call to the %TESTPARM macro needs to be inside %STPBEGIN;/%STPEND; because it is the invocation or %WEEKLY or %DAILY that will really produce my output.
If you are going to do a LOT of conditional processing in your stored process, then you'll end up needing to know about the SAS Macro facility and how to write and use macro programs effectively. The parameters that you set for your stored processes are passed to either the Workspace server or the Stored Process server as Global Macro variables that live in the Global Symbol Table on the server.
Guess who can help you figure out the right location for AUTOCALL macros on your BI installation and/or help you with macro syntax??? Tech Support ;-)