Date Validation in COBOL

  • Permalink
  • submit to reddit
  • Email
  • Follow


OK, so I am certain that this will end up in "style war" discussions and/or 
discussions of how to do "multiple possible error" processing or a number of 
things we have discussed before, but ...

There may be one in the "archives" that I didn't see, but given the other 
thread, I thought I would go ahead and code a "date validation" in COBOL 
routine.  (This assumes YYYYMMDD format and only handles dates in the range of 
Jan 1, 1601 - first date allowed for Intrinsic Functions - thru Dec 31, 9999). 
Expanding it would be easy.

I put the "input date" in WS, but obviously one could change that to a Linkage 
Section parameter or an ACCEPT (from console) or any other way of getting it in 
for validation.

So, for what it is worth, ...

       Identification Division.
        Program-ID.  VALDATE.
       Data Division.
        Working-Storage Section.
       01  Date-IN.
           05  DI-YYYY Pic 9(04).
           05  DI-MM Pic 9(02).
               88 1-to-12 Value 1 thru 12.
               88 31-Days Value 1 3 5 7 8 10 12.
               88 30-Days Value 4 6 9 11.
               88 Feb  Value 2.
           05  DI-DD Pic 9(02).
               88  1-to-31 Value 1 thru 31.
               88  1-to-30 Value 1 thru 30.
               88  1-to-29      Value 1 thru 29.
               88  1-to-28 Value 1 thru 28. .
       01  Info-Out.
           05  Stat Pic 9(01) Value Zero.
           05  Msg Pic X(80) Value Spaces.
       Procedure Division.
        Mainline.
           If Date-In Not Numeric
               Move 1 to Stat
               Move "Non-Numeric Value in Input Date"
                 to Msg
           Else
               If DI-YYYY < 1601
      *            any larger year less than 9999 is valid
                   Move 2 to Stat
                   Move "Year less than 1601"
                     to Msg
               Else
                   If  not 1-to-12
                       Move 3  to Stat
                       Move "Month too small or too large"
                         to Msg
                   Else
                       If  31-Days
                        and not 1-to-31
                         Move 4  to Stat
                         Move "Day of month invalid for this month"
                           to Msg
                       Else
                           If 30-Days
                            And not 1-to-30
                             Move 5  to Stat
                             Move "Day of month invalid for this month"
                               to Msg
                           Else
                               If Feb
                                and not 1-to-29
                                   Move 5  to Stat
                                   Move "Day of month invalid for this month"
                                to Msg
                        Else
                            Perform Check-Leap-Year
                        End-If
                    End-If
                End-If
            End-If
               End-If
           End-If
           Stop Run
            .
       Check-Leap-Year.
           Continue
           If Function Mod (DI-YYYY 400) = 0
               Continue
           Else
               If   (function Mod (DI-yyyy 4) = 0)
                And (Function Mod (DI-YYYY 100) NOT = 0)
                   Continue
               Else
                   If 1-to-28
                       Continue
                   Else
                       Move 6 to Stat
                       Move "Year is not a leap year"
                     to Msg
                   End-If
               End-If
           End-If
             .

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
Reply wmklein40 (279) 1/6/2009 5:51:16 AM

See related articles to this posting


William M. Klein wrote:
> OK, so I am certain that this will end up in "style war" discussions
> and/or discussions of how to do "multiple possible error" processing
> or a number of things we have discussed before, but ...
>
> There may be one in the "archives" that I didn't see, but given the
> other thread, I thought I would go ahead and code a "date validation"
> in COBOL routine.  (This assumes YYYYMMDD format and only handles
> dates in the range of Jan 1, 1601 - first date allowed for Intrinsic
> Functions - thru Dec 31, 9999). Expanding it would be easy.
>
> I put the "input date" in WS, but obviously one could change that to
> a Linkage Section parameter or an ACCEPT (from console) or any other
> way of getting it in for validation.
>
> So, for what it is worth, ...
>
>       Identification Division.
>        Program-ID.  VALDATE.
>       Data Division.
>        Working-Storage Section.
>       01  Date-IN.
>           05  DI-YYYY Pic 9(04).
>           05  DI-MM Pic 9(02).
>               88 1-to-12 Value 1 thru 12.
>               88 31-Days Value 1 3 5 7 8 10 12.
>               88 30-Days Value 4 6 9 11.
>               88 Feb  Value 2.
>           05  DI-DD Pic 9(02).
>               88  1-to-31 Value 1 thru 31.
>               88  1-to-30 Value 1 thru 30.
>               88  1-to-29      Value 1 thru 29.
>               88  1-to-28 Value 1 thru 28. .
>       01  Info-Out.
>           05  Stat Pic 9(01) Value Zero.
>           05  Msg Pic X(80) Value Spaces.
>       Procedure Division.
>        Mainline.
>           If Date-In Not Numeric
>               Move 1 to Stat
>               Move "Non-Numeric Value in Input Date"
>                 to Msg
>           Else
>               If DI-YYYY < 1601
>      *            any larger year less than 9999 is valid
>                   Move 2 to Stat
>                   Move "Year less than 1601"
>                     to Msg
>               Else
>                   If  not 1-to-12
>                       Move 3  to Stat
>                       Move "Month too small or too large"
>                         to Msg
>                   Else
>                       If  31-Days
>                        and not 1-to-31
>                         Move 4  to Stat
>                         Move "Day of month invalid for this month"
>                           to Msg
>                       Else
>                           If 30-Days
>                            And not 1-to-30
>                             Move 5  to Stat
>                             Move "Day of month invalid for this month"
>                               to Msg
>                           Else
>                               If Feb
>                                and not 1-to-29
>                                   Move 5  to Stat
>                                   Move "Day of month invalid for this
>                                month" to Msg
>                        Else
>                            Perform Check-Leap-Year
>                        End-If
>                    End-If
>                End-If
>            End-If
>               End-If
>           End-If
>           Stop Run
>            .
>       Check-Leap-Year.
>           Continue
>           If Function Mod (DI-YYYY 400) = 0
>               Continue
>           Else
>               If   (function Mod (DI-yyyy 4) = 0)
>                And (Function Mod (DI-YYYY 100) NOT = 0)
>                   Continue
>               Else
>                   If 1-to-28
>                       Continue
>                   Else
>                       Move 6 to Stat
>                       Move "Year is not a leap year"
>                     to Msg
>                   End-If
>               End-If
>           End-If
>             .
 I liked the code, Bill. It is refreshing to see date validation without a 
calendar in it... :-)

So, here we have a function that takes a date in a specified format and 
tells us quite a bit about it. It is very unlikely to ever need modification 
(unless the whole basis for our calendar was changed) and any manipulation 
of other date formats can be done outside of it (or it could be wrapped to 
include such formats.)

This is the precise way in which component based systems get built.

If you have no objection, I'll make this into a COM component (using Fujitsu 
NetCobol) and post it on the COBDATA Web Site (where it can be publicly 
downloaded). The site is listed for complete refurbishment as soon as I have 
some time. I expect to be doing it at the end of this month.

What would be of real interest to me, personally, would be to see this code 
converted to a COM object, using the MicroFocus COBOL compiler.The problem 
is that anyone downloading it would have to pay runtime fees...nevertheless, 
I'd like to see the code.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/6/2009 10:30:45 AM

Feel free to use the code (and/or post it in a modified way) in any way you 
would like.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6sgq6lF5tq5mU1@mid.individual.net...
> William M. Klein wrote:
>> OK, so I am certain that this will end up in "style war" discussions
>> and/or discussions of how to do "multiple possible error" processing
>> or a number of things we have discussed before, but ...
>>
>> There may be one in the "archives" that I didn't see, but given the
>> other thread, I thought I would go ahead and code a "date validation"
>> in COBOL routine.  (This assumes YYYYMMDD format and only handles
>> dates in the range of Jan 1, 1601 - first date allowed for Intrinsic
>> Functions - thru Dec 31, 9999). Expanding it would be easy.
>>
>> I put the "input date" in WS, but obviously one could change that to
>> a Linkage Section parameter or an ACCEPT (from console) or any other
>> way of getting it in for validation.
>>
>> So, for what it is worth, ...
>>
>>       Identification Division.
>>        Program-ID.  VALDATE.
>>       Data Division.
>>        Working-Storage Section.
>>       01  Date-IN.
>>           05  DI-YYYY Pic 9(04).
>>           05  DI-MM Pic 9(02).
>>               88 1-to-12 Value 1 thru 12.
>>               88 31-Days Value 1 3 5 7 8 10 12.
>>               88 30-Days Value 4 6 9 11.
>>               88 Feb  Value 2.
>>           05  DI-DD Pic 9(02).
>>               88  1-to-31 Value 1 thru 31.
>>               88  1-to-30 Value 1 thru 30.
>>               88  1-to-29      Value 1 thru 29.
>>               88  1-to-28 Value 1 thru 28. .
>>       01  Info-Out.
>>           05  Stat Pic 9(01) Value Zero.
>>           05  Msg Pic X(80) Value Spaces.
>>       Procedure Division.
>>        Mainline.
>>           If Date-In Not Numeric
>>               Move 1 to Stat
>>               Move "Non-Numeric Value in Input Date"
>>                 to Msg
>>           Else
>>               If DI-YYYY < 1601
>>      *            any larger year less than 9999 is valid
>>                   Move 2 to Stat
>>                   Move "Year less than 1601"
>>                     to Msg
>>               Else
>>                   If  not 1-to-12
>>                       Move 3  to Stat
>>                       Move "Month too small or too large"
>>                         to Msg
>>                   Else
>>                       If  31-Days
>>                        and not 1-to-31
>>                         Move 4  to Stat
>>                         Move "Day of month invalid for this month"
>>                           to Msg
>>                       Else
>>                           If 30-Days
>>                            And not 1-to-30
>>                             Move 5  to Stat
>>                             Move "Day of month invalid for this month"
>>                               to Msg
>>                           Else
>>                               If Feb
>>                                and not 1-to-29
>>                                   Move 5  to Stat
>>                                   Move "Day of month invalid for this
>>                                month" to Msg
>>                        Else
>>                            Perform Check-Leap-Year
>>                        End-If
>>                    End-If
>>                End-If
>>            End-If
>>               End-If
>>           End-If
>>           Stop Run
>>            .
>>       Check-Leap-Year.
>>           Continue
>>           If Function Mod (DI-YYYY 400) = 0
>>               Continue
>>           Else
>>               If   (function Mod (DI-yyyy 4) = 0)
>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>                   Continue
>>               Else
>>                   If 1-to-28
>>                       Continue
>>                   Else
>>                       Move 6 to Stat
>>                       Move "Year is not a leap year"
>>                     to Msg
>>                   End-If
>>               End-If
>>           End-If
>>             .
> I liked the code, Bill. It is refreshing to see date validation without a 
> calendar in it... :-)
>
> So, here we have a function that takes a date in a specified format and tells 
> us quite a bit about it. It is very unlikely to ever need modification (unless 
> the whole basis for our calendar was changed) and any manipulation of other 
> date formats can be done outside of it (or it could be wrapped to include such 
> formats.)
>
> This is the precise way in which component based systems get built.
>
> If you have no objection, I'll make this into a COM component (using Fujitsu 
> NetCobol) and post it on the COBDATA Web Site (where it can be publicly 
> downloaded). The site is listed for complete refurbishment as soon as I have 
> some time. I expect to be doing it at the end of this month.
>
> What would be of real interest to me, personally, would be to see this code 
> converted to a COM object, using the MicroFocus COBOL compiler.The problem is 
> that anyone downloading it would have to pay runtime fees...nevertheless, I'd 
> like to see the code.
>
> Pete.
> -- 
> "I used to write COBOL...now I can do anything."
> 


0
Reply wmklein40 (279) 1/6/2009 10:46:05 AM


Pete Dashwood a �crit :
> William M. Klein wrote:
>   
>> OK, so I am certain that this will end up in "style war" discussions
>> and/or discussions of how to do "multiple possible error" processing
>> or a number of things we have discussed before, but ...
>>
>> There may be one in the "archives" that I didn't see, but given the
>> other thread, I thought I would go ahead and code a "date validation"
>> in COBOL routine.  (This assumes YYYYMMDD format and only handles
>> dates in the range of Jan 1, 1601 - first date allowed for Intrinsic
>> Functions - thru Dec 31, 9999). Expanding it would be easy.
>>
>> I put the "input date" in WS, but obviously one could change that to
>> a Linkage Section parameter or an ACCEPT (from console) or any other
>> way of getting it in for validation.
>>
>> So, for what it is worth, ...
>>
>>       Identification Division.
>>        Program-ID.  VALDATE.
>>       Data Division.
>>        Working-Storage Section.
>>       01  Date-IN.
>>           05  DI-YYYY Pic 9(04).
>>           05  DI-MM Pic 9(02).
>>               88 1-to-12 Value 1 thru 12.
>>               88 31-Days Value 1 3 5 7 8 10 12.
>>               88 30-Days Value 4 6 9 11.
>>               88 Feb  Value 2.
>>           05  DI-DD Pic 9(02).
>>               88  1-to-31 Value 1 thru 31.
>>               88  1-to-30 Value 1 thru 30.
>>               88  1-to-29      Value 1 thru 29.
>>               88  1-to-28 Value 1 thru 28. .
>>       01  Info-Out.
>>           05  Stat Pic 9(01) Value Zero.
>>           05  Msg Pic X(80) Value Spaces.
>>       Procedure Division.
>>        Mainline.
>>           If Date-In Not Numeric
>>               Move 1 to Stat
>>               Move "Non-Numeric Value in Input Date"
>>                 to Msg
>>           Else
>>               If DI-YYYY < 1601
>>      *            any larger year less than 9999 is valid
>>                   Move 2 to Stat
>>                   Move "Year less than 1601"
>>                     to Msg
>>               Else
>>                   If  not 1-to-12
>>                       Move 3  to Stat
>>                       Move "Month too small or too large"
>>                         to Msg
>>                   Else
>>                       If  31-Days
>>                        and not 1-to-31
>>                         Move 4  to Stat
>>                         Move "Day of month invalid for this month"
>>                           to Msg
>>                       Else
>>                           If 30-Days
>>                            And not 1-to-30
>>                             Move 5  to Stat
>>                             Move "Day of month invalid for this month"
>>                               to Msg
>>                           Else
>>                               If Feb
>>                                and not 1-to-29
>>                                   Move 5  to Stat
>>                                   Move "Day of month invalid for this
>>                                month" to Msg
>>                        Else
>>                            Perform Check-Leap-Year
>>                        End-If
>>                    End-If
>>                End-If
>>            End-If
>>               End-If
>>           End-If
>>           Stop Run
>>            .
>>       Check-Leap-Year.
>>           Continue
>>           If Function Mod (DI-YYYY 400) = 0
>>               Continue
>>           Else
>>               If   (function Mod (DI-yyyy 4) = 0)
>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>                   Continue
>>               Else
>>                   If 1-to-28
>>                       Continue
>>                   Else
>>                       Move 6 to Stat
>>                       Move "Year is not a leap year"
>>                     to Msg
>>                   End-If
>>               End-If
>>           End-If
>>             .
>>     
>  I liked the code, Bill. It is refreshing to see date validation without a 
> calendar in it... :-)
>
> So, here we have a function that takes a date in a specified format and 
> tells us quite a bit about it. It is very unlikely to ever need modification 
> (unless the whole basis for our calendar was changed) and any manipulation 
> of other date formats can be done outside of it (or it could be wrapped to 
> include such formats.)
>
> This is the precise way in which component based systems get built.
>
> If you have no objection, I'll make this into a COM component (using Fujitsu 
> NetCobol) and post it on the COBDATA Web Site (where it can be publicly 
> downloaded). The site is listed for complete refurbishment as soon as I have 
> some time. I expect to be doing it at the end of this month.
>
> What would be of real interest to me, personally, would be to see this code 
> converted to a COM object, using the MicroFocus COBOL compiler.The problem 
> is that anyone downloading it would have to pay runtime fees...nevertheless, 
> I'd like to see the code.
>
> Pete.
>   
Using Bill's code, here is a working function :

isdate.cpy :
       78 isdate-succes value 1.
       78 isdate-Non-Numeric Value 0.
       78 isdate-Year-less-than-1601 value 2.
       78 isdate-invalid-Month value 3.
       78 isdate-invalid-day-31-Days value 4.
       78 isdate-invalid-day-30-Days value 5.
       78 isdate-invalid-day-feb value 6.
       78 isdate-not-a-leap-year value 7.

isdate.cbl :
      $set repository (update on)
      $set sourceformat"free"
       identification division.
       function-id. isdate as "isdate".
       working-storage section.
       copy "isdate.cpy".
       1 Date-IN.
         5 DI-YYYY Pic 9(04).
         5 DI-MM Pic 9(02).
           88 1-to-12 Value 1 thru 12.
           88 31-Days Value 1 3 5 7 8 10 12.
           88 30-Days Value 4 6 9 11.
           88 Feb Value 2.
         5 DI-DD Pic 9(02).
           88  1-to-31 Value 1 thru 31.
           88  1-to-30 Value 1 thru 30.
           88  1-to-29 Value 1 thru 29.
           88  1-to-28 Value 1 thru 28.
       1 Info-Out.
         5 Msg Pic X(80) Value Spaces.
       linkage section.
       1 myDate pic 9(8).
       1 Stat pic 9.
       procedure division using myDate returning Stat.
         move isdate-succes to Stat  *> Function returns 1 if date is
correct.
         move myDate to Date-In
         If Date-In Not Numeric
          Move isdate-Non-Numeric to Stat
         Else
          If DI-YYYY < 1601 then *> any larger year less than 9999 is valid
           Move isdate-Year-less-than-1601 to Stat
          Else
           If not 1-to-12 then
            Move isdate-invalid-Month to Stat
           Else
            If 31-Days and not 1-to-31 then
             Move isdate-invalid-day-31-Days to Stat
            Else
             If 30-Days And not 1-to-30 then
              Move isdate-invalid-day-30-Days to Stat
             Else
              If Feb and not 1-to-29 then
               Move isdate-invalid-day-feb to Stat
              Else
               *> Check-Leap-Year
               If Function Mod (DI-YYYY 400) = 0
then                                         
               
Continue                                                                      

              
Else                                                                           

                If (function Mod (DI-yyyy 4) = 0) And (Function Mod
(DI-YYYY 100) NOT = 0) then
                
Continue                                                                     

               
Else                                                                          

                 If 1-to-28
then                                                              
                 
Continue                                                                    

                
Else                                                                         

                  Move isdate-not-a-leap-year to
Stat                                                              
                
End-If                                                                       

               
End-If                                                                        

              
End-If                                                                         

              End-If
             End-If
            End-If
           End-If
          End-If
         End-If
         exit function.
       end function isdate.

testisdate.cbl
       repository.
           function isdate as "isdate".
       data division.
       working-storage section.
       copy "isdate.cpy".
       1 myDate pic 9(8).
       1 bool pic 9.
       procedure division.
        move 20090431 to myDate
        evaluate isDate(myDate)
         when isdate-succes
          display "Correct"
         when isdate-Non-Numeric
          display "Non-Numeric Value in Input Date"
         when isdate-Year-less-than-1601
          display "Year less than 1601"
         when isdate-invalid-Month
          display "Month too small or too large"
         when isdate-invalid-day-31-Days
          display "Day of month invalid for this month. Must be (1..31)"
         when isdate-invalid-day-30-Days
          display "Day of month invalid for this month. Must be (1..30)"
         when isdate-invalid-day-feb
          display "Day of month invalid for feb (1..28/29)"
         when isdate-not-a-leap-year
          display "Year is not a leap year"
        end-evaluate
        if isDate(myDate) = 1 then
          display "Correct"
        else
          display "False"
        end-if
        exit program
        stop run
        .

I really think that implementing user functions in cobol can bring a lot
in simplification and quality of code.

Regards,

Alain

0
Reply arwebmail (75) 1/6/2009 11:32:30 AM

I've done this many times.   It's quick and easy and maintenance
programmers can understand it.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/6/2009 2:28:54 PM

Alain,
  If you care (and you probably don't), use of "78-levels" makes your code NOT 
conform to the 2002 ISO Standard (where User defined functions were introduce 
into Standard COBOL).

I think (but am not positive) that MF now supports the "CONSTANT" clause which 
is MOSTLY the same as MF 78-level extension.

I actually thought of using the following type of code:

1 Stat pic 9.
       88 isdate-succes value 1.
       88 isdate-Non-Numeric Value 0.
       88 isdate-Year-less-than-1601 value 2.
       88 isdate-invalid-Month value 3.
       88 isdate-invalid-day-31-Days value 4.
       88 isdate-invalid-day-30-Days value 5.
       88 isdate-invalid-day-feb value 6.
       88 isdate-not-a-leap-year value 7.

and then instead of the move statement, code
    Set isdate-Year-Less-than-1601 to true

P.S.  I think you reversed the values of "0" and "1".  At least for me, I would 
expect the "successful" to be zero and all the non-zero "returned status values" 
to be treated as unsuccessful.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Alain Reymond" <arwebmail@skynet.be> wrote in message 
news:49634190$0$2846$ba620e4c@news.skynet.be...
>
>
> Pete Dashwood a �crit :
>> William M. Klein wrote:
>>
>>> OK, so I am certain that this will end up in "style war" discussions
>>> and/or discussions of how to do "multiple possible error" processing
>>> or a number of things we have discussed before, but ...
>>>
>>> There may be one in the "archives" that I didn't see, but given the
>>> other thread, I thought I would go ahead and code a "date validation"
>>> in COBOL routine.  (This assumes YYYYMMDD format and only handles
>>> dates in the range of Jan 1, 1601 - first date allowed for Intrinsic
>>> Functions - thru Dec 31, 9999). Expanding it would be easy.
>>>
>>> I put the "input date" in WS, but obviously one could change that to
>>> a Linkage Section parameter or an ACCEPT (from console) or any other
>>> way of getting it in for validation.
>>>
>>> So, for what it is worth, ...
>>>
>>>       Identification Division.
>>>        Program-ID.  VALDATE.
>>>       Data Division.
>>>        Working-Storage Section.
>>>       01  Date-IN.
>>>           05  DI-YYYY Pic 9(04).
>>>           05  DI-MM Pic 9(02).
>>>               88 1-to-12 Value 1 thru 12.
>>>               88 31-Days Value 1 3 5 7 8 10 12.
>>>               88 30-Days Value 4 6 9 11.
>>>               88 Feb  Value 2.
>>>           05  DI-DD Pic 9(02).
>>>               88  1-to-31 Value 1 thru 31.
>>>               88  1-to-30 Value 1 thru 30.
>>>               88  1-to-29      Value 1 thru 29.
>>>               88  1-to-28 Value 1 thru 28. .
>>>       01  Info-Out.
>>>           05  Stat Pic 9(01) Value Zero.
>>>           05  Msg Pic X(80) Value Spaces.
>>>       Procedure Division.
>>>        Mainline.
>>>           If Date-In Not Numeric
>>>               Move 1 to Stat
>>>               Move "Non-Numeric Value in Input Date"
>>>                 to Msg
>>>           Else
>>>               If DI-YYYY < 1601
>>>      *            any larger year less than 9999 is valid
>>>                   Move 2 to Stat
>>>                   Move "Year less than 1601"
>>>                     to Msg
>>>               Else
>>>                   If  not 1-to-12
>>>                       Move 3  to Stat
>>>                       Move "Month too small or too large"
>>>                         to Msg
>>>                   Else
>>>                       If  31-Days
>>>                        and not 1-to-31
>>>                         Move 4  to Stat
>>>                         Move "Day of month invalid for this month"
>>>                           to Msg
>>>                       Else
>>>                           If 30-Days
>>>                            And not 1-to-30
>>>                             Move 5  to Stat
>>>                             Move "Day of month invalid for this month"
>>>                               to Msg
>>>                           Else
>>>                               If Feb
>>>                                and not 1-to-29
>>>                                   Move 5  to Stat
>>>                                   Move "Day of month invalid for this
>>>                                month" to Msg
>>>                        Else
>>>                            Perform Check-Leap-Year
>>>                        End-If
>>>                    End-If
>>>                End-If
>>>            End-If
>>>               End-If
>>>           End-If
>>>           Stop Run
>>>            .
>>>       Check-Leap-Year.
>>>           Continue
>>>           If Function Mod (DI-YYYY 400) = 0
>>>               Continue
>>>           Else
>>>               If   (function Mod (DI-yyyy 4) = 0)
>>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>>                   Continue
>>>               Else
>>>                   If 1-to-28
>>>                       Continue
>>>                   Else
>>>                       Move 6 to Stat
>>>                       Move "Year is not a leap year"
>>>                     to Msg
>>>                   End-If
>>>               End-If
>>>           End-If
>>>             .
>>>
>>  I liked the code, Bill. It is refreshing to see date validation without a
>> calendar in it... :-)
>>
>> So, here we have a function that takes a date in a specified format and
>> tells us quite a bit about it. It is very unlikely to ever need modification
>> (unless the whole basis for our calendar was changed) and any manipulation
>> of other date formats can be done outside of it (or it could be wrapped to
>> include such formats.)
>>
>> This is the precise way in which component based systems get built.
>>
>> If you have no objection, I'll make this into a COM component (using Fujitsu
>> NetCobol) and post it on the COBDATA Web Site (where it can be publicly
>> downloaded). The site is listed for complete refurbishment as soon as I have
>> some time. I expect to be doing it at the end of this month.
>>
>> What would be of real interest to me, personally, would be to see this code
>> converted to a COM object, using the MicroFocus COBOL compiler.The problem
>> is that anyone downloading it would have to pay runtime fees...nevertheless,
>> I'd like to see the code.
>>
>> Pete.
>>
> Using Bill's code, here is a working function :
>
> isdate.cpy :
>       78 isdate-succes value 1.
>       78 isdate-Non-Numeric Value 0.
>       78 isdate-Year-less-than-1601 value 2.
>       78 isdate-invalid-Month value 3.
>       78 isdate-invalid-day-31-Days value 4.
>       78 isdate-invalid-day-30-Days value 5.
>       78 isdate-invalid-day-feb value 6.
>       78 isdate-not-a-leap-year value 7.
>
> isdate.cbl :
>      $set repository (update on)
>      $set sourceformat"free"
>       identification division.
>       function-id. isdate as "isdate".
>       working-storage section.
>       copy "isdate.cpy".
>       1 Date-IN.
>         5 DI-YYYY Pic 9(04).
>         5 DI-MM Pic 9(02).
>           88 1-to-12 Value 1 thru 12.
>           88 31-Days Value 1 3 5 7 8 10 12.
>           88 30-Days Value 4 6 9 11.
>           88 Feb Value 2.
>         5 DI-DD Pic 9(02).
>           88  1-to-31 Value 1 thru 31.
>           88  1-to-30 Value 1 thru 30.
>           88  1-to-29 Value 1 thru 29.
>           88  1-to-28 Value 1 thru 28.
>       1 Info-Out.
>         5 Msg Pic X(80) Value Spaces.
>       linkage section.
>       1 myDate pic 9(8).
>       1 Stat pic 9.
>       procedure division using myDate returning Stat.
>         move isdate-succes to Stat  *> Function returns 1 if date is
> correct.
>         move myDate to Date-In
>         If Date-In Not Numeric
>          Move isdate-Non-Numeric to Stat
>         Else
>          If DI-YYYY < 1601 then *> any larger year less than 9999 is valid
>           Move isdate-Year-less-than-1601 to Stat
>          Else
>           If not 1-to-12 then
>            Move isdate-invalid-Month to Stat
>           Else
>            If 31-Days and not 1-to-31 then
>             Move isdate-invalid-day-31-Days to Stat
>            Else
>             If 30-Days And not 1-to-30 then
>              Move isdate-invalid-day-30-Days to Stat
>             Else
>              If Feb and not 1-to-29 then
>               Move isdate-invalid-day-feb to Stat
>              Else
>               *> Check-Leap-Year
>               If Function Mod (DI-YYYY 400) = 0
> then
>
> Continue
>
>
> Else
>
>                If (function Mod (DI-yyyy 4) = 0) And (Function Mod
> (DI-YYYY 100) NOT = 0) then
>
> Continue
>
>
> Else
>
>                 If 1-to-28
> then
>
> Continue
>
>
> Else
>
>                  Move isdate-not-a-leap-year to
> Stat
>
> End-If
>
>
> End-If
>
>
> End-If
>
>              End-If
>             End-If
>            End-If
>           End-If
>          End-If
>         End-If
>         exit function.
>       end function isdate.
>
> testisdate.cbl
>       repository.
>           function isdate as "isdate".
>       data division.
>       working-storage section.
>       copy "isdate.cpy".
>       1 myDate pic 9(8).
>       1 bool pic 9.
>       procedure division.
>        move 20090431 to myDate
>        evaluate isDate(myDate)
>         when isdate-succes
>          display "Correct"
>         when isdate-Non-Numeric
>          display "Non-Numeric Value in Input Date"
>         when isdate-Year-less-than-1601
>          display "Year less than 1601"
>         when isdate-invalid-Month
>          display "Month too small or too large"
>         when isdate-invalid-day-31-Days
>          display "Day of month invalid for this month. Must be (1..31)"
>         when isdate-invalid-day-30-Days
>          display "Day of month invalid for this month. Must be (1..30)"
>         when isdate-invalid-day-feb
>          display "Day of month invalid for feb (1..28/29)"
>         when isdate-not-a-leap-year
>          display "Year is not a leap year"
>        end-evaluate
>        if isDate(myDate) = 1 then
>          display "Correct"
>        else
>          display "False"
>        end-if
>        exit program
>        stop run
>        .
>
> I really think that implementing user functions in cobol can bring a lot
> in simplification and quality of code.
>
> Regards,
>
> Alain
> 


0
Reply wmklein40 (279) 1/6/2009 5:01:38 PM

William M. Klein a �crit :
> Alain,
>   If you care (and you probably don't), use of "78-levels" makes your code NOT 
> conform to the 2002 ISO Standard (where User defined functions were introduce 
> into Standard COBOL).
>   
Good point!
> I think (but am not positive) that MF now supports the "CONSTANT" clause which 
> is MOSTLY the same as MF 78-level extension.
>
> I actually thought of using the following type of code:
>
> 1 Stat pic 9.
>        88 isdate-succes value 1.
>        88 isdate-Non-Numeric Value 0.
>        88 isdate-Year-less-than-1601 value 2.
>        88 isdate-invalid-Month value 3.
>        88 isdate-invalid-day-31-Days value 4.
>        88 isdate-invalid-day-30-Days value 5.
>        88 isdate-invalid-day-feb value 6.
>        88 isdate-not-a-leap-year value 7.
>
> and then instead of the move statement, code
>     Set isdate-Year-Less-than-1601 to true
>
> P.S.  I think you reversed the values of "0" and "1".  At least for me, I would 
> expect the "successful" to be zero and all the non-zero "returned status values" 
> to be treated as unsuccessful.
>   
Well, I did it on purpose because of the name of the function.
As isdate() is in fact a boolean, I found it more coherent to read "if
isdate() then OK else BAD" (which is in fact written if isdate()=1 then
OK else bad) instead of "if isdate()=0 then OK else bad" if the function
does not return 1. But if you want to keep an view on where is the
error, you have to make a compromise!
0 stands normally for false and 1 for True!

Ok, I can reverse 0 to 1 and rename the function invalidDate().
if invalidDate()<>0 then
  display error message
else
  correct
end-if

Regards

Alain
0
Reply arwebmail (75) 1/6/2009 6:45:22 PM

If you want to do YOUR version as a "boolean", did you think of using
   Pic 1
for the returned value?  I think that MF has added support for PIC 1 - but that 
may only be for bits and only in the .NET product.

