Re: MAINFRAME SHOP STANDARDS

From: Frederico Fonseca (real-email-in-msg-spam_at_email.com)
Date: 12/12/04 

Date: Sun, 12 Dec 2004 12:39:37 +0000

On 12 Dec 2004 10:26:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>. On 12.12.04
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 321f45F3h65spU1@individual.net
> about Re: MAINFRAME SHOP STANDARDS
>
>
>FF>> Application is still being improved and new functionality is
>FF>> being added to it in terms of new products. In many cases to add
>FF>> a new insurance product is only a question of modifying a few(not
>FF>> that few!!) tables, and add new product rules to product files.
>
>PD> That is terriffic, and exactly what you need. But neither Lueko nor
>PD> myself could deduce that when it appeared that the system was
>PD> comprised of ISAM files.
>
> Actually it was my perception that this system of files looked like
>a well designed database, except that the fetching of related
>information from several tables had to be organised "manually", i.e.
>by extracting the key information from one file's record and use this
>to START and READ the corresponding record from another file, instead
>of getting all needed fields from all tables by one SELECT.
The way the application works is really
read main file,
   start/read next the others.
     for each of the others
         start/read next some others

Due to the way the application was originally desiged it would be very
hard to replace the logic with one select.

Just to give an example.
A group scheme can contain several policies. It can also contain
several "persons" and several categories.
So processing of a scheme would be
scheme file
   get scheme details (2 files)
   links file
     get policies attached
         get product details (12 files)
         links file
            get coverages attache
                get coverage specifics (a few files here)
            get persons attached
                get person details (3/4 files)
            get category attached
                get category details (2 files)
     get categories attached
         get category details (2 files)
     get scheme persons attached
         get person details (3/4 files)

If developing a new system it would be feasible to incorporate some of
the above on a single SQL, but not all.
>
> And I would not be astonished at all if the people who have
>developed that system had developed their own CALLable procedures
>which emulate such a SELECT from multiple tables.
All processing is done using I/O modules, with some exceptions where
ESQL was used for some batch programs due to speed contraints.

The whole system is highly parameterizable, and as I said before many
new things can be done just by changing/adding values on tables/files,
no code needed.

I would like to be still working there as my current customer is a
"crap" site compared to that one (sigh||).

>
>
>Yours,
>Lüko Willms http://www.willms-edv.de
>/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
>Das ganze Zeitungs-All. -G.C.Lichtenberg

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Relevant Pages

  • Reminder: Scheme UK Meeting: 7 December 2005
    ... The next meeting of the Scheme UK user's group will be held ... Analysis of Access-Control Policies ... Scheme programming language in particular, ...
    (comp.lang.ml)
  • Re: Setting a Hexidecimal Value in .adm files
    ... I have written an administrative template to select ... > which power scheme is used on a clients computer and it ... > works to set which scheme is used. ... but the registry key defining these policies is ...
    (microsoft.public.windows.group_policy)
  • Setting a Hexidecimal Value in .adm files
    ... I have written an administrative template to select ... which power scheme is used on a clients computer and it ... works to set which scheme is used. ... but the registry key defining these policies is ...
    (microsoft.public.windows.group_policy)