IBM Mainframe Forum

BillyBoyo wrote:Forgot to add, the DFSORT people will maybe be looking this was at San Jose work hours, and if it can be done, they are the guys who can do it.

imbmainframeforum.com is for students and beginners, so forgive any assumptions we make based on that.

You might want to check on imbmainframes.com.

You are also very welcome to stick around and answer the questions of starters, if that takes your fancy.

That's the first time I noticed that tagline

I'll check that out, thanks!

Nuadha wrote:Sorry, I should say "less flexible" rather than clumsy

Each record with it's sub record is based on this template:

Select all

01  XB-SUB-RECORD.   
    05 XB-SUBRECORD-HEADER.
       07 XB-SUBRECORD-NAME         PIC  X(08).
       07 XB-SUBRECORD-VERSION      PIC  X(03).
       07 XB-SUBRECORD-DATA-LENGTH  PIC S9(04) COMP.
    05 XB-SUBRECORD-DATA            OCCURS 1 TO 700 TIMES
                                    DEPENDING ON SUBRECORD-DATA-LENGTH.

A "deblocking" system in our COBOL modules already exists that does what I'm trying to do, but there's talk of change to the record lengths, and as I'm currently developing a new utility, I was looking for a way of handling what I'm trying to do above without having to change COBOL in the future, i.e. make it less dependent on fixed lengths (of the subrecords).

Now you only have one ODO to amend. Starting from zero (after any fixed portion of the main record) until fixed portion + variable already moved + fixed of mini + variable of mini is equal to the record length of the main record.

MOVE MINI-RECORD TO DEBLOCKED-RECORD (presumably also ODO, so set that size first).

Should always work as long as the records adhere to the definition you've already given. I'd check the subrecord-name each time and also that the version has a reasonable value and that the subrecord-data-length does not go over the end of the record, so basically checking that the file is consistent as far as you are able.

Thanks, we're creating the record like that in one system, then decoding in another (though the "decoded" output is never saved), so the COBOL portion is okay, other than being dependent on the 700 length. I was hoping with a system that could parse records by the record name, I could build this to avoid relying on the length of the sub-record.

I see. But you are then reliant on the sequence of characters not being valid elsewhere in the records - ever. And you have in some way to still calculate the lengths (even if not explicit, and not in Cobol), which seems a pity if the lengths are already sitting there. With the self-validation thrown in, I'd be happy with it done that way.

As I say, maybe the DFSORT guys will come up with something that does it how you want.

I understand, and given the sequence of characters used, and the data within each sub-record, chances of it ever occurring natural in another context is very slim. If FINDREP could break the record using /, then I wouldn't be dependent on the lengths at all, but if that's not an option, I'd stick to the same solution you're suggesting, as I think it would be the best way of dealing with it otherwise.

FINDREP cannot break records using /.

You might be able to do this kind of thing with DFSORT's PARSE function, but it only allows up to 100 fields (%00-%99) and you need 300 so that won't work.

Thanks to you both for your help. I'll stick with the COBOL solution already. Might have another question on the part I need to do next, but I'll do so in a different thread if I need any advice, thanks!

Hello,

I'll stick with the COBOL solution already. Might have another question on the part I need to do next, but I'll do so in a different thread if I need any advice

And this new COBOL question will be better served in the COBOL part of the forum

Nah, it's not a COBOL question, next part is a SORT operation with a bit of JOINKEYS that's a whole new level above my previous experience