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

On 8/12/2007 at 8:59 PM, in message
<oMednRMwtNq6VCLbnZ2dnUVZ_qmlnZ2d@xxxxxxxxxxx>, LX-i<lxi0007@xxxxxxxxxxxx>
wrote:

There are benefits to stored procedures - but the RDBMS runtime would
still have been charged to our program, as the thread that started the
whole mess would have been part of the program's charged time. :)
There's another school of thought that stored procedures tie one to a
particular database, and that a program-based solution is preferable to
obtain DB independence. Of course, we've had enough debate in here as
of late... ;)

Personally, I believe that call has to be made for each system, by
analyzing what it's going to do. On our Unisys mainframe-based COBOL
system, putting stored procedures in their proprietary RDMS format would

probably make sense. If it gets ported to another architecture, they're

likely going to have different ways of validating dates. On the other
hand, on my websites I'm working on now with PHP 5, I'm using PHP Data
Objects (PDO), which should allow me to extract the data access from the

underlying database. (Not that I plan on running it on anything but
MySQL; but, I'll have the option.)

This brings to mind an interesting issue that we've been struggling with for
years at our shop. This issue being, where does input validation belong?

Prior to the mid-1990s all of our data input to the mainframe was your good
ol' 3270 green screens. For better or for worse, presentation logic and
business logic were implemented in the same CICS program. Data validation
was hard coded directly in to the same CICS program.

We then started utilizing some distributed (Windows) applications to perform
some of these functions. The same (if slightly modified) CICS programs
still existed on the back end and were utilized by the distributed
applications to actually get the data from there to here (the mainframe).
All of the existing data validation remained in the CICS programs, but much
of the same logic was also put in to the distributed application.

One of the main reasons this was done was because the distributed
application has all those wonderful modern things such as drop-down lists,
radio buttons, etc. In order to present the proper widgets (or whatever
they're called) to the end user the distributed application must, of course,
know what those valid values are. Additionally, with those types of
applications the users are used to knowing pretty much immediately of they
have selected a valid option. They don't want to go through all of the
effort of entering data, then at the end pressing enter and finally getting
back a message "such and such a value is invalid for this account type".

Just this year we implemented a project to 'web enable' a lot of our CSR
screens. Again we ended up duplicating a lot of the
edits/validations/whatever you want to call them. In some situations where
the logic is fairly complex and the relevant data resides on the mainframe
we will let things 'pass through' to be edited on the mainframe, but that's
fairly rare.

Another issue we come upon, even if we wanted to pass the edits through to
the mainframe, is that different applications sometimes allow for different
edits. Here's a real example... If an ATM card is ordered for a customer
who is a minor (under 18) there is a requirement that the order be approved
by an officer. So the order is put in to a 'pending approval' queue. If,
however, the card is ordered as part of setting up a new account through the
new accounts system (a distributed application) then the approval is *not*
required. So I had to add logic to my CICS program to be able to
distinguish between the transaction being initiated directly (via a regular
3270 terminal session) and same transaction being initiated via a
distributed application (which actually still uses a regular 3270 terminal
session, but a 'psuedo signon' process is done by the distributed
application that lets the CICS program know that it's, well, a distributed
application).

Anyway, there are other cases where the 'end' application is more likely to
know what edits need to be in place, and to 'end' applications may not have
the same edits. So putting the edits on the mainframe just makes things
worse.

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).

In the end we do what we have to do to make things work. But no one is
really happy with it.

I don't know that we're going to change our direction at this point, but I
am curious about other's experiences.

Frank

.

Quantcast