Re: field validation (was Re: COBOL/DB2 Date edit question)



"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:46C08338.6F0F.0085.0@xxxxxxxxxxxxxxxxx
On 8/13/2007 at 2:03 PM, in message
<q5e1c3dfemm1rrgrtahacviachdce8dmn4@xxxxxxx>, Clark F
Morris<cfmpublic@xxxxxxxxxxxxxxx> wrote:
On Mon, 13 Aug 2007 11:26:01 -0600, "Frank Swarbrick"
<Frank.Swarbrick@xxxxxxxxxxxxxx> wrote:
Then again, most of the 'end' applications would have the *same* edits,
and
so we end up with a lot of duplicate logic. Even if the logic is somehow
combined, in, say, a Java object, that object cannot be utilized by a
regular Windows application, and certainly not by a mainframe application
(or mainframe OS does not support Java).

Java exists for both z/OS (unfortunately for you, probably not for
z/VSE) and Windows.

Sorry, that was a typo. I mean "our mainframe OS" (which is VSE and does
not support Java), not "or mainframe OS".

I know Windows (of course!) supports Java. I have no idea if the Windows
guys would want to call Java routines. As a one off thing, maybe. As a
general rule? I'm guessing not.


I wouldn't hesitate to call Java if the function I needed was available in a
Java bean. (It can be easily brokered through CORBA.)

The way the question is formulated shows the difference in concepts.

You are still thinking in languages and source code; I think in functions
needed, and simply don't care what it's written in. (that's why I have less
resistance to stored DB procedures and triggers; it is just another
language. To me the encapsulation of data and the validation of it, makes it
worth the effort.)

This comes down to component based solutions as a general approach. I have
applications with components written in VB, OO COBOL, PowerCOBOL, and even
one or two subroutines written in Standard (Fujitsu NetCOBOL) COBOL, and C#,
some of which I wrote and some of which I didn't, (some of which I don't
even have source code for, and don't need it) all playing nicely together
(sometimes even in the same user window) to give a single, seamless, user
experience.

Under Windows this was good, but under DotNET it is superb.

Interop services lets me call unmanaged code into my C# solution, and so I
get to use all of the legacy components I need to, while re-wrapping them
for a modern desktop (or Web) look and feel.

All new development is in C# as it lets stuff run on Windows or Linux (or
anywhere else that supports DotNET or Mono) without requiring a different
compiler. (A bit like Java really... :-), but, having used both Java and C#,
I have come to prefer C#)

Fortunately, I adopted an n-tier layered approach many years ago so there is
no problem with different looking windows or themes. (Legacy presentation
layer components are simply re-written in C#) This is about 20% of my
legacy, so the remaining 80% that has no visual interface, can be easily
re-used. I COULD re-use some of the Windows (PowerCOBOL, especially) stuff,
but it just looks old-fashioned and dated.)

I'm currently revisiting an application I wrote 7 years ago for converting
ISAM and VSAM/KSDS datasets into RDB. It is being enhanced to generate DDL
for various RDBMS, and the whole thing is being re-wrapped into a single
"Management Console" that lets you control the whole process from a single
point. After refactoring PowerCOBOL and OO COBOL I was amazed to have the
main function (analyzes COBOL source SELECT statements and FD/01 record
definitions, then generates an ACCESS DB (really for documentation, but also
for quick initial testing) and DDL for the RDB of your choice), run
perfectly on the first attempt in the new DotNET environment, using the C#
environment handling, control, and user interface.

When I first wrote this system from scratch it took 5 months; the upgrade
and migration to DotNET will take 3/4 weeks with many original components
being re-used without change, just "glued" together differently...New
facilities are also being added. There is a possibility I may be asked to
write some tools to automate the exisiting COBOL code conversion to RDB
also. Any of you who have manually converted code and data to RDB will know
that this is not to be undertaken lightly. It isn't just a matter of
converting ISAM verbs to SQL; these are different paradigms, and OCCURS,
REDEFINES, and group fields in the ISAM definitions have no place on the new
RDB. It all has to be handled.

Once the RDB has been defined and normalized, it needs to be loaded. I can
generate COBOL modules to do that (the client is a COBOL shop) and that was
what led to my question regarding Batch Compiling Fujitsu COBOL (see
different thread here in CLC)

I'm now thinking about NOT generating COBOL but simply generating DDL to
load the data instead. (Of course I still have to read it somehow, and it
is in the ISAM system which is not readily open to tools other than COBOL.)

The point is that component based systems pay off in ways you can't even
imagine when you build them. I had no idea 7 years ago that I would need to
upgrade and enhance this system in some major ways, 7 years down the track.
Now I'm being paid to do so, and thanking my lucky stars it is not a
complete rewrite...in fact, I can focus on the new facilities rather than
having to worry about complete redesigns and rebuilds of the old ones.

Encapsulation rules; objects are what matters; procedural source is as
relevant as Latin.

(Of course there are enclaves where Latin is still important... Vatican City
springs to mind... :-))

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: System Conversion - An Overview
    ... predominately two reasons - we getting off of the mainframe or we feel ... convert part or all of the COBOL application to JAVA. ... I am responding to a client RFP this month, ...
    (comp.lang.cobol)
  • Re: System Conversion - An Overview
    ... COBOL based applications. ... Most of our clients have IDMS, Datacom, IMS, ... predominately two reasons - we getting off of the mainframe or we feel ... convert part or all of the COBOL application to JAVA. ...
    (comp.lang.cobol)
  • Re: COBOL Compiler for Windows
    ... Getting a free or cheap COBOL compiler for Windows that supports IBM ... They no longer use Flex-ES "pc" for mainframe emulation, ...
    (comp.lang.cobol)
  • Re: Recomending Delphi
    ... However others seem to have convinced her that Delphi has ... Since I would expect the Cobol experience is OS390 or MVS, Java or DB/2 ... i guess it could be Cobol on Windows, but that would be even more rare than ...
    (borland.public.delphi.non-technical)
  • Re: Is a career switch to the mainframe/cobol world responsible?
    ... learn mainframe anymore. ... Is the choice to switch to the mainframe world, and lets say become a cobol ... a mix of Cobol and Java ...
    (comp.lang.cobol)