Dave's Program Products Pet Peeves Page

"Always with the negative waves, Moriarty. Always with the negative waves."
--Spoken by Oddball (Donald Sutherland) in the movie Kelly's Heros


I have installed, customized and supported Program Products for a living. So naturally, I've accumulated a few pet peeves over the years.

ANY RESEMBLANCE TO ANY LIVING OR DEAD PROGRAM PRODUCTS IS PURELY COINCIDENTAL.

Dave's open letter to Program Product vendors:

I don't expect you to ever do any of this, otherwise you would have acted on the requests already sent in but here goes:
SYS1.AMODGEN


Welcome to the 1990's, SYS1.MODGEN should be used instead of SYS1.AMODGEN


SYS1.HASPSRC


Welcome to OS/390, SYS1.HASPSRC is now split into SYS1.SHASMAC and SYS1.SHASSRC


SYS1.LINKLIB


Welcome to MVS/XA, we now have a LNKLST concatenation.



PGM=IFOX00 (Assembler F)
PGM=IEV90 (Assembler H)


Welcome to OS/390, the only supported assembler is PGM=ASMA90 (High Level Assembler)


SMP usermods


A large, well-known vendor use to have instructions in Program Product installs to APPLY usermods before ACCEPTing the base product. You had to know to avoid this advice, ACCEPT the base product and then APPLY the usermods.


SMP packaging Part I


I've eyeballed the SMP/E manual SC23-3695 "Standard Packaging Rules for MVS-Based Products", it really doesn't look too hard to package your program products correctly in SMP format. If you don't have the time to do it right, IBM has a service to help you package your products in SMP format.


SMP packaging Part II


As posted by Shane Ginnane on the IBM-Main mailing-list/Newsgroup on 1999/07/13:
Why is it that every third party vendor in the world has no idea on how
to package products under SMP/E ???.  Perhaps (maybe) a little general,
but each new product I have the misfortune to install reinforces the
opinion.

Some examples:
i) "helpful" installer software. WRONG, WRONG, WRONG !!. If you ship
    software this way, at least make it so that it's aware of
    updates that were required to get it to work/install.

ii) IEBCOPY of a heap of libraries, then Zonecopy of the SMP environment
    that just got uplifted. If you ship this way you are telling your
    customers you can't package properly, or don't trust your ability to
    do so.

iii) "install these sysmods, then run these links OUTSIDE of
     SMP" - then maybe some more SMP work. You gotta be kidding .....

iv) "copy this install lib to disk then run the enclosed jobs". Except
    the JCL is wrong and/or the files referenced don't exist on the
    tape. v) PTFs shipped as USERMODs !!!. How many of you ACCEPT your
    USERMODs ?????. etc., etc. ...


ISR@PRIM


Never deliver a member in any PDS called ISR@PRIM. It is too easy for a novice installer to replace the installation ISR@PRIM panel with your lame version. Even an unlucky experienced installer might put your program product library incorrectly in the //ISPPLIB concatenation.


Boring ISPF panels


Welcome to the 1980's, ISPF supports colors in ISPF panels. For example, look at ISR@PRIM in OS/390 ISPF.
U.K. translation: Welcome to the 1980's, ISPF supports colours in ISPF panels. For example, look at ISR@PRIM in OS/390 ISPF.


ALL UPPERCASE ISPF PANELS
ALL UPPERCASE CICS, IMS, ETC SCREENS
ALL UPPERCASE MESSAGES


WELCOME TO THE 1970'S, WE NOW HAVE 3270 TERMINALS AND PRINTERS THAT SUPPORT MIXED CASE.

The CIO at my job in 1989 said "We live in a 8.5 by 11, portrait, mixed case world. Don't think greenbar!".


ISPF libraries


A good convention to use for low level nodes for a ISPF library is the one used by the IBM MODEL command. For Example:


To test this out, get into ISPF edit on a dataset that doesn't end with a node above (like IBMUSER.JCL.CNTL), type in MODEL on the command line and after hitting ENTER, you'll see the list ISPF uses.


No ISPF LIBDEF support