In that case, the function wouldn't have multiple values but just tell whether 
it is or is not a valid date.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Alain Reymond" <arwebmail@skynet.be> wrote in message 
news:4963a705$0$2855$ba620e4c@news.skynet.be...
> William M. Klein a �crit :
>> Alain,
>>   If you care (and you probably don't), use of "78-levels" makes your code 
>> NOT
>> conform to the 2002 ISO Standard (where User defined functions were introduce
>> into Standard COBOL).
>>
> Good point!
>> I think (but am not positive) that MF now supports the "CONSTANT" clause 
>> which
>> is MOSTLY the same as MF 78-level extension.
>>
>> I actually thought of using the following type of code:
>>
>> 1 Stat pic 9.
>>        88 isdate-succes value 1.
>>        88 isdate-Non-Numeric Value 0.
>>        88 isdate-Year-less-than-1601 value 2.
>>        88 isdate-invalid-Month value 3.
>>        88 isdate-invalid-day-31-Days value 4.
>>        88 isdate-invalid-day-30-Days value 5.
>>        88 isdate-invalid-day-feb value 6.
>>        88 isdate-not-a-leap-year value 7.
>>
>> and then instead of the move statement, code
>>     Set isdate-Year-Less-than-1601 to true
>>
>> P.S.  I think you reversed the values of "0" and "1".  At least for me, I 
>> would
>> expect the "successful" to be zero and all the non-zero "returned status 
>> values"
>> to be treated as unsuccessful.
>>
> Well, I did it on purpose because of the name of the function.
> As isdate() is in fact a boolean, I found it more coherent to read "if
> isdate() then OK else BAD" (which is in fact written if isdate()=1 then
> OK else bad) instead of "if isdate()=0 then OK else bad" if the function
> does not return 1. But if you want to keep an view on where is the
> error, you have to make a compromise!
> 0 stands normally for false and 1 for True!
>
> Ok, I can reverse 0 to 1 and rename the function invalidDate().
> if invalidDate()<>0 then
>  display error message
> else
>  correct
> end-if
>
> Regards
>
> Alain 


0
Reply wmklein40 (279) 1/6/2009 8:07:51 PM

Howard Brazee wrote:
> I've done this many times.   It's quick and easy and maintenance
> programmers can understand it.

Done what? Date Validation? Bill's Date validation? Alain's date validation? 
Used a function approach? Used a date component?

Without a quote, I have no idea exactly what you are referring to, Howard.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/6/2009 9:19:50 PM

William M. Klein wrote:
> Alain,
>  If you care (and you probably don't), use of "78-levels" makes your
> code NOT conform to the 2002 ISO Standard (where User defined
> functions were introduce into Standard COBOL).
>
> I think (but am not positive) that MF now supports the "CONSTANT"
> clause which is MOSTLY the same as MF 78-level extension.
>
> I actually thought of using the following type of code:
>
> 1 Stat pic 9.
>       88 isdate-succes value 1.
>       88 isdate-Non-Numeric Value 0.
>       88 isdate-Year-less-than-1601 value 2.
>       88 isdate-invalid-Month value 3.
>       88 isdate-invalid-day-31-Days value 4.
>       88 isdate-invalid-day-30-Days value 5.
>       88 isdate-invalid-day-feb value 6.
>       88 isdate-not-a-leap-year value 7.
>
> and then instead of the move statement, code
>    Set isdate-Year-Less-than-1601 to true

Yes, I prefer set to move. Why did you decide not to do this?
>
> P.S.  I think you reversed the values of "0" and "1".  At least for
> me, I would expect the "successful" to be zero and all the non-zero
> "returned status values" to be treated as unsuccessful.
>

No, the Boolean truth values are 1 for true and zero for false. Many 
different computer languages implement them differently... sometimes a 
negative value is false and zeroor positive is true, for example. That's why 
it is good to use a Boolean type, which can only have values of TRUE or 
FALSE, and it really doesn't matter what the underlying "mechanism" for true 
and false is. Sadly, most COBOLs have no such type (Fujitsu PowerCOBOL 
implements POW-TRUE and POW-FALSE which is compatible with a VB Boolean...) 
and we end up with "Y" and "N" and "yes" and "no" and similar horror stories 
representing true or false.

Why do I personally dislike using "Y" and "N" (and variations thereof)?

Because I have worked in cultures where the words for "yes" and "no" are NOT 
"yes" and "no". Just because COBOL is English like does not mean that the 
English language should be enforced by it. It is arrogant and rude to expect 
programmers in different cultures to recognise English truth values, even 
though most of them can...

Even in English language cultures, using words like "yes" and "no" (or 
variations that are language based) fuse the realm of Logic with the realm 
of Language, and the result is that imprecise language and thought processes 
become imprecise computer logic. Separating Logic from Language in 
programming is a Good Thing. Perhaps in daily speech you are a bit more 
relaxed, but in code there is no mistaking truth and falsity.

The elegant mathematical beauty of Boole's two-valued Algebra transcends all 
languages and cultures. "1" and "0" were good enough for George; they are 
certainly good enopugh for me... :-)

I agree strongly with Alain on this one.

>>
>>
>> Pete Dashwood a �crit :
>>> William M. Klein wrote:
>>>
>>>> OK, so I am certain that this will end up in "style war"
>>>> discussions and/or discussions of how to do "multiple possible
>>>> error" processing or a number of things we have discussed before,
>>>> but ... There may be one in the "archives" that I didn't see, but given 
>>>> the
>>>> other thread, I thought I would go ahead and code a "date
>>>> validation" in COBOL routine.  (This assumes YYYYMMDD format and
>>>> only handles dates in the range of Jan 1, 1601 - first date
>>>> allowed for Intrinsic Functions - thru Dec 31, 9999). Expanding it
>>>> would be easy. I put the "input date" in WS, but obviously one could 
>>>> change that
>>>> to a Linkage Section parameter or an ACCEPT (from console) or any
>>>> other way of getting it in for validation.
>>>>
>>>> So, for what it is worth, ...
>>>>
>>>>       Identification Division.
>>>>        Program-ID.  VALDATE.
>>>>       Data Division.
>>>>        Working-Storage Section.
>>>>       01  Date-IN.
>>>>           05  DI-YYYY Pic 9(04).
>>>>           05  DI-MM Pic 9(02).
>>>>               88 1-to-12 Value 1 thru 12.
>>>>               88 31-Days Value 1 3 5 7 8 10 12.
>>>>               88 30-Days Value 4 6 9 11.
>>>>               88 Feb  Value 2.
>>>>           05  DI-DD Pic 9(02).
>>>>               88  1-to-31 Value 1 thru 31.
>>>>               88  1-to-30 Value 1 thru 30.
>>>>               88  1-to-29      Value 1 thru 29.
>>>>               88  1-to-28 Value 1 thru 28. .
>>>>       01  Info-Out.
>>>>           05  Stat Pic 9(01) Value Zero.
>>>>           05  Msg Pic X(80) Value Spaces.
>>>>       Procedure Division.
>>>>        Mainline.
>>>>           If Date-In Not Numeric
>>>>               Move 1 to Stat
>>>>               Move "Non-Numeric Value in Input Date"
>>>>                 to Msg
>>>>           Else
>>>>               If DI-YYYY < 1601
>>>>      *            any larger year less than 9999 is valid
>>>>                   Move 2 to Stat
>>>>                   Move "Year less than 1601"
>>>>                     to Msg
>>>>               Else
>>>>                   If  not 1-to-12
>>>>                       Move 3  to Stat
>>>>                       Move "Month too small or too large"
>>>>                         to Msg
>>>>                   Else
>>>>                       If  31-Days
>>>>                        and not 1-to-31
>>>>                         Move 4  to Stat
>>>>                         Move "Day of month invalid for this month"
>>>>                           to Msg
>>>>                       Else
>>>>                           If 30-Days
>>>>                            And not 1-to-30
>>>>                             Move 5  to Stat
>>>>                             Move "Day of month invalid for this
>>>>                               month" to Msg
>>>>                           Else
>>>>                               If Feb
>>>>                                and not 1-to-29
>>>>                                   Move 5  to Stat
>>>>                                   Move "Day of month invalid for
>>>>                                this month" to Msg
>>>>                        Else
>>>>                            Perform Check-Leap-Year
>>>>                        End-If
>>>>                    End-If
>>>>                End-If
>>>>            End-If
>>>>               End-If
>>>>           End-If
>>>>           Stop Run
>>>>            .
>>>>       Check-Leap-Year.
>>>>           Continue
>>>>           If Function Mod (DI-YYYY 400) = 0
>>>>               Continue
>>>>           Else
>>>>               If   (function Mod (DI-yyyy 4) = 0)
>>>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>>>                   Continue
>>>>               Else
>>>>                   If 1-to-28
>>>>                       Continue
>>>>                   Else
>>>>                       Move 6 to Stat
>>>>                       Move "Year is not a leap year"
>>>>                     to Msg
>>>>                   End-If
>>>>               End-If
>>>>           End-If
>>>>             .
>>>>
>>>  I liked the code, Bill. It is refreshing to see date validation
>>> without a calendar in it... :-)
>>>
>>> So, here we have a function that takes a date in a specified format
>>> and tells us quite a bit about it. It is very unlikely to ever need
>>> modification (unless the whole basis for our calendar was changed)
>>> and any manipulation of other date formats can be done outside of
>>> it (or it could be wrapped to include such formats.)
>>>
>>> This is the precise way in which component based systems get built.
>>>
>>> If you have no objection, I'll make this into a COM component
>>> (using Fujitsu NetCobol) and post it on the COBDATA Web Site (where
>>> it can be publicly downloaded). The site is listed for complete
>>> refurbishment as soon as I have some time. I expect to be doing it
>>> at the end of this month. What would be of real interest to me, 
>>> personally, would be to see
>>> this code converted to a COM object, using the MicroFocus COBOL
>>> compiler.The problem is that anyone downloading it would have to
>>> pay runtime fees...nevertheless, I'd like to see the code.
>>>
>>> Pete.
>>>
>> Using Bill's code, here is a working function :
>>
>> isdate.cpy :
>>       78 isdate-succes value 1.
>>       78 isdate-Non-Numeric Value 0.
>>       78 isdate-Year-less-than-1601 value 2.
>>       78 isdate-invalid-Month value 3.
>>       78 isdate-invalid-day-31-Days value 4.
>>       78 isdate-invalid-day-30-Days value 5.
>>       78 isdate-invalid-day-feb value 6.
>>       78 isdate-not-a-leap-year value 7.
>>

The 78 levels are a Micro Focus extension. I'd use CONSTANTs or condition 
names.

>> isdate.cbl :
>>      $set repository (update on)
>>      $set sourceformat"free"
>>       identification division.
>>       function-id. isdate as "isdate".
>>       working-storage section.
>>       copy "isdate.cpy".
>>       1 Date-IN.
>>         5 DI-YYYY Pic 9(04).
>>         5 DI-MM Pic 9(02).
>>           88 1-to-12 Value 1 thru 12.
>>           88 31-Days Value 1 3 5 7 8 10 12.
>>           88 30-Days Value 4 6 9 11.
>>           88 Feb Value 2.
>>         5 DI-DD Pic 9(02).
>>           88  1-to-31 Value 1 thru 31.
>>           88  1-to-30 Value 1 thru 30.
>>           88  1-to-29 Value 1 thru 29.
>>           88  1-to-28 Value 1 thru 28.
>>       1 Info-Out.
>>         5 Msg Pic X(80) Value Spaces.
>>       linkage section.
>>       1 myDate pic 9(8).
>>       1 Stat pic 9.
>>       procedure division using myDate returning Stat.
>>         move isdate-succes to Stat  *> Function returns 1 if date is
>> correct.
>>         move myDate to Date-In
>>         If Date-In Not Numeric
>>          Move isdate-Non-Numeric to Stat
>>         Else
>>          If DI-YYYY < 1601 then *> any larger year less than 9999 is
>>           valid Move isdate-Year-less-than-1601 to Stat
>>          Else
>>           If not 1-to-12 then
>>            Move isdate-invalid-Month to Stat
>>           Else
>>            If 31-Days and not 1-to-31 then
>>             Move isdate-invalid-day-31-Days to Stat
>>            Else
>>             If 30-Days And not 1-to-30 then
>>              Move isdate-invalid-day-30-Days to Stat
>>             Else
>>              If Feb and not 1-to-29 then
>>               Move isdate-invalid-day-feb to Stat
>>              Else
>>               *> Check-Leap-Year
>>               If Function Mod (DI-YYYY 400) = 0
>> then
>>
>> Continue
>>
>>
>> Else
>>
>>                If (function Mod (DI-yyyy 4) = 0) And (Function Mod
>> (DI-YYYY 100) NOT = 0) then
>>
>> Continue
>>
>>
>> Else
>>
>>                 If 1-to-28
>> then
>>
>> Continue
>>
>>
>> Else
>>
>>                  Move isdate-not-a-leap-year to
>> Stat
>>
>> End-If
>>
>>
>> End-If
>>
>>
>> End-If
>>
>>              End-If
>>             End-If
>>            End-If
>>           End-If
>>          End-If
>>         End-If
>>         exit function.
>>       end function isdate.
>>
>> testisdate.cbl
>>       repository.
>>           function isdate as "isdate".
>>       data division.
>>       working-storage section.
>>       copy "isdate.cpy".
>>       1 myDate pic 9(8).
>>       1 bool pic 9.
>>       procedure division.
>>        move 20090431 to myDate
>>        evaluate isDate(myDate)
>>         when isdate-succes
>>          display "Correct"
>>         when isdate-Non-Numeric
>>          display "Non-Numeric Value in Input Date"
>>         when isdate-Year-less-than-1601
>>          display "Year less than 1601"
>>         when isdate-invalid-Month
>>          display "Month too small or too large"
>>         when isdate-invalid-day-31-Days
>>          display "Day of month invalid for this month. Must be
>>         (1..31)" when isdate-invalid-day-30-Days
>>          display "Day of month invalid for this month. Must be
>>         (1..30)" when isdate-invalid-day-feb
>>          display "Day of month invalid for feb (1..28/29)"
>>         when isdate-not-a-leap-year
>>          display "Year is not a leap year"
>>        end-evaluate
>>        if isDate(myDate) = 1 then
>>          display "Correct"
>>        else
>>          display "False"
>>        end-if
>>        exit program
>>        stop run
>>        .
>>
>> I really think that implementing user functions in cobol can bring a
>> lot in simplification and quality of code.
>>

Absolutely. Doing so in any language is very valuable.

For me, the idea is to isolate functionality into units that are unlikely to 
require maintenance. (Your function and Bill's code meet that requirement.) 
The next step is to make the "function" available in a form where it can run 
anywhere, and be used by ANYTHING (including other computer languages, and 
scripts on web pages...) One way to achieve this is by wrapping it as a 
Component Object Model (COM) component.

Fujitsu make this easy, but I understand Micro Focus has this functionality 
available also.

Once you have this, you have something that will require minimal 
intervention, can be very efficiently reused (the system can serve up 
instances of it to as many concurrent processes as require it (and these 
processes can be written in ANY language that supports the COM), yet there 
is no duplication of it on your system), and it will run for years, in 
environments you haven't even considered when you built it.

THAT is a very good ROI.

(How you go about addressing change in a component based environment, the 
use of dynamic interfaces and components, is beyond the scope of what I'm 
writing here, but it is certainly viable.)

I cottoned on to this some years back when I started pushing Objects 
(Classes) into components, and suddenly found that once they were wrapped as 
COM their useful life became "indefinite", instead of "a few years on the 
Windows desktop"

COBOL people, for the most part, are used to maintaining source code and 
don't realise that it simply doesn't HAVE to be like that.

Most of them are not familiar with the concepts of Object Orientiation (or 
worse, have improper understanding of them, by never having actually applied 
them...). Using functions in COBOL is a very good way to change some of this 
thinking and I really hope people will pick up on it.

It is a step in the "right" direction towards encapsulated, reusable, code 
that requires minimum maintenance.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/6/2009 10:03:15 PM

Alain Reymond wrote:
> William M. Klein a �crit :
>> Alain,
>>   If you care (and you probably don't), use of "78-levels" makes
>> your code NOT conform to the 2002 ISO Standard (where User defined
>> functions were introduce into Standard COBOL).
>>
> Good point!
>> I think (but am not positive) that MF now supports the "CONSTANT"
>> clause which is MOSTLY the same as MF 78-level extension.
>>
>> I actually thought of using the following type of code:
>>
>> 1 Stat pic 9.
>>        88 isdate-succes value 1.
>>        88 isdate-Non-Numeric Value 0.
>>        88 isdate-Year-less-than-1601 value 2.
>>        88 isdate-invalid-Month value 3.
>>        88 isdate-invalid-day-31-Days value 4.
>>        88 isdate-invalid-day-30-Days value 5.
>>        88 isdate-invalid-day-feb value 6.
>>        88 isdate-not-a-leap-year value 7.
>>
>> and then instead of the move statement, code
>>     Set isdate-Year-Less-than-1601 to true
>>
>> P.S.  I think you reversed the values of "0" and "1".  At least for
>> me, I would expect the "successful" to be zero and all the non-zero
>> "returned status values" to be treated as unsuccessful.
>>
> Well, I did it on purpose because of the name of the function.
> As isdate() is in fact a boolean, I found it more coherent to read "if
> isdate() then OK else BAD" (which is in fact written if isdate()=1
> then OK else bad) instead of "if isdate()=0 then OK else bad" if the
> function does not return 1. But if you want to keep an view on where
> is the error, you have to make a compromise!
> 0 stands normally for false and 1 for True!
>
> Ok, I can reverse 0 to 1 and rename the function invalidDate().
> if invalidDate()<>0 then
>  display error message
> else
>  correct
> end-if
>

You are far too obliging, Alain... :-)

Don't do it...  It is fine as it is. If people want to be computer 
programmers, they should learn the difference between Language and Logic...

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/6/2009 10:06:43 PM

William M. Klein wrote:
> If you want to do YOUR version as a "boolean", did you think of using
>   Pic 1
> for the returned value?

Bill, there is no excuse for using PIC 1 in COBOL, UNLESS you need 
compatibility with some other process.

Using a single bit to represent a Boolean type is inefficient and completely 
unnecessary in today's world.

Part of the "problem" I see with COBOL is that there have been too many 
compromises over the decades, usually prompted by laziness or 
misunderstanding on the part of some elements of the user base...

"People are writing spaghetti..."  OK, let's remove ALTER from the language. 
(the fact that some of the "spaghetti" was very tasty and highly efficient, 
in a time when resources were, by today's standards, extremely limited, 
wasn't a consideration. Instead of imposing a local standard and educating 
people into writing better code, just drop a language element.)

"In Assembler I can use Boolean operations on bits..." OK, we'll add some 
subroutines to support XOR etc., and let's have a PIC 1 binary type so COBOL 
can do it too. How cool is that?!  (The fact that less than 1% of all the 
code written in COBOL actually USES this facility doesn't matter... let's 
keep COBOL up with the "cool" languages...yeah, right)

"I don't like DIVIDE ... INTO... it means I have to think in an unnatural, 
un-English-like way..." OK, we'll allow DIVIDE...BY...  (A lot of work for 
compiler writers because BY can now be confused contextually with MULTIPLY. 
Same thing happened with EXAMINE and INSPECT where the original WITH for 
REPLACING was changed to allow BY by some vendors. All this did was pander 
to the LCD of programming pussies who couldn't even discipline themselves to 
learn a language properly. (If code is being written by people who can't 
discipline themselves even to comply with a clear cut language requirement, 
it is hardly surprising if the results from such undisciplined thought 
processes are horrendous. Ever wonder why there's such a lot of bad code in 
the world? Why is so much of it bad COBOL...?)

"Why doesn't COBOL support a Reporting function, or a Communications 
function, or Object Orientation?" OK, we'll add 'em all.  (Huge effort) 
Anybody using them? No. Why not? Too hard. And different. I can use Crystal 
Reports. If I want to use a network I can use scripting or CICS. And that OO 
stuff is a just a fashion blip that will be gone in a year (15 years 
ago...). It's all a big con. REAL programmers write COBOL....(actually, they 
write Fortran in COBOL...) How come some Java guy is relacing me next month?

And we wonder why COBOL is moribund. The community (for the most part; some 
are waking up now it is too late...) simply doesn't get it.

Attempts to "re-invent" COBOL (like some we've seen advertised here 
recently) are like attempts by Frankenstein to galvanize a corpse. UNLESS 
these new attempts (some of which are quite noble in themselves) can make 
COBOL fly in the 21st century, they are pointless. It needs to have OO, it 
needs to have functionality for encapsulation (COM is one example), and the 
user community needs to recognise the need for these things, if COBOL is to 
have any role other than as a batch processing language, of as much 
relevance in IT as Sanskrit or Chaldean is in modern Language.

Thank you I feel much better now... :-)

All this from PIC 1.... imagine if Bill had suggested banning complex 
constructs like PERFORM...VARYING... :-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/6/2009 10:50:27 PM

I don't mind a
  0 = false
  1 = true

solution, but Alain's original code would return
  0 *AND* 2 thru 6 = false
  1 = true
returned value.

If you have multiple possible returned numeric values, I prefer (and still 
prefer)
  0 = "ok"
  non-zero = "you need more information"

This is why I would expect a (user-defined) function that had a "boolean" 
returned value to use
   PIC 1
(at least where this is possible)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6si2vjF65ns4U1@mid.individual.net...
> Alain Reymond wrote:
>> William M. Klein a �crit :
>>> Alain,
>>>   If you care (and you probably don't), use of "78-levels" makes
>>> your code NOT conform to the 2002 ISO Standard (where User defined
>>> functions were introduce into Standard COBOL).
>>>
>> Good point!
>>> I think (but am not positive) that MF now supports the "CONSTANT"
>>> clause which is MOSTLY the same as MF 78-level extension.
>>>
>>> I actually thought of using the following type of code:
>>>
>>> 1 Stat pic 9.
>>>        88 isdate-succes value 1.
>>>        88 isdate-Non-Numeric Value 0.
>>>        88 isdate-Year-less-than-1601 value 2.
>>>        88 isdate-invalid-Month value 3.
>>>        88 isdate-invalid-day-31-Days value 4.
>>>        88 isdate-invalid-day-30-Days value 5.
>>>        88 isdate-invalid-day-feb value 6.
>>>        88 isdate-not-a-leap-year value 7.
>>>
>>> and then instead of the move statement, code
>>>     Set isdate-Year-Less-than-1601 to true
>>>
>>> P.S.  I think you reversed the values of "0" and "1".  At least for
>>> me, I would expect the "successful" to be zero and all the non-zero
>>> "returned status values" to be treated as unsuccessful.
>>>
>> Well, I did it on purpose because of the name of the function.
>> As isdate() is in fact a boolean, I found it more coherent to read "if
>> isdate() then OK else BAD" (which is in fact written if isdate()=1
>> then OK else bad) instead of "if isdate()=0 then OK else bad" if the
>> function does not return 1. But if you want to keep an view on where
>> is the error, you have to make a compromise!
>> 0 stands normally for false and 1 for True!
>>
>> Ok, I can reverse 0 to 1 and rename the function invalidDate().
>> if invalidDate()<>0 then
>>  display error message
>> else
>>  correct
>> end-if
>>
>
> You are far too obliging, Alain... :-)
>
> Don't do it...  It is fine as it is. If people want to be computer 
> programmers, they should learn the difference between Language and Logic...
>
> Pete.
> -- 
> "I used to write COBOL...now I can do anything."
> 


0
Reply wmklein40 (279) 1/6/2009 10:53:19 PM

