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.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
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.
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.
Joined: 29 Oct 2010 Posts: 121 Location: Puerto Rico
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.
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
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 ( reasonably of course )
( reasonably of course )