COBOL/DB2 Date edit question - cobol

This is a discussion on COBOL/DB2 Date edit question - cobol ; -- "I used to write COBOL...now I can do anything." "LX-i" <lxi0007@netscape.net> wrote in message news:9NydnexmCdlzDSLbnZ2dnUVZ_rGrnZ2d@comcast.com... > Graham Hobbs wrote: >> >> My problem is to find the easiest/clearest way to edit these three >> data types before update occurs. ...

+ Reply to Thread
Page 2 of 10 FirstFirst 1 2 3 4 ... LastLast
Results 11 to 20 of 97

COBOL/DB2 Date edit question

  1. Default Re: COBOL/DB2 Date edit question



    --
    "I used to write COBOL...now I can do anything."
    "LX-i" <lxi0007@netscape.net> wrote in message
    news:9NydnexmCdlzDSLbnZ2dnUVZ_rGrnZ2d@comcast.com...
    > Graham Hobbs wrote:
    >>
    >> My problem is to find the easiest/clearest way to edit these three
    >> data types before update occurs. I suspect three ways are available:
    >>
    >> 1) my 'neat?' EXEC SQL.'s.
    >> 2) inline code like 'if month < 00 or >12 then error, etc'.
    >> 3) exec cics link 'editdate' with suitable commarea (and othe pgms for
    >> TIME and TIMESTAMP) and test a return code. (your library routine)

    >
    > I can vouch for option 2 being very, very efficient. We had a copybook
    > that did date manipulation and validation. It was 3,000+ lines, and I was
    > just sure that it could be made much, much more efficient.
    >
    > Well, when we had some ****ysis done on our source code, the results came
    > out with the paragraphs sorted from longest run time to shortest run time.
    > For every program, the date/time routine's paragraphs filled the bottom of
    > each list!
    >
    > I had been working on a "convert" paragraph to convert time zones, using
    > the database. After we got those results, I abandoned that.


    I think that's a pity, Daniel. If the date validation had been revised, and
    stored as a db stored procedure you may have found very different results
    from your ****ysis. All of the date validation would have "disappeared" for
    a start... :-))

    Never mind. You found a good solution; that's what really matters :-)

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



  2. Default Re: COBOL/DB2 Date edit question

    Pete Dashwood wrote:

    (When you have your "--" and the sig block at the top of the message, my
    reader truncates everything - that's why there's nothing quoted here...)

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

    <ot>
    Then, in my next set of college classes is .NET. I'll be having fun
    with Mono, I'm sure - I may just finally get the knack of that. (Part
    of it is I'm not getting paid for either - it's hard to justify sitting
    on the couch with a laptop in my lap when the kids want folks to bounce
    them on the trampoline, maintain their bikes, etc... ;> )

    And then, I've been "selected" to "voluntarily" retrain into a different
    career field (not programming). They want 20, and I'm #45 on the list,
    so I should be safe. (If 20 don't volunteer, then everyone on the list
    has to pick what they want, and risk being involuntarily retrained.)
    So, I have to decide whether to a) not play this game and get out when
    this enlistment's up (with 13+ years at that point, that seems foolish);
    b) risk being involuntarily retrained to some combat career field; or c)
    choose my own path (there are current openings in safety, radio/TV, and
    as a chaplain's assistant).

    Even if I switch career fields, though, I'll still pursue my bachelor's
    degree in Computer Science - especially when I can breeze through so
    many classes.
    </ot>

    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~ / \/ _ o ~ Live from Albuquerque, NM! ~
    ~ _ /\ | ~ ~
    ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    ~ Business E-mail ~ daniel @ "Business Website" below ~
    ~ Business Website ~ http://www.djs-consulting.com ~
    ~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
    ~ Personal E-mail ~ "Personal Blog" as e-mail address ~
    ~ Personal Blog ~ http://daniel.summershome.org ~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
    V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

    "Who is more irrational? A man who believes in a God he doesn't see,
    or a man who's offended by a God he doesn't believe in?" - Brad Stine

  3. Default Re: COBOL/DB2 Date edit question


    "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
    news:5i9m8uF3lvl7qU1@mid.individual.net...
    [snip]
    > Nope. Most RDBMS will accept anything that looks like a date. (It is one

    of
    > the beautiful things about OO programming, called "overloading".)


    Mr Dashwood, with all due respect, I think you are
    letting your OO fanaticism get the better of you. <g>
    In OO, "overloading" refers to a method accepting
    different types; not different values. More likely is
    that RDBMSs use some form of what might be called
    format matching. For example, DB2 (9.1) apparently
    has six formats: DEF, EUR, ISO, JIS, LOC, and USA.
    For Microsoft Access 97 date literals, "Valid formats
    include the date format specified by the locale settings
    for your code or the universal date format." (However,
    dates in SQL must be in US format.) This suggests
    that formats; not "overloading", have been used for
    some time and by different vendors.




  4. Default VisualAge COBOL (was: COBOL/DB2 Date edit question

    "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
    news:5i8ehiF3lkrtaU1@mid.individual.net...
    >

    <snip>
    >
    > You might not be able to support the ! in the name in Visual Age COBOL (which
    > is actually MicroSoft rebadged)
    >


    IBM's VisualAge COBOL has *nothing* to do with any Microsoft *or* Micro Focus
    product products. IBM's original "IBM COBOL/2" product was a rebadged (slightly
    modified) version of Micro Focus' COBOL/2 product (as was Microsoft's COBOL V4 -
    as I recall its name). However, all the VisualAge (and later) IBM products are
    ports (sort-of) of IBM's mainframe compilers. (The original PC and AIX
    front-ends were identical to the then-current IBM mainframe compiler -- with a
    separate back-end. Since then there have been some divergencies.)

    --
    Bill Klein
    wmklein <at> ix.netcom.com



  5. Default Re: COBOL/DB2 Date edit question



    "LX-i" <lxi0007@netscape.net> wrote in message
    newsMednRMwtNq6VCLbnZ2dnUVZ_qmlnZ2d@comcast.com...
    > Pete Dashwood wrote:
    >
    > (When you have your "--" and the sig block at the top of the message, my
    > reader truncates everything - that's why there's nothing quoted here...)


    Sorry, it was an oversight)
    >
    > 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.



    (Which is right and proper, of course... )

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


    Uh, huh, and what about the program independence? :-)

    I have transferred stored procedure code from MySQL (my personally preferred
    DB, although now that DB2 is "free"I may return to that and bring the wheel
    full circle) and ACCESS and SQL Server, the ones required by the client,
    without problem. (ACCESS is a bit limited in that procedures can only have
    ONE SQL statement, but that's no less than you might expect from ACCESS...
    :-)

    >
    > Personally, I believe that call has to be made for each system, by
    > ****yzing 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.)
    >
    > <ot>
    > Then, in my next set of college classes is .NET. I'll be having fun with
    > Mono, I'm sure - I may just finally get the knack of that. (Part of it is
    > I'm not getting paid for either - it's hard to justify sitting on the
    > couch with a laptop in my lap when the kids want folks to bounce them on
    > the trampoline, maintain their bikes, etc... ;> )


    Play with the kids. They grow quickly. ;-)
    >
    > And then, I've been "selected" to "voluntarily" retrain into a different
    > career field (not programming). They want 20, and I'm #45 on the list, so
    > I should be safe. (If 20 don't volunteer, then everyone on the list has
    > to pick what they want, and risk being involuntarily retrained.) So, I
    > have to decide whether to a) not play this game and get out when this
    > enlistment's up (with 13+ years at that point, that seems foolish); b)
    > risk being involuntarily retrained to some combat career field; or c)
    > choose my own path (there are current openings in safety, radio/TV, and as
    > a chaplain's assistant).
    >
    > Even if I switch career fields, though, I'll still pursue my bachelor's
    > degree in Computer Science - especially when I can breeze through so many
    > classes.
    > </ot>
    >


    I have absolutely no doubt that you will succeed at whatever is asked of
    you, Daniel. You are very capable, and your attitude has never been in
    doubt.

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



  6. Default Re: COBOL/DB2 Date edit question



    "Rick Smith" <ricksmith@mfi.net> wrote in message
    news:13bvjgvie7psk69@corp.supernews.com...
    >
    > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
    > news:5i9m8uF3lvl7qU1@mid.individual.net...
    > [snip]
    >> Nope. Most RDBMS will accept anything that looks like a date. (It is one

    > of
    >> the beautiful things about OO programming, called "overloading".)

    >
    > Mr Dashwood, with all due respect, I think you are
    > letting your OO fanaticism get the better of you. <g>
    > In OO, "overloading" refers to a method accepting
    > different types; not different values. More likely is
    > that RDBMSs use some form of what might be called
    > format matching. For example, DB2 (9.1) apparently
    > has six formats: DEF, EUR, ISO, JIS, LOC, and USA.
    > For Microsoft Access 97 date literals, "Valid formats
    > include the date format specified by the locale settings
    > for your code or the universal date format." (However,
    > dates in SQL must be in US format.) This suggests
    > that formats; not "overloading", have been used for
    > some time and by different vendors.
    >

    OK, I stand corrected.

    All I know is I can throw anything that looks like a date at a RDB and it
    works.

    But you are right, the type is a DATE so it isn't overloaded.

    Pete.



  7. Default Re: VisualAge COBOL (was: COBOL/DB2 Date edit question



    "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
    news:ySRvi.426019$LL7.61210@fe08.news.easynews.com...
    > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
    > news:5i8ehiF3lkrtaU1@mid.individual.net...
    >>

    > <snip>
    >>
    >> You might not be able to support the ! in the name in Visual Age COBOL
    >> (which is actually MicroSoft rebadged)
    >>

    >
    > IBM's VisualAge COBOL has *nothing* to do with any Microsoft *or* Micro
    > Focus product products. IBM's original "IBM COBOL/2" product was a
    > rebadged (slightly modified) version of Micro Focus' COBOL/2 product (as
    > was Microsoft's COBOL V4 - as I recall its name). However, all the
    > VisualAge (and later) IBM products are ports (sort-of) of IBM's mainframe
    > compilers. (The original PC and AIX front-ends were identical to the
    > then-current IBM mainframe compiler -- with a separate back-end. Since
    > then there have been some divergencies.)
    >
    > --
    > Bill Klein
    > wmklein <at> ix.netcom.com
    >


    OK, I said MicroSoft and I meant MicroFocus. I worked on introducing
    MicroFocus into the IBM software house at North Harbour (Southampton, UK) in
    the early 90s. Visual Age was released shortly after that and it was a port,
    not of a mainframe compiler, but simply rebadged MicroFocus in its initial
    release. (It even had the same compiler options). Later they may well have
    done something else with it, but at the time it smacked of MicroFocus. (and
    was a good product...).

    I know you are usually right on these things, Bill, but in this case my
    memory tells it differently. However, I don't see it as important enough to
    argue about and will withdraw my comment if it offends you. (And it was
    definitely wrong,as written, anyway... :-))

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



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

    >>> On 8/12/2007 at 8:59 PM, in message
    <oMednRMwtNq6VCLbnZ2dnUVZ_qmlnZ2d@comcast.com>, LX-i<lxi0007@netscape.net>
    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
    > ****yzing 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


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

    >>> On 8/13/2007 at 11:26 AM, in message
    <46C03FC9.6F0F.0085.0@efirstbank.com>,
    Frank Swarbrick<Frank.Swarbrick@efirstbank.com> wrote:
    >
    > 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.


    I didn't even finish my thoughts! What made me think of this is the
    possible use of the database for validation. Most (all?) RDBMS allow for
    fields to be validated at the database level. This is all fine and dandy,
    but is it really the best way to go? Again, if you do this you allow the
    user to input all of their fields into your application. You then go to the
    database to INSERT (or UPDATE) the record. The database then decides that
    one (or more!) of the values is invalid for their respective fields
    (columns; whatever). It just seems to me to be a lot of extra round trips
    back and forth to the database to finally get valid data inserted. Do
    people really use the database for this? Or to they code the data
    validation in to their applications?

    We're only now, from the mainframe side, starting to utilize a relational
    database, so I have no real world experience when it comes to these things.

    Thanks!

    Frank



  10. Default Re: COBOL/DB2 Date edit question

    >>> On 8/12/2007 at 6:17 PM, in message
    <5i9m8uF3lvl7qU1@mid.individual.net>,
    Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
    >
    > "Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
    > news:jgvub35e1pahgvi467v85db20119s42cub@4ax.com...
    >>I hear what you say Michael. Might I scenario something (and if you
    >> get bored with the subject I will understand) ..
    >>
    >> My 'almost all common data types DB2 table' has 14 columns, one is a
    >> key and in particular, three of the others are DB2 datatypes DATE,
    >> TIME, TIMESTAMP. I populate the CICS screen from this table, any field
    >> may be user changed, I need to edit all changes before they go back
    >> into the table - typical CICS scenario.
    >>
    >> My problem is to find the easiest/clearest way to edit these three
    >> data types before update occurs. I suspect three ways are available:
    >>
    >> 1) my 'neat?' EXEC SQL.'s.
    >> 2) inline code like 'if month < 00 or >12 then error, etc'.
    >> 3) exec cics link 'editdate' with suitable commarea (and othe pgms for
    >> TIME and TIMESTAMP) and test a return code. (your library routine)
    >> 4) some other way??
    >> 5) there is no especially favoured method.
    >>


    > You are suffering from the same problem many have encountered when
    > moving to
    > RDB; incompatibilities between language data types and RDB data types.
    > For
    > the most part, embedded SQL in COBOL does some very good data
    > conversions
    > uder the covers and ensures that the data presented from the DB to the
    > program is in a format that the program can use, and vice versa.


    Looks like I started my previous thread too soon! :-)

    > However, more and more installations are moving away from embedded SQL
    > for a
    > number of reasons:
    >
    > 1. It is still tied back into procedural programming.
    > 2. It is not as powerful as some of the emerging methods for data
    > manipulation which can utilise multiprocessors and deferred execution.
    > (Query Expressions, Lambda functions, etc.)
    >
    > Obviously, most places are not going to move overnight into new database
    >
    > technology. (And it requires using a language that supports the new
    > functions; COBOL doesn't.)
    >
    > The modern trend is to place the editing and validation into stored
    > procedures that are triggered automatically when the data is updated.
    >
    > This makes sense insofar as the validations are stored with the data,
    > and
    > are independent of the language being used. It doesn't matter if you
    > move to
    > Basic, or C++ or C# or whatever, your data still gets validated by the
    > RDBMS
    > back end. (It is also easier to progress from this into the new
    > technology,
    > should you decide to, now or later.)
    >
    > You were close to this solution when you decided to validate the date
    > using
    > an RDB DATE function. All of the solutions you have outlined are
    > workable,
    > it is just a question of what you prefer. Michael thinks it is "obtuse";
    > I
    > disagree. I think it is perfectly sensible. (However, I understand
    > Michael's
    > objection. To a programmer, using program code to do things is the
    > solution.
    > Michael is a very experienced and excellent programmer, so to him this
    > looks
    > like a "sledgehammer to crack a nut'')
    >
    > In fact, there is nothing wrong with using RDB functions to validate
    > data
    > that is being stored on a RDB, the only difference is WHERE you use the
    > function. If you use it from COBOL with embedded SQL, then there is a
    > good
    > argument to be made for simply using program code instead. If, on the
    > other
    > hand, you stored a procedure to do it, and triggered that procedure
    > whenever
    > the date was updated, you have removed the whole business from your
    > program.
    > You get a return saying it worked or it didn't and you can do whatever
    > you
    > want from there. You can also retrieve it, secure in the knowledge that
    > it
    > is "valid" in the wider sense of not just format validation..
    >
    > An important point to note here is that this "back end" validation can
    > go
    > way beyond what you could easily do in program code. You can check the
    > new
    > date against other, previously validated dates now stored on the
    > database,
    > without having to retrieve them into a program. You have all of the
    > extensive SQL DATE manipulation functions immediately available, with no
    >
    > program call overheads. For example, you can check whether the new date,
    >
    > plus a number of days is greater, less, or equal to an existing date,
    > which
    > is, in turn, so many days away from another date which it must exceed,
    > and
    > so on. And that is all before you even start to include data which is
    > NOT a
    > date in the validation.
    >
    > Stored procedures are becoming a way of life on many sites, and embedded
    > SQL
    > is showing a consequent decline.


    I still have the issue I mentioned in my other message. Personally, I am
    not so much concerned as to *where* the business logic / validations exist.
    If it's in a stored procedure, that's fine (as long as I have access to look
    at it!). My concern is that this appears (from my, granted, limited point
    of view) to require a lot of 'back and forth' between the user, the
    application, and the database. Is this not the case?

    One piece of logic that we have in many of our user update type programs is
    the "Do you really mean this" type screen. Here's how it works...

    The user enters various fields on various screens. Secondary screens may or
    may not be present depending on data entered on previous screens. At the
    end of all of the input the user is presented with a screen detailing all of
    the input he has entered, with a button to "Submit" or "Cancel". When he
    submits then the data is actually sent to the database (or to the
    mainframe!).

    Within all of this a lot of validation has been going on. Dates have been
    checked, fields have been validated to make sure they are allowed in
    combination with other fields, etc. The final "Submit/Cancel" page will not
    even be presented to the user until such time as all of the input has been
    validated as being allowed.

    Can this still be done with stored procedures and what have you? I'm not
    trying to be argumentative. I simply see problems and I don't know the
    solutions.

    Thanks!

    Frank


+ Reply to Thread
Page 2 of 10 FirstFirst 1 2 3 4 ... LastLast

Similar Threads

  1. Edit only date in grid
    By Application Development in forum CSharp
    Replies: 2
    Last Post: 12-11-2007, 02:17 PM
  2. Replies: 61
    Last Post: 07-12-2007, 11:26 AM
  3. Replies: 0
    Last Post: 07-05-2007, 05:08 PM
  4. newbie question on cobol syntax
    By Application Development in forum Programming Languages
    Replies: 266
    Last Post: 05-17-2007, 12:38 PM
  5. COBOL/CICS/DB2 - COBOL for MVS and compile option DYNAM
    By Application Development in forum cobol
    Replies: 0
    Last Post: 11-29-2006, 01:39 PM