Did I write a good (efficient) program?
in [Cobol]
|
From: Howard Brazee on 3 Apr 2008 09:47 On Thu, 3 Apr 2008 10:40:31 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >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. Again, my point is that our view of "code" has changed. In assembly code days, we documented simple tasks that have been replaced by compiler language commands. From the point of view of the CoBOL programmer, the assembly language doesn't change and doesn't need documenting (sure, optimizers will make changes - but maintenance programmers don't need to see explanations of what actually happens in a COMPUTE). If the atomic element is library object - then we don't modify that object, and that object doesn't need to have internal programming documentation. But you are still programming - just at a different level. And at this new level - someone is going to be doing maintenance.
From: SkippyPB on 3 Apr 2008 11:46 On Wed, 2 Apr 2008 11:01:28 -0500, "Michael Mattias" <mmattias(a)talsystems.com> wrote: >"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 > Probably my fault. I wasn't following the thread that closely and I obviously missed the sarcasm. I, however, can understand why applications' programmers may have difficulty doing systems work. If you are knowledgeable in IBM Assembler, then systems work should not be that difficult. However if you've spent your whole career doing COBOL, RPG etc, it would be difficult to make the transition. Although nowadays there is little need to dive down into the nuts and bolts of things like it used to be in the late 70's and early 80's when I was doing that sort of thing. On the other hand, a lot of systems programmers could graduate to applications work though I think most would find it distasteful. Regards, //// (o o) -oOO--(_)--OOo- "Save the whales. Collect the whole set." -- Steven Wright ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: Howard Brazee on 3 Apr 2008 12:01 On Thu, 03 Apr 2008 11:46:22 -0400, SkippyPB <swiegand(a)nospam.neo.rr.com> wrote: >Probably my fault. I wasn't following the thread that closely and I >obviously missed the sarcasm. I, however, can understand why >applications' programmers may have difficulty doing systems work. If >you are knowledgeable in IBM Assembler, then systems work should not >be that difficult. However if you've spent your whole career doing >COBOL, RPG etc, it would be difficult to make the transition. > >Although nowadays there is little need to dive down into the nuts and >bolts of things like it used to be in the late 70's and early 80's >when I was doing that sort of thing. Just like everywhere else - we use bigger components. But when the *system* now can include parts that aren't anywhere near the computer room, the scope is different. >On the other hand, a lot of systems programmers could graduate to >applications work though I think most would find it distasteful. Applications are what pay for everything. But systems work now moves into interfacing with people, creating secure & private business practices and such.
From: HeyBub on 3 Apr 2008 19:07 SkippyPB wrote: >> >> 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. >> > > 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. > Because application programmers are "line" and system programmers are "staff." Unfortunately, staff people sometimes think they are line people. Adjutants think they are commanders, accountants think they are CEOs, and lawyers think ... Never mind.
From: Frank Swarbrick on 3 Apr 2008 20:31
I'm not talking about how the Cobol standard has them specified. Just that, as a feature, I would like some better way to work with variable length strings. With regard to DIRECT... Without actually reading the standard, here is what I would intuitively *expected* with regard to a direct "any length" data item (fixed length font required for this to make any sense at all!): 01 AN-01-DATA-AREA. 05 FIXED-STR-10 PIC X(10). 05 VARIABLE-STR-10 PIC X ANY LENGTH LIMIT IS 10 DELIMITED BY X'00'. 05 A-CHAR PIC X. MOVE 'XXXXXXXXXX' TO FIXED-STR-10 MOVE 'TEST' TO VARIABLE-STR-10 MOVE 'Z' TO A-CHAR MOVE 'YYYYYYYYYY' TO VARIABLE-STR-10 Result in memory, before the final MOVE: XXXXXXXXXXTEST_ Z ^^^^^^^^^^^^^^^^^^^^^^ After the final MOVE: XXXXXXXXXXYYYYYYYYYY_Z ^^^^^^^^^^^^^^^^^^^^^^ The underscore represents the delimiter 'null' character. What you say says to me that before the final move we would instead see XXXXXXXXXXTEST_Z I would agree that this is rather crazy. I think how I am looking at it, which is apparently not how you would support it, is that if DIRECT is specified *along with a limit*, then the maximum storage required would be used. This is just like how in C you can have, for instance: struct my_struct { char[21] field1; char[21] field2; char x; }; void cfunc(struct my_struct *s) { strcpy(s->field1, "This is a test"); strcpy(s->field2, "Another test"); s->x = 'X'; } Result in memory: This is a test_ Another test_ X ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If I wanted to call cfunc from Cobol I could do this: 01 MY-STRUCT. 05 field-1 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'. 05 field-2 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'. 05 X PIC X. CALL 'cfunc' USING MY-STRUCT DISPLAY field-1 '/' field-2 '/' x Result: This is a test/Another test/X Now as for a DIRECT any-length data item without a limit specified, I don't think that makes sense. Is it even allowed? My brain doesn't want to try to interpret the standard right now. Frank n 4/1/2008 at 8:54 PM, in message <vzCIj.8760$fY6.7941(a)fe11.news.easynews.com>, 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. |