The reason that I used "MOVE" instead of "SET to TRUE" was that I was "setting" 
the value of two fields (one a number "status" and another being the 
"alphanumeric message".  This was totally redundant in the first place and I 
assume that any "real-world" application would use one or the other, not both. 
Possible a real world application would use the numeric status field and then 
use it to subscript into a table of messages AND there could be multiple message 
tables for multiple languages.  I know that I could have put the actual messages 
as 88-levels and SET TO TRUE for them as well; it just didn't "feel right" to 
me.

Similarly, "just because" was my decision to test the year for "< 1601" instead 
of having an 88-level for "1601 thru 9999" which would have been more consistent 
with what I did with other range validations.

In all of these cases, I suppose that if I were doing a real world application 
AND the date-validation actually were a significant portion of the total 
application logic (which I find doubtful), I might try and compile several 
different approaches and see what the run-time performance was like.  As I see 
all of these coding techniques to be easily maintainable (by even entry-level 
programmer), I guess that performance would be (should be?) the final 
consideration.  On the other hand, date validation is RARELY (if ever) a major 
portion of run-time performance AND I doubt that any of these techniques would 
be significantly better performers than others, so I think I would probably use 
whatever first came into my mind and leave it at that <G>

P.S.  I was actually thinking of coding up another example of how this could be 
done using (mostly) EVALUATE rather than nested IF's as I do (sort-of) see this 
as a "decision table" type of program and I really *like* evaluate for that type 
of algorithm.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6si2p3F62p3gU1@mid.individual.net...
> William M. Klein wrote:
>> Alain,
>>  If you care (and you probably don't), use of "78-levels" makes your
>> code NOT conform to the 2002 ISO Standard (where User defined
>> functions were introduce into Standard COBOL).
>>
>> I think (but am not positive) that MF now supports the "CONSTANT"
>> clause which is MOSTLY the same as MF 78-level extension.
>>
>> I actually thought of using the following type of code:
>>
>> 1 Stat pic 9.
>>       88 isdate-succes value 1.
>>       88 isdate-Non-Numeric Value 0.
>>       88 isdate-Year-less-than-1601 value 2.
>>       88 isdate-invalid-Month value 3.
>>       88 isdate-invalid-day-31-Days value 4.
>>       88 isdate-invalid-day-30-Days value 5.
>>       88 isdate-invalid-day-feb value 6.
>>       88 isdate-not-a-leap-year value 7.
>>
>> and then instead of the move statement, code
>>    Set isdate-Year-Less-than-1601 to true
>
> Yes, I prefer set to move. Why did you decide not to do this?
>>
>> P.S.  I think you reversed the values of "0" and "1".  At least for
>> me, I would expect the "successful" to be zero and all the non-zero
>> "returned status values" to be treated as unsuccessful.
>>
>
> No, the Boolean truth values are 1 for true and zero for false. Many different 
> computer languages implement them differently... sometimes a negative value is 
> false and zeroor positive is true, for example. That's why it is good to use a 
> Boolean type, which can only have values of TRUE or FALSE, and it really 
> doesn't matter what the underlying "mechanism" for true and false is. Sadly, 
> most COBOLs have no such type (Fujitsu PowerCOBOL implements POW-TRUE and 
> POW-FALSE which is compatible with a VB Boolean...) and we end up with "Y" and 
> "N" and "yes" and "no" and similar horror stories representing true or false.
>
> Why do I personally dislike using "Y" and "N" (and variations thereof)?
>
> Because I have worked in cultures where the words for "yes" and "no" are NOT 
> "yes" and "no". Just because COBOL is English like does not mean that the 
> English language should be enforced by it. It is arrogant and rude to expect 
> programmers in different cultures to recognise English truth values, even 
> though most of them can...
>
> Even in English language cultures, using words like "yes" and "no" (or 
> variations that are language based) fuse the realm of Logic with the realm of 
> Language, and the result is that imprecise language and thought processes 
> become imprecise computer logic. Separating Logic from Language in programming 
> is a Good Thing. Perhaps in daily speech you are a bit more relaxed, but in 
> code there is no mistaking truth and falsity.
>
> The elegant mathematical beauty of Boole's two-valued Algebra transcends all 
> languages and cultures. "1" and "0" were good enough for George; they are 
> certainly good enopugh for me... :-)
>
> I agree strongly with Alain on this one.
>
>>>
>>>
>>> Pete Dashwood a �crit :
>>>> William M. Klein wrote:
>>>>
>>>>> OK, so I am certain that this will end up in "style war"
>>>>> discussions and/or discussions of how to do "multiple possible
>>>>> error" processing or a number of things we have discussed before,
>>>>> but ... There may be one in the "archives" that I didn't see, but given 
>>>>> the
>>>>> other thread, I thought I would go ahead and code a "date
>>>>> validation" in COBOL routine.  (This assumes YYYYMMDD format and
>>>>> only handles dates in the range of Jan 1, 1601 - first date
>>>>> allowed for Intrinsic Functions - thru Dec 31, 9999). Expanding it
>>>>> would be easy. I put the "input date" in WS, but obviously one could 
>>>>> change that
>>>>> to a Linkage Section parameter or an ACCEPT (from console) or any
>>>>> other way of getting it in for validation.
>>>>>
>>>>> So, for what it is worth, ...
>>>>>
>>>>>       Identification Division.
>>>>>        Program-ID.  VALDATE.
>>>>>       Data Division.
>>>>>        Working-Storage Section.
>>>>>       01  Date-IN.
>>>>>           05  DI-YYYY Pic 9(04).
>>>>>           05  DI-MM Pic 9(02).
>>>>>               88 1-to-12 Value 1 thru 12.
>>>>>               88 31-Days Value 1 3 5 7 8 10 12.
>>>>>               88 30-Days Value 4 6 9 11.
>>>>>               88 Feb  Value 2.
>>>>>           05  DI-DD Pic 9(02).
>>>>>               88  1-to-31 Value 1 thru 31.
>>>>>               88  1-to-30 Value 1 thru 30.
>>>>>               88  1-to-29      Value 1 thru 29.
>>>>>               88  1-to-28 Value 1 thru 28. .
>>>>>       01  Info-Out.
>>>>>           05  Stat Pic 9(01) Value Zero.
>>>>>           05  Msg Pic X(80) Value Spaces.
>>>>>       Procedure Division.
>>>>>        Mainline.
>>>>>           If Date-In Not Numeric
>>>>>               Move 1 to Stat
>>>>>               Move "Non-Numeric Value in Input Date"
>>>>>                 to Msg
>>>>>           Else
>>>>>               If DI-YYYY < 1601
>>>>>      *            any larger year less than 9999 is valid
>>>>>                   Move 2 to Stat
>>>>>                   Move "Year less than 1601"
>>>>>                     to Msg
>>>>>               Else
>>>>>                   If  not 1-to-12
>>>>>                       Move 3  to Stat
>>>>>                       Move "Month too small or too large"
>>>>>                         to Msg
>>>>>                   Else
>>>>>                       If  31-Days
>>>>>                        and not 1-to-31
>>>>>                         Move 4  to Stat
>>>>>                         Move "Day of month invalid for this month"
>>>>>                           to Msg
>>>>>                       Else
>>>>>                           If 30-Days
>>>>>                            And not 1-to-30
>>>>>                             Move 5  to Stat
>>>>>                             Move "Day of month invalid for this
>>>>>                               month" to Msg
>>>>>                           Else
>>>>>                               If Feb
>>>>>                                and not 1-to-29
>>>>>                                   Move 5  to Stat
>>>>>                                   Move "Day of month invalid for
>>>>>                                this month" to Msg
>>>>>                        Else
>>>>>                            Perform Check-Leap-Year
>>>>>                        End-If
>>>>>                    End-If
>>>>>                End-If
>>>>>            End-If
>>>>>               End-If
>>>>>           End-If
>>>>>           Stop Run
>>>>>            .
>>>>>       Check-Leap-Year.
>>>>>           Continue
>>>>>           If Function Mod (DI-YYYY 400) = 0
>>>>>               Continue
>>>>>           Else
>>>>>               If   (function Mod (DI-yyyy 4) = 0)
>>>>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>>>>                   Continue
>>>>>               Else
>>>>>                   If 1-to-28
>>>>>                       Continue
>>>>>                   Else
>>>>>                       Move 6 to Stat
>>>>>                       Move "Year is not a leap year"
>>>>>                     to Msg
>>>>>                   End-If
>>>>>               End-If
>>>>>           End-If
>>>>>             .
>>>>>
>>>>  I liked the code, Bill. It is refreshing to see date validation
>>>> without a calendar in it... :-)
>>>>
>>>> So, here we have a function that takes a date in a specified format
>>>> and tells us quite a bit about it. It is very unlikely to ever need
>>>> modification (unless the whole basis for our calendar was changed)
>>>> and any manipulation of other date formats can be done outside of
>>>> it (or it could be wrapped to include such formats.)
>>>>
>>>> This is the precise way in which component based systems get built.
>>>>
>>>> If you have no objection, I'll make this into a COM component
>>>> (using Fujitsu NetCobol) and post it on the COBDATA Web Site (where
>>>> it can be publicly downloaded). The site is listed for complete
>>>> refurbishment as soon as I have some time. I expect to be doing it
>>>> at the end of this month. What would be of real interest to me, personally, 
>>>> would be to see
>>>> this code converted to a COM object, using the MicroFocus COBOL
>>>> compiler.The problem is that anyone downloading it would have to
>>>> pay runtime fees...nevertheless, I'd like to see the code.
>>>>
>>>> Pete.
>>>>
>>> Using Bill's code, here is a working function :
>>>
>>> isdate.cpy :
>>>       78 isdate-succes value 1.
>>>       78 isdate-Non-Numeric Value 0.
>>>       78 isdate-Year-less-than-1601 value 2.
>>>       78 isdate-invalid-Month value 3.
>>>       78 isdate-invalid-day-31-Days value 4.
>>>       78 isdate-invalid-day-30-Days value 5.
>>>       78 isdate-invalid-day-feb value 6.
>>>       78 isdate-not-a-leap-year value 7.
>>>
>
> The 78 levels are a Micro Focus extension. I'd use CONSTANTs or condition 
> names.
>
>>> isdate.cbl :
>>>      $set repository (update on)
>>>      $set sourceformat"free"
>>>       identification division.
>>>       function-id. isdate as "isdate".
>>>       working-storage section.
>>>       copy "isdate.cpy".
>>>       1 Date-IN.
>>>         5 DI-YYYY Pic 9(04).
>>>         5 DI-MM Pic 9(02).
>>>           88 1-to-12 Value 1 thru 12.
>>>           88 31-Days Value 1 3 5 7 8 10 12.
>>>           88 30-Days Value 4 6 9 11.
>>>           88 Feb Value 2.
>>>         5 DI-DD Pic 9(02).
>>>           88  1-to-31 Value 1 thru 31.
>>>           88  1-to-30 Value 1 thru 30.
>>>           88  1-to-29 Value 1 thru 29.
>>>           88  1-to-28 Value 1 thru 28.
>>>       1 Info-Out.
>>>         5 Msg Pic X(80) Value Spaces.
>>>       linkage section.
>>>       1 myDate pic 9(8).
>>>       1 Stat pic 9.
>>>       procedure division using myDate returning Stat.
>>>         move isdate-succes to Stat  *> Function returns 1 if date is
>>> correct.
>>>         move myDate to Date-In
>>>         If Date-In Not Numeric
>>>          Move isdate-Non-Numeric to Stat
>>>         Else
>>>          If DI-YYYY < 1601 then *> any larger year less than 9999 is
>>>           valid Move isdate-Year-less-than-1601 to Stat
>>>          Else
>>>           If not 1-to-12 then
>>>            Move isdate-invalid-Month to Stat
>>>           Else
>>>            If 31-Days and not 1-to-31 then
>>>             Move isdate-invalid-day-31-Days to Stat
>>>            Else
>>>             If 30-Days And not 1-to-30 then
>>>              Move isdate-invalid-day-30-Days to Stat
>>>             Else
>>>              If Feb and not 1-to-29 then
>>>               Move isdate-invalid-day-feb to Stat
>>>              Else
>>>               *> Check-Leap-Year
>>>               If Function Mod (DI-YYYY 400) = 0
>>> then
>>>
>>> Continue
>>>
>>>
>>> Else
>>>
>>>                If (function Mod (DI-yyyy 4) = 0) And (Function Mod
>>> (DI-YYYY 100) NOT = 0) then
>>>
>>> Continue
>>>
>>>
>>> Else
>>>
>>>                 If 1-to-28
>>> then
>>>
>>> Continue
>>>
>>>
>>> Else
>>>
>>>                  Move isdate-not-a-leap-year to
>>> Stat
>>>
>>> End-If
>>>
>>>
>>> End-If
>>>
>>>
>>> End-If
>>>
>>>              End-If
>>>             End-If
>>>            End-If
>>>           End-If
>>>          End-If
>>>         End-If
>>>         exit function.
>>>       end function isdate.
>>>
>>> testisdate.cbl
>>>       repository.
>>>           function isdate as "isdate".
>>>       data division.
>>>       working-storage section.
>>>       copy "isdate.cpy".
>>>       1 myDate pic 9(8).
>>>       1 bool pic 9.
>>>       procedure division.
>>>        move 20090431 to myDate
>>>        evaluate isDate(myDate)
>>>         when isdate-succes
>>>          display "Correct"
>>>         when isdate-Non-Numeric
>>>          display "Non-Numeric Value in Input Date"
>>>         when isdate-Year-less-than-1601
>>>          display "Year less than 1601"
>>>         when isdate-invalid-Month
>>>          display "Month too small or too large"
>>>         when isdate-invalid-day-31-Days
>>>          display "Day of month invalid for this month. Must be
>>>         (1..31)" when isdate-invalid-day-30-Days
>>>          display "Day of month invalid for this month. Must be
>>>         (1..30)" when isdate-invalid-day-feb
>>>          display "Day of month invalid for feb (1..28/29)"
>>>         when isdate-not-a-leap-year
>>>          display "Year is not a leap year"
>>>        end-evaluate
>>>        if isDate(myDate) = 1 then
>>>          display "Correct"
>>>        else
>>>          display "False"
>>>        end-if
>>>        exit program
>>>        stop run
>>>        .
>>>
>>> I really think that implementing user functions in cobol can bring a
>>> lot in simplification and quality of code.
>>>
>
> Absolutely. Doing so in any language is very valuable.
>
> For me, the idea is to isolate functionality into units that are unlikely to 
> require maintenance. (Your function and Bill's code meet that requirement.) 
> The next step is to make the "function" available in a form where it can run 
> anywhere, and be used by ANYTHING (including other computer languages, and 
> scripts on web pages...) One way to achieve this is by wrapping it as a 
> Component Object Model (COM) component.
>
> Fujitsu make this easy, but I understand Micro Focus has this functionality 
> available also.
>
> Once you have this, you have something that will require minimal intervention, 
> can be very efficiently reused (the system can serve up instances of it to as 
> many concurrent processes as require it (and these processes can be written in 
> ANY language that supports the COM), yet there is no duplication of it on your 
> system), and it will run for years, in environments you haven't even 
> considered when you built it.
>
> THAT is a very good ROI.
>
> (How you go about addressing change in a component based environment, the use 
> of dynamic interfaces and components, is beyond the scope of what I'm writing 
> here, but it is certainly viable.)
>
> I cottoned on to this some years back when I started pushing Objects (Classes) 
> into components, and suddenly found that once they were wrapped as COM their 
> useful life became "indefinite", instead of "a few years on the Windows 
> desktop"
>
> COBOL people, for the most part, are used to maintaining source code and don't 
> realise that it simply doesn't HAVE to be like that.
>
> Most of them are not familiar with the concepts of Object Orientiation (or 
> worse, have improper understanding of them, by never having actually applied 
> them...). Using functions in COBOL is a very good way to change some of this 
> thinking and I really hope people will pick up on it.
>
> It is a step in the "right" direction towards encapsulated, reusable, code 
> that requires minimum maintenance.
>
> Pete.
> -- 
> "I used to write COBOL...now I can do anything."
> 


0
Reply wmklein40 (279) 1/6/2009 11:03:22 PM

First,  PIC 1 defaults to USAGE DISPLAY not USAGE BIT.  I was NOT suggesting 
that the returned value be a bit.

In those COBOLs (based on the 2002 Standard) that support PIC 1 (with and 
without USAGE BIT), there are also boolean operators that can work with them.

HOWEVER, the main reason that I was suggesting the use of PIC 1 *if* the 
function is intended to return a boolean value is that there is compile-time 
checking (part of the reason that Alain's code uses the Repository paragraph). 
If the function is rally intended to only return 0 or 1 (indicating true or 
false) then defining the returned value as that would allow the compiler to 
verify that it is used that way by the program that activates the function, i.e.

  If Function ValDate  (sent-date)
       then perform it-is-true
    or
  If Function ValDate (sent-date) b-xor  Something-else = B"0"

However, at compile time, it could/would reject

  Add 1 to Function ValDate (sent-item) giving Num-Recv

* * * *

I will certainly add that most existing (and being maintained) COBOL exists 
where boolean support is NOT available. Therefore, it is certainly not 
"critical" for COBOL use.  On the other hand, when using a compiler that does 
support it and trying to return a boolean (truth) value, then I don't see why it 
should NOT be used.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6si5hjF68k6uU1@mid.individual.net...
> William M. Klein wrote:
>> If you want to do YOUR version as a "boolean", did you think of using
>>   Pic 1
>> for the returned value?
>
> Bill, there is no excuse for using PIC 1 in COBOL, UNLESS you need 
> compatibility with some other process.
>
> Using a single bit to represent a Boolean type is inefficient and completely 
> unnecessary in today's world.
>
> Part of the "problem" I see with COBOL is that there have been too many 
> compromises over the decades, usually prompted by laziness or misunderstanding 
> on the part of some elements of the user base...
>
> "People are writing spaghetti..."  OK, let's remove ALTER from the language. 
> (the fact that some of the "spaghetti" was very tasty and highly efficient, in 
> a time when resources were, by today's standards, extremely limited, wasn't a 
> consideration. Instead of imposing a local standard and educating people into 
> writing better code, just drop a language element.)
>
> "In Assembler I can use Boolean operations on bits..." OK, we'll add some 
> subroutines to support XOR etc., and let's have a PIC 1 binary type so COBOL 
> can do it too. How cool is that?!  (The fact that less than 1% of all the code 
> written in COBOL actually USES this facility doesn't matter... let's keep 
> COBOL up with the "cool" languages...yeah, right)
>
> "I don't like DIVIDE ... INTO... it means I have to think in an unnatural, 
> un-English-like way..." OK, we'll allow DIVIDE...BY...  (A lot of work for 
> compiler writers because BY can now be confused contextually with MULTIPLY. 
> Same thing happened with EXAMINE and INSPECT where the original WITH for 
> REPLACING was changed to allow BY by some vendors. All this did was pander to 
> the LCD of programming pussies who couldn't even discipline themselves to 
> learn a language properly. (If code is being written by people who can't 
> discipline themselves even to comply with a clear cut language requirement, it 
> is hardly surprising if the results from such undisciplined thought processes 
> are horrendous. Ever wonder why there's such a lot of bad code in the world? 
> Why is so much of it bad COBOL...?)
>
> "Why doesn't COBOL support a Reporting function, or a Communications function, 
> or Object Orientation?" OK, we'll add 'em all.  (Huge effort) Anybody using 
> them? No. Why not? Too hard. And different. I can use Crystal Reports. If I 
> want to use a network I can use scripting or CICS. And that OO stuff is a just 
> a fashion blip that will be gone in a year (15 years ago...). It's all a big 
> con. REAL programmers write COBOL....(actually, they write Fortran in 
> COBOL...) How come some Java guy is relacing me next month?
>
> And we wonder why COBOL is moribund. The community (for the most part; some 
> are waking up now it is too late...) simply doesn't get it.
>
> Attempts to "re-invent" COBOL (like some we've seen advertised here recently) 
> are like attempts by Frankenstein to galvanize a corpse. UNLESS these new 
> attempts (some of which are quite noble in themselves) can make COBOL fly in 
> the 21st century, they are pointless. It needs to have OO, it needs to have 
> functionality for encapsulation (COM is one example), and the user community 
> needs to recognise the need for these things, if COBOL is to have any role 
> other than as a batch processing language, of as much relevance in IT as 
> Sanskrit or Chaldean is in modern Language.
>
> Thank you I feel much better now... :-)
>
> All this from PIC 1.... imagine if Bill had suggested banning complex 
> constructs like PERFORM...VARYING... :-)
>
> Pete.
> -- 
> "I used to write COBOL...now I can do anything."
> 


0
Reply wmklein40 (279) 1/6/2009 11:15:35 PM

As mentioned in another note, I have coded an alternative routine for this.  The 
difference are (I hope) ONLY to do with style.  This code:
  - Uses EVALUATE to show "decision table" nature of the logic
 - Returns only a "1" (good) or "0" (bad) date indicator

**** Sample code below

       Identification Division.
        Program-ID.  VALDT2.
       Data Division.
        Working-Storage Section.
       01  Date-IN.
           05  DI-YYYY Pic 9(04).
           05  DI-MM Pic 9(02).
           05  DI-DD Pic 9(02).
       01  Info-Out.
           05  Stat Pic X(01) Value High-Values.
               88  Good-Date  Value "1".
               88  Bad-Date  Value "0".
       Procedure Division.
        Mainline.
           If Date-In Not Numeric
               Set Bad-Date To True
           Else
               Evaluate DI-YYYY        Also DI-MM     Also DI-DD
                 When   1601 Thru 9999 Also 1 thru 12 Also 1 thru 31
                   Evaluate  DI-MM Also DI-DD
                     When     1    Also 1 thru 31
                     When     3    Also 1 thru 31
                     When     4    Also 1 thru 30
                     When     5    Also 1 thru 31
                     When     6    Also 1 thru 30
                     When     7    Also 1 thru 31
                     When     8    Also 1 thru 31
                     When     9    Also 1 thru 30
                     when    10    Also 1 thru 31
                     When    11    Also 1 thru 30
                     When    12    Also 1 thru 31
                       Set Good-Date to True
                     When     2    Also Any
                       Perform Check-Leap-Year
                     When Other
                       Set Bad-Date to true
                   End-Evaluate
                 When Other
                   Set Bad-Date To True
                End-Evaluate
           End-If
           Stop Run
            .
       Check-Leap-Year.
           Evaluate Function Mod (DI-YYYY 4)
             Also   Function Mod (DI-YYYY 100)
             Also   Function Mod (DI-YYYY 400)
             Also DI-DD
               When   0
                 Also 0
                 Also 0
                 Also 1 thru 29
               When   0
                 Also not 0
                 Also not 0
                 Also 1 thru 29
               When not 0
                 Also not 0
                 Also not 0
                 Also 1 thru 28
                   Set Good-Date to True
                When Other
                   Set Bad-Date to True
           End-Evaluate
             .

*** end of sample code

-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
Reply wmklein40 (279) 1/7/2009 12:46:11 AM

William M. Klein wrote:
> The reason that I used "MOVE" instead of "SET to TRUE" was that I was
> "setting" the value of two fields (one a number "status" and another
> being the "alphanumeric message".  This was totally redundant in the
> first place and I assume that any "real-world" application would use
> one or the other, not both. Possible a real world application would
> use the numeric status field and then use it to subscript into a
> table of messages AND there could be multiple message tables for
> multiple languages.  I know that I could have put the actual messages
> as 88-levels and SET TO TRUE for them as well; it just didn't "feel
> right" to me.
> Similarly, "just because" was my decision to test the year for "<
> 1601" instead of having an 88-level for "1601 thru 9999" which would
> have been more consistent with what I did with other range
> validations.

Thanks for the clarification, Bill.

I believe that when someone has paid their dues as long as you have, then "I 
just prefer that" or "just because" are perfectly valid reasons for choosing 
an approach. However, it is sometmes difficult to make that case to people 
learning the language... :-)
>
> In all of these cases, I suppose that if I were doing a real world
> application AND the date-validation actually were a significant
> portion of the total application logic (which I find doubtful), I
> might try and compile several different approaches and see what the
> run-time performance was like.  As I see all of these coding
> techniques to be easily maintainable (by even entry-level
> programmer), I guess that performance would be (should be?) the final
> consideration.

So, you see ease-of-maintenance and performance as two very important 
criteria. They are, (especially where source code is being maintained).

I don't personally see either of them as the final consideration. (But I 
probably would in a COBOL environment).

Maintenance is very low on a list of priorities because I really don't 
maintain most of the components I write. (there is a subset of dynamic 
layers which DO require some "maintenance"; I like to call it 
"configuration" :-), but these are not the "building blocks" (like your date 
validation routine), more the "glue" or "mortar"...)

Performance is largely taken care of by multiple cores running separate 
instances of objects (I did some experiments yesterday with a Data Access 
Layer object, fetching on a SQL cursor in COBOL. Where the single object 
instance was doing ALL actions (including updates and writes, as well as 
sequential and random access), the throughput on sequential access was 
around 40 rows a second... fairly poor, and really just marginal for the 
application which requires it. As soon as a second instance was created 
which handled all the updates, the sequential access hit 90 rows a second. I 
would stress that this involved NO CHANGE to logic in the class. They were 
just two instances of the same Class, one being invoked for PUT actions and 
the other for GET actions. They were running on a dual core machine but I 
suspect the process was not spread over separate cores (that is supposed to 
be coming with Windows 7 :-)) The point is that objects can be EASILY 
parallell processed so performance of them is much less problematic than 
with procedural code.

(By comparison, in C# using disconnected result sets, I get 120 rows a 
second...I haven't tried the same access using LINQ but I would expect it to 
be the same or faster... embedded SQL just sucks...)

OK, I'm not worried about maintenance and performance (I have them both 
covered...), so what DO I see as important?

Speed to build, speed and ease of deployment, and match to customer 
requirements (today, not when the requirements were gathered 9 months 
ago...), are all high on my list. I'd rather have something out there doing 
SOMETHING that is of use to people (even if it isn't perfect from an IT 
perspective), than wait for months until it is "right", and then find it 
can't utilise the new multi-core processors my customers have just 
ordered...


> On the other hand, date validation is RARELY (if
> ever) a major portion of run-time performance AND I doubt that any of
> these techniques would be significantly better performers than
> others, so I think I would probably use whatever first came into my
> mind and leave it at that <G>

