In message
<[log in to unmask]>, "Penney,
John" <[log in to unmask]> writes
>Gentle Listers:
>I need some assistance in presenting to my client the necessity for
>performing several database modifications in systematic conceptual
>fashion. We are making several non-trivial changes (additions) in
>functionality to a legacy application. Some of the management feel that
>has an expected life of 5 years and thus are reluctant to change the
>physical design of several critical datasets because a) They fear the
>aspect of missing source modules may arise, and b) There is reluctance
>to diddle the physical design because of the number of affected Cobol
>and Powerhouse programs affected (only about 300). They propose to
>graft on a Detail dataset with the required new fields althought they
>(fields) by rights belong upon the Master that they are referenced to.
>Apart from ascetics and first, second and third normal form concepts, would
>you be so kind as to please furnish me some concrete ideas for my defending
>the'right way' of doing these changes?
>Please reply offline to this forum as discretion is appreciated.
>Horror stories are welcome.
>Cost overruns frankly received.
>Missed deadlines relished.
>Many thanks for assistance.
>John M Penney
I did reply to John offline, as requested, but he thought I should post
my reply here too. And as the List is (or was!) pretty quiet, it seemed
like a good idea.... so here it is, edited to protect the innocent :-)
=================================================
Hi John
I'm making non-trivial changes to an HP3000 system with several
databases and several hundred programs with a further design life of
less than *one month*.
I'm making these changes purely to facilitate the simplification of the
data structures in, and the extraction of data from, this system so that
it can be provided to the folks who are going to migrate it onto an
existing UNIX/Oracle system, with a deadline of 1st April for the
go-live.
(This is a pre-existing system, owned by the people doing the migration,
with existing customers, that handles the business area in question.
Though there will be one or two extensions and customisations for our
specific needs. And it will be run sort-of-externally on a sort-of-FM
basis by them. I've no doctrinal problems with any of that).
But the HP3000 system still has to keep up its customary reliability and
availability, and it has to do about $(umpty-um)m of invoicing at the
March month-end, which also happens to be our FY year-end. And for some
inexplicable reason, the financial folks don't want to miss any of this
billing, and it can't be late, either.
I have Adager to help me in my task, but nothing special beyond that.
This application is *not* expected to break due to my ministrations. How
do I achieve this?
** Code Completeness **
I took a copy of the application, and its live data, recently, onto a
928 I can use for testing, etc. This was before I made any changes at
all. I also put all the sources I thought I needed - COBOL, forms files,
UDALink, Formation templates, etc., - on the 928.
I then deleted *all* the executables - program code, XL, forms files,
Formation templates, etc. - everything.
Then I recompiled the entire app, and resurrected all its components for
the sources I had available. Then I and the users tried to run it.
We found (by testing) one COBOL module missing, uncompiled. It turned
out the source was living in a 'fixes' source group, as we thought it
was just part of a one-time fix, but it was actually part of the live
system. I moved this source over to its rightful place.
We found (by inspection) three sources with different names that
compiled to the same executable - an old one, the live one, and an
abandoned upgrade to that. We deleted the two unwanted ones (guess
which).
Everything else was good and up to date - though it is easy to posit
problems like having an old source which makes it *look* as if you have
a certain module, but what you have is not as up to date as the module
you were using live. I've seen that before, though not on this system.
Bottom Line? Build what you've got, and compare with the live system
now. This should tell you what, if anything is 'too old', 'too new', or
'missing'.
Deal with that and you have a solid base to upgrade from.
** Change Reliability - Code **
All our dataset definitions are in our Copy Library, and it is a
standard that copies of datasets, for files or whatever, when used in
programs, derive from these, possibly with prefix substitution.
It is also a standard that records for these datasets are created with
an
INITIALISE xxx-DATA-RECORD.
So I can:
change the definition of a dataset in one place;
recompile the entire system; (I have a job that dynamically
discovers the contents of the SOURCE group, and compiles each one,
putting it in the XL if it declines to succeed in compiling as a
stand-alone program [1])
know that all new records created will at the very least have
all the
new fields in, initialised to spaces or zeroes as appropriate;
know that all new and old records will be correctly treated as
regards alignment.
** Change Reliability - Database **
All this can only happen, of course, once I've updated the database
definitions in Adager. I do this using Adager's jobstream building
option, so that by the time I've got a procedure that works on the test
database, I have a job that is guaranteed to carry out the exact same
procedure on the live database. And fast, of course, which is what you
need, as well as reliable, when trying to get the production system back
on line as fast as possible.
(I say I use Adager's jobstream building option, and I do, but sometimes
I just regard Adager as a scripting language, and write the 'code' to
make further changes to my databases directly by hand. And then test the
results...)
** Development **
Once I've got an updated test system where I know the code is complete,
and has been updated to at least know about and respect the new extended
dataset definitions in the Adagered database, then I can go on to
implement the changes in functionality that are desired, program by
program. How *you* (talking to John) do this is up to you... :-)
But I think that if/when you have done the above, it would be much
easier, and much more reliable, for the new fields to be placed where
they rightfully belong. (John wanted to extend some master sets. 'They'
wanted the new stuff separate in a detail set or sets.)
This would then mean that, for most of your programs I'd imagine, the
new fields would be served up, and stored away again if updated, by the
existing Image accesses these programs are already making. So 'all' you
have to worry about is the code that validates, maintains, and uses
these fields.
Put them in a separate detail dataset instead (as 'they' propose,
whoever 'they' are), and everywhere you want this stuff, you now have to
write new Image accesses to go get them, and to put them back.
That would be *my* defence for doing it 'properly' anyway. Solid
concrete *and* aesthetically pleasing, TNF, etc. etc.... (NB: aesthetics
- those enchilada dinners militate against us being ascetics.... )
Anyway, you ought to do the 'complete code' check, even if you find a
couple of modules missing that you have to rewrite from scratch.
Otherwise you'll spend five years tiptoeing round holes that might or
might not be there. And what's the betting that they'll be in the stuff
you *have* to rewrite for the new functionality, anyway?
Doing the above, I'm afraid I don't have any horror stories for you. Not
from the HP3000 side, certainly. Likewise, no cost overruns, doing it
properly.
And there have been no missed deadlines on the HP3000-sourced material
for the conversion; so far, all HP3000-sourced contributions have been
on time or sooner....
[1] I'm still looking for a way to tell, reliably and automatically, if
a chunk of object code is a program or a subprogram/ansisub/dynamic, so
I know how to link it. Best I've found so far is to try to link it as a
program, and if that fails, link it into the XL.
Can't even do it the other way round, as that doesn't fail......
=================================================
That was most of what I replied to John. It's a paradox, perhaps, that
an HP3000 system that was last updated in 2002, and has been almost
untouched for the whole of 2003 should, with its imminent demise, see
almost more development activity in its last three months of life than
it has seen in the last two years.
I wonder if this is a feature of migrations, or just peculiar to us?
Anyway, I guess that even if you are not considering migration, the same
sort of considerations that John has will apply to existing apps; not so
much is it worth upgrading them if they only have a short life left, and
how do you do it safely, but that if you want to homestead them, how do
you ensure they are complete, and packaged up nicely for that purpose?
If you found the above useful, I have a couple more verses I can work up
for my Migration Blues -
Verse (2) is "Hell, we can't support that" (or how to tell, when
migrating to a different system/platform/what-have-you, whether the
thing the vendor wants you to give up on is an implementation quirk of
your old system, or essential business functionality you can't afford to
lose. And how to square the circle, maybe).
Verse (3) is "Hey, look at this great stuff I can do with MS Office" (or
data manipulation off the HP3000 - there's a lot of data manipulation in
migration preparation, and you want to strike a nice balance between
repeatability and having to create extensive special programs - and
Office can help. Also known as 'Fun with Vegetables', give how often I
speak of ^p here).
Let me know if you'd like to see these as well, over the next week or
two, and I'll put my experiences there into coherent form....
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
