home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmmain / 2915 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.6 KB  |  90 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!spool.mu.edu!darwin.sura.net!paladin.american.edu!auvm!UCLAMVS.BITNET!CSYSMAS
  3. Message-ID: <IBM-MAIN%92123009324574@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Wed, 30 Dec 1992 07:30:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
  8. Subject:      Re: Is PL/S a dead language?
  9. Lines: 79
  10.  
  11. > In article <IBM-MAIN%92122814293609@RICEVM1.RICE.EDU> Michael Stein
  12. > <CSYSMAS@UCLAMVS.BITNET> writes:
  13. > >Ha!  Exactly backwards.  PL/S allows writing a structure which
  14. > >you *know* the mapping of, while C doesn't (the C mapping depends
  15. >
  16. > Good point. But PL/S only runs on one machine, so there are no
  17. > endianness or word-size issues.
  18.  
  19. That's a claim that PL/S is consistant with itself (since
  20. only one implementation exists).
  21.  
  22. I claim the requirement on PL/S is more than that -- PL/S
  23. structures *have* to exactly match assembler DSECTs or else the
  24. operating system won't work.  So it's an external mapping which
  25. PL/S must support, not just self consistancy.  (You couldn't
  26. change the PL/S structure mapping and just recompile everything
  27. and expect the system to work...)
  28.  
  29. > It would be possible to say that _for any given CPU_ the layout
  30. > of C structures would be well-defined, but the C standard
  31. > cannot do this.
  32.  
  33. IMHO C should support an additional attribute of a structure
  34. which allows *absolute* structure layouts (hopefully with only
  35. forwards bytes?) where *all* implemetations layout the structure
  36. the same.  This allows exportable binary files as well as binary
  37. network communication.
  38.  
  39.   "C is Portable? Ha!, It can't even talk to itself on different
  40.    machines..."
  41.  
  42. > In fact (FLAME ON) IBM should have way back said what C
  43. > compilers on MVS should do, how they should handle the
  44. > record-oriented file system, what the ASCII-to-EBCDIC
  45. > translation routines should be called, then we wouldn't have to
  46. > put up with oddball compilers.
  47.  
  48. C still wouldn't be compatable with itself across a network...
  49.  
  50. > Your point about SRBs etc. is a good one. But under an SRB it's
  51. > important to have highly optimised code.
  52.  
  53. Ouch.  I dislike the term "optimised code".  Most compiler
  54. optimization techinques are designed to undo the pessimizing (?)
  55. introduced by the language straitjacket or compiler code
  56. generation.
  57.  
  58. As someone said "keep it as simple as possible, but no simpler".
  59.  
  60. > I use MVS TCP/IP a lot and I think many of its problems (not
  61. > just performance) are due to vast amounts of bloated PL/S in
  62. > the system (IRB, SRB, PC-call etc.) code.
  63.  
  64. In the MVS TCP/IP case, I think it's just "bloat", the language
  65. doesn't matter (except one of us users might fix some of it if it
  66. wasn't in PL/S or if we had a PL/S compiler).
  67.  
  68. MVS TCP/IP is not even close to being "as simple as possible".
  69.  
  70. > Surely not all the assembler wizards at IBM are working on
  71. > VM/CMS?
  72.  
  73. They may, by and large, have been raised on VM.  Does anyone know
  74. how IBM assembly programmers are trained?  (IBM seems to use VM
  75. internally too much to raise good MVS programmers..)
  76.  
  77. In my experience, there are lots of good IBM 370/390 programmers
  78. around who do NOT understand the requirements of true
  79. multi-tasking and multi-processor coding.  Not surprising, this
  80. includes (can't be all?) VM systems programmers as well as most
  81. MVS systems programmers.
  82.  
  83. A flurry of CS/CDS is one of the later signs of a belated
  84. admission that everything doesn't happen sequentially.
  85.  
  86. There are also people who have managed to get hold of a PL/S
  87. compiler and pretend to be assembler programmers.  The programs
  88. of these people demonstrate that they don't know what the machine
  89. instructions really do...
  90.