Currently we embed sql in Cobol programs using Pro-Cobol. It works great. I do believe they just want to get rid of Cobol altogether
On Jul 17, 6:35 am, jmoore <[email protected]> wrote: > It certianly wasn't my idea to convert programs to pl/sql. We have > plenty of Cobol programmers here. It was somebody's bright idea way > above us that we are going to convert everything to pl/sql procedures > and packages. I guess they do not want to have to pay for micr-focus > anymore. A few of us Cobol programmers have voiced our concerns, but > to no avail. They have not set any kind of standards yet, its more of > the owner says do it. We have pl/sql programmers in India that work > for this company, but there isn't much standardization in what I have > seen. Also, I do not believe it will increase performance when Oracle > is having to load so many porcedures at once. I am just looking for > some good examples of how to use for while loops etc. Being a cobol > guy I am used to structure and from what I have seen these are not. I > need some good logic where 1 table is read and it has to pass by some > exceptions (if not go back read next record) then takes the key and > gets info from table 2, passes some exceptions maybe table 3 and than > it would write out to a sort file. The return would be to create a > file or printfile. The batch programs we have ask the users things > like > Enter from date > Enter thru date > > Enter dept > 1. all > 2. specific > Uses these variables to read the tables to create the sort file. > > On Jul 16, 11:51 pm, Rob Wolfe <[email protected]> wrote: > > > > > On Jul 16, 2:10 pm, jmoore <[email protected]> wrote: > > > > Does anyone have any example code of Cobol programs that were > > > converted to PL/sql procedures/packages? Our company is trying to > > > convert programs to pl/sql and they really haven't addressed many of > > > the challenges. First being batch programs that display/accept data > > > from the user. Any help would be greatly appreciated. I certianly hope > > > there is at least one dinosaur like me in this forum. > > > Big Dino-roar from here. Can I ask why you would want to do such a > > horrible thing to yourself? Seriously, why would you convert cobol to > > PL/SQL of all things? There are lots of perfectly good cobol compilers > > out there and Oracle plays quite nicely with them. > > I know that if someone came up to me with the idea of rewriting a > > bunch of cobol programs in pl/sql I would want a very convincing > > business case for the project. > > Even if you are rehosting from a mainframe to (for instance) a linux > > VM there is still no good reason to do what you are thinking about > > unless someone has a religious aversion to cobol. If you are short on > > cobol programmers then I would suggest that training one of your > > existing ones would be cheaper than converting anything but the most > > trivial program to pl/sql. > > > I would like to hear more about the thinking behind this project > > because you have bitten off some nastiness. I do have to say that I > > don't understand one thing ... in my experience users don't interact > > with batch programs, that is kind of the point of them. Or am I > > missing something?- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Oracle PL/SQL" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Oracle-PLSQL?hl=en -~----------~----~----~----~------~----~------~--~---