Yes, I think that's fair...
>
> P.S.  I was actually thinking of coding up another example of how
> this could be done using (mostly) EVALUATE rather than nested IF's as
> I do (sort-of) see this as a "decision table" type of program and I
> really *like* evaluate for that type of algorithm.
>
>> William M. Klein wrote:
>>> Alain,
>>>  If you care (and you probably don't), use of "78-levels" makes your
>>> code NOT conform to the 2002 ISO Standard (where User defined
>>> functions were introduce into Standard COBOL).
>>>
>>> I think (but am not positive) that MF now supports the "CONSTANT"
>>> clause which is MOSTLY the same as MF 78-level extension.
>>>

I seem to vaguely remember COBOL 59 having a CONSTANT section following WS. 
I think it may have been dropped due to lack of use...

>>> I actually thought of using the following type of code:
>>>
>>> 1 Stat pic 9.
>>>       88 isdate-succes value 1.
>>>       88 isdate-Non-Numeric Value 0.
>>>       88 isdate-Year-less-than-1601 value 2.
>>>       88 isdate-invalid-Month value 3.
>>>       88 isdate-invalid-day-31-Days value 4.
>>>       88 isdate-invalid-day-30-Days value 5.
>>>       88 isdate-invalid-day-feb value 6.
>>>       88 isdate-not-a-leap-year value 7.
>>>
>>> and then instead of the move statement, code
>>>    Set isdate-Year-Less-than-1601 to true
>>
>> Yes, I prefer set to move. Why did you decide not to do this?

Answered in yur response above, thanks.

>>>
>>> P.S.  I think you reversed the values of "0" and "1".  At least for
>>> me, I would expect the "successful" to be zero and all the non-zero
>>> "returned status values" to be treated as unsuccessful.
>>>
>>
>> No, the Boolean truth values are 1 for true and zero for false. Many
>> different computer languages implement them differently... sometimes
>> a negative value is false and zeroor positive is true, for example.
>> That's why it is good to use a Boolean type, which can only have
>> values of TRUE or FALSE, and it really doesn't matter what the
>> underlying "mechanism" for true and false is. Sadly, most COBOLs
>> have no such type (Fujitsu PowerCOBOL implements POW-TRUE and
>> POW-FALSE which is compatible with a VB Boolean...) and we end up
>> with "Y" and "N" and "yes" and "no" and similar horror stories
>> representing true or false.  Why do I personally dislike using "Y" and 
>> "N" (and variations
>> thereof)? Because I have worked in cultures where the words for "yes" and 
>> "no"
>> are NOT "yes" and "no". Just because COBOL is English like does not
>> mean that the English language should be enforced by it. It is
>> arrogant and rude to expect programmers in different cultures to
>> recognise English truth values, even though most of them can...
>>
>> Even in English language cultures, using words like "yes" and "no"
>> (or variations that are language based) fuse the realm of Logic with
>> the realm of Language, and the result is that imprecise language and
>> thought processes become imprecise computer logic. Separating Logic
>> from Language in programming is a Good Thing. Perhaps in daily
>> speech you are a bit more relaxed, but in code there is no mistaking
>> truth and falsity. The elegant mathematical beauty of Boole's two-valued 
>> Algebra
>> transcends all languages and cultures. "1" and "0" were good enough
>> for George; they are certainly good enopugh for me... :-)
>>
>> I agree strongly with Alain on this one.
>>
>>>>
>>>>
>>>> Pete Dashwood a �crit :
>>>>> William M. Klein wrote:
>>>>>
>>>>>> OK, so I am certain that this will end up in "style war"
>>>>>> discussions and/or discussions of how to do "multiple possible
>>>>>> error" processing or a number of things we have discussed before,
>>>>>> but ... There may be one in the "archives" that I didn't see,
>>>>>> but given the
>>>>>> other thread, I thought I would go ahead and code a "date
>>>>>> validation" in COBOL routine.  (This assumes YYYYMMDD format and
>>>>>> only handles dates in the range of Jan 1, 1601 - first date
>>>>>> allowed for Intrinsic Functions - thru Dec 31, 9999). Expanding
>>>>>> it would be easy. I put the "input date" in WS, but obviously
>>>>>> one could change that
>>>>>> to a Linkage Section parameter or an ACCEPT (from console) or any
>>>>>> other way of getting it in for validation.
>>>>>>
>>>>>> So, for what it is worth, ...
>>>>>>
>>>>>>       Identification Division.
>>>>>>        Program-ID.  VALDATE.
>>>>>>       Data Division.
>>>>>>        Working-Storage Section.
>>>>>>       01  Date-IN.
>>>>>>           05  DI-YYYY Pic 9(04).
>>>>>>           05  DI-MM Pic 9(02).
>>>>>>               88 1-to-12 Value 1 thru 12.
>>>>>>               88 31-Days Value 1 3 5 7 8 10 12.
>>>>>>               88 30-Days Value 4 6 9 11.
>>>>>>               88 Feb  Value 2.
>>>>>>           05  DI-DD Pic 9(02).
>>>>>>               88  1-to-31 Value 1 thru 31.
>>>>>>               88  1-to-30 Value 1 thru 30.
>>>>>>               88  1-to-29      Value 1 thru 29.
>>>>>>               88  1-to-28 Value 1 thru 28. .
>>>>>>       01  Info-Out.
>>>>>>           05  Stat Pic 9(01) Value Zero.
>>>>>>           05  Msg Pic X(80) Value Spaces.
>>>>>>       Procedure Division.
>>>>>>        Mainline.
>>>>>>           If Date-In Not Numeric
>>>>>>               Move 1 to Stat
>>>>>>               Move "Non-Numeric Value in Input Date"
>>>>>>                 to Msg
>>>>>>           Else
>>>>>>               If DI-YYYY < 1601
>>>>>>      *            any larger year less than 9999 is valid
>>>>>>                   Move 2 to Stat
>>>>>>                   Move "Year less than 1601"
>>>>>>                     to Msg
>>>>>>               Else
>>>>>>                   If  not 1-to-12
>>>>>>                       Move 3  to Stat
>>>>>>                       Move "Month too small or too large"
>>>>>>                         to Msg
>>>>>>                   Else
>>>>>>                       If  31-Days
>>>>>>                        and not 1-to-31
>>>>>>                         Move 4  to Stat
>>>>>>                         Move "Day of month invalid for this
>>>>>>                           month" to Msg
>>>>>>                       Else
>>>>>>                           If 30-Days
>>>>>>                            And not 1-to-30
>>>>>>                             Move 5  to Stat
>>>>>>                             Move "Day of month invalid for this
>>>>>>                               month" to Msg
>>>>>>                           Else
>>>>>>                               If Feb
>>>>>>                                and not 1-to-29
>>>>>>                                   Move 5  to Stat
>>>>>>                                   Move "Day of month invalid for
>>>>>>                                this month" to Msg
>>>>>>                        Else
>>>>>>                            Perform Check-Leap-Year
>>>>>>                        End-If
>>>>>>                    End-If
>>>>>>                End-If
>>>>>>            End-If
>>>>>>               End-If
>>>>>>           End-If
>>>>>>           Stop Run
>>>>>>            .
>>>>>>       Check-Leap-Year.
>>>>>>           Continue
>>>>>>           If Function Mod (DI-YYYY 400) = 0
>>>>>>               Continue
>>>>>>           Else
>>>>>>               If   (function Mod (DI-yyyy 4) = 0)
>>>>>>                And (Function Mod (DI-YYYY 100) NOT = 0)
>>>>>>                   Continue
>>>>>>               Else
>>>>>>                   If 1-to-28
>>>>>>                       Continue
>>>>>>                   Else
>>>>>>                       Move 6 to Stat
>>>>>>                       Move "Year is not a leap year"
>>>>>>                     to Msg
>>>>>>                   End-If
>>>>>>               End-If
>>>>>>           End-If
>>>>>>             .
>>>>>>
>>>>>  I liked the code, Bill. It is refreshing to see date validation
>>>>> without a calendar in it... :-)
>>>>>
>>>>> So, here we have a function that takes a date in a specified
>>>>> format and tells us quite a bit about it. It is very unlikely to ever
>>>>> need modification (unless the whole basis for our calendar was
>>>>> changed) and any manipulation of other date formats can be done 
>>>>> outside of
>>>>> it (or it could be wrapped to include such formats.)
>>>>>
>>>>> This is the precise way in which component based systems get
>>>>> built. If you have no objection, I'll make this into a COM component
>>>>> (using Fujitsu NetCobol) and post it on the COBDATA Web Site
>>>>> (where it can be publicly downloaded). The site is listed for complete
>>>>> refurbishment as soon as I have some time. I expect to be doing it
>>>>> at the end of this month. What would be of real interest to me,
>>>>> personally, would be to see
>>>>> this code converted to a COM object, using the MicroFocus COBOL
>>>>> compiler.The problem is that anyone downloading it would have to
>>>>> pay runtime fees...nevertheless, I'd like to see the code.
>>>>>
>>>>> Pete.
>>>>>
>>>> Using Bill's code, here is a working function :
>>>>
>>>> isdate.cpy :
>>>>       78 isdate-succes value 1.
>>>>       78 isdate-Non-Numeric Value 0.
>>>>       78 isdate-Year-less-than-1601 value 2.
>>>>       78 isdate-invalid-Month value 3.
>>>>       78 isdate-invalid-day-31-Days value 4.
>>>>       78 isdate-invalid-day-30-Days value 5.
>>>>       78 isdate-invalid-day-feb value 6.
>>>>       78 isdate-not-a-leap-year value 7.
>>>>
>>
>> The 78 levels are a Micro Focus extension. I'd use CONSTANTs or
>> condition names.
>>
>>>> isdate.cbl :
>>>>      $set repository (update on)
>>>>      $set sourceformat"free"
>>>>       identification division.
>>>>       function-id. isdate as "isdate".
>>>>       working-storage section.
>>>>       copy "isdate.cpy".
>>>>       1 Date-IN.
>>>>         5 DI-YYYY Pic 9(04).
>>>>         5 DI-MM Pic 9(02).
>>>>           88 1-to-12 Value 1 thru 12.
>>>>           88 31-Days Value 1 3 5 7 8 10 12.
>>>>           88 30-Days Value 4 6 9 11.
>>>>           88 Feb Value 2.
>>>>         5 DI-DD Pic 9(02).
>>>>           88  1-to-31 Value 1 thru 31.
>>>>           88  1-to-30 Value 1 thru 30.
>>>>           88  1-to-29 Value 1 thru 29.
>>>>           88  1-to-28 Value 1 thru 28.
>>>>       1 Info-Out.
>>>>         5 Msg Pic X(80) Value Spaces.
>>>>       linkage section.
>>>>       1 myDate pic 9(8).
>>>>       1 Stat pic 9.
>>>>       procedure division using myDate returning Stat.
>>>>         move isdate-succes to Stat  *> Function returns 1 if date
>>>> is correct.
>>>>         move myDate to Date-In
>>>>         If Date-In Not Numeric
>>>>          Move isdate-Non-Numeric to Stat
>>>>         Else
>>>>          If DI-YYYY < 1601 then *> any larger year less than 9999
>>>>           is valid Move isdate-Year-less-than-1601 to Stat
>>>>          Else
>>>>           If not 1-to-12 then
>>>>            Move isdate-invalid-Month to Stat
>>>>           Else
>>>>            If 31-Days and not 1-to-31 then
>>>>             Move isdate-invalid-day-31-Days to Stat
>>>>            Else
>>>>             If 30-Days And not 1-to-30 then
>>>>              Move isdate-invalid-day-30-Days to Stat
>>>>             Else
>>>>              If Feb and not 1-to-29 then
>>>>               Move isdate-invalid-day-feb to Stat
>>>>              Else
>>>>               *> Check-Leap-Year
>>>>               If Function Mod (DI-YYYY 400) = 0
>>>> then
>>>>
>>>> Continue
>>>>
>>>>
>>>> Else
>>>>
>>>>                If (function Mod (DI-yyyy 4) = 0) And (Function Mod
>>>> (DI-YYYY 100) NOT = 0) then
>>>>
>>>> Continue
>>>>
>>>>
>>>> Else
>>>>
>>>>                 If 1-to-28
>>>> then
>>>>
>>>> Continue
>>>>
>>>>
>>>> Else
>>>>
>>>>                  Move isdate-not-a-leap-year to
>>>> Stat
>>>>
>>>> End-If
>>>>
>>>>
>>>> End-If
>>>>
>>>>
>>>> End-If
>>>>
>>>>              End-If
>>>>             End-If
>>>>            End-If
>>>>           End-If
>>>>          End-If
>>>>         End-If
>>>>         exit function.
>>>>       end function isdate.
>>>>
>>>> testisdate.cbl
>>>>       repository.
>>>>           function isdate as "isdate".
>>>>       data division.
>>>>       working-storage section.
>>>>       copy "isdate.cpy".
>>>>       1 myDate pic 9(8).
>>>>       1 bool pic 9.
>>>>       procedure division.
>>>>        move 20090431 to myDate
>>>>        evaluate isDate(myDate)
>>>>         when isdate-succes
>>>>          display "Correct"
>>>>         when isdate-Non-Numeric
>>>>          display "Non-Numeric Value in Input Date"
>>>>         when isdate-Year-less-than-1601
>>>>          display "Year less than 1601"
>>>>         when isdate-invalid-Month
>>>>          display "Month too small or too large"
>>>>         when isdate-invalid-day-31-Days
>>>>          display "Day of month invalid for this month. Must be
>>>>         (1..31)" when isdate-invalid-day-30-Days
>>>>          display "Day of month invalid for this month. Must be
>>>>         (1..30)" when isdate-invalid-day-feb
>>>>          display "Day of month invalid for feb (1..28/29)"
>>>>         when isdate-not-a-leap-year
>>>>          display "Year is not a leap year"
>>>>        end-evaluate
>>>>        if isDate(myDate) = 1 then
>>>>          display "Correct"
>>>>        else
>>>>          display "False"
>>>>        end-if
>>>>        exit program
>>>>        stop run
>>>>        .
>>>>
>>>> I really think that implementing user functions in cobol can bring
>>>> a lot in simplification and quality of code.
>>>>
>>
>> Absolutely. Doing so in any language is very valuable.
>>
>> For me, the idea is to isolate functionality into units that are
>> unlikely to require maintenance. (Your function and Bill's code meet
>> that requirement.) The next step is to make the "function" available
>> in a form where it can run anywhere, and be used by ANYTHING
>> (including other computer languages, and scripts on web pages...)
>> One way to achieve this is by wrapping it as a Component Object
>> Model (COM) component. Fujitsu make this easy, but I understand Micro 
>> Focus has this
>> functionality available also.
>>
>> Once you have this, you have something that will require minimal
>> intervention, can be very efficiently reused (the system can serve
>> up instances of it to as many concurrent processes as require it
>> (and these processes can be written in ANY language that supports
>> the COM), yet there is no duplication of it on your system), and it
>> will run for years, in environments you haven't even considered when
>> you built it. THAT is a very good ROI.
>>
>> (How you go about addressing change in a component based
>> environment, the use of dynamic interfaces and components, is beyond
>> the scope of what I'm writing here, but it is certainly viable.)
>>
>> I cottoned on to this some years back when I started pushing Objects
>> (Classes) into components, and suddenly found that once they were
>> wrapped as COM their useful life became "indefinite", instead of "a
>> few years on the Windows desktop"
>>
>> COBOL people, for the most part, are used to maintaining source code
>> and don't realise that it simply doesn't HAVE to be like that.
>>
>> Most of them are not familiar with the concepts of Object
>> Orientiation (or worse, have improper understanding of them, by
>> never having actually applied them...). Using functions in COBOL is
>> a very good way to change some of this thinking and I really hope
>> people will pick up on it. It is a step in the "right" direction towards 
>> encapsulated,
>> reusable, code that requires minimum maintenance.
>>
>> Pete.
>> --
>> "I used to write COBOL...now I can do anything."

-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/7/2009 2:44:56 AM

William M. Klein wrote:
> As mentioned in another note, I have coded an alternative routine for
> this.  The difference are (I hope) ONLY to do with style.  This code:
>  - Uses EVALUATE to show "decision table" nature of the logic
> - Returns only a "1" (good) or "0" (bad) date indicator
>
> **** Sample code below
>
>       Identification Division.
>        Program-ID.  VALDT2.
>       Data Division.
>        Working-Storage Section.
>       01  Date-IN.
>           05  DI-YYYY Pic 9(04).
>           05  DI-MM Pic 9(02).
>           05  DI-DD Pic 9(02).
>       01  Info-Out.
>           05  Stat Pic X(01) Value High-Values.
>               88  Good-Date  Value "1".
>               88  Bad-Date  Value "0".
>       Procedure Division.
>        Mainline.
>           If Date-In Not Numeric
>               Set Bad-Date To True
>           Else
>               Evaluate DI-YYYY        Also DI-MM     Also DI-DD
>                 When   1601 Thru 9999 Also 1 thru 12 Also 1 thru 31
>                   Evaluate  DI-MM Also DI-DD
>                     When     1    Also 1 thru 31
>                     When     3    Also 1 thru 31
>                     When     4    Also 1 thru 30
>                     When     5    Also 1 thru 31
>                     When     6    Also 1 thru 30
>                     When     7    Also 1 thru 31
>                     When     8    Also 1 thru 31
>                     When     9    Also 1 thru 30
>                     when    10    Also 1 thru 31
>                     When    11    Also 1 thru 30
>                     When    12    Also 1 thru 31
>                       Set Good-Date to True
>                     When     2    Also Any
>                       Perform Check-Leap-Year
>                     When Other
>                       Set Bad-Date to true
>                   End-Evaluate
>                 When Other
>                   Set Bad-Date To True
>                End-Evaluate
>           End-If
>           Stop Run
>            .
>       Check-Leap-Year.
>           Evaluate Function Mod (DI-YYYY 4)
>             Also   Function Mod (DI-YYYY 100)
>             Also   Function Mod (DI-YYYY 400)
>             Also DI-DD
>               When   0
>                 Also 0
>                 Also 0
>                 Also 1 thru 29
>               When   0
>                 Also not 0
>                 Also not 0
>                 Also 1 thru 29
>               When not 0
>                 Also not 0
>                 Also not 0
>                 Also 1 thru 28
>                   Set Good-Date to True
>                When Other
>                   Set Bad-Date to True
>           End-Evaluate
>             .
>
> *** end of sample code

I really wanted to like this... but I can't... :-)

I think the use of Also is confusing (especially where we have "when 0" and 
"when NOT 0"  combined with a bunch of "Also 0" and "Also NOT zero"...

It may be logically elegant, but it makes me shudder when I look at it, and 
I had to go scurrying off to COBOL references to remind myself how EVALUATE 
works with ALSO.

Sorry Bill, it is a cool approach, but too strong for me I think...:-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/7/2009 2:55:03 AM

As you saw, it (the EVALUATE code) wasn't the first approach that I coded.  I 
originally thought that I would, but once I got into the actual logic, the 
nested IF did seem "cleaner" to me.

On the other hand, if a COBOL programmer did a lot with decision table coding 
(using EVALUATE), they would be very familiar with how ALSO works (and more 
importantly that sequential WHEN clauses cause an "OR" logic).

To put it simply,
  If EVALUATE is how you like to code, then you will like this code with 
EVALUATE <G>

(Sounds a lot like all our other "if you like "xyz" then "xyz" will look right 
to you for specific cases).

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6sijs6F676t1U1@mid.individual.net...
> William M. Klein wrote:
>> As mentioned in another note, I have coded an alternative routine for
>> this.  The difference are (I hope) ONLY to do with style.  This code:
>>  - Uses EVALUATE to show "decision table" nature of the logic
>> - Returns only a "1" (good) or "0" (bad) date indicator
>>
>> **** Sample code below
>>
>>       Identification Division.
>>        Program-ID.  VALDT2.
>>       Data Division.
>>        Working-Storage Section.
>>       01  Date-IN.
>>           05  DI-YYYY Pic 9(04).
>>           05  DI-MM Pic 9(02).
>>           05  DI-DD Pic 9(02).
>>       01  Info-Out.
>>           05  Stat Pic X(01) Value High-Values.
>>               88  Good-Date  Value "1".
>>               88  Bad-Date  Value "0".
>>       Procedure Division.
>>        Mainline.
>>           If Date-In Not Numeric
>>               Set Bad-Date To True
>>           Else
>>               Evaluate DI-YYYY        Also DI-MM     Also DI-DD
>>                 When   1601 Thru 9999 Also 1 thru 12 Also 1 thru 31
>>                   Evaluate  DI-MM Also DI-DD
>>                     When     1    Also 1 thru 31
>>                     When     3    Also 1 thru 31
>>                     When     4    Also 1 thru 30
>>                     When     5    Also 1 thru 31
>>                     When     6    Also 1 thru 30
>>                     When     7    Also 1 thru 31
>>                     When     8    Also 1 thru 31
>>                     When     9    Also 1 thru 30
>>                     when    10    Also 1 thru 31
>>                     When    11    Also 1 thru 30
>>                     When    12    Also 1 thru 31
>>                       Set Good-Date to True
>>                     When     2    Also Any
>>                       Perform Check-Leap-Year
>>                     When Other
>>                       Set Bad-Date to true
>>                   End-Evaluate
>>                 When Other
>>                   Set Bad-Date To True
>>                End-Evaluate
>>           End-If
>>           Stop Run
>>            .
>>       Check-Leap-Year.
>>           Evaluate Function Mod (DI-YYYY 4)
>>             Also   Function Mod (DI-YYYY 100)
>>             Also   Function Mod (DI-YYYY 400)
>>             Also DI-DD
>>               When   0
>>                 Also 0
>>                 Also 0
>>                 Also 1 thru 29
>>               When   0
>>                 Also not 0
>>                 Also not 0
>>                 Also 1 thru 29
>>               When not 0
>>                 Also not 0
>>                 Also not 0
>>                 Also 1 thru 28
>>                   Set Good-Date to True
>>                When Other
>>                   Set Bad-Date to True
>>           End-Evaluate
>>             .
>>
>> *** end of sample code
>
> I really wanted to like this... but I can't... :-)
>
> I think the use of Also is confusing (especially where we have "when 0" and 
> "when NOT 0"  combined with a bunch of "Also 0" and "Also NOT zero"...
>
> It may be logically elegant, but it makes me shudder when I look at it, and I 
> had to go scurrying off to COBOL references to remind myself how EVALUATE 
> works with ALSO.
>
> Sorry Bill, it is a cool approach, but too strong for me I think...:-)
>
> Pete.
> -- 
> "I used to write COBOL...now I can do anything."
> 


0
Reply wmklein40 (279) 1/7/2009 3:12:44 AM

William M. Klein wrote:
> As you saw, it (the EVALUATE code) wasn't the first approach that I
> coded.  I originally thought that I would, but once I got into the
> actual logic, the nested IF did seem "cleaner" to me.
>
> On the other hand, if a COBOL programmer did a lot with decision
> table coding (using EVALUATE), they would be very familiar with how
> ALSO works (and more importantly that sequential WHEN clauses cause
> an "OR" logic).
> To put it simply,
>  If EVALUATE is how you like to code, then you will like this code
> with EVALUATE <G>

I DO like EVALUATE and use it all the time in places where I would otherwise 
code a "switch"/"case" type construct. I just like it to be simple, and, in 
this case, I think the IF statements are more easily readable.

Having said that, I don't think there's anything "wrong" with using a more 
complex construct; it certainly encourages us to explore the language 
further and learn...


>
> (Sounds a lot like all our other "if you like "xyz" then "xyz" will
> look right to you for specific cases).

The right to code how we like is something that gets earned over time. It 
implies that the possibilities have been examined , absorbed and understood. 
Of course, when we are coding for someone other than ourselves, our 
possibilities are constrained, but that goes with the territory.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/7/2009 7:57:37 AM

On Wed, 7 Jan 2009 11:50:27 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>"Why doesn't COBOL support a Reporting function, or a Communications 
>function, or Object Orientation?" OK, we'll add 'em all.  (Huge effort) 
>Anybody using them? No. Why not? Too hard. And different. I can use Crystal 
>Reports. If I want to use a network I can use scripting or CICS. And that OO 
>stuff is a just a fashion blip that will be gone in a year (15 years 
>ago...). It's all a big con. REAL programmers write COBOL....(actually, they 
>write Fortran in COBOL...) How come some Java guy is relacing me next month?
>
>And we wonder why COBOL is moribund. The community (for the most part; some 
>are waking up now it is too late...) simply doesn't get it.

So what should the community have done?   What *could* they have done
to save CoBOL?   Should it have been saved?

Or have times changed so that newer tools fit better to newer needs?

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/7/2009 3:31:17 PM

On Wed, 7 Jan 2009 10:19:50 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> I've done this many times.   It's quick and easy and maintenance
>> programmers can understand it.
>
>Done what? Date Validation? Bill's Date validation? Alain's date validation? 
>Used a function approach? Used a date component?
>
>Without a quote, I have no idea exactly what you are referring to, Howard.

Used CoBOL code to do the validation he wrote.    Simple stuff like
that doesn't need to be in copymembers, subroutines, nor objects, and
isolation makes debugging and upgrading easy.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/7/2009 3:34:52 PM

On Wed, 7 Jan 2009 15:55:03 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I think the use of Also is confusing (especially where we have "when 0" and 
>"when NOT 0"  combined with a bunch of "Also 0" and "Also NOT zero"...
>
>It may be logically elegant, but it makes me shudder when I look at it, and 
>I had to go scurrying off to COBOL references to remind myself how EVALUATE 
>works with ALSO.

Certainly many maintenance programmers will have troubles - especially
looking at that code in the middle of the night.    The elegance of
the code doesn't equate to either quicker runs, nor more obvious code
for sufficient numbers of maintenance programmers.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/7/2009 3:37:18 PM

On Tue, 6 Jan 2009 21:12:44 -0600, "William M. Klein"
<wmklein@nospam.ix.netcom.com> wrote:

>To put it simply,
>  If EVALUATE is how you like to code, then you will like this code with 
>EVALUATE <G>
>
>(Sounds a lot like all our other "if you like "xyz" then "xyz" will look right 
>to you for specific cases).


But if EVALUATE (with ALSO) is not how other programmers in your shop
think, then liking that code isn't sufficient to use it.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/7/2009 3:38:46 PM

You'll remember the scene of about 15-20 years ago when the PC tsunami
seemed to be about to take over the IT world, when even mighty IBM was
reeling under the assault, when the BUNCH (Burrroughs, Univac, NCR, CDC, and
Honeywell) were effectively eliminated as mainframe companies (stipulating
that Burroughs/Univac still exist as Unisys, but with a vastly changed
business model).  At that time there was much comment as to what IBM should
do.  I remember a series of articles in Computerworld (I think) expressing
opinions; most of them suggested a radical change of course, some going so
far as to insist that IBM must implement Windows on its machines and abandon
its own o/s'es!  None of which they did.

How does this relate to the questions expressed below?

Only this: that a great deal of the changes in this industry are driven by
sincere but not always well-informed enthusiasms.    I instance acouple of
my younger colleagues who goggled with awe at the successive announcements
of a new chip with 10% more speed; "jeez, I've got to have that", they would
cry, then be utterly unable to understand why I didn't follow suit; or the
engineers who were learning VB assuring me that they were using a new
"event-oriented" method of programming which I wouldn't understand, then
shamefacedly admitting that my advice worked; one real enthusiast declared
in print that once C replaced Cobol, maintenance costs would immediately
come down.

This is not to say that young fogeyism is the way to go or be; learning and
adaptation is the only way to stay alive.  But there's no need to be in a
tearing hurry.  Some mainstream languages are less suited than others, but
of those I wouldn't want to say that any of them CAN NOT be used to solve
99% of the business problems that will be encountered.  All languages have
calling facilities, after all, so the lack of intrinsic facilities to handle
everything - e.g., (pending corrections) I don't think any "high-level"
language can directly manipulate I/O gear or handle interrupts, etc. - is no
impediment to its use.  There will come a time when so many such calls must
be made to get the job done as to make it sensible to start using something
else, of course; whether we've reached that point with (for instance) OO or
not seems to be highly up in the air.

My opinions, then: while Cobol is indeed old-fashioned, none of the reasons
for its creation have changed; much of the replacement urge is clamour; and
that Cobol still exists and is still being used for new development (and I'm
NOT going to debate that) is proof enough of its continued vitality.

PL


Howard Brazee <howard@brazee.net> wrote in message
news:r9i9m4t1h77djr80mohj7qopds02u00og6@4ax.com...
> On Wed, 7 Jan 2009 11:50:27 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
> >"Why doesn't COBOL support a Reporting function, or a Communications
> >function, or Object Orientation?" OK, we'll add 'em all.  (Huge effort)
> >Anybody using them? No. Why not? Too hard. And different. I can use
Crystal
> >Reports. If I want to use a network I can use scripting or CICS. And that
OO
> >stuff is a just a fashion blip that will be gone in a year (15 years
> >ago...). It's all a big con. REAL programmers write COBOL....(actually,
they
> >write Fortran in COBOL...) How come some Java guy is relacing me next
month?
> >
> >And we wonder why COBOL is moribund. The community (for the most part;
some
> >are waking up now it is too late...) simply doesn't get it.
>
> So what should the community have done?   What *could* they have done
> to save CoBOL?   Should it have been saved?
>
> Or have times changed so that newer tools fit better to newer needs?
>



0
Reply lacey1 (490) 1/7/2009 7:23:41 PM

It is hare for me to imagine a shop that commonly uses EVALUATE to implement 
decision tables where some programmers understand/know it well and others aren't 
familiar with it.

   *****

Long ago and far away,
  I taught an "entry level COBOL"course at a large (VERY LARGE) utility company 
(with 100's of programmers at that time).  I included Report Writer in the 
course and my graduates saw its uses and  "went out into their departments" and 
used it.

One issue with Report Writer (at least with IBM COBOL's - both OS/VS COBOL where 
it was built-in and as an add-on to VS COBOL II and later compilers) is the fact 
that "debugging aids" are NOT very good.

So when there was a sudden and dramatic increase in the use of RW in production 
code, there were some issues. HOWEVER, as other programmers saw what RW could do 
(especially for "quick and dirty" programs), its use increased significantly - 
not just with programmers I had trained but also with others.

So, why mention this,
  It seems to me that just as a "complex EVALUATE" looks odd (and hard to 
maintain) to a programmer that doesn't know it, so too its USEFULNESS can be 
grasped when programmers who aren't familiar with it, start to see it in use. 
When this happens, its use may increase as the number of programmers (in a shop) 
will increase who are comfortable when they get 2am bug fix calls (if/when such 
things still happen).

Having said all of that, I did do the nested IF program first as I saw that an 
EVALUATE solution would require complex EVALUATEs. I actually think that the 
EVALUATE example is a relatively GOOD example of how EVALUATE works as it shows 
many (certainly not all) of the variations and subtleties in a logic algorithm 
that should be easy for most programmers to follow.  They should understand what 
it is TRYING TO DO and, from this program, they could see how EVALUATE can be 
used to do this type of thing.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message 
news:42j9m411vcag034mphn3pkl9rgbse3b5kq@4ax.com...
> On Tue, 6 Jan 2009 21:12:44 -0600, "William M. Klein"
> <wmklein@nospam.ix.netcom.com> wrote:
>
>>To put it simply,
>>  If EVALUATE is how you like to code, then you will like this code with
>>EVALUATE <G>
>>
>>(Sounds a lot like all our other "if you like "xyz" then "xyz" will look right
>>to you for specific cases).
>
>
> But if EVALUATE (with ALSO) is not how other programmers in your shop
> think, then liking that code isn't sufficient to use it.
>
> -- 
> "In no part of the constitution is more wisdom to be found,
> than in the clause which confides the question of war or peace
> to the legislature, and not to the executive department."
>
> - James Madison 


0
Reply wmklein40 (279) 1/7/2009 7:36:18 PM

Hi Peter,

Very good response from both you and Howard. So I'm taking some time out to 
reply, although some of what I originally wrote was not entirely 
serious...:-)

tlmfru wrote:
> You'll remember the scene of about 15-20 years ago when the PC tsunami
> seemed to be about to take over the IT world, when even mighty IBM was
> reeling under the assault, when the BUNCH (Burrroughs, Univac, NCR,
> CDC, and Honeywell) were effectively eliminated as mainframe
> companies (stipulating that Burroughs/Univac still exist as Unisys,
> but with a vastly changed business model).  At that time there was
> much comment as to what IBM should do.  I remember a series of
> articles in Computerworld (I think) expressing opinions; most of them
> suggested a radical change of course, some going so far as to insist
> that IBM must implement Windows on its machines and abandon its own
> o/s'es!  None of which they did.

I was working for CDC at the timeof the anti-trust suit and remember these 
times very well. I later worked for IBM just after the dismay at losing 
thier leadership (both market and corporate) was beginning to be felt, and I 
think the only thing that saved them was the appointment of a CEO who knew 
what was going on. It's hard to believe that a company whose net profit was 
equivalent in one year to the GNP of New Zealand, could, within a few years, 
be in danger of losing it altogether.

(Some might say this is a lesson MicroSoft would do well to remember...)

>
> How does this relate to the questions expressed below?
>

> Only this: that a great deal of the changes in this industry are
> driven by sincere but not always well-informed enthusiasms.

Absolutely. Seen it many times. COBOL replacing Assembler was one such... 
:-) Instead of developing high level languages which enabled people who 
really weren't programmers to try their hand at it, imagine if they had 
focused on improving the development facilities available in Assembler, 
instead? Programming would have stayed with the professionals, and the 
professionals would have been much more productive.

"properly informed" people would have realised that bringing computer 
programming to the masses was a very bad move and there would have been no 
COBOL or PL/1. Platform transportability could have been achieved by 
low-level code conversion software instead.


  I
> instance acouple of my younger colleagues who goggled with awe at the
> successive announcements of a new chip with 10% more speed; "jeez,
> I've got to have that", they would cry, then be utterly unable to
> understand why I didn't follow suit; or the engineers who were
> learning VB assuring me that they were using a new "event-oriented"
> method of programming which I wouldn't understand,

Ah, the arrogance of youth... :-) There's usually no malice in it. To be 
fair, getting COBOL programmers to understand and embrace the interrupt 
driven model of programming is sometimes difficult, simply because COBOL 
controls everything and is not designed for responding to events. People get 
used to initiating processes and controlling them. When something screams: 
"Attend to me, NOW!" it is a bit of a paradigm shift...

People without the benefit of COBOL experience pick it up very quickly.


> then shamefacedly
> admitting that my advice worked; one real enthusiast declared in
> print that once C replaced Cobol, maintenance costs would immediately
> come down.

Well, they did with the advent of C++. (The OO features mean reuse and less 
maintenance.) I still wouldn't advocate C or C++ as a the preferred choice 
for Business code development; especially not when there is C# which 
combines the best of these worlds with the best of the Java world as well, 
and even throws in a smattering of VB for good measure... :-)
>
> This is not to say that young fogeyism is the way to go or be;
> learning and adaptation is the only way to stay alive.  But there's
> no need to be in a tearing hurry.

I believe a certain German, pondering these things around the early part of 
the 20th century, came to the conclusion that time is not fixed and 
immutable but varies with space and viewpoint. A "tearing hurry" could be 
"unbearably slow" for a different individual... :-)

>Some mainstream languages are less
> suited than others, but of those I wouldn't want to say that any of
> them CAN NOT be used to solve 99% of the business problems that will
> be encountered.

I'd almost agree here. Unfortunately, it isn't just about "business 
problems", it is also about how solutions should be deployed and how 
responsive these solutions are to a rapidly changing business environment. 
If I need some "intelligence" at the Ulan Bator end of the corporate network 
so the boys can keep us updated on the price of mare's milk and spot 
emerging market opportunites, I need a different solution than the one I use 
when I'm talking to Farmer Brown about the price of cheese, for local 
distibution. And if the Mongolians suddenly decide they might go for cows 
instead of horses, I need to be able to amend my solution very quickly.

There was a time when a computer sat in the middle of the office and did its 
thing. Both problems and solutions were simple and relatively static. People 
communicated wth it by means of green screens which it drove by timeslicing 
the power of its processor. (And this was considered a very lucky break, 
after having to provide punch cards and receive information printed on 
screeds of green lineflo...)

That (slightly gentler) time is gone and we are living with a "now" 
generation who have the attention span of a flea, the self-discipline of a 
ferret, and who have been exposed to television advertising since the day 
they were born. OF COURSE, they love what's new. OF COURSE they love 
technology (even though they have no desire to know how or why it works; the 
very few that actually do have some remnant of the curiousity which 
stimulated the Human Race to evolve the way it has, are described as "nerds" 
and "geeks" and prevented from contributing to the gene pool by social mores 
that will ensure no self-respecting member of the opposite sex goes near 
them ...)

So, given this scenario, I can't actually agree that solutions can be 
provided by the mainline languages of yesteryear, to TODAY's problems. Sure 
you can implement an algorithm in almost any language, but that, in and of 
itself, does not necessarily represent a SOLUTION.


> All languages have calling facilities, after all, so
> the lack of intrinsic facilities to handle everything - e.g.,
> (pending corrections) I don't think any "high-level" language can
> directly manipulate I/O gear or handle interrupts, etc. - is no
> impediment to its use.

So, you are advocating using these languages as "glue" or a "Framework" 
where they can simply call out for assistance in the areas they are not good 
at? I think there is something in that. I used COBOL in this capacity for a 
number of years, but now there are simply better tools available.
(See response to Howard, below.)

>There will come a time when so many such
> calls must be made to get the job done as to make it sensible to
> start using something else, of course; whether we've reached that
> point with (for instance) OO or not seems to be highly up in the air.
>
> My opinions, then: while Cobol is indeed old-fashioned, none of the
> reasons for its creation have changed; much of the replacement urge
> is clamour; and that Cobol still exists and is still being used for
> new development (and I'm NOT going to debate that) is proof enough of
> its continued vitality.

OK, let's look at those one by one...

1."none of the reasons for its creation have changed".  COBOL arose out of a 
fear by customers that they were spending large amounts of money to develop 
computer systems which locked them in to a particular vendor's platform. 
Developing lines of code in Assembler is just as expensive as it is in 
COBOL, and knowing that if you ever have a disagreement with your hardware 
vendor, there is nothing you can do about it, doesn't help the situation. 
The idea of "platform independence" gained very rapid acceptance and by the 
early 1960s it was like the "Holy Grail" of computing.
Vendors realised that providing a "high-level" language, was going to be a 
major sales clincher and they were all working flat-out to be first. The 
CODASYL formalised it and got the major players to sit around a table (Grace 
Hopper and the DOD deserve some credit for driving this) and even contribute 
various ideas and existing software. It didn't take vendors long to realise 
that they could still make "migration" away from their hardware very 
difficult by providing and encouraging the use of "extensions" to the early 
standards, and they vied with each other to provide the most "useful" 
extensions. COBOL was NEVER about a language for implementing algorithms 
(Algol and Jovial were already around for that...); it's primary purpose was 
to provide platform independence, then to remove the mystery attached to 
Assembler programming, and improve productivity and ease of maintenance 
(hopefully...)

Is that like today? I don't think so. Platform independence is not a 
problem; we use networks with protocols recognised by all the attached 
hardware. Removal of mystery? Today's generation accept computers as easily 
as they do cell phones. (I was amused yesterday when a friend who is in her 
sixties was looking for GOOGLE on a computer that didn't belong to her. Her 
19 month old grand-daughter obligingly picked up the mouse and opened the 
Browser for her...) Ease of maintenance? What maintenance? Write components 
and reuse them. Productivity? I can write C# at approximately 6 times the 
rate I could write COBOL (NOT based on lines of code, but on results 
achieved. Powerful, more compact languages with highly intelligent IDEs are 
simply quicker and easier to write...)

2."much of the replacement urge is clamour" Yes, there is some truth in 
this. Marketing is now, and has always been, a powerful shaper of demand for 
computer software. I think you have to ask yourself WHO is clamouring?  If 
it is the business, then it's time they got some service and maybe that 
means it is time for IT to review what it does and how effective it is. 
Without clamouring for it, but having walked the road myself, I can say that 
the replacement tools are many times better. And that is not an opinion 
based on Marketing. Had I known 15 years ago what I have learned since, I 
would have moved off COBOL then and there.

3." ... that Cobol still exists and is still being used for new development 
(and I'm NOT going to debate that) is proof enough of its continued 
vitality."  I respect your desire not to debate this, and anyway, you are 
correct that some development is continuing in some places in COBOL. I would 
only make the following comments:

1. The new development in COBOL, as a percentage of ALL new development 
going on in the world, is probably less than 5%. 30 Years ago it was over 
80%. That is hardly an indication of vitality.

2. Some (many?) of the people carrying out this development are doing so 
because they see no choice.

3. Some (many?) of the people carrying out this development have future 
plans to move off COBOL as soon as they can without major risk to their 
business.

COBOL remains an ideal tool for batch processing development, in centralised 
environments (The days may be numbered for such environments and when they 
go, so will COBOL...). It simply cannot compete with parallel servers 
running multiple instances of  object classes for online access.


>>
>> So what should the community have done?   What *could* they have done
>> to save CoBOL?   Should it have been saved?
>>
>> Or have times changed so that newer tools fit better to newer needs?

Given my extemporary rant, that is a very fair question Howard.

In retrospect, I believe COBOL has been overtaken by events, and is no 
longer relevant. It's a pity; I loved it as a language, and it served me 
well for decades.  So, I have to answer "yes" to your last question. 
Emphatically. The fact is that all of the new development I have been doing 
has not suffered because I'm not using COBOL. As a tool, I don't miss it at 
all; on the occasions when I need to go back to it for someone else, I smile 
at how primitive it seems and how primitive the IDE is. It irritates me to 
know I spent years building stuff with tools that were terrible, simply 
because I didn't know any better. (However, that is certainly no fault of, 
or reflection on, COBOL as a language.)

Having answered your last question first, and recognised that any of the 
actions described beow would simply have extended the life of COBOL, not 
saved it, let's look at the other 3 questions...

1. "So what should the community have done? "

They should have been less resistant to change and less insular in their 
approach to IT in general. Object Orientation should have been embraced and 
become a normal part of every COBOL site.(cf with Java sites...) This alone 
would have brought COBOL onto a level playing field with everything else, 
and guaranteed its survival for minimum another 10 years. It would also have 
prevented the need for Java to step in and take over the role of OO language 
of choice on these sites. (Actually, Java is a better OO language than OO 
COBOL, but if the COBOL community had embraced OO COBOL, there would have 
been no need for it. The difference is not SO enormous that you would 
replace OO COBOL with Java...)

At the same time they should have been investing in training people into 
different and better development methodologies, using OO approaches. More 
responsive JAD/Active type development with better tools and better results.

2. "What *could* they have done to save CoBOL?"

For standard COBOL, nothing. The underlying paradigm is superseded by 
Classes and Objects. OO COBOL would have had a chance (I used it effectively 
for nearly 10 years) if there had been support for the IDEA (see 1 above).

3."Should it have been saved?"

At the time, I would have said "yes" (at least OO COBOL), but with hindsight 
I think not. Even OO COBOL is not as capable as Java or C# (or even VB.NET)

The only thing people can do now is devise a strategy for moving off it.

Unfortunately, because the investments in training weren't made, there are 
going to be some painful migrations. It isn't enough to "Move COBOL to the 
Network." The Network is comprised of objects and layers. Running standard 
COBOL in .NET is like running 1401 compatibility mode on a z/90, like 
running your Ferrari on a bag of Methane, or attaching an F16 to a hot air 
ballon...

For COBOL to be useful on the Network it needs to be refactored into 
objects, based around functions. OO COBOL is ideal for this, or the new CLR 
emitting .NET COBOL compilers could be used. Either way, the existing code 
needs to be refactored and rewrapped before runnng it on .NET.  Once you 
actually DO this, you have the keys to the Kingdom. Now you can EASILY move 
off COBOL (or not), mix in other languages or whatever strategy makes most 
sense, given your environment and resources.

I'm planning to retire in about two years (some people say I should have 
done so years ago...:-)) but as long as I enjoy what I do, I'd like to keep 
doing it... I'm finding long hours and stress more difficult as I get older 
so I'd like to just be at home and tinker with stuff that takes my fancy. 
The point is that I'll probably retire before COBOL does and that is somehow 
comforting... :-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/8/2009 2:17:05 AM

Howard Brazee wrote:
> On Wed, 7 Jan 2009 10:19:50 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>> I've done this many times.   It's quick and easy and maintenance
>>> programmers can understand it.
>>
>> Done what? Date Validation? Bill's Date validation? Alain's date
>> validation? Used a function approach? Used a date component?
>>
>> Without a quote, I have no idea exactly what you are referring to,
>> Howard.
>
> Used CoBOL code to do the validation he wrote.    Simple stuff like
> that doesn't need to be in copymembers, subroutines, nor objects, and
> isolation makes debugging and upgrading easy.

Ah, thank you.

So would you just rewrite this stuff every time you need it?

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/8/2009 2:34:06 AM

On Jan 8, 3:17=A0pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Hi Peter,
>
> Very good response from both you and Howard. So I'm taking some time out =
to
> reply, although some of what I originally wrote was not entirely
> serious...:-)
>
> tlmfru wrote:
> > You'll remember the scene of about 15-20 years ago when the PC tsunami
> > seemed to be about to take over the IT world, when even mighty IBM was
> > reeling under the assault, when the BUNCH (Burrroughs, Univac, NCR,
> > CDC, and Honeywell) were effectively eliminated as mainframe
> > companies (stipulating that Burroughs/Univac still exist as Unisys,
> > but with a vastly changed business model). =A0At that time there was
> > much comment as to what IBM should do. =A0I remember a series of
> > articles in Computerworld (I think) expressing opinions; most of them
> > suggested a radical change of course, some going so far as to insist
> > that IBM must implement Windows on its machines and abandon its own
> > o/s'es! =A0None of which they did.
>
> I was working for CDC at the timeof the anti-trust suit and remember thes=
e
> times very well. I later worked for IBM just after the dismay at losing
> thier leadership (both market and corporate) was beginning to be felt, an=
d I
> think the only thing that saved them was the appointment of a CEO who kne=
w
> what was going on. It's hard to believe that a company whose net profit w=
as
> equivalent in one year to the GNP of New Zealand, could, within a few yea=
rs,
> be in danger of losing it altogether.
>
> (Some might say this is a lesson MicroSoft would do well to remember...)

While some will hope that they don't learn from the past and will
repeat it themselves.


> > How does this relate to the questions expressed below?
>
> > Only this: that a great deal of the changes in this industry are
> > driven by sincere but not always well-informed enthusiasms.
>
> Absolutely. Seen it many times. COBOL replacing Assembler was one such...
> :-) Instead of developing high level languages which enabled people who
> really weren't programmers to try their hand at it, imagine if they had
> focused on improving the development facilities available in Assembler,
> instead? Programming would have stayed with the professionals, and the
> professionals would have been much more productive.
>
> "properly informed" people would have realised that bringing computer
> programming to the masses was a very bad move and there would have been n=
o
> COBOL or PL/1. Platform transportability could have been achieved by
> low-level code conversion software instead.
>
> =A0 I
>
> > instance acouple of my younger colleagues who goggled with awe at the
> > successive announcements of a new chip with 10% more speed; "jeez,
> > I've got to have that", they would cry, then be utterly unable to
> > understand why I didn't follow suit; or the engineers who were
> > learning VB assuring me that they were using a new "event-oriented"
> > method of programming which I wouldn't understand,
>
> Ah, the arrogance of youth... :-) There's usually no malice in it. To be
> fair, getting COBOL programmers to understand and embrace the interrupt
> driven model of programming is sometimes difficult, simply because COBOL
> controls everything and is not designed for responding to events. People =
get
> used to initiating processes and controlling them. When something screams=
:
> "Attend to me, NOW!" it is a bit of a paradigm shift...
>
> People without the benefit of COBOL experience pick it up very quickly.
>
> > then shamefacedly
> > admitting that my advice worked; one real enthusiast declared in
> > print that once C replaced Cobol, maintenance costs would immediately
> > come down.
>
> Well, they did with the advent of C++. (The OO features mean reuse and le=
ss
> maintenance.) I still wouldn't advocate C or C++ as a the preferred choic=
e
> for Business code development; especially not when there is C# which
> combines the best of these worlds with the best of the Java world as well=
,
> and even throws in a smattering of VB for good measure... :-)

