IBM Mainframe Forum

However, if, just for fun, I put 300 01 levels in the linkage section, but only one on the procedure division using, that will work as long as there is one on the call using.

Sure.... although a bit "unusual" you can code items in the linkage section even in "main" programs. A "classical" use could be to point to an area that is supplied by an assembler program you called. But now, since the LE was introduced, you can call LE services to obtain a memory area and then assign its address to your item in linkage section. Or, since Cobol Enterprise 3.4, you can even point your items in linkage section to an address in working storage. This enables you, for instance, to define a "dummy section" (to quote assembler...) and point it wherever you want in working storage.
For instance, in a project i'm currentluy working on, somebody decided that routines MUST return data in a 20k block; the caller has to move those 20k in the routine specific area that is defined in another copybook. To avoid moving 20k blocks back and forth, in the main programs I coded I did something like this:



That will save a bit of CPU time.....
But of course there are other interesting use of this!!

Zio69 wrote:A "classical" use could be to point to an area that is supplied by an assembler program you called.

My original point was that just having extra, usued, stuff as 01's in the linkage section isn't going to cause an abend (wheras, mismatched numbers of parameters on the call "using" and procedure division "using" can.

Do you mean the assmbler program that called your cobol main program, or an assembler program you called to sneakily put some addressability to items in your linkage section which didn't previously have addresses?

Also, that's the second reference to LE I've seen today. I'll have to find out what that is

Zio69 wrote:

Select all

       WORKING-STORAGE SECTION.
       01 routine-area.
          03 input-area       pic x(10000).
          03 output-area      pic x(20000).
.....
       LINKAGE SECTION
       copy whatever.
.....
      PROCEDURE DIVISION.
          SET ADDRESS OF WHATEVER TO ADDRESS OF OUTPUT-AREA.

I don't get this yet. This is a main program. It has a linkage section. You make the address of the item in the linkage section the same as the address of output-area. So far, it just looks like a REDEFINES, although it doesn't have to immeditately follow the item at the same level that it is redefining, and indeed it is even in a different section.

I'm not sure how you then use it. I guess I'm missing something.

Certainly, as you have pointed out before, MVCLs are time consuming. I'd say, if you have performance problems yet the program looks OK, look out for MVCLs and see what you can do to avoid some. A CALL/GOBACK sequence is quicker than an MVCL, at the very least when it gets to a certain length (a long time ago, and I never tested to find the exact point where it wins out, but the change was so dramatic, it might be 4096 bytes!). I took a CPU-bound job, just making this change, and when it went live, OPS thought they'd accidently run a tape copy instead of our main update run.

Hello,

Also, that's the second reference to LE I've seen today. I'll have to find out what that is

LE is "Language Environment".

Unless your system is using an antique compiler, you have been using LE for years. Look at a linkedit and see if there are CEE* modules. These are LE modules. In the linkedit output there will be entries like:
This is only a sample from one compiple. . .

dick scherrer wrote:Unless your system is using an antique compiler, you have been using LE for years.

Thanks for the info. It is me who is the antique. Now to find out what this new-fangled "Language Environment" does for new.

BillyBoyo wrote:Do you mean the assmbler program that called your cobol main program, or an assembler program you called to sneakily put some addressability to items in your linkage section which didn't previously have addresses?

The second one.... but no sneaking, please!! (Ok, a casual sneaking here and there is allowed). For instance, the guys I'm working for these days, they have a calendar routine that returns an array of 365/366 elements, each containing date, day of week, festive status and so forth. Problem is.... you don't pass the area to the routine, the routine itself issues a GETMAIN and returns the pointer to the area. It's a quite old piece of code, written in assembler when everything was mostly written in assembler. In cobol, you must define the array in LINKAGE, otherwise there's no way you can address the array.

BillyBoyo wrote:I don't get this yet. This is a main program. It has a linkage section. You make the address of the item in the linkage section the same as the address of output-area. So far, it just looks like a REDEFINES, although it doesn't have to immeditately follow the item at the same level that it is redefining, and indeed it is even in a different section.

Since you're familiar with assembler, defining an item in LINKAGE SECTION without giving it addressability is like defining a DS: it's just an area definition, but it has no address until you assign it one. So it's not exactly a redefine.... it's sort of.

In a perfect world, "whatever" would start with a 03 level redefining output-area. Since I'm not on the analisys side of this project, I don't know why "whatever" (and all other copybooks) start with a 01 level.
So, whenever a routine is called one has got to MOVE output-area to whatever. And that's a 20k mvcl!!! Since everything is "routinized" (access to db/2 tables, file i-o, common date calculations) those mvcl do have a negative impact on performance. So I set out to find a way to preserve copybooks intact while shaving off some cpu time. That's why you put "whatever" in linkage section: this way it can be given an address; in my case the address of the output-area.
.... but this is not the only case where I've used this (not-so) "sneaky" trick!

OK, I get your date example. The ASM returns the address of the table whose storage it acquired with GETMAIN, and then you can use that address to give an item defined in LINKAGE which isn't referenced on the procedure division USING. I was worried that the ASM was trying to "patch" the address in the cobol caller (which would be sneaky).

In your second example, I still don't see why you can't just use the 03 on the call USING. Scrub that, it just clicked as I was writing it. You actually want to use the data-names in your calling program. Because the copybook has the 01 hard-coded, normally to be able to use the individual data-names you'd have to do the cobol MOVE (which then generates the heavy MVCL).

As you point out, they've made a mess for themselves "designing" things that way. Are "they" good guys or bad guys, by which I mean are they able to listen, or do they just think they're so clever no-one can teach them anything. If they are good, I'd try to talk to them, if they're doing the call-and-move any significant number of times, it's going to be a chunk of their CPU time every day. If they are bad guys, and you're not there long, I'd think about a memo, sent on the day I left, to the boss of the highest bad guy, explaining what he is responsible for Oh, get your reference letter first...

I would clearly document what you have done.

I assume you can nest copybooks (I've never really used them, or cobol I/O for that matter). It shouldn't be an onorous change. Can even be a "standing order" - when you change a program for some reason, change this if it not done already, sort of thing.

I was told, when I started programming, that the machine I was using was so big, I needn't worry about the "performance" of my code, like in the old days. Well, that wasn't quite true, and I guess it still isn't. If you do the little things right, it adds up.

Zio69 wrote: Are "they" good guys or bad guys, by which I mean are they able to listen, or do they just think they're so clever no-one can teach them anything.

Well, for a good party it takes all kind... and that's exactly what we've got here. There are the "internal" guys, who are usually "suspicious" (or should I say skeptical?) about anything that is different from what they've got. There are IBM folks, who designed the whole architecture, (so the 01 hard-coded levels is their fault) and are beginning to worry as the first batch simulations are running WAAAAAAAAAY long (nightly job, but they're turning into early-birds..... while they should finish in a couple of hours tops). They are willing to listen, though..... Then there are the JAVA folks, but they are actually the nicest bunch (they'll take almost anything you throw at them). Lastly, there's truly yours.... the mad scientist for hire! I was originally hired to convert a few assembler programs to cobol, but when they noticed that the COBOL versions run faster than their assembler counterparts they thought they could use me for something else too.... so whenever there's something boring, tedious or just needing a fine tune they invite me at the party.