https://communities.sas.com/t5/Developers/Good-ol-Stored-Processes/m-p/370#M1479 Not surprised no one has answered this post yet.<BR /> <BR /> It’s because this stored process is entirely different in nature to the modern equivalent.<BR /> <BR /> Dangerous to use the same terminology for different components of your technology base, as it will confuse people no end. Mon, 22 May 2006 23:51:45 GMT deleted_user 2006-05-22T23:51:45Z https://communities.sas.com/t5/Developers/Good-ol-Stored-Processes/m-p/369#M1478 I gave a presentation on Stored Processes back in 1989 in Johannesburg, to SUGISA (SAS Users Group In South Africa).<BR /> <BR /> Back when we had slow processors, compiling the code of a large datastep took longer than processing the data. In my case I reduced a monthly report run from 40 minutes to just 2 using the above. This was one datastep of over 3000 lines churning through two datasets of over 500 variables each - a legacy of using FSEdit on the mainframe and slow response times (remember those?). I never even thought that this knowledge would ever be used again, but it seems that is now not the case.<BR /> <BR /> Anyone else have any tales from the past to share? Thu, 06 Apr 2006 10:06:56 GMT https://communities.sas.com/t5/Developers/Good-ol-Stored-Processes/m-p/369#M1478 deleted_user 2006-04-06T10:06:56Z https://communities.sas.com/t5/Developers/Good-ol-Stored-Processes/m-p/370#M1479 Not surprised no one has answered this post yet.<BR /> <BR /> It’s because this stored process is entirely different in nature to the modern equivalent.<BR /> <BR /> Dangerous to use the same terminology for different components of your technology base, as it will confuse people no end. Mon, 22 May 2006 23:51:45 GMT https://communities.sas.com/t5/Developers/Good-ol-Stored-Processes/m-p/370#M1479 deleted_user 2006-05-22T23:51:45Z