Home > Archive > Cobol > April 2005 > File conversion
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| gcotterl@co.riverside.ca.us 2005-04-23, 3:55 pm |
| How can I convert records (LRECL = 214) with this format:
FIELD LEVEL/NAME --- PICTURE-- START END LENGTH
3 ACT-RECORD X 1 1 1
3 ACT-ASMTNBR 9(9) 2 10 9
3 ACT-TAXYEAR 9(4) 11 14 4
3 ACT-COLTYPE 99 15 16 2
3 ACT-COLNBR 9(7) 17 23 7
3 ACT-COLDATE 9(9) 24 32 9
3 ACT-TRANBR 9(6) 33 38 6
3 ACT-TAXTYPE 9(7) 39 45 7
3 ACT-TAXTYPE-AMT 9(9)V99 46 56 11
3 ACT-DELPN 9(5)V99 57 63 7
3 ACT-COST 99V99 64 67 4
3 ACT-ACCRUED-PEN 9(5)V99 68 74 7
3 ACT-BILL-FY 9(4) 75 78 4
3 ACT-EFF-FY 9(4) 79 82 4
3 ACT-SPY-PARENT-ASMT 9(9) 83 91 9
3 ACT-RED-PEN 9(9)V99 92 102 11
3 ACT-RED-FEE 999V99 103 107 5
3 ACT-EQUITY-FEE 999V99 108 112 5
3 ACT-TAXDEED-FEE 999V99 113 117 5
3 ACT-STSAMT 9(9)V99 118 128 11
3 ACT-REDEM-DATE 9(8) 129 136 8
3 ACT-ACCTRAN-CODE X 137 137 1
3 ACT-PAYSOURCE 99 138 139 2
3 ACT-CASHIER-NBR XX 140 141 2
3 ACT-CASH-CHECK-AMT 9(7)V99 142 150 9
3 ACT-USER-ID X(4) 151 154 4
3 ACT-FUNDNBR 9(11) 155 165 11
3 ACT-NSF-FILENBR 9(5) 166 170 5
3 ACT-NSFAMT 9(9)V99 171 181 11
3 ACT-TRANSFER-AMT 9(9)V99 182 192 11
3 ACT-DIFF-AMT 999V99 193 197 5
3 ACT-FEES 999V99 198 202 5
3 ACT-23-TRUSTAMT 9(7)V99 203 211 9
3 ACT-SEQUENCE X 212 212 1
3 FILLER XX 213 214 2
to records (LRECL = 160) with this format:
FIELD LEVEL/NAME --- PICTURE-- START END LENGTH
3 ACT-RECORD X 1 1 1
3 ACT-ASMTNBR 9(9) 2 10 9
3 ACT-TAXYEAR 9(4) 11 14 4
3 ACT-COLTYPE 99 15 16 2
3 ACT-COLNBR 9(7) 17 23 7
3 ACT-COLDATE 9(9) 24 32 9
3 ACT-TRANBR 9(6) 33 38 6
3 ACT-TAXTYPE 9(7) 39 45 7
3 ACT-TAXTYPE-AMT S9(9)V99 COMP-3. 46 51 6
3 ACT-DELPN S9(5)V99 COMP-3. 52 55 4
3 ACT-COST S99V99 COMP-3. 56 58 3
3 ACT-ACCRUED-PEN S9(5)V99 COMP-3. 59 62 4
3 ACT-BILL-FY 9(4) 63 66 4
3 ACT-EFF-FY 9(4) 67 70 4
3 ACT-SPY-PARENT-ASMT S9(9) 71 75 5
3 ACT-RED-PEN S9(9)V99 COMP-3. 76 81 6
3 ACT-RED-FEE S999V99 COMP-3. 82 84 3
3 ACT-EQUITY-FEE S999V99 COMP-3. 85 87 3
3 ACT-TAXDEED-FEE S999V99 COMP-3. 88 90 3
3 ACT-STSAMT S9(9)V99 COMP-3. 91 96 6
3 ACT-REDEM-DATE 9(8) 97 104 8
3 ACT-ACCTRAN-CODE X 105 105 1
3 ACT-PAYSOURCE 99 106 107 2
3 ACT-CASHIER-NBR XX 108 109 2
3 ACT-CASH-CHECK-AMT S9(7)V99 COMP-3. 110 114 5
3 ACT-USER-ID X(4) 115 118 4
3 ACT-FUNDNBR 9(11) 119 129 11
3 ACT-NSF-FILENBR 9(5) 130 134 5
3 ACT-NSFAMT S9(9)V99 COMP-3. 135 140 6
3 ACT-TRANSFER-AMT S9(9)V99 COMP-3. 141 146 6
3 ACT-DIFF-AMT S999V99 COMP-3. 147 149 3
3 ACT-FEES S999V99 COMP-3. 150 152 3
3 ACT-23-TRUSTAMT S9(7)V99 COMP-3. 153 157 5
3 ACT-SEQUENCE X 158 158 1
3 FILLER XX 159 160 2
| |
| Robert Jones 2005-04-23, 3:55 pm |
| As this newsgroup isn't yet subscribed to by computers instead of
people, a simple "please" would seem to be in order for common
courtesy.
To answer your question
this seems to be a good case for MOVE CORRESPONDING, many organisations
don't like this construct as a general rule, but this situation appears
to be an obvious candidate. You will have to first check that all
fields fully correspond in respect of data names and convertibility of
formats, I haven't done a detailed check on the two record layouts
myself.
It would also be a good idea to initialise the destination record by
moving spaces to it, so the filler always contains spaces, alternately,
rename the filler such that the same name is used in both layouts.
A di vantage of using MOVE CORRESPONDING is that it is harder to
debug.
Also, programmers making future amendments to the program may not make
the appropriate changes to both record layouts, but then even if they
used lots of independent MOVEs, they still might not do that correctly
either.
Regards
Robert
| |
| docdwarf@panix.com 2005-04-24, 3:55 am |
| In article <1114276347.284485.109550@o13g2000cwo.googlegroups.com>,
<gcotterl@co.riverside.ca.us> wrote:
>How can I convert records (LRECL = 214) with this format:
[snip]
>to records (LRECL = 160) with this format:
There are a few ways... but I'll go out on a limb here and say 'by writing
a program which does so'.
DD
| |
| HeyBub 2005-04-24, 8:55 pm |
| docdwarf@panix.com wrote:
> In article <1114276347.284485.109550@o13g2000cwo.googlegroups.com>,
> <gcotterl@co.riverside.ca.us> wrote:
>
> [snip]
>
>
> There are a few ways... but I'll go out on a limb here and say 'by
> writing a program which does so'.
I think the OP was hoping for something along the lines of "magic," or maybe
"miracle." Certainly not "writing a program."
| |
| docdwarf@panix.com 2005-04-24, 8:55 pm |
| In article <116nrp6qvk85m45@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>docdwarf@panix.com wrote:
>
>I think the OP was hoping for something along the lines of "magic," or maybe
>"miracle." Certainly not "writing a program."
Terribly sorry... let's see... first one needs a fillet of a fenny snake,
in the cauldron boil and bake; eye of newt and toe of frog, wool of bat
and tongue of dog...
.... the usual, you know...  it with a baboon's blood and then the
charm is firm and good.
DD
| |
| Colin Campbell 2005-04-26, 3:55 am |
| Robert Jones wrote:
>As this newsgroup isn't yet subscribed to by computers instead of
>people, a simple "please" would seem to be in order for common
>courtesy.
>
>To answer your question
>
>this seems to be a good case for MOVE CORRESPONDING, many organisations
>don't like this construct as a general rule, but this situation appears
>to be an obvious candidate. You will have to first check that all
>fields fully correspond in respect of data names and convertibility of
>formats, I haven't done a detailed check on the two record layouts
>myself.
>
>It would also be a good idea to initialise the destination record by
>moving spaces to it, so the filler always contains spaces, alternately,
>rename the filler such that the same name is used in both layouts.
>
>A divantage of using MOVE CORRESPONDING is that it is harder to
>debug.
>
>Also, programmers making future amendments to the program may not make
>the appropriate changes to both record layouts, but then even if they
>used lots of independent MOVEs, they still might not do that correctly
>either.
>
>Regards
>
>Robert
>
>
>
MOVE CORR is not hard to debug, in my opinion. I would suggest just
compiling with the XREF option (each elementary field will have an entry
in the XREF) and generating an Assembler expansion of the code for that
verb.
You would then have to do a detailed comparison of what fields the
compiler found to correspond. Once you have done that, and proven that
your COPY members are defined correctly, you're home free! Of course,
future changes to the COPY members could blow you right out of the water....
Writing a series of MOVEs is, as you say, both tedious and error prone.
The same sort of detailed comparison will be required, to ensure that no
MOVEs were left out, and that the from and to fields in each MOVE were
named correctly. And, future changes to the COPY members could blow you
right out of the water....
So why not use the power of the compiler (MOVE CORR) to do part of your
coding for you? It has always seemed like a good idea to me.
| |
|
| "Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:YIOdnew_qZFATPDfRVn-ig@adelphia.com...
> Robert Jones wrote:
[snip]
> MOVE CORR is not hard to debug, in my opinion. I would suggest just
> compiling with the XREF option (each elementary field will have an entry
> in the XREF) and generating an Assembler expansion of the code for that
> verb.
>
> You would then have to do a detailed comparison of what fields the
> compiler found to correspond. Once you have done that, and proven that
> your COPY members are defined correctly, you're home free! Of course,
> future changes to the COPY members could blow you right out of the
> water....
>
> Writing a series of MOVEs is, as you say, both tedious and error prone.
> The same sort of detailed comparison will be required, to ensure that no
> MOVEs were left out, and that the from and to fields in each MOVE were
> named correctly. And, future changes to the COPY members could blow you
> right out of the water....
Not strictly accurate.
If you changed the <from> or the <to> structure only then a MOVE program
would fail to compile whereas a MOVE CORR wouldn't.
Then again, who said that when you change a COPY you automatically remember
to recompile all the code anyway? One could argue that the COPY be more
dangerous than the move.
Having said that, I use MOVE CORR all the time because it's easier :^) I
"NEVER" combine with a REDEFINES though because it makes it easy to lose the
data transition in code reading - much searchability is lost.
> So why not use the power of the compiler (MOVE CORR) to do part of your
> coding for you? It has always seemed like a good idea to me.
JCE
| |
| Joe Zitzelberger 2005-04-30, 3:55 am |
| Short of writing a program, you could use one of the various "sort"
utilities that exist on just about all platforms. Since you mention
LRECL, I will assume some manner of IBM mainframe.
Write a sort with the COPY option and use INREC processing to reduce
your record to the desired fields.
In article <1114276347.284485.109550@o13g2000cwo.googlegroups.com>,
gcotterl@co.riverside.ca.us wrote:
> How can I convert records (LRECL = 214) with this format:
>
> FIELD LEVEL/NAME --- PICTURE-- START END LENGTH
> 3 ACT-RECORD X 1 1 1
> 3 ACT-ASMTNBR 9(9) 2 10 9
> 3 ACT-TAXYEAR 9(4) 11 14 4
> 3 ACT-COLTYPE 99 15 16 2
> 3 ACT-COLNBR 9(7) 17 23 7
> 3 ACT-COLDATE 9(9) 24 32 9
> 3 ACT-TRANBR 9(6) 33 38 6
> 3 ACT-TAXTYPE 9(7) 39 45 7
> 3 ACT-TAXTYPE-AMT 9(9)V99 46 56 11
> 3 ACT-DELPN 9(5)V99 57 63 7
> 3 ACT-COST 99V99 64 67 4
> 3 ACT-ACCRUED-PEN 9(5)V99 68 74 7
> 3 ACT-BILL-FY 9(4) 75 78 4
> 3 ACT-EFF-FY 9(4) 79 82 4
> 3 ACT-SPY-PARENT-ASMT 9(9) 83 91 9
> 3 ACT-RED-PEN 9(9)V99 92 102 11
> 3 ACT-RED-FEE 999V99 103 107 5
> 3 ACT-EQUITY-FEE 999V99 108 112 5
> 3 ACT-TAXDEED-FEE 999V99 113 117 5
> 3 ACT-STSAMT 9(9)V99 118 128 11
> 3 ACT-REDEM-DATE 9(8) 129 136 8
> 3 ACT-ACCTRAN-CODE X 137 137 1
> 3 ACT-PAYSOURCE 99 138 139 2
> 3 ACT-CASHIER-NBR XX 140 141 2
> 3 ACT-CASH-CHECK-AMT 9(7)V99 142 150 9
> 3 ACT-USER-ID X(4) 151 154 4
> 3 ACT-FUNDNBR 9(11) 155 165 11
> 3 ACT-NSF-FILENBR 9(5) 166 170 5
> 3 ACT-NSFAMT 9(9)V99 171 181 11
> 3 ACT-TRANSFER-AMT 9(9)V99 182 192 11
> 3 ACT-DIFF-AMT 999V99 193 197 5
> 3 ACT-FEES 999V99 198 202 5
> 3 ACT-23-TRUSTAMT 9(7)V99 203 211 9
> 3 ACT-SEQUENCE X 212 212 1
> 3 FILLER XX 213 214 2
>
>
>
> to records (LRECL = 160) with this format:
>
> FIELD LEVEL/NAME --- PICTURE-- START END LENGTH
> 3 ACT-RECORD X 1 1 1
> 3 ACT-ASMTNBR 9(9) 2 10 9
> 3 ACT-TAXYEAR 9(4) 11 14 4
> 3 ACT-COLTYPE 99 15 16 2
> 3 ACT-COLNBR 9(7) 17 23 7
> 3 ACT-COLDATE 9(9) 24 32 9
> 3 ACT-TRANBR 9(6) 33 38 6
> 3 ACT-TAXTYPE 9(7) 39 45 7
> 3 ACT-TAXTYPE-AMT S9(9)V99 COMP-3. 46 51 6
> 3 ACT-DELPN S9(5)V99 COMP-3. 52 55 4
> 3 ACT-COST S99V99 COMP-3. 56 58 3
> 3 ACT-ACCRUED-PEN S9(5)V99 COMP-3. 59 62 4
> 3 ACT-BILL-FY 9(4) 63 66 4
> 3 ACT-EFF-FY 9(4) 67 70 4
> 3 ACT-SPY-PARENT-ASMT S9(9) 71 75 5
> 3 ACT-RED-PEN S9(9)V99 COMP-3. 76 81 6
> 3 ACT-RED-FEE S999V99 COMP-3. 82 84 3
> 3 ACT-EQUITY-FEE S999V99 COMP-3. 85 87 3
> 3 ACT-TAXDEED-FEE S999V99 COMP-3. 88 90 3
> 3 ACT-STSAMT S9(9)V99 COMP-3. 91 96 6
> 3 ACT-REDEM-DATE 9(8) 97 104 8
> 3 ACT-ACCTRAN-CODE X 105 105 1
> 3 ACT-PAYSOURCE 99 106 107 2
> 3 ACT-CASHIER-NBR XX 108 109 2
> 3 ACT-CASH-CHECK-AMT S9(7)V99 COMP-3. 110 114 5
> 3 ACT-USER-ID X(4) 115 118 4
> 3 ACT-FUNDNBR 9(11) 119 129 11
> 3 ACT-NSF-FILENBR 9(5) 130 134 5
> 3 ACT-NSFAMT S9(9)V99 COMP-3. 135 140 6
> 3 ACT-TRANSFER-AMT S9(9)V99 COMP-3. 141 146 6
> 3 ACT-DIFF-AMT S999V99 COMP-3. 147 149 3
> 3 ACT-FEES S999V99 COMP-3. 150 152 3
> 3 ACT-23-TRUSTAMT S9(7)V99 COMP-3. 153 157 5
> 3 ACT-SEQUENCE X 158 158 1
> 3 FILLER XX 159 160 2
|
|
|
|
|