Once you create a Stored Process you do not necessarily need the EG project, anymore, that was used initially to create the stored process.
For example, you create a project that points to PERMLIB.JAN2007 and you create some tasks and some reports. Then you turn that project into a stored process. Let's say you want to reuse that SP for PERMLIB.FEB2007 and PERMLIB.MAR2007 and PERMLIB.APR2007 and so forth.
You do NOT have to redo the project every month or create a new SP for every month. But, you DO have to understand SAS macro variables and how they work inside SPs and assuming that every month's file has the same variable names, and that every month's file is registered in the Metadata. Then, all you have to do is either prompt the user for the month and file name when they execute the SP --or use macro syntax to automatically set the month when you run the SP.
Of course, once you make these changes to the EG-generated code, then you have essentially created something (a .SAS program) that is no longer an EG project -- but since it was originally created from an EG project, you should be comfortable with what the output is going to look like enough so that you want to essentially turn the code from that project into a re-usable set of code steps that can be run every month.
In my view, you do not need to create the SP in batch, so much as you need to understand a bit more about SAS macro syntax, how SAS macro variables work and how a SAS macro program can be used to actually generate your changed code every month.
That is too big a set of questions to answer here. There have been many examples of using a SAS macro program to generate self-changing code in a stored process posted to the forums; however, it would probably be better, and less error-prone, for you to get help from Tech Support with your exact problem and what you need to exactly do, rather than getting piece-by-piece and question-by-question advice here. The fact is that the design of your macro code and macro program may change from somthing originally tested with simple substitution to more complex code that uses macro conditional logic to generate chunks of your final stored process. And the kind of SP that you develop may have to change depending on the client application from which the SP will be run and the kind of final code you want have executed based on the user's input (or the kind of automatic code you want to have executed based on some other condition).