ADSM-L

En: [RFI] - ADSM Versioning parameters and Naming convention

1997-04-30 10:04:52
Subject: En: [RFI] - ADSM Versioning parameters and Naming convention
From: Roberto Sep#lveda <rsepulv AT BVEMX.PPCO DOT COM>
Date: Wed, 30 Apr 1997 09:04:52 -0500
Armando,

In our shop we have a long-standing argument about "naming conventions".  The
proponents call them naming conventions.

The opposition calls them "embedded intelligence".

I belong to the opposition.  I believe that "embedded intelligence" schemes are
destined to fail, because sooner or later, you are going to encounter conditions
that were not anticipated.  Then you make a compromise that renders your scheme
worthless.  Even worse than worthless, because it becomes misleading.

Or, to avoid breaking down the "embedded intelligence" you have to jump through
too many hoops and create a lot of work for you or the person that takes over
after you get that huge promotion because of the excellent work you did.

I propose to use meaningless names from the beginning:

For Storage Pools: Pool_01, Pool_02, ..., Pool-nn.

I'll give an example outside ADSM.  In the mainframe world they use control
units to connect 3270 terminals to the mainframe.  We had an "embedded
intelligence" scheme where we assigned a number to each control unit, and then
that number became part of each terminal name.  Later, we went from small
control units that had 16 ports to bigger control units with 32 ports.  That
meant that we had to rename each terminal.  These terminals were used in IMS, an
online application that required that you define each terminal to it.  So, then,
because we bought a bigger control unit, we had to do an IMS gen.  Also, those
terminals were used in RACF definitions.  There is no end to it.

Forget about "embedded intelligence" schemes (or is it schema) and just use
meaningless names.  Your life will be easier.

Roberto Sepulveda
rsepulv AT ppco DOT com
<Prev in Thread] Current Thread [Next in Thread>
  • En: [RFI] - ADSM Versioning parameters and Naming convention, Roberto Sep#lveda <=