Desktop productivity for business analysts and programmers

SAS/EG process vs JCL job

Reply
Occasional Contributor
Posts: 12

SAS/EG process vs JCL job

We have some JCL jobs in maniframe that we want to migrate to SAS/EG process.

That mainframe jobs has about 20 JCL steps by average. This steps are reading input files, data sorts, data filtesa, merge of files, agregations process,and some calls to Cobol or Easytriev programs with no-complex business logic. Thi jobs move files of 100Gb. aprox and are scheduled in a Control-M. The performance is good.

The solution is create a .egp SAS/EG project with all that steps to replace the mainframe job. Ths simple steps like sorts, reads, merges will be made with SAS/EG components and the Cobol/Easytrive programs will be translated to SAS/BASE.

We will generate the SAS/BASE code of the .egp projects, move that .sas file to Unix and call it by a .sh shell script or schedule in Unix Control-M. The Unix server will be a good machine, with necessaty resources.

My doubts are ¿is SAS/EG a suitable tool to replace maninframe JOBS?, ¿its has any limitationes with his components?. For example, the read component of SAS/EG has few optiones compared with an input read step os SAS/DI or other ETL tools.

¿Can we have performance problems?. ¿are Unix systems and SAS process as solid and robust like mainframe environment process?

Any advice will be greatly aprecciatted.

Thanks in advance...

Trusted Advisor
Posts: 2,114

Re: SAS/EG process vs JCL job

I feel like we have already answered several of your questions in your previous thread.  http://communities.sas.com/message/117135#117135

EGuide is simply a client for the SAS Server (in this case on Unix); it handles the presentation and receives the output.  Unix can be as robust as the mainframe or as fragile as a PC; there are so many flavors of Unix that there is no single answer.  With multiple rack mounted blade servers running RedHat and a dedicated attachment to a SAN, the system can just scream, and at less that 10% of the price of the mainframe.

Because EGuide is the client, you will want to keep the .sas programs in the EGuide environment and submit them the server from there.  Scheduling would then all be handled at the EGuide level (on Windows).  [I've done it the other way and getting the timing right can be a real pain.]

Doc Muhlbaier

Duke

Respected Advisor
Posts: 4,132

Re: SAS/EG process vs JCL job

"Because EGuide is the client, you will want to keep the .sas programs in the EGuide environment and submit them the server from there. Scheduling would then all be handled at the EGuide level (on Windows)."

Can't really agree with this. I believe the OP needs to use EG as development tool for SAS code which lives on the Unix server and is scheduled using a reasonable scheduler (like Control-M).

Scheduling EG projects is done from a workstation and I don't think this is on the operational level needed here.

@jvidalg

See EG as a "code generator". If you develop SAS code with PC SAS, EG or any editor has no influence on how the code performs. It's the code itself and the environment it runs in which impacts on performance.

Just work with the tool(s) which suit your development tasks best.

There seems to be a lot of DI work so of course DI studio would appear to be the best choice (even better together with LSF as scheduler) - but it seems it's not available.

Don't worry about the impact of SAS Metadata on performance - it's neglectable.

Trusted Advisor
Posts: 2,114

SAS/EG process vs JCL job

Patrick,

I agree that using EGuide as a development platform and moving to another platform for production makes sense in some cirumstances. 

I had read jvidalg's original two posts as saying that they were going to run production out of EGuide, so I was answering with that context in mind.  We've done both and both can work well; I don't see it as a black-or-white decision.

Doc

Ask a Question
Discussion stats
  • 3 replies
  • 368 views
  • 0 likes
  • 3 in conversation