Did I write a good (efficient) program?
in [Cobol]
|
From: Clark F Morris on 1 Apr 2008 20:43 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. I did have one applications programmer tell me that I always was a systems programmer after he inherited some of my COBOL programs. On the other hand, my last three contracts were in applications where I influenced at least one system and also provided applications technical support to a Year 2000 project. Clark Morris > >MCM > > >
From: William M. Klein on 1 Apr 2008 22:54 Frank, As currently included in WD 1.10, I am very much opposed to it. The problem is that the current definition allows the data to be stored within the structure ("DIRECT") and to have such items within ODO's and with data after this. What this means is that the "data" after the variable length field MUST be "moved" in storage each time the variable data size changes. If the proposed definition - only allowed for "direct" variable length fields at the 01-level, - allowed for "indirect" variable length items within structures - figured out how to handle such fields within FILES (or disallowed it there), - didn't allow the same variable length field to be BOTH prefixed and suffixed then I would be for it. -- Bill Klein wmklein <at> ix.netcom.com "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote in message news:47F232DA.6F0F.0085.0(a)efirstbank.com... >>>> On 3/31/2008 at 8:40 PM, in message > <c463v3p7pdl8dc6dl5seo7j6u0mfrev3qr(a)4ax.com>, Robert<no(a)e.mail> wrote: >> In 1973 everything (except files) was fixed length. We used fixed length >> strings, numbers, >> arrays, records and blocks in files. Now, outside Cobol, most things are >> variable length. >> The next Cobol standard proposes adding 'any length' data items and >> arrays. The Old Guard >> are opposed. > > Is anyone here a member of this Old Guard that is opposed to variable length > strings? I certainly am not. I would love them. > > Frank >
From: Robert on 2 Apr 2008 01:41 On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >Frank, > As currently included in WD 1.10, I am very much opposed to it. The problem >is that the current definition allows the data to be stored within the structure >("DIRECT") and to have such items within ODO's and with data after this. What >this means is that the "data" after the variable length field MUST be "moved" in >storage each time the variable data size changes. > >If the proposed definition > - only allowed for "direct" variable length fields at the 01-level, > - allowed for "indirect" variable length items within structures > - figured out how to handle such fields within FILES (or disallowed it there), > - didn't allow the same variable length field to be BOTH prefixed and suffixed > >then I would be for it. 18.16.2.3 3) The INDIRECT phrase specifies that the subject of the entry is an indirect elementary data item as defined in 8.5.1.7.2, Location of any-length elementary items. If the INDIRECT phrase is not specified, an any-length elementary item declared at the 01 or 77 level or containing the LIMIT phrase is a direct elementary data item; otherwise, that data item is an indirect elementary data item. I read that to say a direct data item in the middle of a record (other than 01/77) must have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to ODO, thus eliminating the need to move everything following when the length changes.
From: William M. Klein on 2 Apr 2008 01:41 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. -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:gh66v3h1ml3rjf9ic3nbgli94sh1j5fr1i(a)4ax.com... > On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >>Frank, >> As currently included in WD 1.10, I am very much opposed to it. The problem >>is that the current definition allows the data to be stored within the >>structure >>("DIRECT") and to have such items within ODO's and with data after this. What >>this means is that the "data" after the variable length field MUST be "moved" >>in >>storage each time the variable data size changes. >> >>If the proposed definition >> - only allowed for "direct" variable length fields at the 01-level, >> - allowed for "indirect" variable length items within structures >> - figured out how to handle such fields within FILES (or disallowed it >> there), >> - didn't allow the same variable length field to be BOTH prefixed and >> suffixed >> >>then I would be for it. > > 18.16.2.3 > 3) The INDIRECT phrase specifies that the subject of the entry is an indirect > elementary > data item as defined in 8.5.1.7.2, Location of any-length elementary items. If > the > INDIRECT phrase is not specified, an any-length elementary item declared at > the 01 or 77 > level or containing the LIMIT phrase is a direct elementary data item; > otherwise, that data item is an indirect elementary data item. > > I read that to say a direct data item in the middle of a record (other than > 01/77) must > have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to > ODO, thus > eliminating the need to move everything following when the length changes.
From: MikeB on 2 Apr 2008 02:20
On Mar 31, 6:20 pm, "Rick Smith" <ricksm...(a)mfi.net> wrote: > "MikeB" <MPBr...(a)gmail.com> wrote in message > > news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e(a)p25g2000hsf.googlegroups.com... > [snip] > > > Please have a look at what I > > wrote and feel free to comment. > [snip] > > thus: 76DF:54AE:A30:1:1:4321:EAD5:AA43 > > or FD05::1:0:5 (in this instance 4 octets have been suppressed) > > or even: ::1 (loopback address) > > > I was under a little time pressure (only had yesterday morning), so I > > haven't figured out the compression part yet. > > I am not feeling pressured and have a lot of time, so ... > I rewrote your program adding the compression part > and wrote a test program to call it. The results are as > expected. > > ----- Results > 76DF:54AE:A30:1:1:4321:EAD5:AA43 > FD05::1:0:5 > ::1 Rick, I took about 1 1/2 hours to work through and understand what you did. I'm stunned. You clearly showed the difference between an amateur (me) and a professional (you). 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? Once again, thank you. This is really great. And I learned a lot. Wish I could find a way to apply such stuff as my day-to-day job. |