What issues arise from changing physical files so that LVLCHK=*NO - IBM AS400

This is a discussion on What issues arise from changing physical files so that LVLCHK=*NO - IBM AS400 ; What issues have you encountered when changing physical files so that LVLCHK=*NO? Would you recommend doing this? If so, under what circumstances? Have you ever worked on a site where this was the standard? What are the pro's and con's? ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: What issues arise from changing physical files so that LVLCHK=*NO

  1. What issues arise from changing physical files so that LVLCHK=*NO

    What issues have you encountered when changing physical files so that
    LVLCHK=*NO?

    Would you recommend doing this? If so, under what circumstances?

    Have you ever worked on a site where this was the standard?

    What are the pro's and con's?

    Best regards,

    Mike


  2. Re: What issues arise from changing physical files so that LVLCHK=*NO


    Mike wrote:
    > What issues have you encountered when changing physical files so that
    > LVLCHK=*NO?
    >
    > Would you recommend doing this? If so, under what circumstances?
    >
    > Have you ever worked on a site where this was the standard?
    >
    > What are the pro's and con's?
    >
    > Best regards,
    >
    > Mike


    Mike,

    In a nutshell...don't do this!!!!

    Turning off level check is a sure way to corrupt your database files.
    It also can bring about data problems that you might not find out for
    some time...like overstating sales by millions of dollars!

    I don't recommend it under any circumstances and turning off level
    check should never be a shop standard.

    So just in case I didn't make myself clear....don't do this!!!!



    Jonas


  3. Re: What issues arise from changing physical files so that LVLCHK=*NO

    Mike wrote:
    > What issues have you encountered when changing physical files so that
    > LVLCHK=*NO?
    >
    > Would you recommend doing this? If so, under what circumstances?
    >
    > Have you ever worked on a site where this was the standard?
    >
    > What are the pro's and con's?
    >
    > Best regards,
    >
    > Mike


    PROS

    Er, none really. The only "safe" way to do it is if you are adding ALPHA
    only fields to the END of an existing file - if you do so, then the
    original part of the record will be unchanged. You can't add PACKED
    fields as the programs that add records that are not recompiled won't
    initialise the database fields... Uh! Horrible. Packed blanks etc...

    CONS

    Database corruption. Miscellaneous errors start to creep into the
    database. RPG programs may or may not fail dependant upon what version
    of the DDS they were compiled against. Generally you will add
    "unpredictable results" to your processing that could cause you LOTS of
    aggro downstream.


    I am assuming that you are asking this because you don't know how to
    recompile the files efficiently OR you don't know how to find all the
    objects that need to be recompiled. Is this so?

    To change a PF DDS efficiently, look at the CHGPF command SRCFILE
    parameter - or scan the newsgroup postings for explanations - it has
    been covered within the last few weeks.

    To find the objects to recompile, you can find them out using several
    methods:-

    1) DSPDBR the physical to get the list of logicals.
    Use the option 25 in PDM (STRPDM, option 2, then select your
    source files, then use 25). Run searches for each logical file
    name (or partial name if you name your logicals generically)...

    2) OR DSPDBR the physical to get the list of logicals.
    DSPPGMREF the program object libraries to a PF (with *ADD) to
    get a list of all the program references. Write a query to pull
    out a list of all programs etc. that are referencing the files
    (again, generically named logicals make it a bit easier...

    3) Formalise 2) to create a utility to automate the process - it
    will pay you back for doing so.

    3) Get some source & object management software. It can be pricey!

    4) Several other methods that other people may suggest when they
    read this...

    HTH

    GB

    P.S. Don't, don't use LVLCHK(*NO)

  4. Re: What issues arise from changing physical files so that LVLCHK=*NO


    "Jonas Temple" wrote in message
    news:1166112423.515023.98080@f1g2000cwa.googlegrou ps.com...
    |
    | Mike wrote:
    | > What issues have you encountered when changing physical files so
    that
    | > LVLCHK=*NO?
    | >
    | > Would you recommend doing this? If so, under what circumstances?
    | >
    | > Have you ever worked on a site where this was the standard?
    | >
    | > What are the pro's and con's?
    | >
    | > Best regards,
    | >
    | > Mike
    |
    | Mike,
    |
    | In a nutshell...don't do this!!!!
    |
    | Turning off level check is a sure way to corrupt your database
    files.
    | It also can bring about data problems that you might not find out
    for
    | some time...like overstating sales by millions of dollars!
    |
    | I don't recommend it under any circumstances and turning off level
    | check should never be a shop standard.
    |
    | So just in case I didn't make myself clear....don't do this!!!!
    |
    |
    |
    | Jonas


    Mike,

    Jonas is right!

    Without LVLCHK, the system will let you run an old version of a
    program against a file that has been redesigned or even a program
    against a file for which it was not designed at all.

    Both cases would likely corrupt the data. With LVLCHK=*YES the system
    will protect you from these accidents and stop programs from opening
    files that do not have the matching formats.

    Unless every programmer in your shop is perfect and never makes
    mistakes you should let the system protect you. It is free and will
    only stop a program run that should not happen anyway!

    Do not do this!

    Mike Sicilian






+ Reply to Thread