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 pai
> 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 ro
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
> 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 C
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.
http://portal.acm.org/cit
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
>cal
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 to
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
>
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 o
When all else fails, your need to answer four questions:
1) Is it authorized by the management that answers for the results of
processing?
2) How do you know if the processing and resulting data are complete?
3) How do you know the results of processing are accurate?
4) Can the results of transact
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 an
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. A
On Nov 1, 2007, at 4:16 PM, Johan Peeters wrote:
sSince so much of the financial
services industry is powered by COBOL, I would have thought that
someone would have done a thorough study of COBOL's security posture.
I certainly have not found one. Anyone else?
Just a couple random(ish) observa
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 come
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 probabl
15 matches
Mail list logo