Newsgroups: bit.listserv.ibm-main
Date:         Fri, 31 Jul 1992 15:55:55 EST
From:         SOMITCW@VCCSCENT.BITNET
Subject:      Re: UNIT and VOLUME specification

 On Fri, 31 Jul 1992 07:49:02 EDT, BENSON@POKVMCR3.VNET.IBM.COM said:
>>Ah hah.  So the real reason we don't get more user-friendly systems
>>from IBM is that it's too hard to change the existing ancient cruddy
>>code.
>With our limited resources we have to prioritize the work and often
>"pet peeves" are at the bottom.  First, we fix our errors.  Next, we
>try to add new function, like SMS and tape libraries, to stay
>competitive.

    What IBM considers "pet peeves", its customers sometimes consider
 broken or poorly designed code.  For example:

    A few weeks ago a user submitted a job that looped passing records
 to SORT.  SORT allocated all of the space on all work volumes causing
 other jobs to go into allocation recovery.  All jobs were canceled
 each time the first user tried to run their job.  Should I explain
 to all of the users that IBM broke allocation recovery 15 years ago
 or that IBM considers their problems as "pet peeves"?

    I have seen a 1 hour restore of a single VSAM cluster take over
 5 hours while hundreds of users were waiting to use it in CICS.
 Should I explain to the users that the person setting up the job didn't
 understand that all VSAM clusters should always under all condition
 be defined specifying SPEED, but IBM defaults to a totally useless
 option of RECOVERY and that the default BUFNI, BUFND, and BUFSP must
 always be overridden.

    We have had to write over unknown user data sets because when
 IBM renamed IBCDMPRS ( Stand alone Dump/Restore ) to ADRDMPRS they
 decided to remove the DUMP function.  I hate being the one to tell
 all users at 23 colleges that they may have lost a data set or two.

    We have been unable to copy and transmit data to other location
 because IBM and other vendors write reasonable block sizes but QSAM
 and BSAM only support less than half of 65535.  Should I try to
 explain to users that a disk track is 47476 but they should write
 in half of a track blocks because QSAM and BSAM have decided to
 treat the half-word block size as signed. ( Note:  Half of a track
 is not 23738 but is 23476. )

    IEBCOPY copies large blocks into data sets with smaller block sizes.
 IEBCOPY then destroys the directories of the output data set if a user
 tries to compress the data set the same day or months later.  This has
 cost us and our users much grief.

    IEHMOVE is slow.  It reloads its subroutines thousands of times
 in a run.  It uses extremely inefficient work files.
 It doesn't support VIO for work files or for input or output files.
 It updates PDS directories between each member written.
 With the long run times and high disk contention it makes our users
 and operators unhappy.  We don't run a data center planning to make
 our users unhappy.

    We are applying MVS maintenance now by SOURCEID.  Could someone at
 IBM tell the engineer if PTFs with SOURCEIDs SMCCOR or SMCREC are
 from the CBPDO tape that came today or from 3 years ago?
 It's a bit late now, the engineer has loaded the entire CBPDO tape to
 disk and edited the ++ ASSIGN statements.

   Right now, we have users that need the online VSAM clusters and
 AIXes copied every night so they can use them the next morning in TSO
 and batch.  DF/DSS does not allow us to rename the DATA and INDEX
 components during the copy and generates duplicate time stamp names
 for the clusters data and AIXes data component so the copy fails.
 The generated names also look like garbage in our LISTVTOCs and
 are impossible to code for in our security system rules.
 DF/DSS has been working on the problem for over 2 months.  Of course
 they never did fix 2 previous problems we sent the a couple of years
 ago ( A backup of a single record VSAM data set can take 3 or more
 tapes for a single density 3380 ).

   Yesterday I called SyncSort Inc. with a suggestion that they include
 record counts in SYNCGENR.  The person I spoke with said 'Thank You',
 she said that she would take the suggestion to the development manager,
 she said the suggestion would be added to the data base of suggestions.
 Could anyone imagine calling the IEBGENER support group and getting
 the same response?  Would they use terms like "pet peeves" or claim
 limited resources to fix customer problems with software that we pay
 dearly for?

   If IBM is hearing that users need JCL improved so the users do not
 have to code a unit parameter for online ready disk, IBM should
 listen.

   I would like to make it clear that IBM has done a good job of fixing
 dozens of problems that I reported, but I also hope that the above
 list of problems and many more not listed will not exist next year.
Newsgroups: bit.listserv.ibm-main