home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / cobol / 686 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.4 KB  |  59 lines

  1. Newsgroups: alt.cobol
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Hello, anybody out there ?
  5. Message-ID: <9302422.23017@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1993Jan20.232429.10611@shared.com>
  9. Distribution: usa
  10. Date: Sun, 24 Jan 1993 11:32:49 GMT
  11. Lines: 46
  12.  
  13. mikek@shared.com (Mike Kenny) writes:
  14.  
  15. >6. debug tools :
  16. >
  17. >   To my eyes it seems that the one true advantage of the proprietary
  18. >   manufacturer was that the could supply the same development and
  19. >   debug tools with all languages supplied on their hardware.  But where
  20. >   are the integrated debug environments on UNIX ?
  21. >
  22. >   Has anybody else encountered this requirement ? found a solution ?
  23.  
  24. Yes, I have needed to use a debugger.
  25. The ACU debugger is pretty good. (My one major complaint was that
  26. it used paragraph names rather than using paragraph within section,
  27. which was basically useless for us since our coding standard was that
  28. ALL paragraphs were named 'SECT-CONTROL'.)
  29.  
  30. >   lain awake at night dreaming of gdb ?
  31.  
  32. No, I dreamt of Borland's Turbo Debugger and Turbo Profiler ;-)
  33. Especially the profiler - or *any* profiler.
  34. What do you do when your customers complain that your 300,000-line
  35. COBOL system is too slow? :-(
  36.  
  37. >I could go on, but these are MY major complaints with the standards and
  38. >the current state of COBOL. What are yours ?
  39. >
  40. >I am aware that for many people the important issues are those relating
  41. >to screen and file handling and perhaps somebody will post some of these
  42. >if we can get some real COBOL dialog started here. For my own case, we
  43. >use third party screen handlers that need no interaction with the COBOL
  44. >and most of our file handling is done by calls to a database package.
  45.  
  46. We wrote our own screen handler and file handler in COBOL.
  47. (Not quite as masochistic as writing your own COBOL compiler in COBOL ;-)
  48.  
  49. As regards alt. vs comp. status of alt.cobol, if you don't like it then
  50. change it! Read the guide on creating a new newgroup in news.announce.new-users
  51. (or somewhere there in the news hierarchy - perhaps news.answers), post
  52. a Request For Discussion, then issue a Call For Votes, etc.
  53.  
  54. -- 
  55. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  56. This .signature virus is a self-referential statement that is true - but 
  57. you will only be able to consistently believe it if you copy it to your own
  58. .signature file!
  59.