Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
COBOL vs. CA-Easytrieve maintenance cost

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
vadim vashchenko

New User


Joined: 21 Mar 2011
Posts: 13
Location: usa

PostPosted: Wed May 18, 2011 11:22 pm    Post subject: COBOL vs. CA-Easytrieve maintenance cost
Reply with quote

We are a COBOL shop. We also have many compiled Easytrieve in production. Today I have been told not to use EZ in Prod anymore because it is a 4G language and is too expensive to run. My understanding was that a compiled EZ is no more expensive than a compiled COBOL - in both cases we have a load module.
Please advise.
PS. I realize that my question reveals the depth of my ignorance. I am ashamed.
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8154
Location: East Dubuque, Illinois, USA

PostPosted: Wed May 18, 2011 11:32 pm    Post subject:
Reply with quote

I think you're probably mis-interpreting things. CA-Easytrieve is a package from an independent software vendor and maintenance for the product must be paid every year. CA is not known for having cheap maintenance rates for its software. COBOL, while not free, is nowhere near as expensive as Easytrieve -- both products base their charges upon the size of the machine, so the larger the machine the larger the cost (in general).

Compiled COBOL code should cost no more nor less than compiled CA-Easytrieve code to execute. The difference is cost will be the monthly maintenance changes.
Back to top
View user's profile Send private message
vadim vashchenko

New User


Joined: 21 Mar 2011
Posts: 13
Location: usa

PostPosted: Wed May 18, 2011 11:35 pm    Post subject:
Reply with quote

Robert Sample wrote:
I think you're probably mis-interpreting things. CA-Easytrieve is a package from an independent software vendor and maintenance for the product must be paid every year. CA is not known for having cheap maintenance rates for its software. COBOL, while not free, is nowhere near as expensive as Easytrieve -- both products base their charges upon the size of the machine, so the larger the machine the larger the cost (in general).

Compiled COBOL code should cost no more nor less than compiled CA-Easytrieve code to execute. The difference is cost will be the monthly maintenance changes.


Thank you much. We pay CA anyway because EZ is being used widely everywhere but Prod.
Back to top
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 111
Location: Puerto Rico

PostPosted: Thu May 19, 2011 12:45 am    Post subject:
Reply with quote

Good afternoon!

Like Mr. Sample stated the only expenses is the maintenance product fee for each CPU that EZ is installed. I don't think there's a big difference in generated object code between EZ and COBOL. In CPU cycle time EZ executes very fast and when you are generating more than 10 reports in one phase there's no comparison to COBOL.
Back to top
View user's profile Send private message
valyk

Active User


Joined: 16 Apr 2008
Posts: 104
Location: South Carolina

PostPosted: Thu May 19, 2011 1:51 am    Post subject:
Reply with quote

Easytrieve can also be interpretive, and does have more overhead than COBOL.

My shop has a restriction on application programmers running Easytrieve in production, but I believe it is on the premise that not every application programmer knows Easytrieve. COBOL is more widely known and does not limit future maintenance.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Thu May 19, 2011 6:20 am    Post subject:
Reply with quote

valyk wrote:
Easytrieve can also be interpretive, and does have more overhead than COBOL.

My shop has a restriction on application programmers running Easytrieve in production, but I believe it is on the premise that not every application programmer knows Easytrieve. COBOL is more widely known and does not limit future maintenance.


Well Valyk, no, Easytrieve Plus cannot be interpretive.

From the manual (6.2)

Quote:

Modes of Operation

You can better understand how CA-Easytrieve/Plus works by examining the
modes in which it operates, the structure of a program, and the syntax rules of
CA-Easytrieve/Plus statements.

CA-Easytrieve/Plus provides five modes of operation that facilitate production
as well as ad hoc programming. The modes of operation (determined by the
PARM statement parameters you choose) are:

Syntax check CA-Easytrieve/Plus source statements.
Syntax check and compile CA-Easytrieve/Plus source statements.
Syntax check, compile, and execute CA-Easytrieve/Plus source statements
(the default).
Syntax check and compile CA-Easytrieve/Plus source statements and
produce an object module.
Execute previously link-edited programs.


I think the confusion arises with the third option, which is when submit your source and your datasets and you get your output all in one go. You execute EZTPA00, with source, and no object library or load library is updated.

