home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1851 < prev    next >
Encoding:
Text File  |  1992-07-31  |  5.0 KB  |  98 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!auvm!VCCSCENT.BITNET!SOMITCW
  3. Message-ID: <IBM-MAIN%92073115003305@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Fri, 31 Jul 1992 15:55:55 EST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         SOMITCW@VCCSCENT.BITNET
  8. Subject:      Re: UNIT and VOLUME specification
  9. Lines: 87
  10.  
  11.  On Fri, 31 Jul 1992 07:49:02 EDT, BENSON@POKVMCR3.VNET.IBM.COM said:
  12. >>Ah hah.  So the real reason we don't get more user-friendly systems
  13. >>from IBM is that it's too hard to change the existing ancient cruddy
  14. >>code.
  15. >With our limited resources we have to prioritize the work and often
  16. >"pet peeves" are at the bottom.  First, we fix our errors.  Next, we
  17. >try to add new function, like SMS and tape libraries, to stay
  18. >competitive.
  19.  
  20.     What IBM considers "pet peeves", its customers sometimes consider
  21.  broken or poorly designed code.  For example:
  22.  
  23.     A few weeks ago a user submitted a job that looped passing records
  24.  to SORT.  SORT allocated all of the space on all work volumes causing
  25.  other jobs to go into allocation recovery.  All jobs were canceled
  26.  each time the first user tried to run their job.  Should I explain
  27.  to all of the users that IBM broke allocation recovery 15 years ago
  28.  or that IBM considers their problems as "pet peeves"?
  29.  
  30.     I have seen a 1 hour restore of a single VSAM cluster take over
  31.  5 hours while hundreds of users were waiting to use it in CICS.
  32.  Should I explain to the users that the person setting up the job didn't
  33.  understand that all VSAM clusters should always under all condition
  34.  be defined specifying SPEED, but IBM defaults to a totally useless
  35.  option of RECOVERY and that the default BUFNI, BUFND, and BUFSP must
  36.  always be overridden.
  37.  
  38.     We have had to write over unknown user data sets because when
  39.  IBM renamed IBCDMPRS ( Stand alone Dump/Restore ) to ADRDMPRS they
  40.  decided to remove the DUMP function.  I hate being the one to tell
  41.  all users at 23 colleges that they may have lost a data set or two.
  42.  
  43.     We have been unable to copy and transmit data to other location
  44.  because IBM and other vendors write reasonable block sizes but QSAM
  45.  and BSAM only support less than half of 65535.  Should I try to
  46.  explain to users that a disk track is 47476 but they should write
  47.  in half of a track blocks because QSAM and BSAM have decided to
  48.  treat the half-word block size as signed. ( Note:  Half of a track
  49.  is not 23738 but is 23476. )
  50.  
  51.     IEBCOPY copies large blocks into data sets with smaller block sizes.
  52.  IEBCOPY then destroys the directories of the output data set if a user
  53.  tries to compress the data set the same day or months later.  This has
  54.  cost us and our users much grief.
  55.  
  56.     IEHMOVE is slow.  It reloads its subroutines thousands of times
  57.  in a run.  It uses extremely inefficient work files.
  58.  It doesn't support VIO for work files or for input or output files.
  59.  It updates PDS directories between each member written.
  60.  With the long run times and high disk contention it makes our users
  61.  and operators unhappy.  We don't run a data center planning to make
  62.  our users unhappy.
  63.  
  64.     We are applying MVS maintenance now by SOURCEID.  Could someone at
  65.  IBM tell the engineer if PTFs with SOURCEIDs SMCCOR or SMCREC are
  66.  from the CBPDO tape that came today or from 3 years ago?
  67.  It's a bit late now, the engineer has loaded the entire CBPDO tape to
  68.  disk and edited the ++ ASSIGN statements.
  69.  
  70.    Right now, we have users that need the online VSAM clusters and
  71.  AIXes copied every night so they can use them the next morning in TSO
  72.  and batch.  DF/DSS does not allow us to rename the DATA and INDEX
  73.  components during the copy and generates duplicate time stamp names
  74.  for the clusters data and AIXes data component so the copy fails.
  75.  The generated names also look like garbage in our LISTVTOCs and
  76.  are impossible to code for in our security system rules.
  77.  DF/DSS has been working on the problem for over 2 months.  Of course
  78.  they never did fix 2 previous problems we sent the a couple of years
  79.  ago ( A backup of a single record VSAM data set can take 3 or more
  80.  tapes for a single density 3380 ).
  81.  
  82.    Yesterday I called SyncSort Inc. with a suggestion that they include
  83.  record counts in SYNCGENR.  The person I spoke with said 'Thank You',
  84.  she said that she would take the suggestion to the development manager,
  85.  she said the suggestion would be added to the data base of suggestions.
  86.  Could anyone imagine calling the IEBGENER support group and getting
  87.  the same response?  Would they use terms like "pet peeves" or claim
  88.  limited resources to fix customer problems with software that we pay
  89.  dearly for?
  90.  
  91.    If IBM is hearing that users need JCL improved so the users do not
  92.  have to code a unit parameter for online ready disk, IBM should
  93.  listen.
  94.  
  95.    I would like to make it clear that IBM has done a good job of fixing
  96.  dozens of problems that I reported, but I also hope that the above
  97.  list of problems and many more not listed will not exist next year.
  98.