HP3000-L Archives

November 2004, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tony Summers <[log in to unmask]>
Reply To:
Tony Summers <[log in to unmask]>
Date:
Tue, 23 Nov 2004 12:05:19 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (108 lines)
This is an interesting thread.  

From my perspective I have been trying to look how I improve our access
to our KSAM database to introduce the perceived benefits of Item lists.
One conclusion I have come to is that we need to split our applications
into at least two layers - a layer for the business logic and a layer
for the database access.  The business layer would simply ask the
database access layer questions like "Get me the X,Y,Z client details
for client # 1 " albeit dressed up in standard cobol subroutines and the
database access layer would have the necessary logic to open the
database, read the data and buffer the difference between the physical
layout of the data and the logical view of the data that the application
requires.    On the fact of it, this would seem to negate the benefits
of using Image's item list approach since you're essentially bundling
the database access layer into subroutines rather than letting the
individual applications be responsible for their own personal item
lists. 

Personally, rather than discussing the merits of items lists vs "@;" and
"*;" we should be looking to a solution that helps you manage changes to
your systems in a controlled manner.   The questions you need to ask
yourself are 

(1) How does the database access layer prove it is accessing a database
in the format implied by the receiving data-buffer ?

As the previous post pointed out, if you change your physical database
layout then you will have to ensure that the copylibrary modules are all
updated and/or re-compile all programs.   If I was ever to use Image
again (unlikely given that we're a KSAM shop and we will no-doubt
initially migrate to some flavour of ISAM) then I would construct my
copylibraries so that each copylibrary had a declared item list along
with the database-buffer corresponding to that item list.   I would also
initially check that the item list is valid - but even as I type I can
think of certain database changes that would make even this approach
invalid unless you were also to cross check that the items still had the
same field type and length as that implied by the copylibrary module. 

(2) What procedures are in place for putting changes into production.  

Quite a hot topic at our site at the moment are the change management
procedures.   Luckily we've always had a well defined approach for
putting changes on our HP3K into production - and being able to reverse
out those changes when something goes wrong.

(3) Does the current structure of your applications prepare yourself for
migration ? 

Whilst I have nothing but praise for the emulation migration vendors (eg
eloquence as an Image clone) once you've migrated you must seriously
consider whether your database technology needs a re-think.   You can
prepare for that change by isolating the database access code as
suggested in my opening paragraph.    Frankly, you probably need to do
the same for the user access layer too (View/character mode). 



-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Roy Brown
Sent: 23 November 2004 10:49
To: [log in to unmask]
Subject: Re: [HP3000-L] Using the "@" list in TurboIMAGE

<clipped> 


The contents of this email are confidential to the intended recipient
and may not be disclosed. Although it is believed that this email and
any attachments are virus free, it is the responsibility of the recipient to confirm this.

Smith & Williamson Corporate Finance Limited - A member of M&A
International Inc. http://www.mergers.net Registered in England No.
4533970. Authorised and regulated by the Financial Services Authority 
Smith & Williamson Investment Management Limited, Registered No. 976145. Authorised and regulated by the Financial Services Authority.
Smith & Williamson Pension Consultancy Limited - Independent
Intermediary. Registered No. 3133226. Authorised and regulated by the
Financial Services Authority.
Smith & Williamson Fund Administration Limited, Registered No. 1934644. Authorised and regulated by the Financial Services Authority.
Smith & Williamson Limited - A member of Nexia International.
Registered in England No. 4534022. Regulated by the Institute of
Chartered Accountants in England & Wales for a range of investment
business activities.

Registered Office: No 1 Riding House Street, London W1A 3AS
Telephone: 020 7637 5377 http://www.smith.williamson.co.uk

Nexia Audit Limited - A member of Nexia International. Registered in
England No. 4469576. Registered to carry on audit work and regulated by the Institute of Chartered Accountants in England & Wales for a range of investment business activities.

Registered Office: No 1 Riding House Street, London W1A 3AS
Telephone: 020 7637 5377 http://www.nexiaaudit.co.uk

NCL Investments Limited, Registered No. 1913794.
Member of the London Stock Exchange authorised and regulated by the Financial Services Authority.

Registered Office: Bartlett House, 9-12 Basinghall Street, London  EC2V 5NS
Telephone: 020 7600 2801 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2