Why read CLC?
in [Cobol]
|
From: klshafer on 10 Jun 2008 13:42 On Jun 10, 3:10 am, "Karl Kiesel" <Karl.Kie...(a)fujitsu-siemens.com> wrote: > No own experience, but many many years ago there was a then popular book by > Michael Jackson 'Structured COBOL programming' (hope I remember the title > correctly): He proposed that the program structure should reflect the > structure of input and output data; he analyzed various cases, where this > was not possible or such an attempt resulted in 'bad' programs: one of the > diagnosed reasons was 'incompatibility' of input and output data, a > situation he called *structure clash*. He proposed soulutions independent of > the concrete problem (similar to 'patterns' in OO, 'discovered' many years > later!). One of the universal solutions used coroutines - without > appropriate COBOL language constructs, his examples did simulate the > coroutines using a main- and a sub-program with a state variable and many go > to statements. Yes, I think I read some of Michael Jackson's work (the computer guy, not the dancer/entertainer :-) ), but that was quite a while ago. And yes, I remember his notion of "structure clash." Some of this is beginning to fit together better in my mind now. I think an example of "structure" clash was in doing a device-to-device copy, as in copying disk binary file to 80-column card, or vice versa (once upon a time, such things were necessary, were they not?) We had a data clash, because the record lengths did not match up (disk sector vs. 80-columns). I have a vague recollection of my computer science instructor telling me that co-routines were a way of compensating for differences in "physical record units" between two devices. That this might be remarked upon by Constantine, would be, I think, in his discussion of "transform centered design", and his "afferent" and "efferent" modules. (One was output only, the other input only, don't recall which was which and don't have my copy handy). Recalling what the data flow diagrams looked like in "transform centered design", they do remind me of the Unix "piping". Ken > > Karl Kiesel > Fujitsu Siemens Computers, München
From: klshafer on 10 Jun 2008 13:45 On Jun 7, 3:30 pm, "HeyBub" <hey...(a)NOSPAMgmail.com> wrote: > Pete Dashwood wrote: > > >> It might be seen, then, that the program grows as the business grew, > >> in a fashion more 'organic' than 'linear'; logic-trees in > >> computer-science classes may have lots of straight lines and right > >> angles while oak trees and baobabs often have fewer. > > > A very nice analogy, Doc. > > > I don't see a popular movement to replace oaks with poplars any time > > soon...(the fact is that both have their place). > > > The idea of evolving systems has strong appeal for me and I am > > finding this approach very useful. In effect it is controlling the > > 'organic' evolution that decides the result. > > Another law: > > "A complex system that works is invariably found to have evolved from a > simple system that works.' > > Corollary: > "A complex system designed from scratch never works and cannot be patched up > to make it work. You have to start over, beginning with a working simple > system."- Hide quoted text - > > - Show quoted text - I believe it is Time Well Spent to design as well as you can, code as well as you can, and test/debug as well as you can, those initial basic building blocks of your system. That way, when you add do it, you need only look in the incremental additions for the "newly" discovered bugs. Does that mean that I agree with you? :-) Ken
From: klshafer on 10 Jun 2008 13:54 On Jun 9, 8:20 am, "HeyBub" <hey...(a)NOSPAMgmail.com> wrote: > More System Laws: > > 1. The System itself tends to expand at 5-6% per year. Yes, along as it is Alive, it is Growing. > > 2. Systems attract systems people. For every system, there is a type of > person adapted to thrive on it or in it. The Puzzle presents itself to the world. The appropriate PuzzleSolvers are then attracted to it. It is rather like sockets, and plugs, is it not? But which is male and which is female? :-) > > 3. Systems develop goals of their own the instant they come into being. > Intrasystem goals come first. I think this can lead to various, differing, manifestations of "success" on software projects. "Success" is in the context of "goals of their own." > > 4. Efficient systems are dangerous to themselves and to others. Dangerous to themselves, because efficent systems create powerful enemies? > > 5. The system can temporarily be controlled, but will eventually win.- Hide quoted text - Yes, but it feels so goooooooddddd to turn oneself over to Something That is Bigger. ... Mr. Heybub, If I may, please, do your co-workers tell you that you are fun to work with? Ken
From: Louis Krupp on 10 Jun 2008 17:33 tlmfru wrote: > Since Yourdon & Constantine have been invoked in this discussion - I have a > question about a concept that turned up in their publications. This was > "co-routines" - two or more definable routines (i.e., having a start and a > finish) that continuously swapped control between themselves to accomplish > some task or other. I never understood the swapping mechanism (not > important, I suppose) and I never could imagine a task that would or could > be handled like that. Anybody have any experience with these? > > PL I don't know if this has been mentioned, but for what it's worth, Unisys COBOL85 has built-in coroutines. Go to: http://public.support.unisys.com/aseries/docs/ClearPath-MCP-12.0/PDF/86001518-309.pdf (Access should be free, although you might have to agree to terms & conditions.) See section 13 ("Tasking in COBOL85), subsection "Coroutines." Some sample code from this document (formatting is screwed up)... Master: IDENTIFICATION DIVISION. PROGRAM-ID. CALL-TASK-CALLER. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 77 TASK-SUB PIC 9 VALUE 4. 01 DEP-TASK-ARRAY TASK. 05 DEP-TASK OCCURS 5 TIMES. 77 WS-PROGID PIC X(40). PROCEDURE DIVISION. DECLARATIVES. RUN-A-PROCESS SECTION. USE EXTERNAL WS-PROGID AS PROCEDURE. END DECLARATIVES. MAIN SECTION. MAIN-PARA. MOVE "OBJECT/C85/CALLED." TO WS-PROGID. CALL DEP-TASK (TASK-SUB) WITH RUN-A-PROCESS. DISPLAY "CONTINUE " WS-PROGID. CONTINUE DEP-TASK (TASK-SUB). DISPLAY "FINAL RETURN " WS-PROGID. DETACH DEP-TASK (TASK-SUB). WAIT-HERE. IF ATTRIBUTE STATUS OF DEP-TASK(TASK-SUB) > VALUE (TERMINATED) THEN WAIT AND RESET UNTIL ATTRIBUTE EXCEPTIONEVENT OF MYSELF GO TO WAIT-HERE. STOP RUN. [I don't know why they use an array of tasks instead of just a task variable.] Slave: IDENTIFICATION DIVISION. PROGRAM-ID. CALL-TASK-CALLED. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 77 MY-NAME PIC X(45). PROCEDURE DIVISION. MAIN SECTION. MAIN-PARA. MOVE ATTRIBUTE NAME OF MYSELF TO MY-NAME. DISPLAY MY-NAME " WAS CALLED". EXIT PROGRAM RETURN HERE. DISPLAY MY-NAME " CALLED AGAIN". EXIT PROGRAM. STOP RUN. Louis
From: Charles Hottel on 10 Jun 2008 18:34
<klshafer(a)att.net> wrote in message news:49f4adbc-183a-4024-b178-10420b64d05e(a)l42g2000hsc.googlegroups.com... On Jun 9, 10:44 pm, "Charles Hottel" <chot...(a)earthlink.net> wrote: > There are several ways to implement coroutines in IBM mainframe assembler, > depending on the brach instructions used. > [stuff from Don Knuth, classical algorithmist, snipped] Thanks, Charles. I caught just a whiff of the Wikipedia entry on co-routines and did some Googling... I think that what are popularly known as "pipes" in the Unix world may be implemented as co-routines. You know, when the output of "grep" is fed into the stream editor "sed". Ken [Charlie] Coroutines call each other, usually using a mechanism that allows them to do so from whatever point they desire. Pipes are not coroutines. They are communicating processes, producers and consumers if you like, usually communicating via a queue. The processes in pipes do not call each other. |