home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / cobol / 709 < prev    next >
Encoding:
Text File  |  1993-01-28  |  3.2 KB  |  84 lines
  1. Newsgroups: alt.cobol
  2. Path: sparky!uunet!think.com!sdd.hp.com!decwrl!pacbell.com!tandem!news
  3. From: Don Nelson <nelson_don@comm.tandem.com>
  4. Subject: Re: comp-3 and ascii data representation
  5. Message-ID: <1993Jan27.200000.14369@tandem.com>
  6. X-Xxdate: Wed, 27 Jan 93 21:13:40 GMT
  7. Sender: news@tandem.com
  8. Nntp-Posting-Host: 130.252.172.59
  9. Organization: Tandem Computers
  10. X-Useragent: Nuntius v1.1.1d16
  11. References: <1k2hkgINNcvi@shelley.u.washington.edu> <1k4t5qINN22j@shelley.u.washington.edu> <1k4v1fINN3pp@shelley.u.washington.edu>
  12. Date: Wed, 27 Jan 1993 20:00:00 GMT
  13. Lines: 69
  14.  
  15. In article <1993Jan27.153424.8408@mfltd.co.uk> James Fidell,
  16. jfid@mfltd.co.uk writes:
  17. >
  18. >In article <1k4v1fINN3pp@shelley.u.washington.edu>, 
  19. >lambert@stein.u.washington.edu (D. Lambert) writes:
  20. >> 
  21. >> If implementaions of Cobol use different file storage formats
  22. >> then wouldn't that make data files not portable?
  23. >
  24. >Yes.
  25. >
  26. >> Would each Data file from say an IBM implementation have to be
  27. converted
  28. >> to ascii representation to be read by a cobol program with the same
  29. >> file defintions on a DG implementation?
  30. >
  31. >Probably.
  32. >
  33. >> I thought that the data was stored the same way. Does the runtime
  34. >> system have anything to do with conversion? I know that the runtile
  35. >> MLS lock server prevents access to users during conficts with other
  36. >> users or security definitions. This prevents corrupting data through
  37. >> simultaneous write access to the file.
  38. >
  39. >Different COBOL vendors write files in different ways -- there is no
  40. >guarantee that a file written by, say, IBM, COBOL will be readable using
  41. >the same program compiled under, say, DG COBOL.
  42. >
  43. Not true.  See below.  All vendors must pass the audit tests and they
  44. require 
  45. reading and writing tapes that can be transported amongst systems (there
  46. is an 
  47. ISO/ANSI standard for these tapes).
  48.  
  49. >IMHO, historically it has been the intention of many language vendors to
  50. >write ``closed'' systems which are incompatible with others, in order to
  51. >tie buyers into their system.
  52. >
  53. Vendors don't use these to tie people into their systems.  They do it
  54. because 
  55. their particular architecture is different than others.  COMP and similar 
  56. formats are particular to their machine and therefore differ from those
  57. on 
  58. other machines.  This is done for efficiency (arithmetic with COMP items
  59. can 
  60. be as much as a hundred times faster than with DISPLAY fields).
  61.  
  62. >I believe, though I would not state categorically, that ANSI specify that
  63. >certain data-types are stored in particular ways in memory (can anyone
  64. >confirm or refute this ?), but that doesn't really get you anywhere.
  65.  
  66. It does get you somewhere.  The ISO/ANSI COBOL Standard does state that 
  67. certain data types are portable.  If the user wants portable files the
  68. method 
  69. is simple.  Do not use any USAGEs other than DISPLAY (the default usage).
  70.  
  71. Specify the SIGN IS LEADING|TRAILING SEPARATE clause for all signed
  72. numeric 
  73. items.  Make the records fixed length.  Write them to a tape that can be
  74. read 
  75. on the other system.  That will do it.  COBOL was designed to allow
  76. porting 
  77. files and programs and it works fine as long as you stick with standard
  78. stuff.
  79.  
  80. Don Nelson
  81. COBOL Development, Tandem Computers, Inc 
  82. nelson_don@comm.tandem.com
  83. No clever quotes here
  84.