Probably not. That has to be designed in at the procedure level, so only certain procedures take advantage of multiple processors. For instance, SORT will use up to 10 processors and REG up to 4, but those are design features rather than something the user controls.
My experience with SAS SQL is that the rate limiting part is I/O, so even if you could execute these independently, I doubt that you would make much gain in overall time to completion.
Have a look at things like: “X command”, “X statement”, “CALL SYSTEM routine”, “%SYSEXEC” and “SYSTASK”.
To use these commands within EG shell escape must be possible (-> run “proc options”, look for “xcmd”).
Some maybe platform dependent. For example if your running on UNIX you could split the code in two sas programs and execute them separately (sas prog1.sas & and then sas.prog2.sas &)
Or you could issue from SAS the X command with the NOWAIT option set (executes asynchronously), which is the same thing but started within SAS.
Or (and this one, would be my favorite) if you want to control the threads from SAS (say, wait for both to end before proceeding with some other thing from SAS) and have the SAS/CONNECT licensed at your site, you could use the MP/CONNECT technique and submit both piece of codes each on a autosignon session.
To follow on to Daniel's comment, if you are on a PC and willing to split the code into multiple SAS programs, the parallel to the Unix "&" would be to right-click on the code and select either 'submit' or 'batch submit' (Batch submit should run faster because it doesn't have to load all the windows display overhead.)