IBM Mainframe Forum

Hi,

I have a RECFM VBfile that consists of variable length records, with an LRECL of 28006. Each record is made up of a length indicator (nn), followed by a string of individual sub-records, each starts with a certain 8 character identifier that have the first four characters in common e.g.



Each record will be guaranteed to have COPY0001 and COPY0002, but may contain any amount of other COPYxxxx records, up to 300 records total, but each is variable and will have between 20 and 700 characters. The process creating this file guarantees either of these conditions aren't exceeded, as obviously 300 x 700 would result in almost ten times the LRECL, so that's not an issue.

What I was hoping I might be able to do is do a FINDREP, but use the / to break the records apart - even if it meant losing the first four bytes that identify a new sub-record.

My aim is to end up with a VB file of LRECL 719, to include the RDW, and a 10 digit key from the COPY001 record - it's in a guaranteed fixed position.


Though thanks to the great documentation, I'm comfortable with doing everything, and it's only the splitting that's still stumping me.

I tried this:


but it didn't work, as I was kind of expecting anyway. Am I barking up the wrong tree here, and should be trying something else maybe?

Out of interest, what did it do?

If it were to work (as in make a new line) perhaps you could even reatain the "COPY" text.

Have a look back at the manual and read up on the \. See where it can be used, and if you feel it can be used in your situation.

Be careful that the text COPY can't legitimately appear elsewhere in a record.

I don't know what the length limits for PARSE are, have you checked on that?

It didn't like the "/" (sorry, I mistakenly used \ once or twice above):



I wasn't using PARSE as I was under the impression that I would have to know the number of sub-records before splitting, whereas there could be a theoretical minimum of around 10, and an absolute maximum of 300 (though usually it's around the 40 - 60 mark).

Also just about COPY, the identifier isn't actually "COPY", it isn't an actual English word (XBCA).

Just to add, I'm not entirely sure how to find "/" in the manual as I'm not sure what the proper term for it is. The character itself shows up hundreds of times, as you might imagine.

Try looking for BUILD to find out what to call it.

I found it under OUTFIL - OUTREC/BUILD (search for ///// here). Looking increasingly like it's likely not possible to use it with the FINDREP.

40-60 would be a lot of conditions after the parse.

Do you speak Cobol?

I've seen a few instances of 230 occurrences, so it can be a lot more than 40 - 60. I speak COBOL rather well, and there is an existing solution, but it's clumsy and I was hoping there might be a way around it, but thanks for your help.

Well, there is a non-clumsy way in Cobol.

I was guessing from your professional approach to this that you might do

EDIT: Sorry, clicked submit without finishing.

Have you considered using OCCURS DEPENDING ON?



Something like that, details depending on how your exact record is set up.

You take care of the two depending on items. Then MOVE MINI-RECORD to wherever-you-want.

For record length of current record, I guess you know how to get that

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.

Sorry, I should say "less flexible" rather than clumsy

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


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).