On Jul 17, 8:49 am, Rob Wolfe <[email protected]> wrote:
> 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?
>
> You will find as much or more structure in PL/SQL than you will in
> cobol. Honestly, you will be best off working through a good pl/sql
> tutorial/cookbook (there are a bunch on amazon.com). I do have to
> reiterate that this is simply a dumb idea (I know it isnt yours) and
> someone has to grow a pair and tell management that they are going to
> spend more rewriting (this isnt a conversion project, it is a rewrite)
> the code than they are going to save on licenses (back it up with
> numbers, MF Cobol isnt THAT expensive, if you can afford Oracle...).
> As soon as they see a negative ROI for the project, if they are
> competent, they will back off on it. Certainly as new functionality is
> added you can use PL/SQL to implement it but you have the makings of a
> disaster here.
>
> Sorry I can't sound more positive about this but I have participated
> in the aftermath of top down technical decisions and they are nearly
> uniformly a result of someone being sold something or reading
> something and half understanding it. It should be VERY easy to do a
> quick ROI on this and I would be shocked if it comes out positive. I
> think that it is the duty of professional development staff to push
> back hard on really dumb ideas with as much business related
> information as they can muster.
>
> Rob- Hide quoted text -
>
> - Show quoted text -
Unfortunately, someone in product design took a pl/sql class or
something and sold this bill of goods to the president. Everything
here is needed yesterday w/o much forethought. So I just have to do
what I have to do. The job market is quite bleak at the moment. But I
whole-heartedly agree with everything you have written
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
