Open Cobol is free and standard.
in [Cobol]
|
Prev: Level 78
Next: Open Cobol is free and standar
From: James J. Gavan on 12 Feb 2010 15:48 SkippyPB wrote: >>For me, a useful CoBOL program is one that someone pays me for. > > If I could write programs in Cobol for use on the PC with gui and all, > I have several things in mind that I'd like to do. I could these > things in CICS utilitzing VSAM files also, but I doubt my clients > would like what I have in mind on their mainframes and it certainly > wouldn't be as pretty. > Steve I'll start by qualifying, I don't know the first thing about mainframes. But I do recall somebody years ago, (in this specific COBOL newsgroup), writing about COBOL files on a mainframe and what he was doing. It didn't have a single line of COBOL in it. He was using all the gizmos associated with IBM file handling ! So you want to do it on a PC (GUIs and all), then throw it back to a mainframe ? Having figured it out at PC-Level I'm assuming you don't want to try and pass back GUIs to the mainframe ? I haven't a clue whether or not that is possible or whether it creates the complete mess you are referring to. What follows is theoretical, but adapted to your mainframe knowledge, just might do the trick. To an extent you can parallel the flexibility of handling COBOL files in OO, *IF* your mainframe compiler has ENTRY-POINTS. Using a separate procedural program per file you use the Entry-Points, separate sections per access type 'Open as Input', 'Open IO', "Read Key', 'Read Next' etc. and so on. If you want to do it right it means also using File-Status codes within each section to trap errors or valid results. Now the bugaboo on separate programs for file handling is knowing if the file is already open. I have never used entry-points but I did check once on a program with entry-points - if you DON'T specifically EXIT from a Section (and without checking, I think I've got that right), it takes you back to your CALLing program. When you come back into the File Program your original file-status is still valid. (In OO using the Animator I can quiz the file status, and it will return telling me the file was opened as Input or IO, as appropriate). You can't do that, but I'm sure it also applies. The value of the file-status is only lost when you specifically say CANCEL program at the end of your run. Slight variation on the above if using an IBM compiler that has OO. Accepting that IBM link mostly to Java for support and GUI-ing, the IBM implementation does provide the full COBOL OO Standard for class and method structure. So now you are able to replace those entry-points above by invoking individual methods per file by access type. Put your thinking cap on and get crackin' :-) Jimmy, Calgary AB
From: Pete Dashwood on 13 Feb 2010 07:29 SkippyPB wrote: > On Thu, 11 Feb 2010 14:52:43 -0700, Howard Brazee <howard(a)brazee.net> > wrote: > >> On Thu, 11 Feb 2010 11:15:07 -0800 (PST), "john(a)wexfordpress.com" >> <john(a)wexfordpress.com> wrote: >> >>> Of course one can also write useful programs in Open Cobol. >> >> I really have no idea what kind of hobbyist program I would want to >> write in CoBOL. >> >> CoBOL has one huge advantage for me - I know it well. But what am I >> going to write that's useful or fun for me on my home computer? >> >> For me, a useful CoBOL program is one that someone pays me for. > > If I could write programs in Cobol for use on the PC with gui and all, > I have several things in mind that I'd like to do. Well, you can. OC would support a GUI interface to COBOL. >I could these > things in CICS utilitzing VSAM files also, but I doubt my clients > would like what I have in mind on their mainframes and it certainly > wouldn't be as pretty. Why not? You could use the OC COBOL screen section and exactly duplicate anything that happens with CICS on a mainframe. In another lifetime I wrote a screen painter that enables you define a CICS (or IMS/DC) screen. You "draw" your screen on a green screen and hit a button when you are happy with it. The system then generates a COBOL definition of the buffer (including attribute bytes for 3270, that actually work on the PC as well), a CICS BMS buffer, an IMS/DC MID/MOD, and a PC COBOL module that handles the screen display. (You interface to it using the generated buffers...just as you would in CICS or IMS/DC, except that it all runs on a PC...). It was all part of a system I developed which (back in the days when these things mattered) allowed a system to be developed on a PC but run on a number of different mainframes or PC architectures. It was called "ACE" (Application Control of the Environment) and, the last I heard, is still running in a major Bank in Spain. ACE was all about separating display and database access from Business Logic. Today, this is taken as read in most Object Oriented communities, but at the time it was quite revolutionary. (ACE is written entirely in procedural COBOL). The major advantage for the Bank was that it enabled their existing VSAM system to convert easily to IMS/DB/DC and, later, DB2, with no major impact on their applications. I had the idea for it while I was soaking in some hot springs near where I live. (I was home for Christmas from Europe...) Nowadays, I go to these same hot springs and have had many useful and financially beneficial ideas while relaxing there (including aspects of the PRIMA Migration Toolset).. I can recommend hot spring therapy if you are stuck with a problem... :-) Point is, Steve, if you want to have a crack at emulating a CICS system on a PC, I'll GIVE you the source code for ACE as a present. (always assuming I can find it, of course) It would be on a machine that has been mothballed many years ago. In fact, I think I recall using Micro Focus COBOL and ADIS for it, so it would be on a Windows 3.1 machine. (16 bit). Nevertheless, it is all COBOL source, and, as such, should be recompilable to 32 or 64 bit. (If anyone is seriously interested in playing with this, mail me. It is sitting there doing nothing and it took many months to develop. I'll gladly give it away ot a good home... :-)) BOTTOM LINE: Emulating a mainframe on a PC is really no big deal; emulating a PC on a mainframe is much more difficult... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 13 Feb 2010 11:34 In article <7tnkugFiidU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >I meant to mention to Steve that this quote is not correctly attributed; it >was Sam Goldwyn of MGM who is supposed to have said it, not "Sam Goldman". >(Goldwyn was famous for howlers like this.... "Anybody who goes to a >psychiatrist should have his head examined" and "We are dealing with >reality, not facts." There is some dispute over whether he actually said the >"oral contract" quote, but he was certainly capable of doing so.) See http://en.wikiquote.org/wiki/Samuel_Goldwyn ... also http://en.wikipedia.org/wiki/Samuel_Goldwyn#Goldwynisms (both of which contain variations of my favorite 'I dont want any yes-men around me. I want everyone to tell the truth - even though it costs him his job. ' DD
From: SkippyPB on 13 Feb 2010 11:43 On Fri, 12 Feb 2010 13:48:04 -0700, "James J. Gavan" <jgavandeletethis(a)shaw.ca> wrote: >SkippyPB wrote: >>>For me, a useful CoBOL program is one that someone pays me for. >> >> If I could write programs in Cobol for use on the PC with gui and all, >> I have several things in mind that I'd like to do. I could these >> things in CICS utilitzing VSAM files also, but I doubt my clients >> would like what I have in mind on their mainframes and it certainly >> wouldn't be as pretty. >> Steve > >I'll start by qualifying, I don't know the first thing about mainframes. > But I do recall somebody years ago, (in this specific COBOL newsgroup), >writing about COBOL files on a mainframe and what he was doing. It >didn't have a single line of COBOL in it. He was using all the gizmos >associated with IBM file handling ! > >So you want to do it on a PC (GUIs and all), then throw it back to a >mainframe ? Having figured it out at PC-Level I'm assuming you don't >want to try and pass back GUIs to the mainframe ? I haven't a clue >whether or not that is possible or whether it creates the complete mess >you are referring to. > No, I don't want to throw it back on the mainframe. I was just pointing out that I could design and write a system to do what I have in mind on the mainframe using the CICS environment and VSAM file structure. However, I don't have a right to do that and I don't usually work with the same client for more than 6 months. >What follows is theoretical, but adapted to your mainframe knowledge, >just might do the trick. > >To an extent you can parallel the flexibility of handling COBOL files in >OO, *IF* your mainframe compiler has ENTRY-POINTS. Using a separate >procedural program per file you use the Entry-Points, separate sections >per access type 'Open as Input', 'Open IO', "Read Key', 'Read Next' etc. >and so on. If you want to do it right it means also using File-Status >codes within each section to trap errors or valid results. > >Now the bugaboo on separate programs for file handling is knowing if the >file is already open. I have never used entry-points but I did check >once on a program with entry-points - if you DON'T specifically EXIT >from a Section (and without checking, I think I've got that right), it >takes you back to your CALLing program. When you come back into the File >Program your original file-status is still valid. (In OO using the >Animator I can quiz the file status, and it will return telling me the >file was opened as Input or IO, as appropriate). You can't do that, but >I'm sure it also applies. > >The value of the file-status is only lost when you specifically say >CANCEL program at the end of your run. > >Slight variation on the above if using an IBM compiler that has OO. >Accepting that IBM link mostly to Java for support and GUI-ing, the IBM >implementation does provide the full COBOL OO Standard for class and >method structure. So now you are able to replace those entry-points >above by invoking individual methods per file by access type. > >Put your thinking cap on and get crackin' :-) > >Jimmy, Calgary AB Thanks for the effort, but I'd rather have the system on my PC. And one other point, I am loathe to use OO anything. I'm too much of a control freak (when it comes to coding) as I'm a bit twiddling IBM Assembler programmer at heart and would rather be able to see "exactly" what's going on and how it is being done rather than use someone else's object. Cheers, -- //// (o o) -oOO--(_)--OOo- "An oral contract isn't worth the paper it's written on." -- Sam Goldwyn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: SkippyPB on 13 Feb 2010 11:50
On Sun, 14 Feb 2010 01:29:02 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >SkippyPB wrote: >> On Thu, 11 Feb 2010 14:52:43 -0700, Howard Brazee <howard(a)brazee.net> >> wrote: >> >>> On Thu, 11 Feb 2010 11:15:07 -0800 (PST), "john(a)wexfordpress.com" >>> <john(a)wexfordpress.com> wrote: >>> >>>> Of course one can also write useful programs in Open Cobol. >>> >>> I really have no idea what kind of hobbyist program I would want to >>> write in CoBOL. >>> >>> CoBOL has one huge advantage for me - I know it well. But what am I >>> going to write that's useful or fun for me on my home computer? >>> >>> For me, a useful CoBOL program is one that someone pays me for. >> >> If I could write programs in Cobol for use on the PC with gui and all, >> I have several things in mind that I'd like to do. > >Well, you can. OC would support a GUI interface to COBOL. > >>I could these >> things in CICS utilitzing VSAM files also, but I doubt my clients >> would like what I have in mind on their mainframes and it certainly >> wouldn't be as pretty. > >Why not? You could use the OC COBOL screen section and exactly duplicate >anything that happens with CICS on a mainframe. > Yikes, I guess I wasn't clear at all in my original post. It would absolutely be prettier and better on a PC using gui than on the mainframe in CICS which is really text based screens with a few enhanced attributes thrown in for good measure. >In another lifetime I wrote a screen painter that enables you define a CICS >(or IMS/DC) screen. You "draw" your screen on a green screen and hit a >button when you are happy with it. The system then generates a COBOL >definition of the buffer (including attribute bytes for 3270, that actually >work on the PC as well), a CICS BMS buffer, an IMS/DC MID/MOD, and a PC >COBOL module that handles the screen display. (You interface to it using the >generated buffers...just as you would in CICS or IMS/DC, except that it all >runs on a PC...). It was all part of a system I developed which (back in the >days when these things mattered) allowed a system to be developed on a PC >but run on a number of different mainframes or PC architectures. It was >called "ACE" (Application Control of the Environment) and, the last I >heard, is still running in a major Bank in Spain. ACE was all about >separating display and database access from Business Logic. Today, this is >taken as read in most Object Oriented communities, but at the time it was >quite revolutionary. (ACE is written entirely in procedural COBOL). The >major advantage for the Bank was that it enabled their existing VSAM system >to convert easily to IMS/DB/DC and, later, DB2, with no major impact on >their applications. > My employer has as part of the software suite that I support a "screen painter" which pretty much does what you describe. We've had it available since the mid 80's. You define your screen in CICS using our tools and then you run a batch program that generates a Cobol copybook for the map to be used in a program. I recall there being an IBM utility available many years ago (forgot its name) that allowed you to design a screen and it would generate the map copybook all in batch. Both those tools are great for folks who don't want to take the time to learn how to code the Assembler macroes to generate the map code. Even though I could do those in my sleep, I'm getting lazy in my advanced years and like using our tools better. >I had the idea for it while I was soaking in some hot springs near where I >live. (I was home for Christmas from Europe...) Nowadays, I go to these same >hot springs and have had many useful and financially beneficial ideas while >relaxing there (including aspects of the PRIMA Migration Toolset).. I can >recommend hot spring therapy if you are stuck with a problem... :-) > >Point is, Steve, if you want to have a crack at emulating a CICS system on a >PC, I'll GIVE you the source code for ACE as a present. (always assuming I >can find it, of course) It would be on a machine that has been mothballed >many years ago. In fact, I think I recall using Micro Focus COBOL and ADIS >for it, so it would be on a Windows 3.1 machine. (16 bit). Nevertheless, it >is all COBOL source, and, as such, should be recompilable to 32 or 64 bit. > Thanks, but that is not my aim. >(If anyone is seriously interested in playing with this, mail me. It is >sitting there doing nothing and it took many months to develop. I'll gladly >give it away ot a good home... :-)) > >BOTTOM LINE: Emulating a mainframe on a PC is really no big deal; emulating >a PC on a mainframe is much more difficult... :-) > >Pete. Regards, -- //// (o o) -oOO--(_)--OOo- "An oral contract isn't worth the paper it's written on." -- Sam Goldwyn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve |