Code Comments
Programming Forum and web based access to our favorite programming groups.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
Post Follow-up to this messageAs 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
Post Follow-up to this messageIn 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
Post Follow-up to this messagedocdwarf@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."
Post Follow-up to this messageIn 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 mayb e >"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
Post Follow-up to this messageRobert 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.
Post Follow-up to this message"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
Post Follow-up to this messageShort 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
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.