The issue of maintenance costs was the subject of an infamous
Datamation article in the mid 80s. They surveyed various development
departments and identified the language used and the time spent on
'new' and 'maintenace'. Of course most in-house and packaged business
software has 'maintenance' as developments needed to meet changing
business requirements, while non-business applications in C tended to
only refer to bug fixing as 'maintenance' and feature enhancement as
'new development'

The conclusion of the article that if C was used, rather than Cobol,
then costs would be slashed because maintenance would disappear was
grossly flawed. The maintenance requirement was a function of the
application type, not of the language.

Even your claim that OO reduces maintenance is flawed. It may do so
because one does not change an existing class (maintenance) but one
writes a _new_ class that inherits from the old and has the
differences catered for. Claiming that this is therefore 'less
maintenance' fails to acknowledge that it arrives at the same result
after much the same effort (but can eventually lead to inheritance
hell).


> > This is not to say that young fogeyism is the way to go or be;
> > learning and adaptation is the only way to stay alive. =A0But there's
> > no need to be in a tearing hurry.
>
> I believe a certain German, pondering these things around the early part =
of
> the 20th century, came to the conclusion that time is not fixed and
> immutable but varies with space and viewpoint. A "tearing hurry" could be
> "unbearably slow" for a different individual... :-)
>
> >Some mainstream languages are less
> > suited than others, but of those I wouldn't want to say that any of
> > them CAN NOT be used to solve 99% of the business problems that will
> > be encountered.
>
> I'd almost agree here. Unfortunately, it isn't just about "business
> problems", it is also about how solutions should be deployed and how
> responsive these solutions are to a rapidly changing business environment=
..
> If I need some "intelligence" at the Ulan Bator end of the corporate netw=
ork
> so the boys can keep us updated on the price of mare's milk and spot
> emerging market opportunites, I need a different solution than the one I =
use
> when I'm talking to Farmer Brown about the price of cheese, for local
> distibution. And if the Mongolians suddenly decide they might go for cows
> instead of horses, I need to be able to amend my solution very quickly.
>
> There was a time when a computer sat in the middle of the office and did =
its
> thing. Both problems and solutions were simple and relatively static. Peo=
ple
> communicated wth it by means of green screens which it drove by timeslici=
ng
> the power of its processor. (And this was considered a very lucky break,
> after having to provide punch cards and receive information printed on
> screeds of green lineflo...)

Actually many computers still do that, except the screens are multi-
coloured, and they may be in the middle of some other office.


> That (slightly gentler) time is gone and we are living with a "now"
> generation who have the attention span of a flea, the self-discipline of =
a
> ferret, and who have been exposed to television advertising since the day
> they were born. OF COURSE, they love what's new. OF COURSE they love
> technology (even though they have no desire to know how or why it works; =
the
> very few that actually do have some remnant of the curiousity which
> stimulated the Human Race to evolve the way it has, are described as "ner=
ds"
> and "geeks" and prevented from contributing to the gene pool by social mo=
res
> that will ensure no self-respecting member of the opposite sex goes near
> them ...)
>
> So, given this scenario, I can't actually agree that solutions can be
> provided by the mainline languages of yesteryear, to TODAY's problems. Su=
re
> you can implement an algorithm in almost any language, but that, in and o=
f
> itself, does not necessarily represent a SOLUTION.
>
> > All languages have calling facilities, after all, so
> > the lack of intrinsic facilities to handle everything - e.g.,
> > (pending corrections) I don't think any "high-level" language can
> > directly manipulate I/O gear or handle interrupts, etc. - is no
> > impediment to its use.
>
> So, you are advocating using these languages as "glue" or a "Framework"
> where they can simply call out for assistance in the areas they are not g=
ood
> at? I think there is something in that. I used COBOL in this capacity for=
 a
> number of years, but now there are simply better tools available.
> (See response to Howard, below.)
>
> >There will come a time when so many such
> > calls must be made to get the job done as to make it sensible to
> > start using something else, of course; whether we've reached that
> > point with (for instance) OO or not seems to be highly up in the air.
>
> > My opinions, then: while Cobol is indeed old-fashioned, none of the
> > reasons for its creation have changed; much of the replacement urge
> > is clamour; and that Cobol still exists and is still being used for
> > new development (and I'm NOT going to debate that) is proof enough of
> > its continued vitality.
>
> OK, let's look at those one by one...
>
> 1."none of the reasons for its creation have changed". =A0COBOL arose out=
 of a
> fear by customers that they were spending large amounts of money to devel=
op
> computer systems which locked them in to a particular vendor's platform.
> Developing lines of code in Assembler is just as expensive as it is in
> COBOL, and knowing that if you ever have a disagreement with your hardwar=
e
> vendor, there is nothing you can do about it, doesn't help the situation.
> The idea of "platform independence" gained very rapid acceptance and by t=
he
> early 1960s it was like the "Holy Grail" of computing.
> Vendors realised that providing a "high-level" language, was going to be =
a
> major sales clincher and they were all working flat-out to be first. The
> CODASYL formalised it and got the major players to sit around a table (Gr=
ace
> Hopper and the DOD deserve some credit for driving this) and even contrib=
ute
> various ideas and existing software. It didn't take vendors long to reali=
se
> that they could still make "migration" away from their hardware very
> difficult by providing and encouraging the use of "extensions" to the ear=
ly
> standards, and they vied with each other to provide the most "useful"
> extensions. COBOL was NEVER about a language for implementing algorithms
> (Algol and Jovial were already around for that...); it's primary purpose =
was
> to provide platform independence, then to remove the mystery attached to
> Assembler programming, and improve productivity and ease of maintenance
> (hopefully...)
>
> Is that like today? I don't think so. Platform independence is not a
> problem; we use networks with protocols recognised by all the attached
> hardware.

'Platform independence' _is_ still a problem, mainly because Microsoft
regards it as meaning 'both Windows XP _and_ Windows Vista' and make
subtle undocumented changes to attempt to lock in their products and
lock out every one else's, as well as their older products.

This is the reason they introduce new .doc formats with almost every
release, they want to force everyone to buy the new versions and to
eliminate non-microsoft products.

This is why they introduced IE incompatibilities and made Frontpage
and IIS generate IE-only http.

Networking with SMB only remains cross platform because the Samba team
can reverse engineer all the changes that MS introduce.

> Removal of mystery? Today's generation accept computers as easily
> as they do cell phones. (I was amused yesterday when a friend who is in h=
er
> sixties was looking for GOOGLE on a computer that didn't belong to her. H=
er
> 19 month old grand-daughter obligingly picked up the mouse and opened the
> Browser for her...) Ease of maintenance? What maintenance? Write componen=
ts
> and reuse them. Productivity? I can write C# at approximately 6 times the
> rate I could write COBOL (NOT based on lines of code, but on results
> achieved. Powerful, more compact languages with highly intelligent IDEs a=
re
> simply quicker and easier to write...)
>
> 2."much of the replacement urge is...
>
> read more =BB

0
Reply riplin (4127) 1/8/2009 4:38:40 AM

In article <6sl610F6vlsbU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>tlmfru wrote:

[snip]

>> Only this: that a great deal of the changes in this industry are
>> driven by sincere but not always well-informed enthusiasms.
>
>Absolutely. Seen it many times. COBOL replacing Assembler was one such... 
>:-) Instead of developing high level languages which enabled people who 
>really weren't programmers to try their hand at it, imagine if they had 
>focused on improving the development facilities available in Assembler, 
>instead? Programming would have stayed with the professionals, and the 
>professionals would have been much more productive.

.... and the cry of 'I know that's what I *told* you but it's not what I 
*want*' would never have been heard... and I am the King of England, too.

>
>"properly informed" people would have realised that bringing computer 
>programming to the masses was a very bad move and there would have been no 
>COBOL or PL/1. Platform transportability could have been achieved by 
>low-level code conversion software instead.

'Bringing computer programming to the masses' was a matter - at least in 
the Corporate World - of allocating resources.  Some might wonder who is 
responsible for such things... the blade of sarcase might have multiple 
edges.

DD

0
Reply docdwarf (6044) 1/8/2009 10:35:29 AM

On Thu, 8 Jan 2009 15:17:05 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> print that once C replaced Cobol, maintenance costs would immediately
>> come down.
>
>Well, they did with the advent of C++. (The OO features mean reuse and less 
>maintenance.) I still wouldn't advocate C or C++ as a the preferred choice 
>for Business code development; especially not when there is C# which 
>combines the best of these worlds with the best of the Java world as well, 
>and even throws in a smattering of VB for good measure... :-)

Do we have good evidence that maintenance costs immediately (or
delayed) went down?   

If so, did it go down the same way as TV repair costs went down - we
no longer repair TVs, we replace them?

On the other hand, if we are getting more benefit from IS, it isn't
easy to evaluate whether the new tools made our costs go up more
slowly than the old tools would have.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/8/2009 2:31:38 PM

The big advantage in having a dominant tool (maybe CoBOL on IBM
mainframes) is that we can hire someone from the next company over who
is skilled in using it.

But there are some significant advantages in having a bunch of tools,
even if some of these require training.

Some of the less obvious advantages are:

1.  When we make mistakes, we can more easily change directions.   An
example of this is our new security requirements.   While it was
difficult for Microsoft to change directions (they needed to be all
things for all people), other companies have been able to redesign
their IS flow for this requirement.

2.  We can buy 3rd party products that weren't written in our
language.   We don't need to be able to maintain them at the code
level.   Heck, the high-security mainframe data warehouse can be
thought of as a black-box object.

3.  Competition is more free and varied.   This also means that we are
less vulnerable to evolutionary dead ends (think banana plague).

Question:  Which is used more - CoBOL or PeopleCode?   
Answer:   It doesn't matter anymore.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/8/2009 2:56:28 PM

On Thu, 8 Jan 2009 15:34:06 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> Used CoBOL code to do the validation he wrote.    Simple stuff like
>> that doesn't need to be in copymembers, subroutines, nor objects, and
>> isolation makes debugging and upgrading easy.
>
>Ah, thank you.
>
>So would you just rewrite this stuff every time you need it?

When it's simple enough, sure.   Sometimes it is easier and quicker to
write a simple piece of code than to find the appropriate library code
someone else wrote, much less to verify that it does what you want.

I suppose we can create libraries for anything - including a library
member to increment a counter.   But nobody does that, we all have a
level where it's quicker and easier to put the code in the program.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/8/2009 3:04:22 PM

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
news:6sl70sF6srkuU1@mid.individual.net...
> So would you just rewrite this stuff every time you need it?

That would be considered the "traditional" method in many, many shops, Pete.

MCM



0
Reply mmattias (364) 1/8/2009 3:42:50 PM

On Thu, 8 Jan 2009 09:42:50 -0600, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>> So would you just rewrite this stuff every time you need it?
>
>That would be considered the "traditional" method in many, many shops, Pete.

Even without tradition, we all have levels where we should decide
whether a code element is worth separating out (to copy members,
called programs, objects, or whatever).

I've seen a copy member which only stated that this program has been
converted to Y2K.   Typing in the copy statement was no less work as
typing "Y2K ready".

For someone who has to look up how to verify dates, it might be
quicker and easier to look up the library date routine, and adjust his
program to use it.     But for me writing the date routine is the more
trivial of those two options.   It's not as though two programmers
will have incompatible date check routines (unless that was part of
the business requirements).

And I might do it differently if my program needed to do something
unusual with that date.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/8/2009 4:37:03 PM

In article <Otp9l.4621$jZ1.1698@flpi144.ffdc.sbc.com>,
Michael Mattias <mmattias@talsystems.com> wrote:
>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message 
>news:6sl70sF6srkuU1@mid.individual.net...
>> So would you just rewrite this stuff every time you need it?
>
>That would be considered the "traditional" method in many, many shops, Pete.

If 'writing a new component to do a modified function' is not considered 
rewriting then the 'tradition' seems to encompass even more places.
DD

0
Reply docdwarf (6044) 1/8/2009 4:50:32 PM

<docdwarf@panix.com> wrote in message news:gk5aso$nj4$1@reader1.panix.com...
> In article <Otp9l.4621$jZ1.1698@flpi144.ffdc.sbc.com>,
> Michael Mattias <mmattias@talsystems.com> wrote:
>>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>>news:6sl70sF6srkuU1@mid.individual.net...
>>> So would you just rewrite this stuff every time you need it?
>>
>>That would be considered the "traditional" method in many, many shops, 
>>Pete.
>
> If 'writing a new component to do a modified function' is not considered
> rewriting then the 'tradition' seems to encompass even more places.


C'mon, Doc, I'm just doing my bi-annual whine decrying the lack of foresight 
among programmers and analysts and the general failure of so-called 
'managers' to undserstand the world will still exist fter this quarter's 
numbers come out.

You know what we need to weed out all this cruft?  A good recession, that's 
what!

MCM






0
Reply mmattias (364) 1/8/2009 5:17:32 PM

In article <Fwq9l.1706$FM6.1577@flpi143.ffdc.sbc.com>,
Michael Mattias <mmattias@talsystems.com> wrote:
>
><docdwarf@panix.com> wrote in message news:gk5aso$nj4$1@reader1.panix.com...
>> In article <Otp9l.4621$jZ1.1698@flpi144.ffdc.sbc.com>,
>> Michael Mattias <mmattias@talsystems.com> wrote:
>>>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>>>news:6sl70sF6srkuU1@mid.individual.net...
>>>> So would you just rewrite this stuff every time you need it?
>>>
>>>That would be considered the "traditional" method in many, many shops, 
>>>Pete.
>>
>> If 'writing a new component to do a modified function' is not considered
>> rewriting then the 'tradition' seems to encompass even more places.
>
>
>C'mon, Doc, I'm just doing my bi-annual whine decrying the lack of foresight 
>among programmers and analysts and the general failure of so-called 
>'managers' to undserstand the world will still exist fter this quarter's 
>numbers come out.

Was this part of the schedule?  My apologies, Mr Mattias, I didn't know I 
was supposed to keep your timesheets on such matters.  On a more-or-less 
serious note... I've worked in more than one shop where the following was 
commonplace:

The manager would come to the programmer and say 'Marketing wants a 
report, nothing special... just all the customers in the Northern Division 
who have purchased more than $n of stuff in the last quarter.'

The programmer would say 'No problem'... and code something that did a 
sequential read through the A615281-CUST-MAST KSDS; if the DIV-CODE had a 
first character of 'N' and the YTD-PURCH field was > $n then a detail-line 
was generated for a report.

Code, test, peer-review, submit to Testing, get signed off and implemented 
to Prod to be run as scheduled/ad hoc.

A while later the same manager would go back to the same programmer and 
say 'Remember that BIGCUST program you wrote?  Marketing called, they want 
the same thing for the Eastern Division.'

The programmer would then copy the first program, change the test of 
DIV-CODE from 'N' to 'E'... test, peer-review, submit to Testing, get 
signed off and implemented to Prod to be run as scheduled/ad hoc.

I came on board, such a request was made of me... and I cobbled together a 
set of SyncSort/DFSORT control statements to do the same thing.  It was 
rejected before it got to peer review; the manager said 'Nobody here 
understands that stuff, just use COBOL.'

I offered to put together a cheat-sheet that would make clear the more 
basic functions of the utility... and was told 'Nobody here wants that, 
just do it in COBOL.'

So... I grabbed a copy of a version of BIGCUST and used a parm passed by 
JCL... and was told by a Old Hand that this was counter-productive because 
one of the ways a coder's productivity (and status and raises) was judged 
was by the amount of code he had his fingers in.  'Louie?  He's good, he 
put together BIGCUST for the Northern Division and BIGCUSTE for the 
Eastern Division and BIGCUSTW for the Western Division...' etc.

This attitude was encouraged by management, of course, because the more 
'stuff' they had to deal with the more important they were... they needed 
more DASD, they needed more CPU, they needed more programmers... and their 
budgets grew and with larger budgets came larger salaries and more status.

What glory is there in using a system utility and different sets of 
control statements?  

Fortunately... well, not 'fortunately', it is by intention and effort... I 
am a consultant/contractor/hired gun, I get cash, up front, and leave 
worrying about the Corner Office to others.  As for the rest of the 
organisation something about 'a fish rots from the head' comes to mind.

>
>You know what we need to weed out all this cruft?  A good recession, that's 
>what!

There have been recessions before... and here we are, today, dealing with 
yet the same.  One might think that someone would have noticed how little 
new there is under the sun.

DD
0
Reply docdwarf (6044) 1/8/2009 6:47:48 PM

I do enjoy these historical matters!

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:6sl610F6vlsbU1@mid.individual.net...
> Hi Peter,
>
> Very good response from both you and Howard. So I'm taking some time out
to
> reply, although some of what I originally wrote was not entirely
> serious...:-)
>
> >
> > How does this relate to the questions expressed below?
> >
>
> > Only this: that a great deal of the changes in this industry are
> > driven by sincere but not always well-informed enthusiasms.
>
> Absolutely. Seen it many times. COBOL replacing Assembler was one such...
> :-) Instead of developing high level languages which enabled people who
> really weren't programmers to try their hand at it, imagine if they had
> focused on improving the development facilities available in Assembler,
> instead? Programming would have stayed with the professionals, and the
> professionals would have been much more productive.
>
> "properly informed" people would have realised that bringing computer
> programming to the masses was a very bad move and there would have been no
> COBOL or PL/1. Platform transportability could have been achieved by
> low-level code conversion software instead.
>

Tongue-in-cheek here, of course.  Although there was definite resistance to
the new thing (Cobol) most of the older programmers I encountered at the
time were eager converts once they found out how easy it was and how much
more they could get done.  And there was a sizeable group that positively
reveled in it from the get-go as they simply weren't up to the intellectual
requirements of Assembler.

Much more recently, in the late 90's in fact, I came across a proposal to
turn the users loose on certain programming requirements - each new product
the company introduced required a new editing and pricing program, and the
burden was getting away from I/T.  The language was PRIME Infobasic - a
fairly able and productive thing but very labour-intensive and not at all
easy to grasp for newbies in the I/T dep't, let alone non-programming users.
(One of my sayings is "you can't get away from screwed-up thinking.  The
decision to go with one program per product is an example; although a
table-driven method had been worked out at that time as well,; I never did
find out the rationale).  So your scenario above isn't a pure phantasy after
all!

>
> Ah, the arrogance of youth... :-) There's usually no malice in it. To be
> fair, getting COBOL programmers to understand and embrace the interrupt
> driven model of programming is sometimes difficult, simply because COBOL
> controls everything and is not designed for responding to events. People
get
> used to initiating processes and controlling them. When something screams:
> "Attend to me, NOW!" it is a bit of a paradigm shift...
>
> People without the benefit of COBOL experience pick it up very quickly.
>
>
>

Now that's a bit of a canard, you know.  Positing a screen-handler that the
application programmer needn't worry about, then event-oriented or
interrupt-driven programming is straightforward in Cobol.  You fire out your
initial screen and set up the flags to indicate what you did, then wait for
a response.  So long as the response info includes all identifying info -
last key pressed, what screen was in control, what information was entered -
then the program will always know what to do.  There will be processing
particular to the screen in control, there may be successor screens to set
up. file i/o to do, termination, etc.  But in no case is the list of
possible events very large: I can't imagine why an application program would
care that the window was resized or moved; that's the screen handler's
business.  The program can always relate its previous state to the current
action required.  Your statement above that Cobol controls everything is
misleading in this case: all it's doing is presenting the info and waiting
for the user to do something, then responding to that something.  There is
no absolute sequence of events.  It's true that it's more difficult in Cobol
as opposed to VB or anything else, because many of the details that are
under the hood in VB etc. must be explixitly done in Cobol.  I've been doing
that sort of thing since about 1973; once I understood why the program was
always resumed in the same paragraph (instead of immediately following where
it released control to the screen handler) I had no conceptual trouble at
all; the problems were in the details.  Using other languages, as a result,
was straightforward too, although I was bedeviled by the different ways  the
various languages treated the same event.

(screen = window in the above).

PL






0
Reply lacey1 (490) 1/8/2009 6:49:00 PM

Howard Brazee wrote:
> On Thu, 8 Jan 2009 09:42:50 -0600, "Michael Mattias"
> <mmattias@talsystems.com> wrote:
>
>>> So would you just rewrite this stuff every time you need it?
>>
>> That would be considered the "traditional" method in many, many
>> shops, Pete.
>
> Even without tradition, we all have levels where we should decide
> whether a code element is worth separating out (to copy members,
> called programs, objects, or whatever).
>
> I've seen a copy member which only stated that this program has been
> converted to Y2K.   Typing in the copy statement was no less work as
> typing "Y2K ready".
>

Which makes it easy to scan the entire library looking for those modules 
that HAVEN'T been converted. 


0
Reply heybub (535) 1/8/2009 7:34:15 PM

When I used to work with and for large IBM mainframe shops, they usually did 
have a callable date routine.  However, besides just checking for "valid dates" 
it was the common (company wide) routine that one used to determine things like:

 - what business week of the year is it
 - is it a legal state holiday? banking holiday? federal holiday?
 - is it a month-end? quarter-end? year-end processing date
 - end-of-payroll for except or non-except employees
 - etc, etc

and lots of other "company-specific_ information.

Such routines WERE updated regularly; certainly at the beginning/end of a 
financial year, but also when various business or legal "thingies" changed.

Certainly, this COULD (using modern paradigms) be a "component" - but I don't 
think that those types of shops would have considered such routines "stable" and 
replace-rather-than-modify eligible.  I suppose there were parts of the logic 
that were stable and those could have been "modularized" into components 
accessed by the main company date routine, but I am not certain how much that 
would have gained.  Many of these routines were (eventually) modified to be 
external table-driven. However (again speaking for IBM mainframe environments), 
the overhead of reading an external table (even once per transaction or 
application) was often too great to meet performance requirements.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message 
news:pdacm4lqntd9pamds09vpv97sa3anlunrk@4ax.com...
> On Thu, 8 Jan 2009 09:42:50 -0600, "Michael Mattias"
> <mmattias@talsystems.com> wrote:
>
>>> So would you just rewrite this stuff every time you need it?
>>
>>That would be considered the "traditional" method in many, many shops, Pete.
>
> Even without tradition, we all have levels where we should decide
> whether a code element is worth separating out (to copy members,
> called programs, objects, or whatever).
>
> I've seen a copy member which only stated that this program has been
> converted to Y2K.   Typing in the copy statement was no less work as
> typing "Y2K ready".
>
> For someone who has to look up how to verify dates, it might be
> quicker and easier to look up the library date routine, and adjust his
> program to use it.     But for me writing the date routine is the more
> trivial of those two options.   It's not as though two programmers
> will have incompatible date check routines (unless that was part of
> the business requirements).
>
> And I might do it differently if my program needed to do something
> unusual with that date.
>
> -- 
> "In no part of the constitution is more wisdom to be found,
> than in the clause which confides the question of war or peace
> to the legislature, and not to the executive department."
>
> - James Madison 


0
Reply wmklein40 (279) 1/8/2009 10:18:52 PM

William M. Klein wrote:
> When I used to work with and for large IBM mainframe shops, they usually did 
> have a callable date routine.  However, besides just checking for "valid dates" 
> it was the common (company wide) routine that one used to determine things like:
> 
>  - what business week of the year is it
>  - is it a legal state holiday? banking holiday? federal holiday?
>  - is it a month-end? quarter-end? year-end processing date
>  - end-of-payroll for except or non-except employees
>  - etc, etc
> 
> and lots of other "company-specific_ information.
> 
> Such routines WERE updated regularly; certainly at the beginning/end of a 
> financial year, but also when various business or legal "thingies" changed.
> (snip)

Another example would tables of start/end dates for USA Daylight Saving 
Time, or holidays in non-USA countries.

> Certainly, this COULD (using modern paradigms) be a "component" - but I don't 
> think that those types of shops would have considered such routines "stable" and 
> replace-rather-than-modify eligible.  I suppose there were parts of the logic 
> that were stable and those could have been "modularized" into components 
> accessed by the main company date routine, but I am not certain how much that 
> would have gained.  Many of these routines were (eventually) modified to be 
> external table-driven. However (again speaking for IBM mainframe environments), 
> the overhead of reading an external table (even once per transaction or 
> application) was often too great to meet performance requirements.
> 

Well, I have supported systems where the table of USA Daylight Saving 
Time dates was hard-coded in the program, so performance was certainly 
good.  It's probably not considered a good practice, but it wasn't that 
difficult to maintain.

-- 
http://arnold.trembley.home.att.net/
0
Reply arnold.trembley (268) 1/9/2009 5:55:52 AM

Howard Brazee wrote:
> On Thu, 8 Jan 2009 15:34:06 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
> 
>>> Used CoBOL code to do the validation he wrote.    Simple stuff like
>>> that doesn't need to be in copymembers, subroutines, nor objects, and
>>> isolation makes debugging and upgrading easy.
>> Ah, thank you.
>>
>> So would you just rewrite this stuff every time you need it?
> 
> When it's simple enough, sure.   Sometimes it is easier and quicker to
> write a simple piece of code than to find the appropriate library code
> someone else wrote, much less to verify that it does what you want.
> 
> I suppose we can create libraries for anything - including a library
> member to increment a counter.   But nobody does that, we all have a
> level where it's quicker and easier to put the code in the program.
> 

I have seen cases where programmers code their own routines because they 
don't know a library routine is available, or they didn't have the tools 
to search for them.  But that was a system written in C, not COBOL.

-- 
http://arnold.trembley.home.att.net/
0
Reply arnold.trembley (268) 1/9/2009 5:58:23 AM

Richard wrote:
> On Jan 8, 3:17 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Hi Peter,
>>
>> Very good response from both you and Howard. So I'm taking some time
>> out to reply, although some of what I originally wrote was not
>> entirely serious...:-)
>>
>> tlmfru wrote:
>>> You'll remember the scene of about 15-20 years ago when the PC
>>> tsunami seemed to be about to take over the IT world, when even
>>> mighty IBM was reeling under the assault, when the BUNCH
>>> (Burrroughs, Univac, NCR, CDC, and Honeywell) were effectively
>>> eliminated as mainframe companies (stipulating that
>>> Burroughs/Univac still exist as Unisys, but with a vastly changed
>>> business model). At that time there was much comment as to what IBM
>>> should do. I remember a series of articles in Computerworld (I
>>> think) expressing opinions; most of them suggested a radical change
>>> of course, some going so far as to insist that IBM must implement
>>> Windows on its machines and abandon its own o/s'es! None of which
>>> they did.
>>
>> I was working for CDC at the timeof the anti-trust suit and remember
>> these times very well. I later worked for IBM just after the dismay
>> at losing thier leadership (both market and corporate) was beginning
>> to be felt, and I think the only thing that saved them was the
>> appointment of a CEO who knew what was going on. It's hard to
>> believe that a company whose net profit was equivalent in one year
>> to the GNP of New Zealand, could, within a few years, be in danger
>> of losing it altogether.
>>
>> (Some might say this is a lesson MicroSoft would do well to
>> remember...)
>
> While some will hope that they don't learn from the past and will
> repeat it themselves.
>
>
>>> How does this relate to the questions expressed below?
>>
>>> Only this: that a great deal of the changes in this industry are
>>> driven by sincere but not always well-informed enthusiasms.
>>
>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>> such... :-) Instead of developing high level languages which enabled
>> people who really weren't programmers to try their hand at it,
>> imagine if they had focused on improving the development facilities
>> available in Assembler, instead? Programming would have stayed with
>> the professionals, and the professionals would have been much more
>> productive.
>>
>> "properly informed" people would have realised that bringing computer
>> programming to the masses was a very bad move and there would have
>> been no COBOL or PL/1. Platform transportability could have been
>> achieved by low-level code conversion software instead.
>>
>> I
>>
>>> instance acouple of my younger colleagues who goggled with awe at
>>> the successive announcements of a new chip with 10% more speed;
>>> "jeez, I've got to have that", they would cry, then be utterly
>>> unable to understand why I didn't follow suit; or the engineers who
>>> were learning VB assuring me that they were using a new
>>> "event-oriented" method of programming which I wouldn't understand,
>>
>> Ah, the arrogance of youth... :-) There's usually no malice in it.
>> To be fair, getting COBOL programmers to understand and embrace the
>> interrupt driven model of programming is sometimes difficult, simply
>> because COBOL controls everything and is not designed for responding
>> to events. People get used to initiating processes and controlling
>> them. When something screams: "Attend to me, NOW!" it is a bit of a
>> paradigm shift...
>>
>> People without the benefit of COBOL experience pick it up very
>> quickly.
>>
>>> then shamefacedly
>>> admitting that my advice worked; one real enthusiast declared in
>>> print that once C replaced Cobol, maintenance costs would
>>> immediately come down.
>>
>> Well, they did with the advent of C++. (The OO features mean reuse
>> and less maintenance.) I still wouldn't advocate C or C++ as a the
>> preferred choice for Business code development; especially not when
>> there is C# which combines the best of these worlds with the best of
>> the Java world as well, and even throws in a smattering of VB for
>> good measure... :-)
>
> The issue of maintenance costs was the subject of an infamous
> Datamation article in the mid 80s. They surveyed various development
> departments and identified the language used and the time spent on
> 'new' and 'maintenace'. Of course most in-house and packaged business
> software has 'maintenance' as developments needed to meet changing
> business requirements, while non-business applications in C tended to
> only refer to bug fixing as 'maintenance' and feature enhancement as
> 'new development'
>
> The conclusion of the article that if C was used, rather than Cobol,
> then costs would be slashed because maintenance would disappear was
> grossly flawed. The maintenance requirement was a function of the
> application type, not of the language.
>
> Even your claim that OO reduces maintenance is flawed.

No, it isn't. I have figures and statistics collected over 3 years to back 
it up. I was saving before that, but that is all I have documented.

I can't speak to other people's experience, but in my case, at least, moving 
from procedural to OO COBOL was a major step in increasing overall ROI. 
Moving to C# has increased it again because productivity is higher, and 
using .NET means that "old" and "new" can play nicely together without 
problem. This extends the life of the "old".

>It may do so
> because one does not change an existing class (maintenance) but one
> writes a _new_ class that inherits from the old and has the
> differences catered for. Claiming that this is therefore 'less
> maintenance' fails to acknowledge that it arrives at the same result
> after much the same effort (but can eventually lead to inheritance
> hell).

No, you have failed to realise that with a component based approach things 
are much more configurable. It isn't just about extending existing classes 
(although that certainly figures in it). Behaviour can be changed by 
configuration, by the order that components are activated in, by adding or 
configuring Framework Classes that require no maintenance at all, or by 
minor changes in the "glue" that holds everything together.It doesn't ALWAYS 
require a Class extension. The reason I say that OO component based 
approaches require less maintenance is because of granularity, not becase of 
the innate mechanics of this architecture.

As for ".dll Hell" I've not personally experienced it. I have good 
inventories of the components I use and the .NET framework is very well 
documented, publicly, so the components available from there are easily 
recognized. Provided proper design is done, there should be no need to 
descend into "inheritance (or any other kind of) hell".
>
>
<snip>.
>>
>> I'd almost agree here. Unfortunately, it isn't just about "business
>> problems", it is also about how solutions should be deployed and how
>> responsive these solutions are to a rapidly changing business
>> environment. If I need some "intelligence" at the Ulan Bator end of
>> the corporate network so the boys can keep us updated on the price
>> of mare's milk and spot emerging market opportunites, I need a
>> different solution than the one I use when I'm talking to Farmer
>> Brown about the price of cheese, for local distibution. And if the
>> Mongolians suddenly decide they might go for cows instead of horses,
>> I need to be able to amend my solution very quickly.
>>
>> There was a time when a computer sat in the middle of the office and
>> did its thing. Both problems and solutions were simple and
>> relatively static. People communicated wth it by means of green
>> screens which it drove by timeslicing the power of its processor.
>> (And this was considered a very lucky break, after having to provide
>> punch cards and receive information printed on screeds of green
>> lineflo...)
>
> Actually many computers still do that, except the screens are multi-
> coloured, and they may be in the middle of some other office.
>

