IBM Mainframe Forum

Hi everyone,

I'm working on a E15 exit routine that is intended as an utility, and I'd like to be able to use it in SORT operations on FB records with different length.

What I've done is to declare a IN-RECORD long enough to accommodate the maximum possible record length, but I'd like to know if it could cause problems when the exit routine is being used with smaller record's lengths. I've done some tests and it seems to work but I'd like to be sure it wont cause me any problems.

The exit routine is used to delete some records.

On a side note, if I know that on average the routine is going to delete about 75% of the records, is it possible to tell DFSORT to allocate less workspace (I'm using DYNALLOC)?. I know I can specify the number of records or bytes to be processed (FILSZ option), but I was looking for something like "so you think you need X word space? just make it X*0.25"

This is the actual code I'm using right now:

You are deleting (or ignoring) records in your exit, but how are you deciding what to delete?

As long as you define as far as any data items you use to identify what you want to ignore, then there is no need to define any more than that (assuming that you are not doing moves to/from the 01 in the Linkage Section).

When passing data to a Cobol program via a call, there is nothing which indicates the length of the field/group being passed. So in your called program, you can define it any way you want. Obviously, you will "want" a way that works.

In your example, there is just no need to define anything beyond any fields in the record that you actually use (which will assume that they are in the same place, no matter what the length of the record - "something" must be, else you will be lost).

As to the second part of your question, I don't know. Can you find any relevant documentation on the DFSORT web site?

On a side note, if I know that on average the routine is going to delete about 75% of the records, is it possible to tell DFSORT to allocate less workspace (I'm using DYNALLOC)?. I know I can specify the number of records or bytes to be processed (FILSZ option), but I was looking for something like "so you think you need X word space? just make it X*0.25"

There's no way to tell DFSORT to use x% of the work space it thinks it needs.

BillyBoyo wrote:You are deleting (or ignoring) records in your exit, but how are you deciding what to delete?

As long as you define as far as any data items you use to identify what you want to ignore, then there is no need to define any more than that (assuming that you are not doing moves to/from the 01 in the Linkage Section).

When passing data to a Cobol program via a call, there is nothing which indicates the length of the field/group being passed. So in your called program, you can define it any way you want. Obviously, you will "want" a way that works.

In your example, there is just no need to define anything beyond any fields in the record that you actually use (which will assume that they are in the same place, no matter what the length of the record - "something" must be, else you will be lost).

Thanks BillyBoyo,

The actual positions used to detect if the record has to be ignored are defined by the user. The routine uses a "DD *" similar to DFSORT's SYSIN.

Aditionally another dataset is used within the routine (OPEN/READ/CLOSE).

Making sure that those positions don't do beyond the record length is up to the user. But I need to make sure that even if I define a linkage section larger that the actual data "passed" by DFSORT it won't cause any problems (for example by defining a linkage area that oversteps some short of restricted memory area?!) as long as the user defined positions are within the actual record.

Frank Yaeger wrote:

On a side note, if I know that on average the routine is going to delete about 75% of the records, is it possible to tell DFSORT to allocate less workspace (I'm using DYNALLOC)?. I know I can specify the number of records or bytes to be processed (FILSZ option), but I was looking for something like "so you think you need X word space? just make it X*0.25"

There's no way to tell DFSORT to use x% of the work space it thinks it needs.

Thanks Frank,

That's what I thought. I guess I'll have to do with the FILSZ option.

aaa wrote:[...]

The actual positions used to detect if the record has to be ignored are defined by the user. The routine uses a "DD *" similar to DFSORT's SYSIN.

Aditionally another dataset is used within the routine (OPEN/READ/CLOSE).

Making sure that those positions don't do beyond the record length is up to the user. But I need to make sure that even if I define a linkage section larger that the actual data "passed" by DFSORT it won't cause any problems (for example by defining a linkage area that oversteps some short of restricted memory area?!) as long as the user defined positions are within the actual record.

Yes, you can define it bigger, there is no problem in the definition. Then, as you say, up to the user. Have you checked if the exit record length is available for F records? If it is, I'd suggest using it to validate the maximum position of the user parameters.

BillyBoyo wrote:

aaa wrote:[...]

The actual positions used to detect if the record has to be ignored are defined by the user. The routine uses a "DD *" similar to DFSORT's SYSIN.

Aditionally another dataset is used within the routine (OPEN/READ/CLOSE).

Making sure that those positions don't do beyond the record length is up to the user. But I need to make sure that even if I define a linkage section larger that the actual data "passed" by DFSORT it won't cause any problems (for example by defining a linkage area that oversteps some short of restricted memory area?!) as long as the user defined positions are within the actual record.

Yes, you can define it bigger, there is no problem in the definition. Then, as you say, up to the user. Have you checked if the exit record length is available for F records? If it is, I'd suggest using it to validate the maximum position of the user parameters.

As far as I know the record length is only available for VB records. Not only that, but it's located after the actual record so I'd be impossible to find it.
Guess I have reached a dead-end

What is it you actually want your E15 to do? Ie, what is it that DFSORT doesn't support that you need?

If in your input data you can have a card for the record-length, then maybe not so bad. How to match it to the DFSORT parameters? Have the DFSORT cards on a file, have a little program which reads that file and your file and ensures that the record sizes are the same. Reject your file if not.

Then, if you want to do MOVEs from the Linkage you will at least know the length to move.

But, be sure you're not re-inventing the wheel. You are talking of doing something as a "utility", but what is it that you are doing like that the DFSORT can't?

Just to emphasise, the length you define the record in the Linkage Section will not affect anything in any program which is calling you (this case, DFSORT).

What is important is to not access data out of the size of the record that is passed to you. Why? Because you end up either trying to access storage which you are not allowed to, or accessing storage which is nothing to do with the 01 in your Linkage.

This applies to all called programs, not just your example here, or E15s, or whatever.

How do you go about this? It is actually both more tricky and less tricky than it seems.

It is "more tricky" because Cobol does not give you the length of the data being passed in the call, only the address of the first (and sometimes only) byte.

It is "less tricky" because usually you have control over both the calling and the called program and you make sure.

Here, you don't. So you have to be careful.

You need to know the length of the record, possible method already suggested.

You MUST NOT in any way access data beyond that length. If you want to move the whole record to/from Linkage, then you need a method, you cannot MOVE the 01-level.

Not a "dead end" but a thinking time.

[quote="aaa
[...]

As far as I know the record length is only available for VB records. Not only that, but it's located after the actual record so I'd be impossible to find it.
Guess I have reached a dead-end [/quote]

Forgot to mention about this. The record-length for a variable-length record is the parameter (on your PROCEDURE DIVISION USING) after the record-area, so it is not impossible to find. It would be nice if DFSORT gave it to you, but I guess it doesn't because for a variable-length record, which you might be inserting, DFSORT needs to know the length. You could also re-format (shorten or lengthen (OK, check about this last one)) the record passed by DFSORT. So DFSORT needs to know the length that YOU think the current record is, it is passed to you with the length of the current record.

For a fixed-length record, DFSORT already knows the length, so doesn't need you to ever tell it (because the length is fixed).