However, if you read the third option, you'll see what it is doing according to CA. Does it do that? Yes. Don't believe me? Write a program. Compile it with EZTPA00. Link it. Run it with JCL. Then do option 3 with just the source, JCL. Compare CPU usage and IOs. They will be marginally higher, because of the syntax/compile, so add those from your own compile. Now you'll get something pretty similar.

It is not interpreted. It is not sem-interpreted/semi-compiled (generaging "p-code" and "interpreting" that at run time). When you run your program, from source or from the object produced from a compile, it is always fully compiled. Generate the pseudo-assembler source. You can do that from the compile-and-run.

You are probably right about why your site does not use Easytrieve in production. It is less well known, and has some different concepts from Cobol. If you try to write Easytrieve like Cobol, you will get a bad program. Because of lack of familiarity, it is much easier to write a bad Easytrieve program than a bad Cobol program.

I think Easytrieve is still let down by the manual. It has a very useful Macro facility, but little-documented. The automatic file matching is powerful, but you have to know how to use it. The manual is better these days on this, but used to be terrible. It can have user-written "file exits", but you'd hardly know that. To find out how that worked, we had to "su**-it-and-see". However, once we saw, it was easy to make a Cobol file exit for all the printer output, which allows you to do additional usefule things (one site had routing codes, and standards requiring a module call to handle all output. No problem. Another wanted a footer at the end of each page and a special end of report page. No problem. It can also relieve you of the problem of fixed-position titles and wanting to use SPREAD for the report lines). It is wooly on the distinction betwee type S fields and type W fields. Etc.

However, it is possible to write very good, flexible, easily maintainable, efficient, etc programs in Easytrieve Plus.

The first place I used Easytrieve Plus, they gave us a choice. Here's the spec, you choose the language. First I chose Cobol. But since it was new to me and a colleague, we looked at it, developed some macros and a PRINTER exit and then got going. By the time I finished there, I'd guess all reports and most of the file updates I'd written were in Easytrieve Plus, say 95% of the programs, about 2/3 of the system. Why? Development time. Big reduction there, especially for reports. Also the ability to split a task into logical units which all run seperately and consecutively, reduced amount of JCL. SORTs which are readable. VIRTUAL files. Many little things that help out if you know how to use them.

How do you get to writing good programs? Different strokes for different folks. If you can find some good training for a small group who are then able to "mentor", might be a way. A couple of weeks with no time-pressure, just to play around with it and find out what it can do. Or, the usual, just writing programs in it, testing, finding out what went wrong. Getting better each time.

Is it still called a 4GL? Wow. We always thought 3.5GL at most, a bit of a sales-con giving it more than that given what we were led to believe other 4GLs could do.

For batch applications Easytrieve Plus is a powerful tool. So is Cobol. Development is quicker, but it is easier to make a terrible Easytrieve program than a terrible Cobol one.

If you are paying for it anyway, it might make sense to spend some more to bring all the programmers up to speed on it and get some value back from the bucks being spent. If there is not going to be such investment (shortsighted, but it happens), then out of Production is probably best.
Back to top
View user's profile Send private message
vadim vashchenko

New User


Joined: 21 Mar 2011
Posts: 13
Location: usa

PostPosted: Thu May 19, 2011 4:44 pm    Post subject:
Reply with quote

Thanks to everyone. In our case, some latent political consideration prevailed over the common sense.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10308
Location: italy

PostPosted: Thu May 19, 2011 7:15 pm    Post subject: Reply to: COBOL vs. EZ - please enlighten me
Reply with quote

Quote:
In our case, some latent political consideration prevailed over the common sense.


I beg to disagree, it could be just a cost issue
EZT licensed to run on two processors or two LPARS cost more than a single license ...
no politics here , just money
and I tend to respect money more than politics icon_biggrin.gif ( reasonably of course )
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. Extract all "IF" Statements... Adarsh Damodaran CLIST & REXX 1 Wed Sep 06, 2017 9:28 am
No new posts ALPHABETIC check in COBOL vidyaa COBOL Programming 8 Thu Aug 17, 2017 7:13 pm
No new posts UNIT=AFF for Easytrieve code gandikk JCL & VSAM 7 Wed Jul 12, 2017 11:42 pm
No new posts XML Parse for COBOL 5.2 Bhanu Praveen COBOL Programming 1 Sat Jul 08, 2017 8:58 pm
No new posts Dynamic output file creation in cobol... smileheal COBOL Programming 7 Thu Jun 15, 2017 10:53 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us