Did I write a good (efficient) program?
in [Cobol]
|
From: William M. Klein on 2 Apr 2008 17:37 The problems with using the "max" rather than the "current" size occurs when referencing the entire group item and moving it, for example, to a single receiving item. Having "undefined/garbage" data in the "unused" portion of the max part will cause problems. The GROUP item doesn't know (need to know) how the individual sub-items are defined. Is this clear? If not, I can try doing an example. *** As far as you example goes, when passing an indirect variable length item or a group containing one, what will be past is a pointer. If the called program is in another language, then you would define the structure with a pointer as what was received and need to process it "accordingly". If the subprogram did something that COBOL couldn't handle when it came back, then various "exception conditions" might be raised. -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:tce6v3hriqrje7kcom4petuon9rp0a84bl(a)4ax.com... > 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: Pete Dashwood on 2 Apr 2008 17:40 "Howard Brazee" <howard(a)brazee.net> wrote in message news:rp37v3pcskcjhk6ui9ack5lus9tcipff8k(a)4ax.com... > 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. Yes, of course. However, the WAY in which the goals are met is very different. "Self-documenting" code is irrelevant. It only matters if code is to be constantly changed. If the code NEVER changes, then it doesn't matter. That was my point. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 2 Apr 2008 21:55 On Wed, 02 Apr 2008 21:37:18 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >The problems with using the "max" rather than the "current" size occurs when >referencing the entire group item and moving it, for example, to a single >receiving item. Having "undefined/garbage" data in the "unused" portion of the >max part will cause problems. The GROUP item doesn't know (need to know) how >the individual sub-items are defined. I think a group move DOES need to handle any-length items separately. 8.5.1.9 says: "Unlike other group items, a variable-length group is not equivalent to an alphanumeric data item and cannot undergo a comparison or a move operation, in either direction, explicitly or otherwise, unless the other operand is a compatible group. Groups are compatible if all variable-length data items correspond and match as specified below. For the purposes of compatibility, either both operands may be variable-length groups or only one of the operands may be a variable-length group. Determination of compatibility between a variable-length group and another group is as follows: 3) For each any-length elementary item in either group there is a corresponding any-length elementary item in the other group as specified in 8.5.1.9.1, Positional correspondence." You say, above, a variable length group can be moved to a single receiving item. The last sentence of the first paragraph says the same. But the first sentence and 3) appear to require they both be variable-length groups with corresponding any-length items. It is easy picture a move from a variable-length group to a fixed-length item, such as a file record. It is not as easy to picture the reverse. Say it's moving bytes until it gets to an any-length string defined as prefixed by binary-long. The input doesn't contain a binary-long. How does it determine the length of the string? Getting back to a move between two variable-length groups, there is no requirement that the corresponding any-length items match on direct/indirect prefixed/delimited limit On a group move, the sending group might contain a direct item (with limit) while the corresponding item in the receiving group is indirect. The sending item might be delimited by low-value while the receiving group is prefixed by binary-long. For these reasons, it seems a grouip move would have to be three operations copy the bytes preceding the any-length item copy the any-length item, which may require scanning for a delimiter or allocating memory copy the bytes following the any-length item >Is this clear? If not, I can try doing an example. I would appreciate an example that deals with the above points. > *** > >As far as your example goes, when passing an indirect variable length item or a >group containing one, what will be passed is a pointer. If the called program is >in another language, then you would define the structure with a pointer as what >was received and need to process it "accordingly". If the subprogram did >something that COBOL couldn't handle when it came back, then various "exception >conditions" might be raised. I found the answer under CALL. Any-length items and variable-length groups are NOT ALLOWED to be passed as parameters, period. That avoids dealing with the issue of size changing in the called program. The returning item is not allowed to be an any-length item, but can be a variable-length group containing an any-length item. This is not a mistake, it shows that someone on the standards committee understands the issues I asked about. If the returning were an any-length elementary item, the called program would have no way to communicate its new location after a size change. But when the returning item is a group, the group contains pointers to its variable-length elements, enabling the called program to pass back their new locations. > >-- >Bill Klein > wmklein <at> ix.netcom.com >"Robert" <no(a)e.mail> wrote in message >news:tce6v3hriqrje7kcom4petuon9rp0a84bl(a)4ax.com... >> 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 3 Apr 2008 00:08 "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message news:65fmhdF2fbsenU1(a)mid.individual.net... [snip] > To modify existing functionality does NOT mean modifying a base class. It > means extending (through inheritance) or over-riding existing behaviours. The priniples of object-oriented design do not include the use of inheritance to overcome inadequate or faulty design. In such cases, modifying a base class may be unavoidable.
From: Pete Dashwood on 3 Apr 2008 08:39
"Rick Smith" <ricksmith(a)mfi.net> wrote in message news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d(a)mid-floridainternet... > > "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message > news:65fmhdF2fbsenU1(a)mid.individual.net... > [snip] >> To modify existing functionality does NOT mean modifying a base class. It >> means extending (through inheritance) or over-riding existing behaviours. > > The priniples of object-oriented design do not include > the use of inheritance to overcome inadequate or faulty > design. In such cases, modifying a base class may be > unavoidable. I have never encountered such a situation and do not expect to. (Guess my designs are not "inadequate" or "faulty"...:-)) I really don't care about academic "principles of OO design" unless they are pertinent to the world in which I live and work; your statement above is not. My own principles (derived from over a decade of real world use) tell me not to modify a Base Class. So I don't. Pete. -- "I used to write COBOL...now I can do anything." |