home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / bit / listserv / sasl / 4007 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.8 KB  |  67 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!NIHCU.BITNET!HIS
  3. Message-ID: <SAS-L%92090310063386@UGA.CC.UGA.EDU>
  4. Newsgroups: bit.listserv.sas-l
  5. Date:         Thu, 3 Sep 1992 10:03:45 EDT
  6. Reply-To:     Howard Schreier <HIS@NIHCU.BITNET>
  7. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  8. From:         Howard Schreier <HIS@NIHCU.BITNET>
  9. Subject: Re: SASLIST output before SASLOG output r6.07; what are other
  10.               sites
  11. Lines: 54
  12.  
  13. CONTENT:  Response/Comment
  14. SUMMARY:  Don't require that *all* DD names be alphabetized
  15. REL/PLTF: MVS
  16.  
  17. >   We are moving from r5.18 to r6.07 at our site, MVS batch.  The
  18. > problem is the name change of the SASLIST and SASLOG DDnames.  It
  19. > is a long standing practice at our site to order all the DDnames
  20. > alphabetically in public procs.  In r5.18 of SAS, the SASLIST DD
  21. > name was FORTRAN unit FT12F001 and came after the SASLOG DD name
  22. > FT11F001 (alphabetically).  Consequently, in r5.18, the user would
  23. > always get the LOG output before the LIST output.  However, for
  24. > r6.07, the user always gets the LIST output before the LOG output
  25. > (again, because SASLIST comes before SASLOG alphabetically).
  26. >
  27. >   This has caused a stir for our SAS Software Consultant.  She
  28. > insists that the LOG output MUST come first, for a variety of
  29. > reasons, among them being:
  30.  
  31. [details deleted for sake of brevity]
  32.  
  33. >   My question is, what are other sites doing about this change?
  34. > Or, is it a non-issue at most sites?  There are two ways I know
  35. > of to work around this problem:
  36.  
  37. [details deleted for sake of brevity]
  38.  
  39. This whole thing is real flame-bait, but I'll refrain.
  40.  
  41. As this problem illustrates, the ordering of  DD  statements
  42. is significant.  Therefore, a rigid, arbitrary rule like the
  43. mandatory alphabetization at  this  site  has  some  serious
  44. implications;  in  particular,  there  will be problems with
  45. procedures imported from sites which  don't  adhere  to  the
  46. rule.
  47.  
  48. IMHO, the answer is to  relax  the  alphabetization  policy.
  49. Something   like   this:    (1)   alphabetize  except  where
  50. circumstances   require   exceptions,   and   annotate   the
  51. exceptions;  (2)  design  locally  developed  procedures  to
  52. conform to the alphabetization standard.
  53.  
  54. > Which is the lesser of two evils?
  55. >
  56. > Are there any other solutions or options I have overlooked?  I
  57. > need some ideas, as we are soon to have a meeting to decide once
  58. > and for all which way SAS r6.07 will go.  Any help will be
  59. > appreciated!
  60.  
  61. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
  62. \   Howard Schreier, U.S. Dept. of Commerce, Washington    /
  63. /                     MVS 5.18 & 6.07                      \
  64. \   Voice: (202) 377-4180        BITNET: HIS@NIHCU         /
  65. /   Fax:   (202) 377-4614      INTERNET: HIS@CU.NIH.GOV    \
  66. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  67.