Why read CLC?
in [Cobol]
|
From: Pete Dashwood on 9 Jun 2008 20:42 <klshafer(a)att.net> wrote in message news:d2639c03-667e-409a-85ba-314941e45856(a)x41g2000hsb.googlegroups.com... On Jun 8, 12:38 pm, "tlmfru" <la...(a)mts.net> 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 Hi, tlmfru/PL, Posted directly under you, but with recognition of what Mr. Pete D. and Mr. Charles H. have already said... here is what I remember about co-routines... Probably have their origin in the FORTRAN world, though as Pete points out can be hosted in other languages. Since FORTRAN has "subroutines" (and not "subprograms", or "procedures", or whatever", that is probably why they are called co-ROUTINES. Pete, do you know if much of SCOPE was written in FORTRAN? I had always heard that much (even most) of KRONOS was written in FORTRAN (that is where I cut my computer teeth.) [Pete] I believe SCOPE was written in COMPASS, the Cyber Assembler. But I can't be sure. It doesn't surprise me to hear that KRONOS was written in FORTRAN. FORTRAN was much beloved by CDCers... :-) In the early 1970s the Professional Services division of CDC were trying to establish a COBOL "presence" within the Australian subsidiary. I was involved in that and my Boss was very successful in getting it set up. After it took off, I was seconded to the new NZ subsidiary as a pre-sales analyst and support consultant. I remember those times with fondness. The guy I was supporting was one of the best computer salesmen I have ever encountered and he taught me much. He pulled off some amazing marketing coups... (NZ TAB (national online betting system), replacement of IBM 3330s with plug compatible CDC equivalents at a prestige IBM site, and setting up the first public bureau satellite link between Australia and NZ. All very interesting and educational for me... :-)) There were still a limited number of Business oriented analysts within the company and demand for their services was increasing, so I was constantly being forced to pack a bag and be somewhere at the drop of a hat. (Mainly USA or Oz...) It played Hell with my relationship at the time and in the end I had to choose, so I quit the company (reluctantly...). <snipped a very good explanation of co-routines> Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 9 Jun 2008 20:59 <klshafer(a)att.net> wrote in message news:03ee5e39-07b8-4688-a1a6-fe89c641d4d2(a)d77g2000hsb.googlegroups.com... On Jun 9, 11:16 am, "klsha...(a)att.net" <klsha...(a)att.net> wrote: > Sequence goes something like this... both of them are subroutines in > the FORTRAN sense, but in their interaction, they are co-routines... > Names are limited to seven characters or less :-). > Subroutine prodrec (record) > C comment - produces a record, then consumes it > <do some stuff to build a record> > Call consrec (record) > 999 return > end > > Subroutine consrec (record) > C comment - consumes a record, then asks for another > <do some stuff to dispose of record> > Call prodrec (record) > 999 return > end > > Notice that the return statements are never executed, unless we allow > for an "exceptional event" and a conditional RETURN, or the evil GOTO > 999. Hmmmm... upon re-reading this, I don't think I got it "just right." In the above, wouldn't the "return addresses" be stacked, and because the stack was never "popped", eventually this would cause a run-time error? There must have been a way to do the RETURNs, and still let each of the other subroutines invoke the other as if it were a slave. I have a vague recollection that it involved the use of a "switch" variable, which had the effect of determining the "entry point" within each routine. Ya'll are welcome to refresh my memory, if deemed worthwhile. [Pete] You may be getting confused with "serial reusability" which used an indicator value to select an entry point. This was a "poor man's re-entrancy" which could be used in COBOL environments, even though COBOL did not support true re-entrancy.(To do so would require saving and restoring registers, and the instruction counter...) IMS DC in the IBM mainframe environment used this for resuming conversations with 3270 screens in conversational mode. It was very efficient and a good solution, but fell into disfavour because it required a GO TO... DEPENDING ON ... :-) (and the TP software moved on as well...) I have seen the same approached used on other platforms, where multiple threads can use the same piece of code, within a clearly defined set of boundaries. Once a thread gets the code, it executes it up to the boundary (always just preceding a referenceable label), dequeues, then re-enters when it is re-activated and carries on from the label until the next boundary... hence, "serial reusability". These are not co-routines. (If the code was TRULY re-entrant and reusable, it would be interruptible at ANY point, and could resume from the immediately following instruction, wthout needing an "entry point" or label at that place in the code. This is pretty much the "exchange jump" mechanism I described earlier for the Cyber.) Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 9 Jun 2008 21:34 On Mon, 9 Jun 2008 10:02:35 -0700 (PDT), "klshafer(a)att.net" <klshafer(a)att.net> wrote: >On Jun 7, 10:11�pm, Robert <n...(a)e.mail> wrote: >> >> Starving the interface is a bad idea. Rather than passing four data >> >> structures, they'll >> >> copy the data of interest into a single structure. >> >> >> Generally, I see MOVE statements as non-productive, unless they actually do something like >> editing a number. They are bureaucratic overhead. It is better to use primary sources >> where they sit in memory. Called programs do not mischeviously screw around with other >> fields in the structure. You're paranoic if you think so. >> > >I'm unsure that I understand you. Nevertheless, here is my opinion, in >the context of my understanding of coupling and cohesion... > >Generally, the fewer parameters passed to a subprogram/subroutine, the >better. A large number of parameters passed, either to or from, is a >"clue" that the invoked module may be performing more than one >"function" (somewhat vague, I grant you), and thus is not as >"cohesive" as it should be. (Because functional cohesion is the >highest level of cohesion. Said for the benefit of others, because I >know you already know this :-).) > >Passing more "parameters", or "fields" to an invoked module, than it >really needs, may tempt the coder to "use" those fields in the invoked >module, thus weakening it cohesion. That is why, in the absence of >other all-other-considerations, it is better to pass four parameters >than five. > >And "packaging" the four parameters into one customized (for purpose >of invocation) structure so that only _one_ parameter is passed is a >"sleight of hand" which though it may "conform to shop standards, in >perverted form", does not reduce the coupling in fact. You just stated what I meant. Copying four variables to a fifth structure doesn't simplify anything, it adds four unnecessary MOVE statements. Plus, it obscures the fact that the called program is referencing four structures. >There are tradeoffs to be made here. We all make compromises. If a >record-level structure has the three or four things that the invoked >module needs, yeah, go ahead and pass it in its entirety. But Mr. >Klein has given us the syntax to "mask out" the things we don't need >in the linkage section COPYLIB, so that the invoked module isn't >tempted to "do mischief" beyond its "authority" of designed scope. The blocking structure redefining the original structure is little different from a customi interface block. PIC X redefining non-string types is error-prone. You might make an error in addition. Someone might add a field in the middle. The size of a tiny binary might change from one to two bytes. If you fear your own programs doing mischief, you should be in security rather than development. >Not that I would advocate doing that in COBOL. I've never seen it done >that way. But I have seen it, and did it myself, in passing labeled >COMMON in FORTRAN. If there were large areas of the COMMON area not to >be used by the subroutine, we masked them out such as IARRAY(100), >IDUMMY1(367), ICMD(10), IDUMMY2(28), IRETURN. > >The invoked module was thus "permitted" to use IARRAY and ICMD and to >return result in IRETURN. Areas masked in IDUMMY1 and IDUMMY2 were not >needed, and because they were masked, the coder of the subordinate >module was not ever tempted to use them. Tempted? If a future change adds another parameter, you need only change the called program. That's simpler than changing three lines in a blocking structure, or adding a variable to a custom structure and a MOVE. Then forgetting to change another caller, and getting garbage in the new field. >Thus was the interface "starved", and "cohesion" protected (best as >could be). If you want to starve the interface, passing four variables individually takes less code than four MOVEs.
From: Charles Hottel on 9 Jun 2008 22:00 google for z390, it is free and lets you assemble and run ibm assembler on a pc "tlmfru" <lacey(a)mts.net> wrote in message news:VE03k.228$QN1.89(a)newsfe15.lga... > Will have a shufty at it. I know BAL but don't have access to am IBM > system. > > Thanks > Pl > > Charles Hottel <chottel(a)earthlink.net> wrote in message > news:2rudnVqdmKQ5F9HVnZ2dnUVZ_hadnZ2d(a)earthlink.com... >> >> "Charles Hottel" <chottel(a)earthlink.net> wrote in message >> news:w4OdnUs30PyKFNHVnZ2dnUVZ_tHinZ2d(a)earthlink.com... >> > >> > "tlmfru" <lacey(a)mts.net> wrote in message >> > news:TUT2k.163$Jh7.149(a)newsfe21.lga... >> >> 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 >> >> >> >> >> > >> > Donald Knuth's The ARt of Computer Programming Volume 1 discusses >> > coroutines. There is an elevator simulation and some other examples. > If >> > you know IBM mainframe assembler language there are some examples of >> > the >> > coroutines from Knuth at: http://www.cbttape.org/cbtdowns.htm >> > >> >> Opps sorry, forgot to mention, see file number 590 >> >> > >
From: Charles Hottel on 9 Jun 2008 22:44
There are several ways to implement coroutines in IBM mainframe assembler, depending on the brach instructions used. If you have two coroutinescalled IN and OUT you can do the following using two registers: "IN" ------BALR R7,R8 -----> "OUT" "IN" <-----BALR R8,R7 -------"OUT" Or you can use the following using a single register: "IN" <----BAL R7,0(R7) -----> "OUT" Or here is another way using a single register: "IN" <------BALR R7,R7 ------> "OUT" IIRC the elevator simulation uses a more general "Call Table" approach. If you download the zip file you will also need Xmit Manager to view the files on a PC. Here is the overview documentation from the $$ASMDOC file: *------------------------------------------------------------------- --* * ASM00003 KNUTH COROUTINE * *------------------------------------------------------------------- --* 17 JUL 1980 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 191-194 COROUTINE EXAMPLE TRANSLATE ONE CODE INTO ANOTHER. INPUT CODE TO BE TRANSLATED IS A SEQUENCE OF ALPHAMERIC CHARACTERS TERMINATED BY A PERIOD, E.G., A2B5E3426FG0ZYW3210PQ89R. BLANK COLUMNS ARE TO BE IGNORED. FROM LEFT TO RIGHT, IF THE NEXT CHARACTER IS A DIGIT, SAY N, IT INDICATES (N+1) REPETITIONS OF THE FOLLOWING CHARACTER, WHETHER THE FOLLOWING DIGIT IS A DIGIT OR NOT .. A NONDIGIT SIMPLY DENOTES ITSELF. OUTPUT CONSISTS OF THE SEQUENCE INDICATED AND SEPARATED INTO GROUP S OF THREE CHARACTERS: ABB BEE EEE E44 446 66F GZY W22 220 0PQ 999 999 999 R. TWO COROUTINES AND A SUBROUTINE. SUBROUTINE 'NEXTCHAR' FINDS THE NONBLANK CHARACTER. COROUTINE 'IN' FINDS THE CHARACTERS OF THE INOUT CODE WITH THE PROPER REPLICATION. COROUTINE 'OUT' PUT THE CO DE INTO THREE-DIGIT GROUPS. *------------------------------------------------------------------- --* * ASM00004 KNUTH COROUTINE USING BALR R7,R8 * *------------------------------------------------------------------- --* 17 JUL 1980 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 191-194 COROUTINE EXAMPLE TRANSLATE ONE CODE INTO ANOTHER. INPUT CODE TO BE TRANSLATED IS A SEQUENCE OF ALPHAMERIC CHARACTERS TERMINATED BY A PERIOD, E.G., A2B5E3426FG0ZYW3210PQ89R. BLANK COLUMNS ARE TO BE IGNORED. FROM LEFT TO RIGHT, IF THE NEXT CHARACTER IS A DIGIT, SAY N, IT INDICATES (N+1) REPETITIONS OF THE FOLLOWING CHARACTER, WHETHER THE FOLLOWING DIGIT IS A DIGIT OR NOT .. A NONDIGIT SIMPLY DENOTES ITSELF. OUTPUT CONSISTS OF THE SEQUENCE INDICATED AND SEPARATED INTO GROUP S OF THREE CHARACTERS: ABB BEE EEE E44 446 66F GZY W22 220 0PQ 999 999 999 R. TWO COROUTINES AND A SUBROUTINE. SUBROUTINE 'NEXTCHAR' FINDS THE NONBLANK CHARACTER. COROUTINE 'IN' FINDS THE CHARACTERS OF THE INOUT CODE WITH THE PROPER REPLICATION. COROUTINE 'OUT' PUT THE CO DE INTO THREE-DIGIT GROUPS. 'IN' ------BALR R7,R8 -----> 'OUT' 'IN' <-----BALR R8,R7 ------ 'OUT' *------------------------------------------------------------------- --* * ASM00005 KNUTH COROUTINE USING BAL R7,0(R7) * *------------------------------------------------------------------- --* 17 JUL 1980 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 191-194 COROUTINE EXAMPLE TRANSLATE ONE CODE INTO ANOTHER. INPUT CODE TO BE TRANSLATED IS A SEQUENCE OF ALPHAMERIC CHARACTERS TERMINATED BY A PERIOD, E.G., A2B5E3426FG0ZYW3210PQ89R. BLANK COLUMNS ARE TO BE IGNORED. FROM LEFT TO RIGHT, IF THE NEXT CHARACTER IS A DIGIT, SAY N, IT INDICATES (N+1) REPETITIONS OF THE FOLLOWING CHARACTER, WHETHER THE FOLLOWING DIGIT IS A DIGIT OR NOT .. A NONDIGIT SIMPLY DENOTES ITSELF. OUTPUT CONSISTS OF THE SEQUENCE INDICATED AND SEPARATED INTO GROUP S OF THREE CHARACTERS: ABB BEE EEE E44 446 66F GZY W22 220 0PQ 999 999 999 R. TWO COROUTINES AND A SUBROUTINE. SUBROUTINE 'NEXTCHAR' FINDS THE NONBLANK CHARACTER. COROUTINE 'IN' FINDS THE CHARACTERS OF THE INOUT CODE WITH THE PROPER REPLICATION. COROUTINE 'OUT' PUT THE CO DE INTO THREE-DIGIT GROUPS. 'IN' <---BAL R7,0(R7)---> 'OUT' *------------------------------------------------------------------- --* * ASM00006 KNUTH COROUTINE USING BALR R7,R7 * *------------------------------------------------------------------- --* 17 JUL 1980 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 191-194 COROUTINE EXAMPLE TRANSLATE ONE CODE INTO ANOTHER. INPUT CODE TO BE TRANSLATED IS A SEQUENCE OF ALPHAMERIC CHARACTERS TERMINATED BY A PERIOD, E.G., A2B5E3426FG0ZYW3210PQ89R. BLANK COLUMNS ARE TO BE IGNORED. FROM LEFT TO RIGHT, IF THE NEXT CHARACTER IS A DIGIT, SAY N, IT INDICATES (N+1) REPETITIONS OF THE FOLLOWING CHARACTER, WHETHER THE FOLLOWING DIGIT IS A DIGIT OR NOT .. A NONDIGIT SIMPLY DENOTES ITSELF. OUTPUT CONSISTS OF THE SEQUENCE INDICATED AND SEPARATED INTO GROUP S OF THREE CHARACTERS: ABB BEE EEE E44 446 66F GZY W22 220 0PQ 999 999 999 R. TWO COROUTINES AND A SUBROUTINE. SUBROUTINE 'NEXTCHAR' FINDS THE NONBLANK CHARACTER. COROUTINE 'IN' FINDS THE CHARACTERS OF THE INOUT CODE WITH THE PROPER REPLICATION. COROUTINE 'OUT' PUT THE CO DE INTO THREE-DIGIT GROUPS. 'IN' <---BALR R7,R7---> 'OUT' *------------------------------------------------------------------- --* * ASM00007 KNUTH ELEVATOR SIMULATION * *------------------------------------------------------------------- --* 18 MAY 1981 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 279-293 ELEVATOR SIMULATION *------------------------------------------------------------------- --* * ASM00008 KNUTH ELEVATOR SIMULATION 2.2.5 EXERCISE 5 * *------------------------------------------------------------------- --* 18 MAY 1981 - CHARLES HOTTEL KNUTH, FUNDAMENTAL ALGORITHMS, 2ND EDITION, PP 279-293 ELEVATOR SIMULATION SECTION 2.2.5 EXERCISE 5: MAN NUMBER 10, IN=2, OUT=4 "Charles Hottel" <chottel(a)earthlink.net> wrote in message news:EtGdnd-JTbG6fdDVnZ2dnUVZ_oDinZ2d(a)earthlink.com... > google for z390, it is free and lets you assemble and run ibm assembler > on a pc > > "tlmfru" <lacey(a)mts.net> wrote in message > news:VE03k.228$QN1.89(a)newsfe15.lga... >> Will have a shufty at it. I know BAL but don't have access to am IBM >> system. >> >> Thanks >> Pl >> >> Charles Hottel <chottel(a)earthlink.net> wrote in message >> news:2rudnVqdmKQ5F9HVnZ2dnUVZ_hadnZ2d(a)earthlink.com... >>> >>> "Charles Hottel" <chottel(a)earthlink.net> wrote in message >>> news:w4OdnUs30PyKFNHVnZ2dnUVZ_tHinZ2d(a)earthlink.com... >>> > >>> > "tlmfru" <lacey(a)mts.net> wrote in message >>> > news:TUT2k.163$Jh7.149(a)newsfe21.lga... >>> >> 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 >>> >> >>> >> >>> > >>> > Donald Knuth's The ARt of Computer Programming Volume 1 discusses >>> > coroutines. There is an elevator simulation and some other examples. >> If >>> > you know IBM mainframe assembler language there are some examples of >>> > the >>> > coroutines from Knuth at: http://www.cbttape.org/cbtdowns.htm >>> > >>> >>> Opps sorry, forgot to mention, see file number 590 >>> >>> >> >> > > |