I haven't seen anything recently driving a 3270 screen in 32K of Foreground 
1, but I'll take your word for it. :-)
>
>> That (slightly gentler) time is gone and we are living with a "now"
>> generation who have the attention span of a flea, the
>> self-discipline of a ferret, and who have been exposed to television
>> advertising since the day they were born. OF COURSE, they love
>> what's new. OF COURSE they love technology (even though they have no
>> desire to know how or why it works; the very few that actually do
>> have some remnant of the curiousity which stimulated the Human Race
>> to evolve the way it has, are described as "nerds" and "geeks" and
>> prevented from contributing to the gene pool by social mores that
>> will ensure no self-respecting member of the opposite sex goes near
>> them ...)
>>
>> So, given this scenario, I can't actually agree that solutions can be
>> provided by the mainline languages of yesteryear, to TODAY's
>> problems. Sure you can implement an algorithm in almost any
>> language, but that, in and of itself, does not necessarily represent
>> a SOLUTION.
>>
>>> All languages have calling facilities, after all, so
>>> the lack of intrinsic facilities to handle everything - e.g.,
>>> (pending corrections) I don't think any "high-level" language can
>>> directly manipulate I/O gear or handle interrupts, etc. - is no
>>> impediment to its use.
>>
>> So, you are advocating using these languages as "glue" or a
>> "Framework" where they can simply call out for assistance in the
>> areas they are not good at? I think there is something in that. I
>> used COBOL in this capacity for a number of years, but now there are
>> simply better tools available. (See response to Howard, below.)
>>
>>> There will come a time when so many such
>>> calls must be made to get the job done as to make it sensible to
>>> start using something else, of course; whether we've reached that
>>> point with (for instance) OO or not seems to be highly up in the
>>> air.
>>
>>> My opinions, then: while Cobol is indeed old-fashioned, none of the
>>> reasons for its creation have changed; much of the replacement urge
>>> is clamour; and that Cobol still exists and is still being used for
>>> new development (and I'm NOT going to debate that) is proof enough
>>> of its continued vitality.
>>
>> OK, let's look at those one by one...
>>
>> 1."none of the reasons for its creation have changed". COBOL arose
>> out of a fear by customers that they were spending large amounts of
>> money to develop computer systems which locked them in to a
>> particular vendor's platform. Developing lines of code in Assembler
>> is just as expensive as it is in COBOL, and knowing that if you ever
>> have a disagreement with your hardware vendor, there is nothing you
>> can do about it, doesn't help the situation. The idea of "platform
>> independence" gained very rapid acceptance and by the early 1960s it
>> was like the "Holy Grail" of computing.
>> Vendors realised that providing a "high-level" language, was going
>> to be a major sales clincher and they were all working flat-out to
>> be first. The CODASYL formalised it and got the major players to sit
>> around a table (Grace Hopper and the DOD deserve some credit for
>> driving this) and even contribute various ideas and existing
>> software. It didn't take vendors long to realise that they could
>> still make "migration" away from their hardware very difficult by
>> providing and encouraging the use of "extensions" to the early
>> standards, and they vied with each other to provide the most
>> "useful" extensions. COBOL was NEVER about a language for
>> implementing algorithms (Algol and Jovial were already around for
>> that...); it's primary purpose was to provide platform independence,
>> then to remove the mystery attached to Assembler programming, and
>> improve productivity and ease of maintenance (hopefully...)
>>
>> Is that like today? I don't think so. Platform independence is not a
>> problem; we use networks with protocols recognised by all the
>> attached hardware.
>
> 'Platform independence' _is_ still a problem, mainly because Microsoft
> regards it as meaning 'both Windows XP _and_ Windows Vista' and make
> subtle undocumented changes to attempt to lock in their products and
> lock out every one else's, as well as their older products.

No comment to blatant troll, Richard... tsk, tsk, you really should know 
better... :-)

I have no problem with communicating across platforms using a commonly 
acepted protocol (and even, occasionally, some that are NOT so commonly 
accepted... TCP/IP is not the ONLY internet protocol...). If you want stuff 
to be platform independent, develop Web based systems. They'll run on XP 
Vista, Linux, Unix, MacOS and any other OS that recognises the protocol and 
has a browser... Sure there can be browser inconsistencies, but they are 
minor and comparatively easily rectified, as we have seen here recently. 
That was simply inconceivable at the time COBOL was developed.
>
> This is the reason they introduce new .doc formats with almost every
> release, they want to force everyone to buy the new versions and to
> eliminate non-microsoft products.

Aren't you even a little bit tired of banging this old hackneyed drum?  The 
doc formats are now public, anyone can download a FREE viewer for any MS 
document, and people ARE using alternative products (I get offered Open 
Office for free every time my system updates Java...)  Sure, MS would like 
us to buy their products. I don't know any business currently trading where 
that ISN'T the case...Personally, I use MS products because they work 
extremely well (for the most part), and on the occasions when they don't, 
Help is a couple of mouse clicks away. Mainly, I use them because that's 
what most of  my customers (existing and potential) use, but I'm aware there 
are alternatives and I have a choice. Given that such is the case, I cannot 
share your vitriol for MicroSoft (although, of course, I respect your right 
to your opinion).

>
> This is why they introduced IE incompatibilities and made Frontpage
> and IIS generate IE-only http.

IIS doesn't generate anything. FrontPage has fallen into disfavour and I 
believe is now replaced.(I don't know a single professional web developer 
who ever used it, anyway. I tried it myself and found it to be a poor shadow 
of DreamWeaver so haven't used it since - that was around 10 years ago...) 
IE extensions were introduced because the standard stuff (at the time) 
couldn't cut it. Most of what were extensions are now standard (or there is 
equivalent standard functionality), so that is academic. I could argue that 
MS did the community a favour by providing the functionality that people 
wanted and thereby urging W3C to consider these features.

You may be a bit out of date on web development, or at least web development 
using MS tools.
>
> Networking with SMB only remains cross platform because the Samba team
> can reverse engineer all the changes that MS introduce.

Well, that's a good thing.
>
>> Removal of mystery? Today's generation accept computers as easily
>> as they do cell phones. (I was amused yesterday when a friend who is
>> in her sixties was looking for GOOGLE on a computer that didn't
>> belong to her. Her 19 month old grand-daughter obligingly picked up
>> the mouse and opened the Browser for her...) Ease of maintenance?
>> What maintenance? Write components and reuse them. Productivity? I
>> can write C# at approximately 6 times the rate I could write COBOL
>> (NOT based on lines of code, but on results achieved. Powerful, more
>> compact languages with highly intelligent IDEs are simply quicker
>> and easier to write...)
>>
>> 2."much of the replacement urge is...
>>
>> read more

No, I don't think so... :-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 12:06:57 PM

docdwarf@panix.com wrote:
> In article <6sl610F6vlsbU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>> tlmfru wrote:
>
> [snip]
>
>>> Only this: that a great deal of the changes in this industry are
>>> driven by sincere but not always well-informed enthusiasms.
>>
>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>> such... :-) Instead of developing high level languages which enabled
>> people who really weren't programmers to try their hand at it,
>> imagine if they had focused on improving the development facilities
>> available in Assembler, instead? Programming would have stayed with
>> the professionals, and the professionals would have been much more
>> productive.
>
> ... and the cry of 'I know that's what I *told* you but it's not what
> I *want*' would never have been heard... and I am the King of
> England, too.
>

We would have heard the cry of  " I don't understand a bleedin' word your 
saying; never mind the technobabble, just give me this report..." instead.

Much better, some might say...
>>
>> "properly informed" people would have realised that bringing computer
>> programming to the masses was a very bad move and there would have
>> been no COBOL or PL/1. Platform transportability could have been
>> achieved by low-level code conversion software instead.
>
> 'Bringing computer programming to the masses' was a matter - at least
> in the Corporate World - of allocating resources.  Some might wonder
> who is responsible for such things... the blade of sarcase might have
> multiple edges.

If it only had one, it would be the axe of sarcase...

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 12:11:26 PM

Howard Brazee wrote:
> On Thu, 8 Jan 2009 15:17:05 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>> print that once C replaced Cobol, maintenance costs would
>>> immediately come down.
>>
>> Well, they did with the advent of C++. (The OO features mean reuse
>> and less maintenance.) I still wouldn't advocate C or C++ as a the
>> preferred choice for Business code development; especially not when
>> there is C# which combines the best of these worlds with the best of
>> the Java world as well, and even throws in a smattering of VB for
>> good measure... :-)
>
> Do we have good evidence that maintenance costs immediately (or
> delayed) went down?

I have enough to satisfy me personally. I accept that not all people will 
agree, but as my universe is totally egocentric, I only care about what 
happens to me...

Seriously, Howard, what evidence would persuade you, or anyone who doesn't 
want to believe this? I can post stuff showing how using OO cuts maintenance 
(and regression testing); I have done so here, but nobody believes it, or 
understands it, so what is the point in me doing so? Changing or writing 
more lines of code is ingrained in most of the readership here as being the 
only way systems can be maintained. It isn't, but frankly, I'm tired of 
talking about it. Words like "encapsulation" and "reuse" might as well be 
Swahili for people here. I'm fine with the case remaining unproven, as far 
as this forum is concerned, anyway.

>
> If so, did it go down the same way as TV repair costs went down - we
> no longer repair TVs, we replace them?

That's a good analogy and certainly true to some extent. When granularity in 
a system is small, it can often be cheaper to simply replace something than 
to repair it.
>
> On the other hand, if we are getting more benefit from IS, it isn't
> easy to evaluate whether the new tools made our costs go up more
> slowly than the old tools would have.

Does it matter if the new tools are more productive (and, obviously, the 
cost of using them doesn't exceed the benefits returned by them)?

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 12:28:43 PM

Howard Brazee wrote:
> The big advantage in having a dominant tool (maybe CoBOL on IBM
> mainframes) is that we can hire someone from the next company over who
> is skilled in using it.

And the next company over can do exacty the same to us...
>
> But there are some significant advantages in having a bunch of tools,
> even if some of these require training.
>
> Some of the less obvious advantages are:
>
> 1.  When we make mistakes, we can more easily change directions.   An
> example of this is our new security requirements.   While it was
> difficult for Microsoft to change directions (they needed to be all
> things for all people), other companies have been able to redesign
> their IS flow for this requirement.
>
> 2.  We can buy 3rd party products that weren't written in our
> language.   We don't need to be able to maintain them at the code
> level.   Heck, the high-security mainframe data warehouse can be
> thought of as a black-box object.
>
> 3.  Competition is more free and varied.   This also means that we are
> less vulnerable to evolutionary dead ends (think banana plague).
>
> Question:  Which is used more - CoBOL or PeopleCode?
> Answer:   It doesn't matter anymore.

I agree.

I'm also in favour of a full tool box.

Pete.

-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 12:31:21 PM

tlmfru wrote:
> I do enjoy these historical matters!
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:6sl610F6vlsbU1@mid.individual.net...
>> Hi Peter,
>>
>> Very good response from both you and Howard. So I'm taking some time
>> out to reply, although some of what I originally wrote was not
>> entirely serious...:-)
>>
>>>
>>> How does this relate to the questions expressed below?
>>>
>>
>>> Only this: that a great deal of the changes in this industry are
>>> driven by sincere but not always well-informed enthusiasms.
>>
>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>> such... :-) Instead of developing high level languages which enabled
>> people who really weren't programmers to try their hand at it,
>> imagine if they had focused on improving the development facilities
>> available in Assembler, instead? Programming would have stayed with
>> the professionals, and the professionals would have been much more
>> productive.
>>
>> "properly informed" people would have realised that bringing computer
>> programming to the masses was a very bad move and there would have
>> been no COBOL or PL/1. Platform transportability could have been
>> achieved by low-level code conversion software instead.
>>
>
> Tongue-in-cheek here, of course.

Well spotted, old fruit... :-)


>Although there was definite
> resistance to the new thing (Cobol) most of the older programmers I
> encountered at the time were eager converts once they found out how
> easy it was and how much more they could get done.  And there was a
> sizeable group that positively reveled in it from the get-go as they
> simply weren't up to the intellectual requirements of Assembler.
>

Well, where I was workng it was an Assembler shop and the old timers WEREN'T 
more productive with COBOL at all. In fact,most of them could code rings 
around the COBOL guys. There was little advantage in a high level language 
(from the programming perspective), that couldn't be obtained by the use of 
macros in Assembler...

> Much more recently, in the late 90's in fact, I came across a
> proposal to turn the users loose on certain programming requirements
> - each new product the company introduced required a new editing and
> pricing program, and the burden was getting away from I/T.  The
> language was PRIME Infobasic - a fairly able and productive thing but
> very labour-intensive and not at all easy to grasp for newbies in the
> I/T dep't, let alone non-programming users. (One of my sayings is
> "you can't get away from screwed-up thinking.  The decision to go
> with one program per product is an example; although a table-driven
> method had been worked out at that time as well,; I never did find
> out the rationale).  So your scenario above isn't a pure phantasy
> after all!

I should hope none of my fantasies would ever be considered "pure"... :-)

>
>>
>> Ah, the arrogance of youth... :-) There's usually no malice in it.
>> To be fair, getting COBOL programmers to understand and embrace the
>> interrupt driven model of programming is sometimes difficult, simply
>> because COBOL controls everything and is not designed for responding
>> to events. People get used to initiating processes and controlling
>> them. When something screams: "Attend to me, NOW!" it is a bit of a
>> paradigm shift...
>>
>> People without the benefit of COBOL experience pick it up very
>> quickly.
>>
>>
>>
>
> Now that's a bit of a canard, you know.

You mean a yellow thing in France that quacks?

Given that one online meaning is: "An unfounded or false, deliberately 
misleading story.", given that I generally avoid lying (it makes life more 
complex than my tired old brain can accommodate), and given that the comment 
was based on actual experience gained teaching interrupt driven (PowerCOBOL) 
programming to COBOL programmers in two different organisations, and to 
non-COBOL programmers (VB) in one other organisation, I have to say it 
neither waddles like a duck nor quacks like a duck. My experience has been 
exactly as stated. (I didn't make it up...)

>Positing a screen-handler
> that the application programmer needn't worry about, then
> event-oriented or interrupt-driven programming is straightforward in
> Cobol.  You fire out your initial screen and set up the flags to
> indicate what you did, then wait for a response.

....or not...

> So long as the
> response info includes all identifying info - last key pressed, what
> screen was in control, what information was entered - then the
> program will always know what to do.  There will be processing
> particular to the screen in control, there may be successor screens
> to set up. file i/o to do, termination, etc.  But in no case is the
> list of possible events very large: I can't imagine why an
> application program would care that the window was resized or moved;
> that's the screen handler's business.  The program can always relate
> its previous state to the current action required.  Your statement
> above that Cobol controls everything is misleading in this case: all
> it's doing is presenting the info and waiting for the user to do
> something, then responding to that something.

And, according to your own statement above "You fire out your initial screen 
and
set up the flags to indicate what you did, then wait for a response"

How is that NOT controlling the process?

It's a semantic argument anyway. I stated that "COBOL controls everything 
and is not designed for responding to events", but that comment was about 
general use of COBOL, NOT using it in the scenario you posited.

>There is no absolute
> sequence of events.  It's true that it's more difficult in Cobol as
> opposed to VB or anything else, because many of the details that are
> under the hood in VB etc. must be explixitly done in Cobol.  I've
> been doing that sort of thing since about 1973; once I understood why
> the program was always resumed in the same paragraph (instead of
> immediately following where it released control to the screen
> handler) I had no conceptual trouble at all; the problems were in the
> details.  Using other languages, as a result, was straightforward
> too, although I was bedeviled by the different ways  the various
> languages treated the same event.

Hmmm...You are describing ONE model of interrupt driven processing and it is 
not a good one. (A good one WOULD return control to the statement 
immediately following the dequeue. This is achieved by true re-entrancy 
which, historically, has not been available in COBOL, because access to the 
system context is not generally available in COBOL... Specifying RENTRANT in 
a compiler directive does NOT mean the system can or will do the necessary 
context switch with all registers and the instruction counter being saved 
and restored, at any point where you want it to... like immediately before 
your dequeue boundary) A true interrupt driven process would handle other 
interrupts besides the one it was "waiting for" in your scenario and it 
would involve true re-entrancy, rather than the serial re-usability you have 
described.

But I didn't want to digress into interrupt driven processing (as 
interesting as that may be...)

If you seriously disagree that in general, outside of contrived interrupt 
scenarios, "COBOL controls everything and is not designed for responding to 
events", then by all means make your case. But please don't call me a liar 
or "misleader" if I make mine with an honest statement based on actual 
experience.

Cheers,

Pete.








0
Reply dashwood (4370) 1/9/2009 1:24:08 PM

On Thu, 8 Jan 2009 13:34:15 -0600, "HeyBub" <heybub@NOSPAMgmail.com>
wrote:

>> I've seen a copy member which only stated that this program has been
>> converted to Y2K.   Typing in the copy statement was no less work as
>> typing "Y2K ready".
>>
>
>Which makes it easy to scan the entire library looking for those modules 
>that HAVEN'T been converted. 

Either of those two choices I stated must be put in a standard - and
they both are equally effective.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/9/2009 3:10:50 PM

On Fri, 09 Jan 2009 05:55:52 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>Well, I have supported systems where the table of USA Daylight Saving 
>Time dates was hard-coded in the program, so performance was certainly 
>good.  It's probably not considered a good practice, but it wasn't that 
>difficult to maintain.

I don't think I have ever worked with a system that was designed for
laws changing when daylight savings time started.    

Operating systems that cared about daylight savings time (Windows) had
to be modified when that became an issue.   The original design did
not foresee the utility of updating the rules for daylight savings
time.   

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/9/2009 3:14:55 PM

In article <6sot7fF7dkkdU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>docdwarf@panix.com wrote:
>> In article <6sl610F6vlsbU1@mid.individual.net>,
>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>>> such... :-) Instead of developing high level languages which enabled
>>> people who really weren't programmers to try their hand at it,
>>> imagine if they had focused on improving the development facilities
>>> available in Assembler, instead? Programming would have stayed with
>>> the professionals, and the professionals would have been much more
>>> productive.
>>
>> ... and the cry of 'I know that's what I *told* you but it's not what
>> I *want*' would never have been heard... and I am the King of
>> England, too.
>>
>
>We would have heard the cry of  " I don't understand a bleedin' word your 
>saying; never mind the technobabble, just give me this report..." instead.
>
>Much better, some might say...

Quite right, Mr Dashwood... because such a cry would have invoked the 
response of 'I gave you that report, just as you asked... oh, and if you 
use that language or tone of voice with me again you'll be talking to an 
empty chair.  If you want something more I'll need to be informed of it.'

DD

0
Reply docdwarf (6044) 1/9/2009 3:34:39 PM

In article <6soucqF7etljU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>Howard Brazee wrote:
>> The big advantage in having a dominant tool (maybe CoBOL on IBM
>> mainframes) is that we can hire someone from the next company over who
>> is skilled in using it.
>
>And the next company over can do exacty the same to us...

That might be a reason, Mr Dashwood, for companies to make sure that their 
employees have better reasons to stay with them than for moving to another 
shop.

DD
0
Reply docdwarf (6044) 1/9/2009 3:57:59 PM

On Fri, 9 Jan 2009 15:57:59 +0000 (UTC), docdwarf@panix.com () wrote:

>>> The big advantage in having a dominant tool (maybe CoBOL on IBM
>>> mainframes) is that we can hire someone from the next company over who
>>> is skilled in using it.
>>
>>And the next company over can do exacty the same to us...
>
>That might be a reason, Mr Dashwood, for companies to make sure that their 
>employees have better reasons to stay with them than for moving to another 
>shop.

Of course, seeing how many people get hired because a line on their
resume indicates that the company won't consider technical training,
expecting companies to value employees understanding of the business
process might be a bad bet.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/9/2009 4:52:05 PM

In article <kuvem4pvq9683rmn78ols21m9a7vs56m4s@4ax.com>,
Howard Brazee  <howard@brazee.net> wrote:
>On Fri, 9 Jan 2009 15:57:59 +0000 (UTC), docdwarf@panix.com () wrote:
>
>>>> The big advantage in having a dominant tool (maybe CoBOL on IBM
>>>> mainframes) is that we can hire someone from the next company over who
>>>> is skilled in using it.
>>>
>>>And the next company over can do exacty the same to us...
>>
>>That might be a reason, Mr Dashwood, for companies to make sure that their 
>>employees have better reasons to stay with them than for moving to another 
>>shop.
>
>Of course, seeing how many people get hired because a line on their
>resume indicates that the company won't consider technical training,
>expecting companies to value employees understanding of the business
>process might be a bad bet.

That might be, Mr Brazee, a reason for various companies having exactly 
the workforce they deserve... and a reason why I do what I do.

DD

0
Reply docdwarf (6044) 1/9/2009 6:13:25 PM

On Jan 10, 1:06=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Richard wrote:
> > On Jan 8, 3:17 pm, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
> >> Hi Peter,
>
> >> Very good response from both you and Howard. So I'm taking some time
> >> out to reply, although some of what I originally wrote was not
> >> entirely serious...:-)
>
> >> tlmfru wrote:
> >>> You'll remember the scene of about 15-20 years ago when the PC
> >>> tsunami seemed to be about to take over the IT world, when even
> >>> mighty IBM was reeling under the assault, when the BUNCH
> >>> (Burrroughs, Univac, NCR, CDC, and Honeywell) were effectively
> >>> eliminated as mainframe companies (stipulating that
> >>> Burroughs/Univac still exist as Unisys, but with a vastly changed
> >>> business model). At that time there was much comment as to what IBM
> >>> should do. I remember a series of articles in Computerworld (I
> >>> think) expressing opinions; most of them suggested a radical change
> >>> of course, some going so far as to insist that IBM must implement
> >>> Windows on its machines and abandon its own o/s'es! None of which
> >>> they did.
>
> >> I was working for CDC at the timeof the anti-trust suit and remember
> >> these times very well. I later worked for IBM just after the dismay
> >> at losing thier leadership (both market and corporate) was beginning
> >> to be felt, and I think the only thing that saved them was the
> >> appointment of a CEO who knew what was going on. It's hard to
> >> believe that a company whose net profit was equivalent in one year
> >> to the GNP of New Zealand, could, within a few years, be in danger
> >> of losing it altogether.
>
> >> (Some might say this is a lesson MicroSoft would do well to
> >> remember...)
>
> > While some will hope that they don't learn from the past and will
> > repeat it themselves.
>
> >>> How does this relate to the questions expressed below?
>
> >>> Only this: that a great deal of the changes in this industry are
> >>> driven by sincere but not always well-informed enthusiasms.
>
> >> Absolutely. Seen it many times. COBOL replacing Assembler was one
> >> such... :-) Instead of developing high level languages which enabled
> >> people who really weren't programmers to try their hand at it,
> >> imagine if they had focused on improving the development facilities
> >> available in Assembler, instead? Programming would have stayed with
> >> the professionals, and the professionals would have been much more
> >> productive.
>
> >> "properly informed" people would have realised that bringing computer
> >> programming to the masses was a very bad move and there would have
> >> been no COBOL or PL/1. Platform transportability could have been
> >> achieved by low-level code conversion software instead.
>
> >> I
>
> >>> instance acouple of my younger colleagues who goggled with awe at
> >>> the successive announcements of a new chip with 10% more speed;
> >>> "jeez, I've got to have that", they would cry, then be utterly
> >>> unable to understand why I didn't follow suit; or the engineers who
> >>> were learning VB assuring me that they were using a new
> >>> "event-oriented" method of programming which I wouldn't understand,
>
> >> Ah, the arrogance of youth... :-) There's usually no malice in it.
> >> To be fair, getting COBOL programmers to understand and embrace the
> >> interrupt driven model of programming is sometimes difficult, simply
> >> because COBOL controls everything and is not designed for responding
> >> to events. People get used to initiating processes and controlling
> >> them. When something screams: "Attend to me, NOW!" it is a bit of a
> >> paradigm shift...
>
> >> People without the benefit of COBOL experience pick it up very
> >> quickly.
>
> >>> then shamefacedly
> >>> admitting that my advice worked; one real enthusiast declared in
> >>> print that once C replaced Cobol, maintenance costs would
> >>> immediately come down.
>
> >> Well, they did with the advent of C++. (The OO features mean reuse
> >> and less maintenance.) I still wouldn't advocate C or C++ as a the
> >> preferred choice for Business code development; especially not when
> >> there is C# which combines the best of these worlds with the best of
> >> the Java world as well, and even throws in a smattering of VB for
> >> good measure... :-)
>
> > The issue of maintenance costs was the subject of an infamous
> > Datamation article in the mid 80s. They surveyed various development
> > departments and identified the language used and the time spent on
> > 'new' and 'maintenace'. Of course most in-house and packaged business
> > software has 'maintenance' as developments needed to meet changing
> > business requirements, while non-business applications in C tended to
> > only refer to bug fixing as 'maintenance' and feature enhancement as
> > 'new development'
>
> > The conclusion of the article that if C was used, rather than Cobol,
> > then costs would be slashed because maintenance would disappear was
> > grossly flawed. The maintenance requirement was a function of the
> > application type, not of the language.
>
> > Even your claim that OO reduces maintenance is flawed.
>
> No, it isn't. I have figures and statistics collected over 3 years to bac=
k
> it up. I was saving before that, but that is all I have documented.
>
> I can't speak to other people's experience, but in my case, at least, mov=
ing
> from procedural to OO COBOL was a major step in increasing overall ROI.
> Moving to C# has increased it again because productivity is higher, and
> using .NET means that "old" and "new" can play nicely together without
> problem. This extends the life of the "old".
>
> >It may do so
> > because one does not change an existing class (maintenance) but one
> > writes a _new_ class that inherits from the old and has the
> > differences catered for. Claiming that this is therefore 'less
> > maintenance' fails to acknowledge that it arrives at the same result
> > after much the same effort (but can eventually lead to inheritance
> > hell).
>
> No, you have failed to realise that with a component based approach thing=
s
> are much more configurable. It isn't just about extending existing classe=
s
> (although that certainly figures in it). Behaviour can be changed by
> configuration, by the order that components are activated in, by adding o=
r
> configuring Framework Classes that require no maintenance at all, or by
> minor changes in the "glue" that holds everything together.It doesn't ALW=
AYS
> require a Class extension. The reason I say that OO component based
> approaches require less maintenance is because of granularity, not becase=
 of
> the innate mechanics of this architecture.
>
> As for ".dll Hell" I've not personally experienced it. I have good
> inventories of the components I use and the .NET framework is very well
> documented, publicly, so the components available from there are easily
> recognized. Provided proper design is done, there should be no need to
> descend into "inheritance (or any other kind of) hell".
>
>
>
>
>
> <snip>.
>
> >> I'd almost agree here. Unfortunately, it isn't just about "business
> >> problems", it is also about how solutions should be deployed and how
> >> responsive these solutions are to a rapidly changing business
> >> environment. If I need some "intelligence" at the Ulan Bator end of
> >> the corporate network so the boys can keep us updated on the price
> >> of mare's milk and spot emerging market opportunites, I need a
> >> different solution than the one I use when I'm talking to Farmer
> >> Brown about the price of cheese, for local distibution. And if the
> >> Mongolians suddenly decide they might go for cows instead of horses,
> >> I need to be able to amend my solution very quickly.
>
> >> There was a time when a computer sat in the middle of the office and
> >> did its thing. Both problems and solutions were simple and
> >> relatively static. People communicated wth it by means of green
> >> screens which it drove by timeslicing the power of its processor.
> >> (And this was considered a very lucky break, after having to provide
> >> punch cards and receive information printed on screeds of green
> >> lineflo...)
>
> > Actually many computers still do that, except the screens are multi-
> > coloured, and they may be in the middle of some other office.
>
> I haven't seen anything recently driving a 3270 screen in 32K of Foregrou=
nd
> 1, but I'll take your word for it. :-)

Nor have I, but do you think that a TSE or Citrix server doesn't use
timeslicing ?

Do you think that IIS or Apache doesn't have a timeslicing box running
it ?



0
Reply riplin (4127) 1/9/2009 10:14:10 PM

Howard Brazee wrote:
> On Thu, 8 Jan 2009 09:42:50 -0600, "Michael Mattias"
> <mmattias@talsystems.com> wrote:
>
>>> So would you just rewrite this stuff every time you need it?
>>
>> That would be considered the "traditional" method in many, many
>> shops, Pete.
>
> Even without tradition, we all have levels where we should decide
> whether a code element is worth separating out (to copy members,
> called programs, objects, or whatever).
>
> I've seen a copy member which only stated that this program has been
> converted to Y2K.   Typing in the copy statement was no less work as
> typing "Y2K ready".
>
> For someone who has to look up how to verify dates, it might be
> quicker and easier to look up the library date routine, and adjust his
> program to use it.     But for me writing the date routine is the more
> trivial of those two options.   It's not as though two programmers
> will have incompatible date check routines (unless that was part of
> the business requirements).

