performance

More events in the Gen Calendar

Don’t forget the first in the series of Jumar Solutions webcasts which will be starting in January. View the press release here, and sign up to the first of the webcasts about modernising your Gen systems.

I’ve seen some of the tooling that Jumar uses and in the right hands it can be powerful and exciting technology. But in the wrong hands, like any other tool, it can be potentially dangerous. Modernising Gen systems is easy, yet hard ! It’s easy because Gen is designed to be forwardly compatible with newer technologies and platforms, yet to leverage some paradigm changes, such as 3270 to Web, you need some assistance with the refactoring of the codebase – let Gen worry about generating code for the new platform – that’s straightforward – but refactoring code and converting older code to be web-friendly, or client/server friendly needs some help.

It’s great that there are tools in the ecosystem to migrate older languages (such as PL/1) and tools and services to evolve those applications forward toward the future.

Tuning AEFAD

When changing technologies, it’s all too easy to forget that those Asynchronous Daemon parameters that have been religiously tuned over the years need re-evaluating. This is especially true when changing database technology.

Take database connections, for example – each load module requires a connection to the database, but how long do those connections last, and how large are they – different load modules contain different numbers of open cursors, for example, leading to varying sizes of connections.

Does the -a parameter to AEFAD now hold true (this is the maximum number of load modules allowable per daemon) ?

The reason that this might be a bone of contention is that database connections require memory, and a change in technology will necessitate a recalculation of how much memory on the target database server is required. Reducing -a does indeed reduce the memory overhead, but at what cost ? Performance is usually the first thing to go here – additional paging and loading up of load modules as a result of a lower -a parameter.

Counteracting this may be a strategy to pre-load load modules into memory and lock them in, thus almost specifying the number of database connections required and thus the memory requried on the database server - but this also comes with an downside – if your application has more load modules than can be pre-loaded, then packaging needs to be changed to reduce the number of open connections – but again, at a development cost.

An invaluable tool in the tuner’s arsenal is aefc (see this post), but its no substitute for pre-thinking and performance and stress testing of a newly ported application.

Issues like re-planning the configuration of the Transaction Enabler are items on a porting project’s list that should probably come higher than they do, such that it is planned in from the start.

Gaining a DEEP understanding of the application and how it currently works is critical to the success of a porting project – allow time for this in any plan.

Performance tuning with Gen – thoughts…

Does Gen offer enough facilities to allow performance tuning of its applications ?

This loosely links back to one of my earlier posts on database independance, I suppose. Most of the performance issues that I have come across seem to be with database access. I know that a lot of performance issues are to do with badly written code, such as calculations done many times within a loop, that only need to be done once etc…, but aside from removing that sort of stuff, which, really can be considered the first stage of performance tuning of any app – not just Gen ones, what more could Gen offer ?
Well, I suppose that from a point of view of hacking code to modify SQL statements to dump their execution plans to a flat file, then it would be nice to have the ability, not only to generate with trace, but to “generate with stats” – which would, at the very least, switch “explain plans” on for all SQL statements. Also, those stats could contain “timing points” which could be inserted (possibly as new statements ???) into the code, and enabled through the “generate with stats” approach. These timing points would dump time information to a file, so that application engineers could see what was going on, and how long it took.

I understand that any collection of statistics modifies the way an application works, but used carefully could aid the performance engineer no end.

Disclaimer:
This kind of approach should NOT be used without the safety net of other methods of performance tuning – proper database design, proper configuration of machines etc etc!!!!

Jumar Solutions updates website and Gen complexity analysis

One of the most prolific CA Smart Partners (Jumar Solutions ) has updated their website with complete new look – Go and check it out !!

Why am I “plugging” a company in this blog entry rather than waxing lyrical about Gen ?

First of all, let me say that I have no connection with the company, save from experiencing them as a client (they have performed several tasks and delivered many training courses for the company that I work for).

Ok – down to the real stuff – I recently had reason to examine the complexity of a bunch of Gen procedure steps.

We looked at a number of mechanisms to determine the complexity of the code – using CRUD matrices, lines of code, etc etc. None seemed to give the right results. By “right” results, I had a feeling for what should turn out to be complex, what should be medium and what should be regarded as being simple. None of the metrics that I used effectively measured complexity and ranked the procedure steps in the order that I was expecting. One could argue that:

a) I should be using a tool to measure complexity and relying on what the tool says rather than “fixing it” by using my own intuition
b) Complexity is a very subjective term anyway, so what’s the use

In fact, the reason we wished to categorise the transactions in this way was to simulate loads on a new system by taking a small number of procedure steps and simulating a load of small, medium and complex transactions, slowly ramping up to a break point.

The reason that I mention Jumar here is that they have a tool which does EXACTLY what I wanted.

Jumar:Xtras has a model reporting module which we looked at an yes – it does what it says on the tin – it reports on your models!
It uses MS-Access and MS-Excel to store data which it culls from your model. It allows an analyst then, to look at the data and compile it and cross-reference it in many ways. Thus, you have a flexible, non-intrusive (i.e. it doesn’t tie up your encyclopedia) mechanism for reporting.
Anyway, the complexity of a procedure step can be analysed in whichever way you need – for exmaple:

CRUD
Number of Action Blocks called
Levels of nesting
Number of loops
Number of views
Number of entity types
Number of mathematical operations
….
….

and many others besides.

The point here is that the analysis is not down to the tool – the tool provides the raw data (which is so difficult to get from a CSE – note that it also works on a HOST CE too) and then the analysis can be done in a way that suits the organisation.

In summing up, then – Gen provides a model which contains all the code, definitions, window designs etc. This is a good thing as a single repository for a “system” is then accessible in a SINGLE way using toolsets. This lends itself to add-on tools, since ALL the information that you need to analyse when looking at that system is there in ONE PLACE – this is where Gen scores above most other development environments. To get back to the complexity question then, we developed a notion of what contributes to complexity which worked for us – maybe other things work for other organisations – whichever way you go, the model is the place to start, and there ARE tools out there to analyse it in MANY different and unexpected ways.