IBM Mainframe Forum

Which is why I'd always start with the compile listing. Let the compiler worry about all things, because the compiler does it exactly as the compiler does it. For you to get code to work exactly as the compiler does is 1) difficult and 2) silly, because of 1).

The compiler will "normalise" everything. No matter how coded, the compiler will produce what work it out and produce one single format, for PICture clauses, level-numbers, starting position of data-names, etc.

what i call data is a file that take things from the copybook. the first column is the name of every variable declared in the copybook the second is the type of the variable (i.e N for variable declare in PIC 9 in the copybook) the third is the position (from where position the variable start, p.s the first variable start at 1) and the last column is the length of the variable.

I hope things will be clear for you, so you can help me. Because i still block on convert in something like pic 9(02) or pic p(01)v9(02) to create my data in order to calculate my position and length

Please do not use attachments - a simple cut and paste using the code tags would have been much easier and use fewer bytes.

Is that dataset an input to your program or an output from it?

What is your block? PIC 9 is one byte, PIC 9(2) is 2 bytes PIC 9V9(2) is 3 bytes etc. Fairly simple.

I've chopped and pasted this from the "data-map" in a compile listing. First column is the level-number, second the data-name, sixth is the length and type and last is a better description of the type. If look at a data-map for your record-layout, you'll find you can get the start positions.

Try it. Have a look in the Enterprise COBOL Programming Guide for a description of the data-map, and how to get it. Then let the compiler do all the work.

You may need extra, but if you look at the full thing you'll see it has the source line-number on, and the source line-number of the next field, so if you want to know the number of decimals or the number of occurs you only need to look for exactly those things.

NicC wrote:Please do not use attachments - a simple cut and paste using the code tags would have been much easier and use fewer bytes.

Is that dataset an input to your program or an output from it?

What is your block? PIC 9 is one byte, PIC 9(2) is 2 bytes PIC 9V9(2) is 3 bytes etc. Fairly simple.

ok. the dataset is the output of my program. the input is the copybook; i'm trying to convert pic 99 or something like pic 9(02)v99 into pic 9(02) or pic 9(02)v9(02). Can U help please?

Can U help please?

the chances of getting help are pretty slim ...
You were already told to process the output of a compilation.
to properly parse a copybook You will have to rewrite a small part of the cobol compiler

I dont know how to put and image, but my program abend on s0c7 because of consecutive 9 in the definition of the copybook

Probably even better, though it didn't exist when I started processing copybooks this way, would be to look at the SYSADATA. Consult the Programming Guide as a starting point on that. Probably gives you the decimals and occurs that way as well.

Unless your copybooks are very formally defined (and they're not, you've got mixed PICture definitions already) then you are piling up a whole amount of work that, as enrico has said, duplicates, probably poorly, what the compiler does.

why not use a bit of lateral thinking an try to build on what somebody else has already done ???

see here

ftp://ftp.software.ibm.com/storage/dfso ... rttrck.pdf

PAGE 84

the task of creating DFSORT SYMNAMES is pretty similar to what You are trying to do

i don't want to do my processing in jcl but in COBOL. and i would like to know if dfsort work for a copybook in input?