I have come across date routines, on the same site, written by different 
programmers, that DID give different results. (One was simply "wrong" 
because it didn't do the 4 and 400 check on centuries. The programmer who 
wrote it simply wasn't aware that this is necessary; that's why I always 
include 29/02/1900 in anything date related that needs testing. If the date 
is accepted as OK, then the routine is flawed. Now, you can argue that this 
is unlikely tobe a problem for current use, but what about the different 
styles involved? One guy uses a calendar lookup, another uses a tractenburg 
type algorithm, another recognises state transitions by condition names, and 
another (like Bill), sees it as a decision table...

And dates are something we are all aware of and agree about. Suppose two 
different people interpret a "trivial" business rule differently in their 
code?

I understand your point, Howard, but I really think that duplicating code is 
NOT good and should be avoided for many reasons OTHER than just pure 
efficiency.
>
> And I might do it differently if my program needed to do something
> unusual with that date.

Ouch! I think that's even worse... :-) Adate is a date is a date is a date. 
Whatever "unusual" things you need to do with it do not change it from being 
a valid date.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 10:15:37 PM

William M. Klein wrote:
> When I used to work with and for large IBM mainframe shops, they
> usually did have a callable date routine.  However, besides just
> checking for "valid dates" it was the common (company wide) routine
> that one used to determine things like:
> - what business week of the year is it
> - is it a legal state holiday? banking holiday? federal holiday?
> - is it a month-end? quarter-end? year-end processing date
> - end-of-payroll for except or non-except employees
> - etc, etc
>
> and lots of other "company-specific_ information.
>
> Such routines WERE updated regularly; certainly at the beginning/end
> of a financial year, but also when various business or legal
> "thingies" changed.
> Certainly, this COULD (using modern paradigms) be a "component" - but
> I don't think that those types of shops would have considered such
> routines "stable" and replace-rather-than-modify eligible.  I suppose
> there were parts of the logic that were stable and those could have
> been "modularized" into components accessed by the main company date
> routine, but I am not certain how much that would have gained.  Many
> of these routines were (eventually) modified to be external
> table-driven. However (again speaking for IBM mainframe
> environments), the overhead of reading an external table (even once
> per transaction or application) was often too great to meet
> performance requirements.
A good point, Bill. I worked on sites (especially Banks) where this was an 
essential part of the business also.

I liked that you even considered in your post above how this might be a 
standard component.

It can be, of course, and, I obviously think it SHOULD be.

The mechanics of it don't change and separate methods could return separate 
items (based on properties of the Class). The calendars would definitely be 
modifiable externally. As for performance, I am surprised that access to an 
essential external table was considered to be too much overhead. It would 
seem the obvious solution was to compile the calendar as a load module and 
load it to the LPA. Pre-loaded, in-memory, is not going to make any 
detectable performance difference over having it loaded as a static table in 
the module that uses it. (There is always a way when it comes to 
performance; there isn't always a will... :-))

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 10:29:00 PM

Richard wrote:
> On Jan 10, 1:06 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Richard wrote:
>>> On Jan 8, 3:17 pm, "Pete Dashwood"
>>> <dashw...@removethis.enternet.co.nz> wrote:
>>>> Hi Peter,
>>
>>>> Very good response from both you and Howard. So I'm taking some
>>>> time out to reply, although some of what I originally wrote was not
>>>> entirely serious...:-)
>>
>>>> tlmfru wrote:
>>>>> You'll remember the scene of about 15-20 years ago when the PC
>>>>> tsunami seemed to be about to take over the IT world, when even
>>>>> mighty IBM was reeling under the assault, when the BUNCH
>>>>> (Burrroughs, Univac, NCR, CDC, and Honeywell) were effectively
>>>>> eliminated as mainframe companies (stipulating that
>>>>> Burroughs/Univac still exist as Unisys, but with a vastly changed
>>>>> business model). At that time there was much comment as to what
>>>>> IBM should do. I remember a series of articles in Computerworld (I
>>>>> think) expressing opinions; most of them suggested a radical
>>>>> change of course, some going so far as to insist that IBM must
>>>>> implement Windows on its machines and abandon its own o/s'es!
>>>>> None of which they did.
>>
>>>> I was working for CDC at the timeof the anti-trust suit and
>>>> remember these times very well. I later worked for IBM just after
>>>> the dismay at losing thier leadership (both market and corporate)
>>>> was beginning to be felt, and I think the only thing that saved
>>>> them was the appointment of a CEO who knew what was going on. It's
>>>> hard to believe that a company whose net profit was equivalent in
>>>> one year to the GNP of New Zealand, could, within a few years, be
>>>> in danger of losing it altogether.
>>
>>>> (Some might say this is a lesson MicroSoft would do well to
>>>> remember...)
>>
>>> While some will hope that they don't learn from the past and will
>>> repeat it themselves.
>>
>>>>> How does this relate to the questions expressed below?
>>
>>>>> Only this: that a great deal of the changes in this industry are
>>>>> driven by sincere but not always well-informed enthusiasms.
>>
>>>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>>>> such... :-) Instead of developing high level languages which
>>>> enabled people who really weren't programmers to try their hand at
>>>> it, imagine if they had focused on improving the development
>>>> facilities available in Assembler, instead? Programming would have
>>>> stayed with the professionals, and the professionals would have
>>>> been much more productive.
>>
>>>> "properly informed" people would have realised that bringing
>>>> computer programming to the masses was a very bad move and there
>>>> would have been no COBOL or PL/1. Platform transportability could
>>>> have been achieved by low-level code conversion software instead.
>>
>>>> I
>>
>>>>> instance acouple of my younger colleagues who goggled with awe at
>>>>> the successive announcements of a new chip with 10% more speed;
>>>>> "jeez, I've got to have that", they would cry, then be utterly
>>>>> unable to understand why I didn't follow suit; or the engineers
>>>>> who were learning VB assuring me that they were using a new
>>>>> "event-oriented" method of programming which I wouldn't
>>>>> understand,
>>
>>>> Ah, the arrogance of youth... :-) There's usually no malice in it.
>>>> To be fair, getting COBOL programmers to understand and embrace the
>>>> interrupt driven model of programming is sometimes difficult,
>>>> simply because COBOL controls everything and is not designed for
>>>> responding to events. People get used to initiating processes and
>>>> controlling them. When something screams: "Attend to me, NOW!" it
>>>> is a bit of a paradigm shift...
>>
>>>> People without the benefit of COBOL experience pick it up very
>>>> quickly.
>>
>>>>> then shamefacedly
>>>>> admitting that my advice worked; one real enthusiast declared in
>>>>> print that once C replaced Cobol, maintenance costs would
>>>>> immediately come down.
>>
>>>> Well, they did with the advent of C++. (The OO features mean reuse
>>>> and less maintenance.) I still wouldn't advocate C or C++ as a the
>>>> preferred choice for Business code development; especially not when
>>>> there is C# which combines the best of these worlds with the best
>>>> of the Java world as well, and even throws in a smattering of VB
>>>> for good measure... :-)
>>
>>> The issue of maintenance costs was the subject of an infamous
>>> Datamation article in the mid 80s. They surveyed various development
>>> departments and identified the language used and the time spent on
>>> 'new' and 'maintenace'. Of course most in-house and packaged
>>> business software has 'maintenance' as developments needed to meet
>>> changing business requirements, while non-business applications in
>>> C tended to only refer to bug fixing as 'maintenance' and feature
>>> enhancement as 'new development'
>>
>>> The conclusion of the article that if C was used, rather than Cobol,
>>> then costs would be slashed because maintenance would disappear was
>>> grossly flawed. The maintenance requirement was a function of the
>>> application type, not of the language.
>>
>>> Even your claim that OO reduces maintenance is flawed.
>>
>> No, it isn't. I have figures and statistics collected over 3 years
>> to back it up. I was saving before that, but that is all I have
>> documented.
>>
>> I can't speak to other people's experience, but in my case, at
>> least, moving from procedural to OO COBOL was a major step in
>> increasing overall ROI. Moving to C# has increased it again because
>> productivity is higher, and using .NET means that "old" and "new"
>> can play nicely together without problem. This extends the life of
>> the "old".
>>
>>> It may do so
>>> because one does not change an existing class (maintenance) but one
>>> writes a _new_ class that inherits from the old and has the
>>> differences catered for. Claiming that this is therefore 'less
>>> maintenance' fails to acknowledge that it arrives at the same result
>>> after much the same effort (but can eventually lead to inheritance
>>> hell).
>>
>> No, you have failed to realise that with a component based approach
>> things are much more configurable. It isn't just about extending
>> existing classes (although that certainly figures in it). Behaviour
>> can be changed by configuration, by the order that components are
>> activated in, by adding or configuring Framework Classes that
>> require no maintenance at all, or by minor changes in the "glue"
>> that holds everything together.It doesn't ALWAYS require a Class
>> extension. The reason I say that OO component based approaches
>> require less maintenance is because of granularity, not becase of
>> the innate mechanics of this architecture.
>>
>> As for ".dll Hell" I've not personally experienced it. I have good
>> inventories of the components I use and the .NET framework is very
>> well documented, publicly, so the components available from there
>> are easily recognized. Provided proper design is done, there should
>> be no need to descend into "inheritance (or any other kind of) hell".
>>
>>
>>
>>
>>
>> <snip>.
>>
>>>> I'd almost agree here. Unfortunately, it isn't just about "business
>>>> problems", it is also about how solutions should be deployed and
>>>> how responsive these solutions are to a rapidly changing business
>>>> environment. If I need some "intelligence" at the Ulan Bator end of
>>>> the corporate network so the boys can keep us updated on the price
>>>> of mare's milk and spot emerging market opportunites, I need a
>>>> different solution than the one I use when I'm talking to Farmer
>>>> Brown about the price of cheese, for local distibution. And if the
>>>> Mongolians suddenly decide they might go for cows instead of
>>>> horses, I need to be able to amend my solution very quickly.
>>
>>>> There was a time when a computer sat in the middle of the office
>>>> and did its thing. Both problems and solutions were simple and
>>>> relatively static. People communicated wth it by means of green
>>>> screens which it drove by timeslicing the power of its processor.
>>>> (And this was considered a very lucky break, after having to
>>>> provide punch cards and receive information printed on screeds of
>>>> green lineflo...)
>>
>>> Actually many computers still do that, except the screens are multi-
>>> coloured, and they may be in the middle of some other office.
>>
>> I haven't seen anything recently driving a 3270 screen in 32K of
>> Foreground 1, but I'll take your word for it. :-)
>
> Nor have I, but do you think that a TSE or Citrix server doesn't use
> timeslicing ?
>
> Do you think that IIS or Apache doesn't have a timeslicing box running
> it ?

I agree timeslicing is a useful technique, but I mentioned it in the context 
that there was only ONE "intelligence" available to do everythng, including 
driving the user interface. The servers you mention may well employ 
timeslicing, but when this gets a bit much, additional servers, and 
processors can be deployed to "distribute" the load. That was not always the 
case.

In the mainframe world of yesteryear distributed processing was a relative 
latecomer. IBM released their block MUX and advanced DMA architectures, 
which were a kind of separation designed to ease the CPU load, then 
intelligent subsystems like 3330 started including processors which sorted 
disk requests by track and optimized head movemet,  the CDC 6600 (available 
in the mid-60s, years ahead of its time and many times faster than anything 
else around) range was the first system I recall which actually had separate 
I/O processors (9 of them, with a 10th one co-ordinating everything - there 
had to be 10 to match the 10 processor cycles required to execute an 
instruction.), but all of this (apart  from the 6600) was AFTER the scenario 
I described.

Processors (and hand made memory) were prohibitively expensive and 
processing was centralised by necessity. This was the world where COBOL 
evolved and that was the world it was (and still is...) very well suited 
for.

That was my point.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/9/2009 11:08:33 PM

On Sat, 10 Jan 2009 11:15:37 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> And I might do it differently if my program needed to do something
>> unusual with that date.
>
>Ouch! I think that's even worse... :-) Adate is a date is a date is a date. 
>Whatever "unusual" things you need to do with it do not change it from being 
>a valid date.

It could add overhead to the routine though that I normally would
skip.

-- 
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace 
to the legislature, and not to the executive department." 

- James Madison
0
Reply howard (6275) 1/10/2009 12:43:39 AM

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:6sp1fpF7eupmU1@mid.individual.net...

> >> Absolutely. Seen it many times. COBOL replacing Assembler was one
> >> such... :-) Instead of developing high level languages which enabled
> >> people who really weren't programmers to try their hand at it,
> >> imagine if they had focused on improving the development facilities
> >> available in Assembler, instead? Programming would have stayed with
> >> the professionals, and the professionals would have been much more
> >> productive.
> >>
> >> "properly informed" people would have realised that bringing computer
> >> programming to the masses was a very bad move and there would have
> >> been no COBOL or PL/1. Platform transportability could have been
> >> achieved by low-level code conversion software instead.
> >>
> >
> > Tongue-in-cheek here, of course.
>
> Well spotted, old fruit... :-)
>
>
> >Although there was definite
> > resistance to the new thing (Cobol) most of the older programmers I
> > encountered at the time were eager converts once they found out how
> > easy it was and how much more they could get done.  And there was a
> > sizeable group that positively reveled in it from the get-go as they
> > simply weren't up to the intellectual requirements of Assembler.
> >
>
> Well, where I was workng it was an Assembler shop and the old timers
WEREN'T
> more productive with COBOL at all. In fact,most of them could code rings
> around the COBOL guys. There was little advantage in a high level language
> (from the programming perspective), that couldn't be obtained by the use
of
> macros in Assembler...
>

Your experience / my experience.  It's a wash.

> >>
> >> Ah, the arrogance of youth... :-) There's usually no malice in it.
> >> To be fair, getting COBOL programmers to understand and embrace the
> >> interrupt driven model of programming is sometimes difficult, simply
> >> because COBOL controls everything and is not designed for responding
> >> to events. People get used to initiating processes and controlling
> >> them. When something screams: "Attend to me, NOW!" it is a bit of a
> >> paradigm shift...
> >>
> >> People without the benefit of COBOL experience pick it up very
> >> quickly.
> >>
> >>
> >>
> >
> > Now that's a bit of a canard, you know.
>
> You mean a yellow thing in France that quacks?

No, it's a small external sensor, jocularly known as a "whisker", used on
high-performance jets (including the Concorde & Concordski) to aid in
attitude control & speed control.

Surprised that you hadn't come across the word before.

>
> Given that one online meaning is: "An unfounded or false, deliberately
> misleading story.", given that I generally avoid lying (it makes life more
> complex than my tired old brain can accommodate), and given that the
comment
> was based on actual experience gained teaching interrupt driven
(PowerCOBOL)
> programming to COBOL programmers in two different organisations, and to
> non-COBOL programmers (VB) in one other organisation, I have to say it
> neither waddles like a duck nor quacks like a duck. My experience has been
> exactly as stated. (I didn't make it up...)
>

Who said you did?  Judging by the remainder of your post you are arguing
about interrupts, not events.  The distinction is clear, in my mind anyway:
interrupts are the business of the hardware and the O/S; events are actions
initiated by the operator of an interactive (= using a screen) program.  I
did wonder, when I read your post, if you were equating the two and decided
that you must be, or else you'd be changing the subject.  So I was wrong.  I
am talking about EVENT-oriented programming - which all the engineers
learning VB smugly informed me they were doing - and it's as such that my
remarks must be interpreted.

Since you seem to be taking it personally, let me rephrase my statement: to
wit:  the view that event-oriented programming (as I've defined it) can't be
done in Cobol  - is WRONG.


> >Positing a screen-handler
> > that the application programmer needn't worry about, then
> > event-oriented or interrupt-driven programming is straightforward in
> > Cobol.  You fire out your initial screen and set up the flags to
> > indicate what you did, then wait for a response.
>
> ...or not...

Then the program times out ....

>
> > So long as the
> > response info includes all identifying info - last key pressed, what
> > screen was in control, what information was entered - then the
> > program will always know what to do.  There will be processing
> > particular to the screen in control, there may be successor screens
> > to set up. file i/o to do, termination, etc.  But in no case is the
> > list of possible events very large: I can't imagine why an
> > application program would care that the window was resized or moved;
> > that's the screen handler's business.  The program can always relate
> > its previous state to the current action required.  Your statement
> > above that Cobol controls everything is misleading in this case: all
> > it's doing is presenting the info and waiting for the user to do
> > something, then responding to that something.
>
> And, according to your own statement above "You fire out your initial
screen
> and
> set up the flags to indicate what you did, then wait for a response"
>
> How is that NOT controlling the process?

So you don't do this in VB or C++ ?????  Come on, man, get real; you're
flailing.

>
> It's a semantic argument anyway. I stated that "COBOL controls everything
> and is not designed for responding to events", but that comment was about
> general use of COBOL, NOT using it in the scenario you posited.
>

Well, then, you're excluding an unreasonable amount of  "Cobol as she is
used".  The scenario as I posited it is a common one.  Define "general use".

>
> Hmmm...You are describing ONE model of interrupt driven processing and it
is
> not a good one. (A good one WOULD return control to the statement
> immediately following the dequeue. This is achieved by true re-entrancy
> which, historically, has not been available in COBOL, because access to
the
> system context is not generally available in COBOL... Specifying RENTRANT
in
> a compiler directive does NOT mean the system can or will do the necessary
> context switch with all registers and the instruction counter being saved
> and restored, at any point where you want it to... like immediately before
> your dequeue boundary) A true interrupt driven process would handle other
> interrupts besides the one it was "waiting for" in your scenario and it
> would involve true re-entrancy, rather than the serial re-usability you
have
> described.
>
> But I didn't want to digress into interrupt driven processing (as
> interesting as that may be...)
>

Since you have already so digressed ... I hope I've made it clear what I was
talking about.  Events, not interrupts.  I'm familiar enough with re-entrant
protramming, thank you, having done some in the '70's, using Cobol; although
I was not using the Univac 1100's at the time, I know the Cobol compilers it
had could generate re-entrant code.  I didn't like it all that much because
the rules were unfamiliar but I used it successfully.  And they were
serially re-usable OR multi-threaded: I had to do both, not in the same
program, of course.

Your note about context switching etc. has to do with the o/s running the
programs: dynamic memory allocation, dynamic memory re-allocation, release
of control, re-establishing control, etc., etc.: nothing to do with
re-entrant programming at all.  What I was talking about was the program
using its own WORKING STORAGE to specify what it's been up to.  It doesn't
give a hoot where it's running in memory, or if it loses control voluntarily
(an I/O-out) or due to time-slice expiration: it just needs to have its own
"memory" to carry on.  I've never had to write a program that had to be
aware of its own context: I wrote the things and it was up to the compiler &
o/s to worry about the dirty details.


> If you seriously disagree that in general, outside of contrived interrupt
> scenarios, "COBOL controls everything and is not designed for responding
to
> events", then by all means make your case. But please don't call me a liar
> or "misleader" if I make mine with an honest statement based on actual
> experience.
>


Well, if you must use "interrupts" and "events" in the same sentence to mean
the same thing, then I guess I can't discuss it with you.  If you really
consider my "scenario" to be contrived - I have to wonder where you're
coming from.  In any event, I did not call you a liar or a misleader: you
read that into my question.  Did you sleep with a large kakapo the previous
night?  Uncomfortable bedmates, kakapos.

PL


0
Reply lacey1 (490) 1/10/2009 6:50:34 PM

tlmfru wrote:
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:6sp1fpF7eupmU1@mid.individual.net...
>
>>>> Absolutely. Seen it many times. COBOL replacing Assembler was one
>>>> such... :-) Instead of developing high level languages which
>>>> enabled people who really weren't programmers to try their hand at
>>>> it, imagine if they had focused on improving the development
>>>> facilities available in Assembler, instead? Programming would have
>>>> stayed with the professionals, and the professionals would have
>>>> been much more productive.
>>>>
>>>> "properly informed" people would have realised that bringing
>>>> computer programming to the masses was a very bad move and there
>>>> would have been no COBOL or PL/1. Platform transportability could
>>>> have been achieved by low-level code conversion software instead.
>>>>
>>>
>>> Tongue-in-cheek here, of course.
>>
>> Well spotted, old fruit... :-)
>>
>>
>>> Although there was definite
>>> resistance to the new thing (Cobol) most of the older programmers I
>>> encountered at the time were eager converts once they found out how
>>> easy it was and how much more they could get done.  And there was a
>>> sizeable group that positively reveled in it from the get-go as they
>>> simply weren't up to the intellectual requirements of Assembler.
>>>
>>
>> Well, where I was workng it was an Assembler shop and the old timers
>> WEREN'T more productive with COBOL at all. In fact,most of them
>> could code rings around the COBOL guys. There was little advantage
>> in a high level language (from the programming perspective), that
>> couldn't be obtained by the use of macros in Assembler...
>>
>
> Your experience / my experience.  It's a wash.
>
>>>>
>>>> Ah, the arrogance of youth... :-) There's usually no malice in it.
>>>> To be fair, getting COBOL programmers to understand and embrace the
>>>> interrupt driven model of programming is sometimes difficult,
>>>> simply because COBOL controls everything and is not designed for
>>>> responding to events. People get used to initiating processes and
>>>> controlling them. When something screams: "Attend to me, NOW!" it
>>>> is a bit of a paradigm shift...
>>>>
>>>> People without the benefit of COBOL experience pick it up very
>>>> quickly.
>>>>
>>>>
>>>>
>>>
>>> Now that's a bit of a canard, you know.
>>
>> You mean a yellow thing in France that quacks?
>
> No, it's a small external sensor, jocularly known as a "whisker",
> used on high-performance jets (including the Concorde & Concordski)
> to aid in attitude control & speed control.
>
> Surprised that you hadn't come across the word before.

I had...:-)
>
>>
>> Given that one online meaning is: "An unfounded or false,
>> deliberately misleading story.", given that I generally avoid lying
>> (it makes life more complex than my tired old brain can
>> accommodate), and given that the comment was based on actual
>> experience gained teaching interrupt driven (PowerCOBOL) programming
>> to COBOL programmers in two different organisations, and to
>> non-COBOL programmers (VB) in one other organisation, I have to say
>> it neither waddles like a duck nor quacks like a duck. My experience
>> has been exactly as stated. (I didn't make it up...)
>>
>
> Who said you did?  Judging by the remainder of your post you are
> arguing about interrupts, not events.

Not really arguing about anything, Peter...

> The distinction is clear, in
> my mind anyway: interrupts are the business of the hardware and the
> O/S; events are actions initiated by the operator of an interactive
> (= using a screen) program.  I did wonder, when I read your post, if
> you were equating the two and decided that you must be, or else you'd
> be changing the subject.  So I was wrong.  I am talking about
> EVENT-oriented programming - which all the engineers learning VB
> smugly informed me they were doing - and it's as such that my remarks
> must be interpreted.
>
> Since you seem to be taking it personally, let me rephrase my
> statement: to wit:  the view that event-oriented programming (as I've
> defined it) can't be done in Cobol  - is WRONG.

I'm not taking it personally, apart from the "canard" which implies I was 
lying ("a false misleading statement"), and it really isn't so important I'd 
get unwrapped about it. As to event-oriented programming being done in 
COBOL, of course it can. PowerCOBOL uses COBOL to handle all events and you 
could argue this is actually better than the DIALOG solution offered by 
MicroFocus, which employs a separate language to do it.

Once an event occurs, the handling of it is often a sequential process and 
can be done in COBOL just as well as in anything else. However, whether 
COBOL is the BEST language to do it, is open for discussion.

If you can't easily detect events in COBOL, you might be struggling to make 
a case for processing them in it.

All the environments that use COBOL for this kind of programming have 
management systems (sometimes called a TP monitor) that do the tricky stuff 
like detecting events and allocating buffers at the right moment.

Mainframe environments like CICS and what used to be IMS/DC (I can't 
remember what they call it now...) are NOT using COBOL to handle the actual 
detection of events, any more than PowerCOBOL does.  By managing terminal 
dependent buffers (The SPA and DHCOMM areas) process state is maintained and 
re-entered at specific points using serial re-usability. NONE of that 
management  is done in COBOL. Just as in PowerCOBOL the actual detection of 
events  is NOT handled by the COBOL programmer; it is all "under the 
covers".

It's a bit like an ant an elephant walking across a swing bridge. The ant 
(COBOL) says to the elephant (TP monitor): "Man, are we rockin' this 
bridge..."  Because some event processes are written in COBOL does NOT mean 
COBOL is a great language for event oriented programming.

VB, Java, and C# on the other hand, manage the events as well as process 
them once they're raised. I can raise an event in C# and I can detect and 
process other events,even interrupting  a process to handle events which may 
have occurrred, then resuming it at exactly the point where I left it. (True 
re-entrancy). I can't do that in COBOL.

>
>
>>> Positing a screen-handler
>>> that the application programmer needn't worry about, then
>>> event-oriented or interrupt-driven programming is straightforward in
>>> Cobol.  You fire out your initial screen and set up the flags to
>>> indicate what you did, then wait for a response.
>>
>> ...or not...
>
> Then the program times out ....

Or the processor goes off and does something else...
>
>>
>>> So long as the
>>> response info includes all identifying info - last key pressed, what
>>> screen was in control, what information was entered - then the
>>> program will always know what to do.  There will be processing
>>> particular to the screen in control, there may be successor screens
>>> to set up. file i/o to do, termination, etc.  But in no case is the
>>> list of possible events very large: I can't imagine why an
>>> application program would care that the window was resized or moved;
>>> that's the screen handler's business.  The program can always relate
>>> its previous state to the current action required.  Your statement
>>> above that Cobol controls everything is misleading in this case: all
>>> it's doing is presenting the info and waiting for the user to do
>>> something, then responding to that something.
>>
>> And, according to your own statement above "You fire out your
>> initial screen and
>> set up the flags to indicate what you did, then wait for a response"
>>
>> How is that NOT controlling the process?
>
> So you don't do this in VB or C++ ?????  Come on, man, get real;
> you're flailing.

You think so?  :-) One of us certainly is...

I don't personally do it in VB or C++... no.
>
>>
>> It's a semantic argument anyway. I stated that "COBOL controls
>> everything and is not designed for responding to events", but that
>> comment was about general use of COBOL, NOT using it in the scenario
>> you posited.
>>
>
> Well, then, you're excluding an unreasonable amount of  "Cobol as she
> is used".  The scenario as I posited it is a common one.  Define
> "general use".
>

I don't wish to annoy you any further, so I think not....:-)

>>
>> Hmmm...You are describing ONE model of interrupt driven processing
>> and it is not a good one. (A good one WOULD return control to the
>> statement immediately following the dequeue. This is achieved by
>> true re-entrancy which, historically, has not been available in
>> COBOL, because access to the system context is not generally
>> available in COBOL... Specifying RENTRANT in a compiler directive
>> does NOT mean the system can or will do the necessary context switch
>> with all registers and the instruction counter being saved and
>> restored, at any point where you want it to... like immediately
>> before your dequeue boundary) A true interrupt driven process would
>> handle other interrupts besides the one it was "waiting for" in your
>> scenario and it would involve true re-entrancy, rather than the
>> serial re-usability you have described.
>>
>> But I didn't want to digress into interrupt driven processing (as
>> interesting as that may be...)
>>
>
> Since you have already so digressed ... I hope I've made it clear
> what I was talking about.  Events, not interrupts.

Unfortunately (for this discussion) events are detected by means of 
interrupts being raised, thus inextricably intertwining the two concepts.


>  I'm familiar
> enough with re-entrant protramming, thank you, having done some in
> the '70's, using Cobol; although I was not using the Univac 1100's at
> the time, I know the Cobol compilers it had could generate re-entrant
> code.  I didn't like it all that much because the rules were
> unfamiliar but I used it successfully.  And they were serially
> re-usable OR multi-threaded: I had to do both, not in the same
> program, of course.
>
> Your note about context switching etc. has to do with the o/s running
> the programs: dynamic memory allocation, dynamic memory
> re-allocation, release of control, re-establishing control, etc.,
> etc.: nothing to do with re-entrant programming at all.

It is the essence of truly re-entrant programming. A process cannot be 
re-entered "properly" unless it's previous context can be restored. Anything 
else called "re-entrancy" is simply a misnomer. You can certainly "re-enter" 
a process in COBOL at defined points, but between those points the process 
is "serially reusable", not re-entrant in the true sense of the word.


>What I was
> talking about was the program using its own WORKING STORAGE to
> specify what it's been up to.  It doesn't give a hoot where it's
> running in memory, or if it loses control voluntarily (an I/O-out) or
> due to time-slice expiration: it just needs to have its own "memory"
> to carry on.

In which case you would need a copy of the program for every terminal you 
were servicing. A terminal dependent buffer serves this purpose much better.

> I've never had to write a program that had to be aware
> of its own context: I wrote the things and it was up to the compiler
> & o/s to worry about the dirty details.

Exactly. The dirty details were not handled in COBOL... I think that was 
what I said.
>
>
>> If you seriously disagree that in general, outside of contrived
>> interrupt scenarios, "COBOL controls everything and is not designed
>> for responding to events", then by all means make your case. But
>> please don't call me a liar or "misleader" if I make mine with an
>> honest statement based on actual experience.
>>
>
>
> Well, if you must use "interrupts" and "events" in the same sentence
> to mean the same thing, then I guess I can't discuss it with you.

As it was never my intention to have such a discussion in the first place, 
I'm fine with that. :-)

> If
> you really consider my "scenario" to be contrived - I have to wonder
> where you're coming from.  In any event, I did not call you a liar or
> a misleader: you read that into my question.

Peter, if you refer to something I wrote, based on actual events in the real 
world, which I have experienced, with a phrase which means "false or 
misleading", is it unreasonable to "read into" your response that you are 
calling me a liar or misleader? Maybe I'm over-sensitive and no such offense 
was intended. If so, I'm sorry.

>Did you sleep with a
> large kakapo the previous night?  Uncomfortable bedmates, kakapos.
>

Kakapos are far too rare to ever have the privilege of sleeping with one. I 
have heard kiwis (the birds, not the people...) in the bush at night but 
have never encountered a kakapo. You might be thinking of katipo which is a 
spider. Also extremely rare and only found in driftwood on certain beaches.

And no, these days for the most part, I sleep alone, and the sound sleep of 
the just... :-)

Pete
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/10/2009 8:44:50 PM

On Jan 10, 12:08=A0pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Richard wrote:
> > On Jan 10, 1:06 am, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
> >> Richard wrote:
> >>> On Jan 8, 3:17 pm, "Pete Dashwood"
> >>> <dashw...@removethis.enternet.co.nz> wrote:
> >>>> Hi Peter,
>
> >>>> Very good response from both you and Howard. So I'm taking some
> >>>> time out to reply, although some of what I originally wrote was not
> >>>> entirely serious...:-)
>
> >>>> tlmfru wrote:
> >>>>> You'll remember the scene of about 15-20 years ago when the PC
> >>>>> tsunami seemed to be about to take over the IT world, when even
> >>>>> mighty IBM was reeling under the assault, when the BUNCH
> >>>>> (Burrroughs, Univac, NCR, CDC, and Honeywell) were effectively
> >>>>> eliminated as mainframe companies (stipulating that
> >>>>> Burroughs/Univac still exist as Unisys, but with a vastly changed
> >>>>> business model). At that time there was much comment as to what
> >>>>> IBM should do. I remember a series of articles in Computerworld (I
> >>>>> think) expressing opinions; most of them suggested a radical
> >>>>> change of course, some going so far as to insist that IBM must
> >>>>> implement Windows on its machines and abandon its own o/s'es!
> >>>>> None of which they did.
>
> >>>> I was working for CDC at the timeof the anti-trust suit and
> >>>> remember these times very well. I later worked for IBM just after
> >>>> the dismay at losing thier leadership (both market and corporate)
> >>>> was beginning to be felt, and I think the only thing that saved
> >>>> them was the appointment of a CEO who knew what was going on. It's
> >>>> hard to believe that a company whose net profit was equivalent in
> >>>> one year to the GNP of New Zealand, could, within a few years, be
> >>>> in danger of losing it altogether.
>
> >>>> (Some might say this is a lesson MicroSoft would do well to
> >>>> remember...)
>
> >>> While some will hope that they don't learn from the past and will
> >>> repeat it themselves.
>
> >>>>> How does this relate to the questions expressed below?
>
> >>>>> Only this: that a great deal of the changes in this industry are
> >>>>> driven by sincere but not always well-informed enthusiasms.
>
> >>>> Absolutely. Seen it many times. COBOL replacing Assembler was one
> >>>> such... :-) Instead of developing high level languages which
> >>>> enabled people who really weren't programmers to try their hand at
> >>>> it, imagine if they had focused on improving the development
> >>>> facilities available in Assembler, instead? Programming would have
> >>>> stayed with the professionals, and the professionals would have
> >>>> been much more productive.
>
> >>>> "properly informed" people would have realised that bringing
> >>>> computer programming to the masses was a very bad move and there
> >>>> would have been no COBOL or PL/1. Platform transportability could
> >>>> have been achieved by low-level code conversion software instead.
>
> >>>> I
>
> >>>>> instance acouple of my younger colleagues who goggled with awe at
> >>>>> the successive announcements of a new chip with 10% more speed;
> >>>>> "jeez, I've got to have that", they would cry, then be utterly
> >>>>> unable to understand why I didn't follow suit; or the engineers
> >>>>> who were learning VB assuring me that they were using a new
> >>>>> "event-oriented" method of programming which I wouldn't
> >>>>> understand,
>
> >>>> Ah, the arrogance of youth... :-) There's usually no malice in it.
> >>>> To be fair, getting COBOL programmers to understand and embrace the
> >>>> interrupt driven model of programming is sometimes difficult,
> >>>> simply because COBOL controls everything and is not designed for
> >>>> responding to events. People get used to initiating processes and
> >>>> controlling them. When something screams: "Attend to me, NOW!" it
> >>>> is a bit of a paradigm shift...
>
> >>>> People without the benefit of COBOL experience pick it up very
> >>>> quickly.
>
> >>>>> then shamefacedly
> >>>>> admitting that my advice worked; one real enthusiast declared in
> >>>>> print that once C replaced Cobol, maintenance costs would
> >>>>> immediately come down.
>
> >>>> Well, they did with the advent of C++. (The OO features mean reuse
> >>>> and less maintenance.) I still wouldn't advocate C or C++ as a the
> >>>> preferred choice for Business code development; especially not when
> >>>> there is C# which combines the best of these worlds with the best
> >>>> of the Java world as well, and even throws in a smattering of VB
> >>>> for good measure... :-)
>
> >>> The issue of maintenance costs was the subject of an infamous
> >>> Datamation article in the mid 80s. They surveyed various development
> >>> departments and identified the language used and the time spent on
> >>> 'new' and 'maintenace'. Of course most in-house and packaged
> >>> business software has 'maintenance' as developments needed to meet
> >>> changing business requirements, while non-business applications in
> >>> C tended to only refer to bug fixing as 'maintenance' and feature
> >>> enhancement as 'new development'
>
> >>> The conclusion of the article that if C was used, rather than Cobol,
> >>> then costs would be slashed because maintenance would disappear was
> >>> grossly flawed. The maintenance requirement was a function of the
> >>> application type, not of the language.
>
> >>> Even your claim that OO reduces maintenance is flawed.
>
> >> No, it isn't. I have figures and statistics collected over 3 years
> >> to back it up. I was saving before that, but that is all I have
> >> documented.
>
> >> I can't speak to other people's experience, but in my case, at
> >> least, moving from procedural to OO COBOL was a major step in
> >> increasing overall ROI. Moving to C# has increased it again because
> >> productivity is higher, and using .NET means that "old" and "new"
> >> can play nicely together without problem. This extends the life of
> >> the "old".
>
> >>> It may do so
> >>> because one does not change an existing class (maintenance) but one
> >>> writes a _new_ class that inherits from the old and has the
> >>> differences catered for. Claiming that this is therefore 'less
> >>> maintenance' fails to acknowledge that it arrives at the same result
> >>> after much the same effort (but can eventually lead to inheritance
> >>> hell).
>
> >> No, you have failed to realise that with a component based approach
> >> things are much more configurable. It isn't just about extending
> >> existing classes (although that certainly figures in it). Behaviour
> >> can be changed by configuration, by the order that components are
> >> activated in, by adding or configuring Framework Classes that
> >> require no maintenance at all, or by minor changes in the "glue"
> >> that holds everything together.It doesn't ALWAYS require a Class
> >> extension. The reason I say that OO component based approaches
> >> require less maintenance is because of granularity, not becase of
> >> the innate mechanics of this architecture.
>
> >> As for ".dll Hell" I've not personally experienced it. I have good
> >> inventories of the components I use and the .NET framework is very
> >> well documented, publicly, so the components available from there
> >> are easily recognized. Provided proper design is done, there should
> >> be no need to descend into "inheritance (or any other kind of) hell".
>
> >> <snip>.
>
> >>>> I'd almost agree here. Unfortunately, it isn't just about "business
> >>>> problems", it is also about how solutions should be deployed and
> >>>> how responsive these solutions are to a rapidly changing business
> >>>> environment. If I need some "intelligence" at the Ulan Bator end of
> >>>> the corporate network so the boys can keep us updated on the price
> >>>> of mare's milk and spot emerging market opportunites, I need a
> >>>> different solution than the one I use when I'm talking to Farmer
> >>>> Brown about the price of cheese, for local distibution. And if the
> >>>> Mongolians suddenly decide they might go for cows instead of
> >>>> horses, I need to be able to amend my solution very quickly.
>
> >>>> There was a time when a computer sat in the middle of the office
> >>>> and did its thing. Both problems and solutions were simple and
> >>>> relatively static. People communicated wth it by means of green
> >>>> screens which it drove by timeslicing the power of its processor.
> >>>> (And this was considered a very lucky break, after having to
> >>>> provide punch cards and receive information printed on screeds of
> >>>> green lineflo...)
>
> >>> Actually many computers still do that, except the screens are multi-
> >>> coloured, and they may be in the middle of some other office.
>
> >> I haven't seen anything recently driving a 3270 screen in 32K of
> >> Foreground 1, but I'll take your word for it. :-)
>
> > Nor have I, but do you think that a TSE or Citrix server doesn't use
> > timeslicing ?
>
> > Do you think that IIS or Apache doesn't have a timeslicing box running
> > it ?
>
> I agree timeslicing is a useful technique, but I mentioned it in the cont=
ext
> that there was only ONE "intelligence" available to do everythng, includi=
ng
> driving the user interface. The servers you mention may well employ
> timeslicing, but when this gets a bit much, additional servers, and
> processors can be deployed to "distribute" the load. That was not always =
the
> case.

