For Programmers: Free Programming Magazines  


Home > Archive > Cobol > September 2005 > Re: Moving display to computational items









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: Moving display to computational items
foodman123

2005-09-20, 6:55 pm

Unless you absolutely HAVE to use COMP for reasons beyond your
control, why bother?

It is virtually impossible to justify the use of COMP in 99% of
the cases; so, why COMPlicate your existence using it?

Had you not done so, you would not have had to waste time
figuring out why it did not work. Then spending time posting on
CLC, then spending time reading the replies. Not to mention the
time spent by the responders replying to your post at the
probable expense of their employers.

Had you not used it, your program would be a memory by now and
you could merrily be on your next one.

(For the flamers, I couldn't used my regular Foodman address
so had to use MotorByte.)

Tony Dilworth

Chuck Stevens

2005-09-20, 6:55 pm

I'll go you one better: presuming you're using USAGE DISPLAY everywhere
(explicitly or implicitly) -- which isn't actually stated -- for any signed
item, why use anything other than SIGN LEADING SEPARATE?

-Chuck Stevens

"foodman123" <motorbyte@aol.com> wrote in message
news:1127247766.474256.184660@o13g2000cwo.googlegroups.com...
> Unless you absolutely HAVE to use COMP for reasons beyond your
> control, why bother?
>
> It is virtually impossible to justify the use of COMP in 99% of
> the cases; so, why COMPlicate your existence using it?
>
> Had you not done so, you would not have had to waste time
> figuring out why it did not work. Then spending time posting on
> CLC, then spending time reading the replies. Not to mention the
> time spent by the responders replying to your post at the
> probable expense of their employers.
>
> Had you not used it, your program would be a memory by now and
> you could merrily be on your next one.
>
> (For the flamers, I couldn't used my regular Foodman address
> so had to use MotorByte.)
>
> Tony Dilworth
>



Arnold Trembley

2005-09-20, 6:55 pm



foodman123 wrote:

> Unless you absolutely HAVE to use COMP for reasons beyond your
> control, why bother?
>
> It is virtually impossible to justify the use of COMP in 99% of
> the cases; so, why COMPlicate your existence using it?


I think it makes sense to use COMP when there is large volume of
computations. Studies have shown that it is faster than COMP-3 in an
IBM mainframe COBOL environmnet, and USAGE DISPLAY is very slow. But
that criteria wouldn't apply in the example cited.

Of course, if the record layout was already in use with COMP fields,
you pretty much have to work with what you've got.

But if the record layout is for a new application I agree it makes
absolutely no sense to use COMP fields for a date in a record key.
Dates are unlikely to have much computation performed on them. I
would argue for a PIC X(8) field, and even a numeric date is fine as
an unsigned USAGE DISPLAY field. How often is a date going to be
negative?


--
http://arnold.trembley.home.att.net/

HeyBub

2005-09-21, 3:55 am

foodman123 wrote:
> Unless you absolutely HAVE to use COMP for reasons beyond your
> control, why bother?
>
> It is virtually impossible to justify the use of COMP in 99% of
> the cases; so, why COMPlicate your existence using it?


EVERY call to my compiler's GUI interface involving setting attributes,
returning status, etc., is COMP (i.e., mostly 2-byte binary). It's easy to
justify - just about nothing works unless I follow the compiler's
conventions. Following constraints over which one has no control isn't
really hard to justify.

>
> Had you not done so, you would not have had to waste time
> figuring out why it did not work. Then spending time posting on
> CLC, then spending time reading the replies. Not to mention the
> time spent by the responders replying to your post at the
> probable expense of their employers.


City Slicker: "Why are you holding that pig up in the air so he can reach
the apples?"
Farmer: "It should be obvious: I'm feedin' the pig."
City Slicker: "Seems like an awful waste of time to me."
Farmer: "What's time to a pig?"



howard.brazee@cusys.edu

2005-09-21, 6:55 pm

On Tue, 20 Sep 2005 21:21:17 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>I think it makes sense to use COMP when there is large volume of
>computations. Studies have shown that it is faster than COMP-3 in an
>IBM mainframe COBOL environmnet, and USAGE DISPLAY is very slow. But
>that criteria wouldn't apply in the example cited.


Sometimes. Sometimes packed is faster than binary. (it converts
quickly)

>Of course, if the record layout was already in use with COMP fields,
>you pretty much have to work with what you've got.
>
>But if the record layout is for a new application I agree it makes
>absolutely no sense to use COMP fields for a date in a record key.
>Dates are unlikely to have much computation performed on them. I
>would argue for a PIC X(8) field, and even a numeric date is fine as
>an unsigned USAGE DISPLAY field. How often is a date going to be
>negative?


I've seen social security numbers stored as packed to save space. Such
efficiency is expensive in an era where space is cheap compared to
programming time.

Your PIC X(8) works well, as long as it is YYYYMMDD format, so
compares are cheap. But be aware of the application "unlikely"
doesn't mean "never".
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com