INIT as opposed to MOVE

, , ,
1

Hi,

I have been tasked with looking at code and trying to ‘speed it up’.

As part of that task, I found a number of places where a literall is moved into a field, (mainly error messages).

I was wondering which of the following was more efficient;
01 MESSAGE (A4) INIT <‘text’>
…
MOVE MESSAGE TO OUTPUT

or
01 MESSAGE (A4) INIT <‘text’>
…
OUTPUT := MESSAGE

or
MOVE ‘TEXT’ TO OUTPUT.

Thanks

2

Hi Rambo

Last I checked,

MOVE MESSAGE TO OUTPUT and OUTPUT := MESSAGE

produced the same object code. So, no difference there.

The INIT clause is a compile time “MOVE”. No “cost” at execution time.
MOVE MESSAGE and MOVE ‘TEXT’ should produce the same object code.
MOVE ‘TEXT’ , at compile time, will produce an “internal” variable, as opposed to
the INIT of MESSAGE, which will produce a user defined variable.

In brief, you will not be improving efficiency by looking here. You should look elsewhere for improvements.

steve

3

Thanks Steve,

I guessed as much, but it is good to have confirmation.

Unfortunately the piece of code I am currently looking at does not really have a great deal to it. It has an Histogram(1) with a starting from field and a to field. A find on a superdesciptor and a read again using a superdescriptor. The parameter is an 01 level of a structure but the sublevel variables are not redefined.

Perhaps on that point,
I read the bit about using redefines within a parameter list, to save on the number of addresses passed. Does this still apply to a structure? e.g.

01 Var1.
02 Var2 (A5)
02 Var3 (N5.3)
02 Var4
03 Var5 (A4), etc.

or
01 Var1 (Ann)
01 Redefine Var1
02 Var2 (A5)
02 Var3 (N5.3)
02 Var4
03 Var5 (A4), etc.

Also, I do not know if this is where to ask the question, but does Freeze Frame - a product from Macro 4 - analyse Natural programs, or will it produce a generic for a CICS transaction?

Thanks

4

Hi Rambo,

To make it easier to “talk” about, consider:

1 #group
2 #ga (a5)
2 #gb (n5.3)

versus

1 #field (a13)
1 redefine #field
2 #fa (a5)
2 #fb (n5.3)

The obvious stuff first. #group is NOT a field. It has neither format nor length. I
prefer the term “group name” for such an item (group field being a misnomer,
since it is not a field).

Group names in Natural are abbreviations (one exception to this, when used in
a READ WORK FILE RECORD statement). At compile time, Natural basically crosses out a Group name and replaces it with the component field names.
Thus, WRITE #GROUP becomes WRITE #GA #GB.

By contrast, #FIELD is , well, a field. It has format and length. Note that WRITE #field will not have a blank between #fa and #fb. By contrast, WRITE #group will have a blank between #ga and #gb.

In terms of efficiency, as you noted, #field would be more efficient than #group when used as an argument to be passed, say to a subprogram. That said, the difference is fairly small. However, if there were twenty “sub fields” involved, the performance difference would really suggest #field, not #group.

Groups are useful when there is a need for a statement such as MOVE BY NAME with just a subset of the fields in the Group. Of course, the same efficiency would result from individual MOVEs of the sub fields.

I have no knowledge of Freeze Frame.

steve

5

Thanks once again for the quick response.

I understand now.

Best Regards

6

How about using SYSERR in this case if mainly error messages to be output, of course with error number in MOVE?

7

Are you having performance issues? High CPU usage? Long running transactions? Slow screen response? Before doing tuning, you need to know what the problem is!

The items you mention don’t sound like things that would cause a response time issue. You haven’t really given enough information: are there WHERE clauses on the HISTOGRAM/FIND/READ? A poor combination of database access and WHERE clause can send the most innocent looking program off into response time hell. Two things often happen here: 1) there are a lot of values/records returned by the HISTOGRAM/READ range, but the WHERE clause suppresses most of them 2) the end of the HISTOGRAM/READ range is the end of the file, but the WHERE clause prevents evaluating the exit condition (not usually applicable to a THRU clause).

8

To second what Douglas said.

Many, many years ago, when I was still in school, my father would help me with homework. His favorite acronym, which I unfortunately would need constant reminding of, was RTP; Read The Problem.

Eventually, I got it. Since then, however, I have discovered in the business world, ETP is probably even more important. Reading The Problem is of no use if someone does not Explain The Problem.

If you do not have a monitor of sorts to narrow down your search, you could at least use SETA. SETTIME, before a “suspect” loop, then after the loop write out something like
WRITE ‘time for FIND loop’ *timd (seta.)

This may allow you to narrow down the problem area sufficiently so that the performance problem will be obvious. Depending on your platform, it may also be possible to write out the CPU time for a loop (or even a group of statements). This too would be quite helpful.

There are a lot of very experienced Natural people that read this forum. In toto, they have seen most every bit of inefficient code it is possible to write. But RTP’ing will not help if you do not ETP. :slight_smile:

steve