Did I write a good (efficient) program?
in [Cobol]
|
From: Robert on 2 Apr 2008 04:37 On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >It does have a "limit" - but it still needs to "move" the following data. (Of >course in Standard COBOL there can't be data following an ODO). "for contiguity" >of items, see, > >"8.5.1.8.1 Contiguity of data items >A variable-length data item may be part of any group structure, and its >neighbors may be non-variable-length data >items or variable-length data items. A variable-length data item is logically >but not necessarily physically >contiguous with its neighbors. However a variable-length data item behaves in >all respects as though it were in fact >contiguous with its neighbors whenever a procedural operation is applied to a >group containing it." > >In other words, no matter how direct items are stored, if you process the "group >item" containing them, it must "appear" as if the following items are directly >after the current length - not after the MAXIMUM length. The next paragraph seems to confirm that, when it qualifies any-length with indirect. The implication is that a change to a direct any-length item DOES affect the addresses of its neighbors. "The physical address of a variable-length data item may change during execution of the program. Dynamic-capacity tables and indirect any-length elementary items, however they may change during execution, do not in any way affect the addresses of their neighbors." What procedural operations are they referring to? A MOVE and comparison would work if the maximum length were allocated and following items not shifted. I can think of two situations where it matters. FUNCTION LENGTH says nothing about variable-length groups, which seems like an error. Reference modification cannot be used on variable-length groups. How can a program tell whether the item following an any-length elementary item is contiguous? What behavior would be different? Suppose program A calls B with the address of an indirect any-length item or variable-length group containing a direct any-length item. B changes the item's size and address. How does A know the new address? The parameter passed was the address of the item or group, not the address of its base pointer. If a Cobol program did pass the addess of the base pointer, which it would almost have to, that would cause problems for other languages, including the OS API.
From: Rick Smith on 2 Apr 2008 04:08 "MikeB" <MPBrede(a)gmail.com> wrote in message news:5bc82b56-8468-4624-9602-4d7085ffe9ff(a)m73g2000hsh.googlegroups.com... [snip] > Thank you. That was a valuable learning experience for me. I have 1 > simple question to see if I understood all of that code correctly. > > * Compress adjacent " 0"s, once > > move 1 to ip-compress-state > perform > varying ip-index1 from 1 by 4 > until ip-index1 > 28 > evaluate ip-compress-state > when 1 > if ip-octets (ip-index1:4) = " 0" > and ip-octets (ip-index1 + 4:4) = " 0" > then > move spaces to ip-octets (ip-index1:4) > move ": " to ip-octets (ip-index1 + 4:4) > move 2 to ip-compress-state > else > move 1 to ip-compress-state > end-if > when 2 > > The > else move 1 to ip-compress state seems redundant, since you > can only ever be in that particular piece of code when the state = 1? > > I could not conceive of a logic path that would lead you to excecute > that statement when the state would be other than 1, but perhaps I > missed something? It is redundant, but it shows what state will be the next state. I do the same in the code following 'when 2', which has 'move 2 to ip-compress-state', after adjusting for an adjacent compressable field. Perhaps, it is something that was left over from my days servicing computer equipment that used ROM-based microprogramming, where next address fields are never left empty. > Once again, thank you. This is really great. And I learned a lot. You're welcome, though I am left with the feeling that I could have made it more clear as to how it worked or perhaps had chosen a different way, if I had spent a bit more time on it. And I apologize for not removing the comment about formatting in reverse, which no longer applies.
From: Howard Brazee on 2 Apr 2008 09:53 On Wed, 2 Apr 2008 10:07:54 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >OO Code has a different set... > >1. Does it work? >2. Is it small and complete (encapsulated)? >3. Can I reuse and extend it easily? > >Efficiency is taken care of by keeping components small, and using >optimizing compilers. > >Maintainability is not a consideration as long as the interface is simple or >non existent. Except those characteristics are essential for good maintainability. The application needs to be maintainable. The system needs to be maintainable. The component size is different and techniques for making the code maintainable have changed. But the goal is the same.
From: SkippyPB on 2 Apr 2008 11:50 On Tue, 01 Apr 2008 23:21:29 GMT, "Michael Mattias" <mmattias(a)talsystems.com> wrote: >"Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message >news:65folmF1f605pU1(a)mid.individual.net... >>> I don't about "industry" but I have always weighed 'maintainability' >>> very, very heavily: When was the last time you saw a program which NEVER >>> was upgraded/enhanced/changed? >>> >> I have dozens of them :-) >> >> They're called "components"... > >Applications programmers (eg, moi) don't think in terms of "components"; >strangely enough, we think in terms of "applications." > >I guess that explains as well as anything why it is 'systems' programmers >are the ones who just couldn't cut it in applications. > >MCM > > > What make you think systems progrmmers can't cut it in application? In the beginning of my career I pulled double duty as a systems and applications programmer. Never had a problem with either. Regards, //// (o o) -oOO--(_)--OOo- "Save the whales. Collect the whole set." -- Steven Wright ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: Michael Mattias on 2 Apr 2008 12:01
"SkippyPB" <swiegand(a)nospam.neo.rr.com> wrote in message news:7oa7v3t4asvik0cnrlsk5j8k4o7g4jkodt(a)4ax.com...> > What make you think systems progrmmers can't cut it in application? In > the beginning of my career I pulled double duty as a systems and > applications programmer. Never had a problem with either. I was afraid of this. I was too subtle in my saracasm. Well, at least the *applications* programmers "get it." MCM |