View previous topic :: View next topic
|
Author |
Message |
340662
New User
Joined: 23 Apr 2011 Posts: 5 Location: india
|
|
|
|
I'm facing problem on occur depending on fields. The requirement of my prog is to convert occur depending on fields to fixed occur statements. I have input file in VB with copybook of that file.
The copybook contains three place where there is occur depending on clause.
1. A occurs 0 to 20 times depending on P.
2. B occurs 0 to 100 times depending on Q.
3. C occurs 0 to 10 times depending on R.
Also, there are comp fields in the occur statement fields where im facing problem in calculating field length.
The requirement is to convert this file in FB with fixed occur statements without depending on condition.
Please suggest me the solution and sample prog in this regards.[/b] |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
340662 wrote: |
I'm facing problem on occur depending on fields. The requirement of my prog is to convert occur depending on fields to fixed occur statements. I have input file in VB with copybook of that file.
The copybook contains three place where there is occur depending on clause.
1. A occurs 0 to 20 times depending on P.
2. B occurs 0 to 100 times depending on Q.
3. C occurs 0 to 10 times depending on R.
Also, there are comp fields in the occur statement fields where im facing problem in calculating field length.
The requirement is to convert this file in FB with fixed occur statements without depending on condition.
Please suggest me the solution and sample prog in this regards.[/b] |
It won't be as bad as it seems to you. You don't, yourself, need to calculate the length of anything. The compiler does all that.
The record layout can be identical except removing the "0 to" and "depending on x" bits.
Move all the stuff which is not in the ODOs from input to output. Do three loops to move the data from the ODOs. Remembering might be zero.
Write the output record.
Validating the change is another matter. I doubt, but I don't know, that any compare utility in the world is going to be able to handle your input.
What Cobol are you using? I thought the "complex occurs depending on" had been left in the waste-bin between versions 2 and 4. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Bill Woodger wrote: |
Move all the stuff which is not in the ODOs from input to output. Do three loops to move the data from the ODOs. Remembering might be zero.
|
I notice that having thought to say "it goes without saying" I forgot to say it, so it really did go without saying. And, looking at it again, maybe it doesn't go without saying anyway.
It is important to set your OCCURS in your output record to initial values each time before you store the data.
I may well be being pessimistic about your comparing options. I can't say I've ever used three ODOs in the same table, but for a computer there is nothing too difficult. If your compare understands Cobol, then the compare should work.
Your "downline" work should be surprisingly simple. For this file, and as long as the technique hasn't been repeated in other outputs or otherwise in the data division, just recompile and test. |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
Change A OCCURS 0 TO 20 TIMES DEPENDING ON P
to A OCCURS 20 TIMES
Get rid of P unless it is required in some other context.
Repeat for B and C.
Look at the manual for the number of bytes your COMP fields take or just compile the thing and look at your compile messages and adjust whatever (RECORD CONTAINS xyz BYTES or JCL LRECL or both) depending on what you find. That gives you and FB record. You will need to write a conversion program to convert the VB dataset to FB and you will need to change the processing of the tables (presumably). |
|
Back to top |
|
|
340662
New User
Joined: 23 Apr 2011 Posts: 5 Location: india
|
|
|
|
I'm thinking to move the fields one by one in work storage section where i will use if condition for Y. But i had one more ques in mind...tht if P = 3 Can i move the fields one by one or i can directly move A to working storage ...n rest occur value i.e. 4 to 20 will be blank...this will also reduce my prog length to greater extent.
Please correct me if im wrong at any stage or if something is not clear. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
340662 wrote: |
I'm thinking to move the fields one by one in work storage section where i will use if condition for Y. But i had one more ques in mind...tht if P = 3 Can i move the fields one by one or i can directly move A to working storage ...n rest occur value i.e. 4 to 20 will be blank...this will also reduce my prog length to greater extent.
Please correct me if im wrong at any stage or if something is not clear. |
I doesn't matter if the record you are constructing is in the working-storage, and WRITE FROM, or the file section. Up to you.
From your earlier description, A is the item which occurs. So, no, you can't just move A. If P is 3, you have to move A three times, with a subscript/index set to a different, appropriate, value each time.
I wouldn't worry about the length of your program. It is all "editor" stuff. Copy the copybook into your procedure division. Change all the level numbers to "MOVE". R(epeat) each line. X(clude) the first of each pair of lines. Change the remaining visible MOVE to TO. Show everything again. Use erase-to-end-of-line and the arrow keys. Presto.
Then three loops to put around the MOVEs for the items which occur.
Don't forget to initialise your output occurs items. Not vital, as the count will always tell you, but if there is something that looks like real data in them, someone will wonder if the counter is OK. Also not good for "data protection" sort of stuff. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I had submitted an Assembler sub-program to several IBM-MF colleagues last week or so, to test this sub-program because I'm restricted from doing so in my environment.
This sub-program is called from a given Batch COBOL program and it returns the number of records in a KSDS or ESDS file along with the average record length of this KSDS or ESDS file.
Once you know how many records there are, you can move the 01 level definition to LINKAGE and allocate the required amount of storage, using the LE Callable Service routine "CEEGTST".
With that, you can have a TRUE "ODO" array in LINKAGE, effectively defined as a "Dynamic Table/Array'.
You can make your ODO as high as the compiler will accept. Then, it is unlikely you'll have you worry about ever exceeding the max ODO.
From the feedback I've received, the sub-program works, although this is the first go-around and some "tweaking" could prove to be beneficial. But, like anything, it needs to begin somewhere.
If you'd like, send me a PM and I'll send the sub-program for your review.
There are comments for its usage in the source, plus some EXAMPLE code.
No warranty. Accepted as-is....
Bill |
|
Back to top |
|
|
340662
New User
Joined: 23 Apr 2011 Posts: 5 Location: india
|
|
|
|
Can anyone please resolve this :
"REDEFINES" SUBJECT "X" CONTAINED AN ""OCCURS DEPENDING ON" CLAUSE OR WAS VARIABLE-LENGTH.THE "REDEFINES" CLAUSE WAS DISCARDED. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
You are redefining a table, or part of a table, which has, subordinate to it, OCCURS DEPENDING ON. You are, I believe, no longer able to do this. You have to find another solution, or, maybe, try with the COMPR2 compiler option, since this is a one-off program. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Or not. COMPR2 (typo) is CMPR2. Depends what compiler you are using. Not available in Enterprise Cobol.
I assume this is part of your same task. Why/what are you redefining?
You read the file with ODO. Move all the non-occurs items to your new record layout (with straight OCCURS). Set the occurs items in the new record to initial values. Do three loops to move the data from the the ODOs. Write out your new record. Keep doing all that until no more input records. Close the files. Write out some nice totals, with dates, whatever is your site standard.
Unless you are trying to do something else along the way, it really is as simple as that. |
|
Back to top |
|
|
|