Dual and multi-processors have been with us for decades. Even the ICL
1908 was a dual or quad 1906 running George 4, and that was the 60s.

But even dual quad-core machines must timeslice when they are running
dozens, or hundreds, of tasks.

I have clients on a single CPU server with over 20 users <shrug>, but
it don't run Windows, and there's the difference.


> In the mainframe world of yesteryear distributed processing was a relativ=
e
> latecomer. IBM released their block MUX and advanced DMA architectures,
> which were a kind of separation designed to ease the CPU load, then
> intelligent subsystems like 3330 started including processors which sorte=
d
> disk requests by track and optimized head movemet, =A0the CDC 6600 (avail=
able
> in the mid-60s, years ahead of its time and many times faster than anythi=
ng
> else around) range was the first system I recall which actually had separ=
ate
> I/O processors (9 of them, with a 10th one co-ordinating everything - the=
re
> had to be 10 to match the 10 processor cycles required to execute an
> instruction.), but all of this (apart =A0from the 6600) was AFTER the sce=
nario
> I described.

Punch cards and green lineflow lasted well into the 70s, your
arguments are rather flexible.


> Processors (and hand made memory) were prohibitively expensive and...
>
> read more =BB

0
Reply riplin (4127) 1/10/2009 9:59:28 PM

On Jan 10, 12:08=A0pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Richard wrote:
> > On Jan 10, 1:06 am, "Pete Dashwood"
>
> Processors (and hand made memory) were prohibitively expensive and
> processing was centralised by necessity. This was the world where COBOL
> evolved and that was the world it was (and still is...) very well suited
> for.
>
> That was my point.

It was not well made then.

Or perhaps I simply disagree with it.

Since the late 70s I have been using Cobol on networked (DRS20) and
multi-user (MP/M and Unix) micros and found it very well suited. In
the early 80s I wrote Windows based graphics programs (not just GUI
but Graphics) and CGI web based system and found Cobol to be very well
suited.



0
Reply riplin (4127) 1/10/2009 10:06:56 PM

On Jan 11, 7:50=A0am, "tlmfru" <la...@mts.net> wrote:
> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote in message
>
>
> > > Now that's a bit of a canard, you know.
>
> > You mean a yellow thing in France that quacks?
>
> No, it's a small external sensor, jocularly known as a "whisker", used on
> high-performance jets (including the Concorde & Concordski) to aid in
> attitude control & speed control.

The Concorde does not have canards, the Tu-144 did.

0
Reply riplin (4127) 1/10/2009 10:12:52 PM

On Jan 11, 9:44=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> tlmfru wrote:
> > Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote in message
> >news:6sp1fpF7eupmU1@mid.individual.net...
>
> >>>> Absolutely. Seen it many times. COBOL replacing Assembler was one
> >>>> such... :-) Instead of developing high level languages which
> >>>> enabled people who really weren't programmers to try their hand at
> >>>> it, imagine if they had focused on improving the development
> >>>> facilities available in Assembler, instead? Programming would have
> >>>> stayed with the professionals, and the professionals would have
> >>>> been much more productive.
>
> >>>> "properly informed" people would have realised that bringing
> >>>> computer programming to the masses was a very bad move and there
> >>>> would have been no COBOL or PL/1. Platform transportability could
> >>>> have been achieved by low-level code conversion software instead.
>
> >>> Tongue-in-cheek here, of course.
>
> >> Well spotted, old fruit... :-)
>
> >>> Although there was definite
> >>> resistance to the new thing (Cobol) most of the older programmers I
> >>> encountered at the time were eager converts once they found out how
> >>> easy it was and how much more they could get done. =A0And there was a
> >>> sizeable group that positively reveled in it from the get-go as they
> >>> simply weren't up to the intellectual requirements of Assembler.
>
> >> Well, where I was workng it was an Assembler shop and the old timers
> >> WEREN'T more productive with COBOL at all. In fact,most of them
> >> could code rings around the COBOL guys. There was little advantage
> >> in a high level language (from the programming perspective), that
> >> couldn't be obtained by the use of macros in Assembler...
>
> > Your experience / my experience. =A0It's a wash.
>
> >>>> Ah, the arrogance of youth... :-) There's usually no malice in it.
> >>>> To be fair, getting COBOL programmers to understand and embrace the
> >>>> interrupt driven model of programming is sometimes difficult,
> >>>> simply because COBOL controls everything and is not designed for
> >>>> responding to events. People get used to initiating processes and
> >>>> controlling them. When something screams: "Attend to me, NOW!" it
> >>>> is a bit of a paradigm shift...
>
> >>>> People without the benefit of COBOL experience pick it up very
> >>>> quickly.
>
> >>> Now that's a bit of a canard, you know.
>
> >> You mean a yellow thing in France that quacks?
>
> > No, it's a small external sensor, jocularly known as a "whisker",
> > used on high-performance jets (including the Concorde & Concordski)
> > to aid in attitude control & speed control.
>
> > Surprised that you hadn't come across the word before.
>
> I had...:-)
>
>
>
> >> Given that one online meaning is: "An unfounded or false,
> >> deliberately misleading story.", given that I generally avoid lying
> >> (it makes life more complex than my tired old brain can
> >> accommodate), and given that the comment was based on actual
> >> experience gained teaching interrupt driven (PowerCOBOL) programming
> >> to COBOL programmers in two different organisations, and to
> >> non-COBOL programmers (VB) in one other organisation, I have to say
> >> it neither waddles like a duck nor quacks like a duck. My experience
> >> has been exactly as stated. (I didn't make it up...)
>
> > Who said you did? =A0Judging by the remainder of your post you are
> > arguing about interrupts, not events.
>
> Not really arguing about anything, Peter...
>
> > The distinction is clear, in
> > my mind anyway: interrupts are the business of the hardware and the
> > O/S; events are actions initiated by the operator of an interactive
> > (=3D using a screen) program. =A0I did wonder, when I read your post, i=
f
> > you were equating the two and decided that you must be, or else you'd
> > be changing the subject. =A0So I was wrong. =A0I am talking about
> > EVENT-oriented programming - which all the engineers learning VB
> > smugly informed me they were doing - and it's as such that my remarks
> > must be interpreted.
>
> > Since you seem to be taking it personally, let me rephrase my
> > statement: to wit: =A0the view that event-oriented programming (as I've
> > defined it) can't be done in Cobol =A0- is WRONG.
>
> I'm not taking it personally, apart from the "canard" which implies I was
> lying ("a false misleading statement"), and it really isn't so important =
I'd
> get unwrapped about it. As to event-oriented programming being done in
> COBOL, of course it can. PowerCOBOL uses COBOL to handle all events and y=
ou
> could argue this is actually better than the DIALOG solution offered by
> MicroFocus, which employs a separate language to do it.
>
> Once an event occurs, the handling of it is often a sequential process an=
d
> can be done in COBOL just as well as in anything else. However, whether
> COBOL is the BEST language to do it, is open for discussion.

I am not sure that any one claimed any language to be the 'best', it
doesn't have to be the best to be suitable.


> If you can't easily detect events in COBOL, you might be struggling to ma=
ke
> a case for processing them in it.
>
> All the environments that use COBOL for this kind of programming have
> management systems (sometimes called a TP monitor) that do the tricky stu=
ff
> like detecting events and allocating buffers at the right moment.

'All' ???  Well perhaps in your experience, or with a suitably
flexible set of 'all' that excludes the areas that don't do that.

I wrote 100% Cobol event driven graphics programs using the Windows
API (the shame of it!!) without any form of 'TP Monitor'.

In fact TP Monitors are not particularly about 'event driven' so much
as 'multi-user' systems where they maintain context for each user
while processing messages from multiple users.

The more modern systems are web server based. When I wrote Cobol CGI
programs I had to maintain context myself. I suppose one could say I
wrote my own TP Monitor that was Cobol CGI based as the same base code
supported various different systems.


> Mainframe environments like CICS and what used to be IMS/DC (I can't
> remember what they call it now...) are NOT using COBOL to handle the actu=
al
> detection of events, any more than PowerCOBOL does. =A0By managing termin=
al
> dependent buffers (The SPA and DHCOMM areas) process state is maintained =
and
> re-entered at specific points using serial re-usability. NONE of that
> management =A0is done in COBOL. Just as in PowerCOBOL the actual detectio=
n of
> events =A0is NOT handled by the COBOL programmer; it is all "under the
> covers".

I suppose that you would also argue that a CGI program does not
'handle the events', but that merely attempts to define what the
'event' is and catagorise some as 'handled' and some as 'not handled'
and then allocate these to suit your arguiment.


> It's a bit like an ant an elephant walking across a swing bridge. The ant
> (COBOL) says to the elephant (TP monitor): "Man, are we rockin' this
> bridge..." =A0Because some event processes are written in COBOL does NOT =
mean
> COBOL is a great language for event oriented programming.

No one said it had to be the best, or even that it is a 'great'. only
that it does it adequately and is suitable.

It is.


> VB, Java, and C# on the other hand, manage the events as well as process
> them once they're raised. I can raise an event in C# and I can detect and
> process other events,even interrupting =A0a process to handle events whic=
h may
> have occurrred, then resuming it at exactly the point where I left it. (T=
rue
> re-entrancy). I can't do that in COBOL.

Maybe _YOU_ can't.


> >>> Positing a screen-handler
> >>> that the application programmer needn't worry about, then
> >>> event-oriented or interrupt-driven programming is straightforward in
> >>> Cobol. =A0You fire out your initial screen and set up the flags to
> >>> indicate what you did, then wait for a response.
>
> >> ...or not...
>
> > Then the program times out ....
>
> Or the processor goes off and does something else...

The processor is _always_ going off and doing something else, except
when running MS-DOS of course.


> >>> So long as the
> >>> response info includes all identifying info - last key pressed, what
> >>> screen was in control, what information was entered - then the
> >>> program will always know what to do. =A0There will be processing
> >>> particular to the screen in control, there may be successor screens
> >>> to set up. file i/o to do, termination, etc. =A0But in no case is the
> >>> list of possible events very large: I can't imagine why an
> >>> application program would care that the window was resized or moved;
> >>> that's the screen handler's business. =A0The program can always relat=
e
> >>> its previous state to the current action required. =A0Your statement
> >>> above that Cobol controls everything is misleading in this case: all
> >>> it's doing is presenting the info and waiting for the user to do
> >>> something, then responding to that something.
>
> >> And, according to your own statement above "You fire out your
> >> initial screen and
> >> set up the flags to indicate what you did, then wait for a response"
>
> >> How is that NOT controlling the process?
>
> > So you don't do this in VB or C++ ????? =A0Come on, man, get real;
> > you're flailing.
>
> You think so? =A0:-) One of us certainly is...
>
> I don't personally do it in VB or C++... no.
>
>
>
> >> It's a semantic argument anyway. I stated that "COBOL controls
> >> everything and is not designed for responding to events", but that
> >> comment was about general use of COBOL, NOT using it in the scenario
> >> you posited.
>
> > Well, then, you're excluding an unreasonable amount of =A0"Cobol as she
> > is used". =A0The scenario as I posited it is a common one. =A0Define
> > "general use".
>
> I don't wish to annoy you any further, so I think not....:-)
>
>
>
>
>
> >> Hmmm...You are describing ONE model of interrupt driven processing
> >> and it is not a good one. (A good one WOULD return control to the
> >> statement immediately following the dequeue. This is achieved by
> >> true re-entrancy which, historically, has not been available in
> >> COBOL, because access to the system context is not generally
> >> available in COBOL... Specifying RENTRANT in a compiler directive
> >> does NOT mean the system can or will do the necessary context switch
> >> with all registers and the instruction counter being saved and
> >> restored, at any point where you want it to... like immediately
> >> before your dequeue boundary) A true interrupt driven process would
> >> handle other interrupts besides the one it was "waiting for" in your
> >> scenario and it would involve true re-entrancy, rather than the
> >> serial re-usability you have described.
>
> >> But I didn't want to digress into interrupt driven processing (as
> >> interesting as that may be...)
>
> > Since you have already so digressed ... I hope I've made it clear
> > what I was talking about. =A0Events, not interrupts.
>
> Unfortunately (for this discussion) events are detected by means of
> interrupts being raised, thus inextricably intertwining the two concepts.
>
> > =A0I'm familiar
> > enough with re-entrant protramming, thank you, having done some in
> > the '70's, using Cobol; although I was not using the Univac 1100's at
> > the time, I know the Cobol compilers it had could generate re-entrant
> > code. =A0I didn't like it all that much because the rules were
> > unfamiliar but I used it successfully. =A0And they were serially
> > re-usable OR multi-threaded:
>
> ...
>
> read more =BB

0
Reply riplin (4127) 1/10/2009 10:36:40 PM

Yer right, I stand corrected.

PL

Richard <riplin@Azonic.co.nz> wrote in message
news:b867573d-5929-406d-8c15-cccf9e1faa5c@f40g2000pri.googlegroups.com...
On Jan 11, 7:50 am, "tlmfru" <la...@mts.net> wrote:
> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote in message
>
>
> > > Now that's a bit of a canard, you know.
>
> > You mean a yellow thing in France that quacks?
>
> No, it's a small external sensor, jocularly known as a "whisker", used on
> high-performance jets (including the Concorde & Concordski) to aid in
> attitude control & speed control.

The Concorde does not have canards, the Tu-144 did.



0
Reply lacey1 (490) 1/11/2009 12:12:46 AM

Richard wrote:
> On Jan 10, 12:08 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> Richard wrote:
>>> On Jan 10, 1:06 am, "Pete Dashwood"
>>
>> Processors (and hand made memory) were prohibitively expensive and
>> processing was centralised by necessity. This was the world where
>> COBOL evolved and that was the world it was (and still is...) very
>> well suited for.
>>
>> That was my point.
>
> It was not well made then.
>
> Or perhaps I simply disagree with it.

Probably both of the above. :-)


>
> Since the late 70s I have been using Cobol on networked (DRS20) and
> multi-user (MP/M and Unix) micros and found it very well suited.

That doesn't mean you wouldn't have found something else even better 
though... we'll never know :-)

> In
> the early 80s I wrote Windows based graphics programs (not just GUI
> but Graphics) and CGI web based system and found Cobol to be very well
> suited.

Fair enough. If it works well for you I am persuaded by that argument.

I thought it was working well for me, but it was only when I moved that I 
realised what I'd been missing.

However, we work in different environments so mileage may well vary.

I've developed web sites with CGI in COBOL and it did work well. But there 
is no comparison (at least as far as I'm concerned) in doing that (or even 
using ISAPI) and using C# code behind with ASP.NET, Silverlight and Ajax. 
They are different worlds, I think. The facilities available, the things you 
can do, how quickly and easily you can do them, and the time from design to 
deployment, are all factors to take into account.

As far as I'm concerned, COBOL is not relevant to the tasks I find myself 
faced with these days. C# is quicker, smarter, cooler, better supported, and 
cheaper in both capital cost and cost of ownership.

However, I'm not in the business of selling it and I have no vested interest 
in any specific development software.

I post here simply to share an experience and show that there ARE other 
options and it is no longer necessary to tolerate expensive compilers and 
run times, poor support, and 1960s approaches to data processing.

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 1/11/2009 12:54:39 AM

On Jan 11, 1:54 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> Richard wrote:
> > On Jan 10, 12:08 pm, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
> >> Richard wrote:
> >>> On Jan 10, 1:06 am, "Pete Dashwood"
>
> >> Processors (and hand made memory) were prohibitively expensive and
> >> processing was centralised by necessity. This was the world where
> >> COBOL evolved and that was the world it was (and still is...) very
> >> well suited for.
>
> >> That was my point.
>
> > It was not well made then.
>
> > Or perhaps I simply disagree with it.
>
> Probably both of the above. :-)
>
> > Since the late 70s I have been using Cobol on networked (DRS20) and
> > multi-user (MP/M and Unix) micros and found it very well suited.
>
> That doesn't mean you wouldn't have found something else even better
> though... we'll never know :-)

Well actually I _DO_ know, and did at the time.

For a start I wasn't claiming it was "the best" (for whatever criteria
anyone may wish to set), but it was perfectly suitable.

I could write code that worked in a multi-user environment with file
sharing and record locking that worked accross many platforms: ICL
DRX, MP/M, Unix without much code change (small things like file name
formats), that later went to Multi-User DOS, Windows and Linux with
various compilers. Some code is still in use, and still being
developed for new needs, nearly 30 years later.

Of course I evaluated alternatives at the time and every year since.
Nothing that was available over that time has survived. There may well
have been 'better' stuff, but only at huge prices that my clients
would not have paid.

While others may have gone down the Algol -> Pascal -> Delphi -> C++ -
> Java -> C# route, what are they planning for their next language
move ?

As it happens Most of my development last year was done in Python: web
based systems (with AJAX), unattended middleware, GUI (with Glade),
database (with MSSQL and Postgress). It just runs and works on
everything from my handheld to servers, including Windows.

But that wasn't available 30 years ago.

The last couple of months I am back developing with Cobol adding new
features to an existing application.

> > In
> > the early 80s I wrote Windows based graphics programs (not just GUI
> > but Graphics) and CGI web based system and found Cobol to be very well
> > suited.
>
> Fair enough. If it works well for you I am persuaded by that argument.
>
> I thought it was working well for me, but it was only when I moved that I
> realised what I'd been missing.

> However, we work in different environments so mileage may well vary.
>
> I've developed web sites with CGI in COBOL and it did work well. But there
> is no comparison (at least as far as I'm concerned) in doing that (or even
> using ISAPI) and using C# code behind with ASP.NET, Silverlight and Ajax.
> They are different worlds, I think. The facilities available, the things you
> can do, how quickly and easily you can do them, and the time from design to
> deployment, are all factors to take into account.
>
> As far as I'm concerned, COBOL is not relevant to the tasks I find myself
> faced with these days. C# is quicker, smarter, cooler, better supported, and
> cheaper in both capital cost and cost of ownership.

I had found all that with Python long before C# was thought up. While
you are acting like a 'born again' C# fanboy who has been liberated
from the 'drudgery' or Cobol, many may have developed ways of mixing
different systems to achieve levels of productivity that you didn't
manage with Cobol.


> However, I'm not in the business of selling it and I have no vested interest
> in any specific development software.
>
> I post here simply to share an experience and show that there ARE other
> options and it is no longer necessary to tolerate expensive compilers and
> run times, poor support, and 1960s approaches to data processing.

While you may have been taking "1960s approaches to data processing"
with your Cobol work this does not mean that everyone does.


> Pete.
> --
> "I used to write COBOL...now I can do anything."

0
Reply riplin (4127) 1/11/2009 7:23:59 PM
comp.lang.cobol 4196 articles. 3 followers. Post

67 Replies
316 Views

Similar Articles

[PageSpeed] 27


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

Validating date date
I have a large data set with a number of variables that have dates in it. Is there a way of checking that it is a valid date ie the data looks like Var1 var2 var3 28/06/2006 . 32/01/2001 28/06/2006 . 27/10/2007 28/06/2006 27/10/2007 27/10/2007 28/06/2006 27/10/2000 27/10/2007 28/06/2006 27/10/2001 27/10/2007 28/06/2006 27/10/2004 27/10/2007 28/06/2006 27/10/2010 27/10/2007 so basically i can do if missing (var2) then output a; which will identify missi...

Re: Validating date date
Jeli , If you would convert your date values to SAS Date values two things will happen: 1.) You will have a Data Value which you can actually work with 2.) SAS wont convert an invalid text Date Value to a SAS Date Value. Toby Dunn From: jeli0703@HOTMAIL.CO.UK Reply-To: jeli0703@HOTMAIL.CO.UK To: SAS-L@LISTSERV.UGA.EDU Subject: Validating date date Date: Thu, 29 Jun 2006 08:38:43 -0700 I have a large data set with a number of variables that have dates in it. Is there a way of checking that it is a valid date ie the data looks like Var1 var2 var3 ...

Date Validation
Hi Everyone, I've got a form that provides a pop-up calendar for users to select dates for requesting jobs to be completed. The calendar works great, but it unfortunately allows users to select dates earlier than today (which they should't be allowed to do). I've started coding some validation scripts, but I'm stuck now and my approach doesn't seem to be working. I've Googled all morning looking for an answer and couldn't find one and I searched the newsgroups as well. Below is my code: <html> <script language="JavaScript" type="te...

Re: Validating date date #3
Like Toby said: the best way to test if a date is valid, try to convert it and test the _error_ variable. 71 data q; 72 x="28/06/2006"; 73 y=input(x,ddmmyy10.); 74 put y date9.; 75 x="31/06/2006"; 76 y=input(x,ddmmyy10.); 77 put y date9.; 78 run; 28JUN2006 NOTE: Invalid argument to function INPUT at line 76 column 7. . x=31/06/2006 y=. _ERROR_=1 _N_=1 NOTE: Mathematical operations could not be performed at the following places. The results of the operations have been set to missing values. Each place is given by:...

setting date format to validate date in ruby
Hi, I'm just learning ruby. I was searching for date validation in ruby and found this: ================================================================================ for date in dateArray if %r{(\d\d)/(\d\d)/(\d\d\d\d)} =~ date mday, month, year = $1.to_i, $2.to_i, $3.to_i puts date if Date.valid_civil?(year, month, mday) else puts "Invalid Format" end end ================================================================================ This seemed to do the job but found out not. The problem is it only validates the 01/12/2008 but 1/2/2008 fails. Also ...

Struts Validator to validate *optional* date fields?
Does anyone know how to use the Struts Validator to validate dates on *optional* fields? The Validator validates dates fine but it always returns an ActionError if the field is empty. We would like to ensure that any entered date is valid but not enforce the user to enter a date. We tried removing the depends="required" from validator-rules.xml but the problem remains. Does anyone have any ideas? Thanks One add'l note. It seems it is possible to validate optional integer and long fields. Just not dates. With numeric, the Validator does not create a requierd error if the ...

Re: Validating date date #4 669980
On Thu, 29 Jun 2006 10:33:54 -0700, tanwan <tanwanzang@YAHOO.COM> wrote: >SAS will never accept INVALID dates, so all you to check for invalid >dates is to convert them (I guess from char variables) to SAS dates. >Invalid dates (past and future) will be set to missing. For example, >2007 is will not be a leap year but 2008 is, November has 30 days in >every year, and no month has 32 days! > > >data INVALID; >input pseudodate anydtdte10.; >format pseudodate date9.; >datalines; >29/02/2007 >31/11/2004 >32/09/2006 >proc print;run; > >data ...

Re: Validating date date #4 1555142
If one has V9 you can do the following: data q ; x = "28/06/2006" ; y = input( x , Anydtdte10. ) ; put y= date9. ; x = "31/06/2006" ; y = input( x , Anydtdte10. ) ; put y= date9. ; run ; I know Ian doesnt like the use of the AnyDtDte informat, but in this case it does exactly what you want, it converts valid Date values to SAS Date Values and if it isnt valid simply doesnt convert the value. the upside is that it doesnt create any nasty notes in the log. Toby Dunn From: Gerhard Hellriegel <ghellrieg@T-ONLINE.DE> Reply-To: Gerhard Hellriegel <ghellrieg@T...

Computed PERSISTED column for dates that tests for valid date: How To
What I want to do: Make a PERSISTED computed column that converts a string to a date, and tests the string for valid dates before attempting the conversion. Does anyone know how to make ISDATE deterministic (BOL indicates it could happen) Background: I can't always guarantee the column to be converted is a valid date. I wish i could, but the source is out of my control. I would prefer not to PERSIST derived data, but I need to in this case. I planned to use ISDATE to test for legal dates in the conversion, but SQL tells me the ISDATE function is non-deterministic. I get ...

date validation
hello just a quickie: how do I do date validation with the Date class? *confused* /G -- http://www.gh-webinteractive.com Bob Smith <greger@gh-webinteractive.com> wrote: > just a quickie: > how do I do date validation with the Date class? You don't: the Date class represents dates, it doesn't validate them. What you can do, is create a SimpleDateFormat with the date format you want. For example "yyyy-MM-dd'T'HH:mm:ss", the ISO datetime format without timezone. You then let this SimpleDateFormat instance parse the date. It it succeeds, the date is valid....

Date validation
I have an abc app being run thru the web. On a form I have a date field - @D6 - the default is today(). If I enter an invalid date it gives no message but inserts today's date instead. Anyone know of a date function or method of validating the entry at time of entry - bearing in mind that I'm running it thru the Web? Many thanks in advance Jenny Jenny, When you enter a date (or any field) on a web form, if you want some action then you have to force a refresh of the screen or control with internet settings for the control itself. I haven't played with this specifically but...

Date range not found, please try again with a valid date range
(Please note I have waited about 4 hours for this to post on GigaNews. Am reposting with the admitted risk that it may double post. I apologize if this happens...) Using FM 5.0 for our non profit org to control and report on client visits and activities. Today, for some reason, I can't pull a report showing yesterday's visits. I don't know what happened at last evening's session-there was some indication that a problem occurred - it had something to do with being unable to view the last names of newly added records but no one at the session could clearly define what...

validating dates
The date values are stored on the file as stings, with the format '31.12.2005'. The tast is to test if the dates are valid according to the gregorian calender. Assume I read the values into a dataset as stings, and do the validation test from there on. data dates; attrib date_values length=$12.; infile cards; input @1 date_values $12.; datalines; 0000000000 01.05.2001 31.12.2002 01.02.2002 31.09.1999 40.10.1998 20.04.1800 22644840 01.01.21000 run; The 31. of september is not valid, neither is the 40. of october. And '22644840' is a phone number. May be a blan...

valid date
Hi, I have the following problem. I get data delivered in a text file with dates in the format yyyymmdd, f.i. 20041026. Sometimes there is a mistype, like 09740101, instead of 19740101. The problem is known and apparently the organization is unable, or unwilling to solve this problem in the front. What I want to do, is to check if there's a valid date, without any error messages or other notes in the SAS log. Because it is a known issue, one doesn't check the error messages any more if they appear. Instead I want to write the erroneous records to a separate file, again without any e...

date validation
Was wondering if anyone can help my friday mind block I have a dataset with a number of variables in it, some of which are dates. However 2 of the date variables are in character format whilst all the others are numeric, thus i can assume that if it was incorrect it would be ., i need to pass it through a quality check to make sure that the dates are in the correct format ddmmyy10. and if they fall outside todays date then suspend that observation otherwise good data. any help?? A similar discussion was held here recently. Plz see http://tinyurl.com/hkpcf Good luck!!! ...

date validation
I am trying to validate whether an input on a GUI is a date. The datenum function returns errors if it is something other than a date. How do I alert the user to only enter a date without command-line errors showing up (I want to compile the program eventually)? Use a try-catch block around your datenum call and in the catch block, put an error/warning dialog that will point out that the input expected is a date format.This way, any error generated will be caught in the 'catch' block and your program can elegantly throw the error instead of terminating at that point. See help try...

Date validation
Hi! I have a form which contains many fields for users to fill in. One of them is a date field, where I'd like to code some input validation. The problem is that if the user fills in the field incorrectly and saves the form, the field value after that is just an error message: "Re: ERROR: Unable to interpret Time or Date". So what I need is an input validation that checks the date fields whenever the form is saved. How should I do that? The input validation should allow different kinds of date types, e.g. 12.5.2004, 2004-5-12, and then convert them to the date type use...

Is not a valid date
Hi, In an application I write for a W2003 server I have the following line: DateAppointment:=StrToDate('8-9-2003'); I get: '8-9-2003 is not a valid date error' The ShortDateFormat is d-M-yyyy so it should work OK, on another server (W2000) I do not have this problem. What am I doing wrong? Greetings, Ronald van der Pas On Wed, 17 Sep 2003 14:05:06 +0200, "Ronald van der Pas" <rvdpas@TAKETHISOUTwanadoo.nl> waffled on about something: >Hi, > >In an application I write for a W2003 server I have the following line: > >DateA...

How to validate date and time?
I have a program that deals with files with names such as SA_2005-01-03_01-00-00_sqf1974_1.0.0_Iub_Iu_CT.csv The format is SA_<date>_<time>_.... Befor processing a file, I would like the program to validate the filename by checking whether the date and time parts are correct. I tried using mktime, hoping for perl to return an error value if the date and time are wrong. But for some reason even if I give plain text in the time part, mktime does not return an error. I use ActivePerl 5.8.2 on Windows 2000. This does not have the Date module. Can someone suggest a way to do the validat...

Date validation issue
Hi guys I'm having a hard time trying to validate some dates. I have a form that accept dates from users in this format (YYYY-mm-dd). I've been looking at the available datetime functions and I'm still clueless as to how they can help me achieve my goals. what I need to do id check is: 1- convert the input string into date first. At this point I couldn't find any srtTOdate type of functions. then I tried doing it the hard way...by using "checkdate" function. I could split the string fine (using "explode") but then I was stuck because I couldn't find an...

date validation 325291
hi, is there anyway that I can validate my date format in javascript?? the format should be mmddyy, no space, no dash, and has to include 0 if month is from 1-9, for example 01, 02, like that???? please help me out thanks in advance Wei Wei.Huang@slps.org (weiwei) writes: > is there anyway that I can validate my date format in javascript?? the > format should be mmddyy, no space, no dash, and has to include 0 if > month is from 1-9, for example 01, 02, like that???? Your date format looks correct. Or did you mean to validate dates against the date format? Following a link from thi...

function to validate date?
Hi, Does anyone know a predefined function (or can provide one) that takes three varaibles, $day, $month, and $year and returns whether or not all three constitute a valid date in which it is expected that day is a 2 or 1 digit number, month is a 2 or 1 digit number, and year is a 4 digit number. I'm using PHP 4. Thanks, - Dave laredotornado@zipmail.com wrote: > Does anyone know a predefined function (or can provide one) that > takes three varaibles, $day, $month, and $year and returns whether or > not all three constitute a valid date http://php.net/checkdate -- E. D...

Numeric Date Validation
It has appeared that ancient sources give a method for Numeric Date Validation that involves numerous tests to determine month length; versions are often posted by incomers here. That sort of code seems unnecessarily long. For some while, the following approach has been given here :- function ValidDate(y, m, d) { // m = 0..11 ; y m d integers, y!=0 with (new Date(y, m, d)) return (getMonth()==m && getDate()==d) } and it may remain the shortest code. But it does require, in every case, the creation and disposal of a Date Object. The following is about 50% longer in code...

Simple date validation
I want to perfom a simple date validation on a variable. I have got the following script working, but I want it to fail if it does not match the pattern How do I reverse the test -------------------------------------- case $p1 in [0-3][0-9]/[0-1][0-9]/[0-9][0-9]) echo "Invalid" exit 1 ;; esac ... continue processing -------------------------------------- Thanks Derrick Derk wrote: > I want to perfom a simple date validation on a variable. I have got the > following script working, but I want it to fail if it does not match the > pattern > > How d...