We want to easily install and test your program products. Please give examples of invoking your ISPF applications using LIBDEFs. Please ensure that your ISPF applications that use load libraries are compatible with LIBDEFs. Here is an example of a Rexx exec that invokes an ISPF application via LIBDEFs:
/* REXX - Invoke the XYZ Dialog */
address ISPEXEC
"LIBDEF ISPLLIB DATASET    ID('"SYS2.xyz.LOAD"')"
"LIBDEF ISPPLIB DATASET    ID('"SYS2.xyz.PANELS"')"
"SELECT CMD(XYZ) NEWAPPL(XYZ) PASSLIB"
"LIBDEF ISPLLIB DATASET"
"LIBDEF ISPPLIB DATASET"
exit
        
Using this LIBDEF method of invoking this product required no changes to the shop's ISPF concatenation or logon proc. A happy sysprog will be better disposed to recommend your future products.


CLISTs


Welcome to the 1990's, I HATE looking at all upper case CLIST code. Please use REXX! We have to customize your lame products to run at our shops.


SMF record writing on by default


Never ship a product that has SMF record writing ON by default. Please give instructions to check at the shop (usually with the MVS sysprog) for an unused SMF record to use. No value should be shipped, as in "SMF=250", ship with something like "SMF=(OFF,???)" and don't accept a number not in the 200-255 range.

BTW: Non-IBM SMF records are in the 200-255 range.


SVC numbers


Please include an option to use the ESR 109 SVC in addition to normal user SVCS. For example, have the option of "SVC=250" or "SVC=(109,250)". If possible, please use PC routines instead of SVCs.

BTW: Non-IBM SVCs are in the 200-255 range.

A large, well-known vendor deceitfully dynamically installs their SVCs in the upper part of the IBM range (below 200). You should only use a SVC below 200 when you have to front end an IBM SVC.


SVC names


Welcome to MVS/XA, we no longer have to call type 3/4 SVCs IGC00xxx. A name like XYZSVC in LPA beats the pants off IGC0024D any day of the week. Check out SYS1.PARMLIB(IEASVCxx):
SVCPARM 244,REPLACE,TYPE(3),EPNAME(XYZSVC) /* Vaporware, Inc. */
WTORs


You can tell how 1970's a product is by its outstanding WTOR. Please support the Modify and Stop interface as in "F name,option" and "P name". You can do this in about 20-30 instructions.

BTW: Batch jobs can use the Modify and Stop interface also. It is not restricted to started tasks. For example, I wrote a batch utility that reads SMF records. If I'm monitoring it (like in SDSF) and see that I have all the information I need, I can do a graceful stop using the "P jobname" command. No operator cancel is needed and I get the summary report at the end.


AMASPZAP


Us real men love to zap core and load modules but our auditors have an irrational fear of the AMASPZAP utility. Your program products should avoid zaps that aren't for maintenance fixes.


IEBCOPY Overdrive


You must really want us to type. Why do this:
//JUSTDOIT EXEC PGM=IEBCOPY
//SYSUT3   DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL...
//SYSUT4   DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL...
//SYSPRINT DD SYSOUT=*
//INDD     DD ...
//OUTDD    DD ...
//SYSIN    DD *
  COPY INDD=INDD,OUTDD=OUTDD
