In my experience of reviewing COBOL and mainframes in general, it's
worthwhile to evaluate doing bad things to the business logic. The
designers are literal in their translation of the business
requirements to specifications, and never think of the mis-use cases.
Mainframe coders aren't
At 11:45 PM +0100 11/2/07, Florian Weimer wrote:
My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
Usually, Ada programmers switch off bounds checking before shipping
code. I don't know why Ada has such a reputation for robustness.
Cobol is highly structured and very difficult to just whip together a program.
Your DATA section had to be specified EXACTLY as your design specifies. Any
program which input data over the stated limit would give an exception. On the
older mainframes your program would terminate. Do not have
At 4:11 PM +0100 11/2/07, Johan Peeters wrote:
Let me offer a little variant on the previous theme though to
illustrate, hopefully more convincingly, why I find COBOL worrisome:
...
01 txtpic x(2).
move 'hi' to txt
call
I have been looking at an IBM system. If I do something like this
...
01 txt PIC X(120)
string '**'
into txt
end-string
display txt
I get to see ** on sysout followed by what appears
ljknews wrote:
At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
I think this could do a great service to the community.
Recently I was hired by a major financial institution as a lead
developer. They said they needed me for some Java applications, but it
turns out that the majority of code is
At 2:16 PM +0100 11/2/07, Johan Peeters wrote:
I have been looking at an IBM system. If I do something like this
...
01 txt PIC X(120)
string '**'
into txt
end-string
display
On 02/11/2007, Glenn and Mary Everhart [EMAIL PROTECTED] wrote:
I believe there are some old COBOL static analyzers around,
One of them is the Anno Domini system, which was developed to help the
Y2K (do anybody remember what was this hype?) experts to do their
work.
My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
Usually, Ada programmers switch off bounds checking before shipping
code. I don't know why Ada has such a reputation for robustness.
___
Secure
At 11:45 PM +0100 11/2/07, Florian Weimer wrote:
My limited exposure to Cobol makes me think it is as unlikely to have
a buffer overflow as PL/I or Ada.
Usually, Ada programmers switch off bounds checking before shipping
code. I don't know why Ada has such a reputation for robustness.
Can
I was thinking that there is an opportunity for us otherwise lazy
enterprisey types to do our part in order to promote secure coding in an
open source way. Small vendors tend to be filled with lots of folks that
know C, Java and .NET but may not have anyone who knows COBOL.
Minimally, they
I think this could do a great service to the community.
Recently I was hired by a major financial institution as a lead
developer. They said they needed me for some Java applications, but it
turns out that the majority of code is in COBOL. As I have never
before been anywhere near COBOL, this
At 9:16 PM +0100 11/1/07, Johan Peeters wrote:
I think this could do a great service to the community.
Recently I was hired by a major financial institution as a lead
developer. They said they needed me for some Java applications, but it
turns out that the majority of code is in COBOL. As I
13 matches
Mail list logo
