They said it couldn't be done.
in [Cobol]
|
From: Pete Dashwood on 26 Jan 2010 23:28 Michael Wojcik wrote: > Pete Dashwood wrote: >> Michael Wojcik wrote: >>> Pete Dashwood wrote: >>> >>> - In Windows, use the pointer-testing routines or SEH to probe >>> locations in the buffer to see if they're writable >> >> I hadn't thought of that one. Not elegant but a possibility. > > Yes, it's rather a hack. And the Windows IsBadReadPtr / IsBadWritePtr > functions are deprecated (and particularly dangerous in a > multithreaded process), so SEH would be the way to go - but it's > difficult to use in a language that doesn't have built-in support. > >> I did consider trying to detect the end of the buffer by checking >> characters and trapping a storage violation, but it is pretty awful >> isn't it? (As the buffer could be 8000 characters this approach was >> ruled out fairly early on in the piece.) > > Agreed. It's inelegant and the overhead is bad. It can be improved by > only testing each page, on a paged-memory system - with a maximum > length of 8000 bytes, you'd only have to test three addresses on the > typical 4KB-page OS. (8000 bytes could begin partway through one page, > contain all of a second, and stretch into a third.) > > But deliberately trapping, however popular with the "use exceptions > for control flow" crowd, really isn't something you want to do on > every call. > >> Another possibility would be to drop into Assembler and get the >> parameter length from the stack (this is Windows), assuming COBOL >> puts it there. (I have a feeling the calling program pushes each >> parameter and its length onto the stack (the calling mode >> determines who cleans up the stack afterwards if I remember >> rightly),but it is ages since I worked at that level and I simply >> don't have time for the experiments I would need to do to confirm >> it. > > Depends on the implementation, and in many cases on compiler options > or language extensions. The standard Windows calling conventions don't > put parameter lengths on the stack, but compilers can implement other > calling conventions. They can even be interoperable (ie, a COBOL > implementation could include length info without breaking calls to C, > for example), if the length information doesn't change the layout of > the normal parameter values. For example, a COBOL implementation could > put length info after the last parameter, effectively making it a > "hidden" parameter, as long as it's using a convention where the > caller cleans up the stack. Thanks for the comments Michael. I've never used SEH and have put it on my "homework" list... :-) (A chance'd be a fine thing... :-)) Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 27 Jan 2010 09:39 In article <7s9tbqF323U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: >> In article <7s6kgdF5etU1(a)mid.individual.net>, >> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >>> Why would >>> you make money for people who have no idea what's going on? >> >> That was my point exactly, Mr Dashwood... IBM not only had no idea >> what was going on (insofar as your manipulation of their technology >> was concerned) and stated that your techniques must have required >> modification of their software to the point of unsupportability. >> >> To learn that this conclusion is Just Plain Wrong is, I would say, a >> valuable thing and not to be given away without due recompense. > >I understand your point, Doc, but there was more at stake here than >"teaching IBM a lesson..." My apologies for being so obscure, Mr Dashwood, but what I saw at stake here was not 'teach(ing) IBM a lesson', it was adhering to the rather ancient tradition of barter/trade/sale of 'I have something you would like to have, you have something I would like to have... perhaps arrangements might be made for an exchange.' As I formulated, long ago, when I was more bitter and less kindly and altruistic than I am now... 'Knowledge is Power but Information is Money.' DD
From: john on 13 Feb 2010 09:21 On Jan 24, 6:19 am, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > Here's a couple of intellectual exercises if anyone is bored or wants to > think about something else for a break... > > Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both > solutions, or whatever version of COBOL you use if you can solve them with > your current compiler.) > > 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI > 74 procedural COBOL. Almost every one of these programs makes static calls > to a number of subroutines (say there are around 20 of these subroutines).. > > sample call : CALL "X1" using p1, p2, p3, p4. > > Obviously, because of the static linkage, there is HUGE duplication of these > subroutines throughout the environment. (Every other program has the same > subroutines statically linked into it, and some of these "subroutines" are > "large"...) Changing any of the called routines means a nightmare of > identifying and recompiling every program that uses it. > > For reasons connected with a new environment, you need these routines to be > dynamically called, but you cannot change all the calling programs. (In > fact, the client has insisted that the calling program code must remain > EXACTLY as it is.) > > Can you get to a dynamic environment WITHOUT recoding or amending the > calling programs? > > 2. You are replacing a service routine (a called program, not in COBOL) with > a new routine, in COBOL. The new routine has the same signature as the old > one and receives several parameters from the calling programs. Here is its > signature: > > procedure division using > p1, p2, p3, p4.. > > p1, p3, and p4 are always the same type and length. > > But, p2 can vary in length (it is a record buffer). It could be defined in > the working storage of each calling program as anything from 20 to 8000 > bytes. (Not with OCCURS... DEPENDING, just different fixed length records..) > > Your called routine has to update this buffer; if you set a wrong length in > the Linkage section you will immediately crash on a storage violation as > soon as you try to write the record back. > > You might think it is pretty easy to pass a record length or some other > clue) as another parameter. Nope. The same rules as above; you cannot > modify the existing code, and it doesn't have a "p2-length" in its parameter > list. > > Clue: You MIGHT be able to derive the p2 length from an existing > "dictionary", accessible by your new program. > > Any thoughts on how the called program could be coded to accommodate these > requirements? > > FINALLY, as inspiration, some poetry... > > "They said it couldn't be done > But he, with a smile, denied it > He said:'How do you know that it cannot be done?' > Until you, at least, have tried it. > > So he rolled up his sleeves > And he gritted his teeth > And where there was doubt > He hid it. > > And he tackled that job that > 'Couldn't be done'.... > And, Whaddya know?!! > He couldn't bloody do it..." > > Pete. > -- > "I used to write COBOL...now I can do anything." In Open Office COBOL the choice between static and dynamic linking is made at compile time and not in the programs themselves. The main program is compiled as usual: cobc -x -o main main.cob The called program is compiled as a module: cobc -m subr.cob Next you take the subprogram and install it in a library of such: cp subr.so /your/cobol/lib Now you set a variable: export COB_LIBRARY_PATH=/your/cobol/lib Finally you run the program: ../main The variable length buffer can be defined in LINKAGE SECTION as a data item of ANY LENGTH and the picture clause must be defined as a single byte of 9, X or A. OK, that was easy. The above is taken from the Open Cobol Manual and the Open Cobol Programmer's Guide. It should work on Linux and on Windows running cygwin, a faux Linux environment. Obviously these methods are not transportable to environments that don't run Open Cobol. But it does show the functional capability and user friendliness of the OC compiler. John Culleton
From: Anonymous on 13 Feb 2010 11:24 In article <7e4c53ff-7c49-4dc0-9c17-279b44164fb8(a)b18g2000vbl.googlegroups.com>, john(a)wexfordpress.com <john(a)wexfordpress.com> wrote: [snip] >In Open Office COBOL the choice between static and dynamic linking is >made at compile time >and not in the programs themselves. If you are converting mainframe programs you might want to watch out for this; I seem to recall working with a bunch o' programs, some of which began with IDENTIFICATION DIVISION. .... and others with stuff like CBL NODYNAM,TEST(NONE),MAP,FASTSRT IDENTIFICATION DIVISION. This was long ago... and my inquiry of 'what is the reason or benefit for these variations?' was met with 'They've always been that way so we just leave them alone.' I have since learned that there might have been other reasons for having done things in this manner, ranging from optimising COBOL-F performance to someone's hoping to keep their job due to idiosyncratic knowledge... and more than those, as well! DD
From: Richard on 13 Feb 2010 13:44
On Feb 14, 3:21 am, "j...(a)wexfordpress.com" <j...(a)wexfordpress.com> wrote: > On Jan 24, 6:19 am, "Pete Dashwood" > > > > <dashw...(a)removethis.enternet.co.nz> wrote: > > Here's a couple of intellectual exercises if anyone is bored or wants to > > think about something else for a break... > > > Two problems relating to COBOL... (Assume Fujitsu NetCOBOL for both > > solutions, or whatever version of COBOL you use if you can solve them with > > your current compiler.) > > > 1. Imagine you have a couple of thousand COBOL programs, all written in ANSI > > 74 procedural COBOL. Almost every one of these programs makes static calls > > to a number of subroutines (say there are around 20 of these subroutines). > > > sample call : CALL "X1" using p1, p2, p3, p4. > > > Obviously, because of the static linkage, there is HUGE duplication of these > > subroutines throughout the environment. (Every other program has the same > > subroutines statically linked into it, and some of these "subroutines" are > > "large"...) Changing any of the called routines means a nightmare of > > identifying and recompiling every program that uses it. > > > For reasons connected with a new environment, you need these routines to be > > dynamically called, but you cannot change all the calling programs. (In > > fact, the client has insisted that the calling program code must remain > > EXACTLY as it is.) > > > Can you get to a dynamic environment WITHOUT recoding or amending the > > calling programs? > > > 2. You are replacing a service routine (a called program, not in COBOL) with > > a new routine, in COBOL. The new routine has the same signature as the old > > one and receives several parameters from the calling programs. Here is its > > signature: > > > procedure division using > > p1, p2, p3, p4. > > > p1, p3, and p4 are always the same type and length. > > > But, p2 can vary in length (it is a record buffer). It could be defined in > > the working storage of each calling program as anything from 20 to 8000 > > bytes. (Not with OCCURS... DEPENDING, just different fixed length records.) > > > Your called routine has to update this buffer; if you set a wrong length in > > the Linkage section you will immediately crash on a storage violation as > > soon as you try to write the record back. > > > You might think it is pretty easy to pass a record length or some other > > clue) as another parameter. Nope. The same rules as above; you cannot > > modify the existing code, and it doesn't have a "p2-length" in its parameter > > list. > > > Clue: You MIGHT be able to derive the p2 length from an existing > > "dictionary", accessible by your new program. > > > Any thoughts on how the called program could be coded to accommodate these > > requirements? > > > FINALLY, as inspiration, some poetry... > > > "They said it couldn't be done > > But he, with a smile, denied it > > He said:'How do you know that it cannot be done?' > > Until you, at least, have tried it. > > > So he rolled up his sleeves > > And he gritted his teeth > > And where there was doubt > > He hid it. > > > And he tackled that job that > > 'Couldn't be done'.... > > And, Whaddya know?!! > > He couldn't bloody do it..." > > > Pete. > > -- > > "I used to write COBOL...now I can do anything." > > In Open Office COBOL OpenCobol. > the choice between static and dynamic linking is > made at compile time > and not in the programs themselves. That is not entirely true, If the source code has: 01 Program-Name PIC X(20), .... MOVE something TO Program-Name CALL Program-Name USING .... Then the call will technically be dynamic regardless of what the compiler was told. > The main program is compiled as > usual: > cobc -x -o main main.cob > > The called program is compiled as a module: > cobc -m subr.cob > > Next you take the subprogram and install it in a library of such: > cp subr.so /your/cobol/lib > > Now you set a variable: > export COB_LIBRARY_PATH=/your/cobol/lib > > Finally you run the program: > ./main > > The variable length buffer can be defined in LINKAGE SECTION as a data > item of > ANY LENGTH > and the picture clause must be defined as a single byte of 9, X or A. > > OK, that was easy. Note that the standard (2002) and implementations such as Fujitsu only allow ANY LENGTH in a method, not in a (sub)program. > The above is taken from the Open Cobol Manual and the Open Cobol > Programmer's Guide. It should work on Linux and on Windows running > cygwin, a faux Linux environment. > > Obviously these methods are not transportable to environments that > don't run Open Cobol. > But it does show the functional capability and user friendliness of > the OC compiler. > > John Culleton |