Endevor

  • 1.  Problem in Processor group

    Posted Nov 01, 2010 12:48 PM
    Hi

    My client is havin some problem in a moving a module to the PROD. The problem behind is nothing but the module is generating a PARMCARD which has a statement PARM LINK(module name) PLAN(plan name) BIND(STATIC-ONLY) but its throwing an error. If the statement is replaced as PARM LINK(module name) PLAN(plan name) BIND(STATIC-ONLY) SQLSYNTAX NONE it'll not through the error.


    This statement is defined in an SYSIN statement where as that particular statement is defined in an Processor Group which gets picked up automatically for the GENERATION purpose. So that particular statement cannot be modified because its common for all the elements.

    Please let me know if there is anyother way to get this code to PROD without changing the Processor group


    Thanks In Advance.

    Cheers

    Nithyaraj
    -_-


  • 2.  RE: Problem in Processor group

    Posted Nov 09, 2010 11:19 AM
    Can your client provide the error being produced by the processor using the DB2 bind card? If it works by ignoring SQL syntax, there must be a DB2 error causing the problem. If you can attached the bind error, then I can probably see what wrong.


  • 3.  RE: Problem in Processor group

    Posted Nov 10, 2010 09:59 AM
    Grant,

    It looks like its not possible to pull out the error log now since its not there in the spool. Is there any other info that i can provide which can help you out other than the error.Any how i have attached the SYSIN stmt where the change has to be made have a look at it.


    // IF ((&C1PRGRP = EZTB2) OR (&C1PRGRP = EZTBM)) THEN 08571200
    //* 08571300
    //BLDCMP2 EXEC PGM=IEBGENER,MAXRC=0 08571400
    //SYSPRINT DD DUMMY 08571500
    //SYSOUT DD DUMMY 08571700
    //SYSIN DD DUMMY 08571800
    //SYSUT2 DD DSN=&&CMPELM,DISP=(,PASS), 08571900
    // UNIT=&WRKUNIT,SPACE=(TRK,(1,1)), 08572000
    // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120) 08572100
    //SYSUT1 DD * 08572300
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY) 08572400
    /* 08572600
    //* 08572700
    // ENDIF

    Regards

    Nithyaraj
    -_-


  • 4.  RE: Problem in Processor group
    Best Answer

    Posted Nov 10, 2010 01:41 PM
    Nithyaraj,

    So this is a Easytrieve paramter passed into the EZTPA00 program. Since the move of the element into production only works with the SQLSYNTAX NONE parameter, something must be wrong with the SQL within the Easytrieve. I've seen this happen if a DB2 table isn't in the production region or a definition in production is different than in test.

    I would suggest Re-generate the program to see what the SQL error really is, then fixing the DB2 issue. If this condition is unavoidable for a valid reason when moving to production, then I would suggest the following:

    1) Create a new processor group for Easytrieve the will add this SQLSYNTAX NONE parameter to the IEBGENER step in the processor
    ==============
    OPTION ONE:
    ==============
    // IF ((&C1PRGRP = EZTB2) OR (&C1PRGRP = EZTBM) OR
    // (&C1PRGRP = EZTBNEW)) THEN
    //*
    //BLDCMP2 EXEC PGM=IEBGENER,MAXRC=0
    //SYSPRINT DD DUMMY
    //SYSOUT DD DUMMY
    //SYSIN DD DUMMY
    //SYSUT2 DD DSN=&&CMPELM,DISP=(,PASS),
    // UNIT=&WRKUNIT,SPACE=(TRK,(1,1)),
    // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
    //
    // IF (&C1PRGRP = EZTBNEW) THEN
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY) +
    SQLSYNTAX NONE
    /*
    //* ELSE
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY)
    /*
    //* ENDIF
    //*
    // ENDIF

    2) Don't create a new processor group and use CCID to add this SQLSYNTAX NONE parameter to the IEBGENER step in the processor
    ==============
    OPTION TWO:
    ==============
    // IF ((&C1PRGRP = EZTB2) OR (&C1PRGRP = EZTBM))
    //*
    //BLDCMP2 EXEC PGM=IEBGENER,MAXRC=0
    //SYSPRINT DD DUMMY
    //SYSOUT DD DUMMY
    //SYSIN DD DUMMY
    //SYSUT2 DD DSN=&&CMPELM,DISP=(,PASS),
    // UNIT=&WRKUNIT,SPACE=(TRK,(1,1)),
    // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
    //
    // IF (&C1CCID = 'SYNTAXNONE') THEN
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY) +
    SQLSYNTAX NONE
    /*
    //* ELSE
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY)
    /*
    //* ENDIF
    //*
    // ENDIF

    3) Don't create a new processor group and use COMMENT to add this SQLSYNTAX NONE parameter to the IEBGENER step in the processor

    ==============
    OPTION THREE:
    ==============
    // IF ((&C1PRGRP = EZTB2) OR (&C1PRGRP = EZTBM))
    //*
    //BLDCMP2 EXEC PGM=IEBGENER,MAXRC=0
    //SYSPRINT DD DUMMY
    //SYSOUT DD DUMMY
    //SYSIN DD DUMMY
    //SYSUT2 DD DSN=&&CMPELM,DISP=(,PASS),
    // UNIT=&WRKUNIT,SPACE=(TRK,(1,1)),
    // DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)
    //
    // IF (&C1COM = 'SYNTAXNONE') THEN
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY) +
    SQLSYNTAX NONE
    /*
    //* ELSE
    //SYSUT1 DD *
    PARM LINK(&C1ELEMENT(R)) PLAN(&C1ELEMENT(1,7)C) BIND(STATIC-ONLY)
    /*
    //* ENDIF
    //*
    // ENDIF

    I do think there is probably a DB2 error that can be resolved in the Easytrieve code that would require no changes at all. Here is an explanation for the Easytrieve parameter:

    All SQL Environments

    In all environments, use the SQLSYNTAX parameter to specify the level of SQL
    syntax checking to perform on the SQL statements in your program.

    SQLSYNTAX FULL indicates that SQL statements undergo detail-level syntax
    checking. An SQL PREPARE statement executes for those SQL statements that
    can be dynamically prepared. Your DBMS must be available to CA-Easytrieve
    Plus.

    SQLSYNTAX PARTIAL checks your SQL statements for valid commands and
    secondary keywords. No connection is made to your DBMS unless you coded an
    SQL INCLUDE statement in your program. Your program cannot execute until it
    undergoes FULL syntax checking.

    SQLSYNTAX NONE
    You can use the SQLSYNTAX NONE parameter on the PARM statement with a
    static bind if you want the DB2 for OS/390 and z/OS preprocessor to perform
    syntax checking in a batch environment. An option of NONE performs partial
    syntax checking on your program. If no partial level compile errors are found
    and a BIND option of STATIC-ONLY is specified and no other non-SQL syntax
    errors are found, your program continues to execution.
    You can use SQLSYNTAX NONE with BIND STATIC-ONLY to process
    unqualified tables. With SQLSYNTAX NONE, you eliminate the dynamic bind
    which qualifies all unqualified tables. You can then set a qualifier when you
    BIND the DBRM of the static-command-program.

    Hope this helps.

    Grant


  • 5.  RE: Problem in Processor group - Thanks

    Posted Nov 11, 2010 08:52 AM
    Grant,

    Good Day.

    The information you've provided is really helpful. Thanks for the detailed explanation and you've made the things very much clear. I'll let you know what

    exactly i have followed for getting this done.

    Thanks Again.

    Cheers

    Ntihyaraj
    :happy