/*
The default if SYSIN is dummy is to copy SYSUT1 to SYSUT2. The SYSUT3 and SYSUT4 work files haven't been used since the first Star Wars movies came out.
//JUSTDOIT EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD ...
//SYSUT2   DD ...
//SYSIN    DD DUMMY
TMS foreign tapes


A lot of us run a popular Tape Management System called T M S. When we need to read your lame product tape in, the JCL needs "EXPDT=98000" for it to work. The better products have sample JCL something like this:
//SYSUT1   DD DISP=(OLD,KEEP),
//            LABEL=(x,SL),                 Non-TMS
//*           LABEL=(x,SL,,,EXPDT=98000),   TMS
//*           LABEL=(x,BLP),                Bypass Label Processing
//            ...other parms here...
Okay, the only time this is a problem is when there is so much JCL on one line and you don't have room enough for a "C 'SL)' 'SL,,,EXPDT=98000)' all". This has happened to me two or three times this year.


FAXing of ZAPs


Welcome to the 1990's, most of us have email capability. Please give your technical support staff access to email us load module fixes in XMIT format, technical information and Zaps.

Besides, an individual connection to the Internet via an ISP is only $9-20 a month, Don't, in this day and age, tell us you're looking into that "Internet thing" as I recently heard from a large vendor.

I missed hanging out with a former boss at SCIDS all week at the Summer 1993 Share conference because he had to go back home due to major IDMS outages that were caused by a ZAP keyed in incorrectly from a Fax.

Also, non-SMP ZAPs should come with a CHECKSUM!!!


Dumps to tape


Welcome to the 1990's, please put up a FTP site on the Internet so we can FTP dumps and other documentation to you for problem determination. And yes, a BBS in the day of the Internet is sooo 1980's. You might be proud of your 9600 baud BBS and the fancy use of ANSI graphics but spare us.


SLIP traps


I don't know how many times this has happened: another sysprog comes into my cubicle and says: "you're the MVS guy and the vendor wants a SLIP trap". I don't know your requirements. You need to supply us with the SLIP trap command syntax. Unless you are just trying to get rid of us. So in that case, it won't matter: the dump will be too long after the problem to be relevant or something else to blow us off. You're probably needing to talk to a headhunter because you just got layed off after the merger to you-know-who.


Requiring non-standard shutdown commands New :: [2001-09-17]


Looking back through the SYSLOG at one place I worked, I saw this sequence of commands by an operator trying to shutdown an IDMS CV:
R 22,SHUT IMM
IEE600I REPLY TO 22 IS;SHUT IMM
Drats, the NETVIEW shutdown command doesn't stop IDMS
R 23,CEMT P SHUTDOWN
IEE600I REPLY TO 23 IS;CEMT P SHUTD
Drats, the CICS shutdown command doesn't shutdown IDMS
R 24,CEMT SHUT
IEE600I REPLY TO 24 IS;CEMT SHUT
Drats, another variation on the CICS shutdown command didn't stop IDMS. I guess I'll crack open the procedures manual.
VENDORS: Please support "P taskname". Our time is valuable. Our operators have better things to do than look up the syntax of your lame product's commands. If operations calls us at three in the morning all the time, we are going to start hating your company and will NOT buy anymore of your lame products.


Not supporting the "P taskname" function New :: [2001-09-17]


Recently I was shutting down a system that was running a new started task called DIF. I did a "P DIF" which I found it ignored. It required "F DIF,Z". The usual course of action for a STC is if it doesn't take the "P taskname" command that it must be hung and the next thing we are going to do is "C taskname". When you have some funky type of non-standard shutdown, use the modify command otherwise just be sane and support the stop command.

VENDORS: Please support "P taskname". Our time is valuable. Our operators have better things to do than look up the syntax of your lame product's commands. If operations calls us at three in the morning all the time, we are going to start hating your company and will NOT buy anymore of your lame products.


Not using the CPF macro New :: [2001-09-19]


Welcome to the early 1990s. The CPF macro was introduced in MVS version 4.1. When you issue the "D OPDATA" command, you should see ALL command prefixes in use by ALL tasks in the system (and SYSPLEX). Many of our program products (and a couple from IBM) don't invoke the CPF macro. Here's what the IBM Auth ASM manual says:
"CPF also ensures that two or more systems do not have the same or overlapping prefixes, which helps prevent confusion."
The CPF macro looks pretty easy to code.





I know, I know: but Dave, we have to support MVT, MVS OS 3.8, MVS SP1.3, MVS/XA, MVS/ESA, OS/390, yada yada yada. Well after 12/31/99, only MVS v5 and higher systems will work, so there!

When I say "lame product", I don't mean yours. I mean your inferior competitor(s)!. No one said life is fair. Besides if you don't do any of the bad things I've mentioned, your product won't be lame and I'm not talking to you, am I?

I've been spending too much time reading alt.sysadmin.recovery and my mind is warped. Us sysprogs are normal, I tell you.

As you can tell by this page I'm concurrently writing two books: Sometimes I get through installing a product, I sit back and think: another chapter in the book "When bad software happens to good people".

Woof
, enough with these negative waves, can't you be positive!
THE VIEWS ON THIS PAGE DO NOT REPRESENT THE VIEWS OF MY PAST, CURRENT AND FUTURE EMPLOYERS.

OS/390 and MVS are registered trademarks of IBM. All other trademarks are owned by their respective companies.


Last Updated: 2003-02-08
This web page is © 1997-2003+ by David Alcock. All Rights Reserved.