Re: Weird CL behavior -- MIDRANGE-L

Bruce -

Here ya go -

Call to CHKIFSOBJ from CL program:

DCL        VAR(&STMFPATH) TYPE(*CHAR) LEN(25)
DCL        VAR(&OBJTYPE) TYPE(*CHAR) LEN(7)
DCL        VAR(&COUNTER) TYPE(*DEC) LEN(7 0) VALUE(0)
DCL        VAR(&TOMBRNAM) TYPE(*CHAR) LEN(10)
/*   some stuff omitted    */
READFILE:    RCVF
             MONMSG     MSGID(CPF0864) EXEC(GOTO CMDLBL(CLEANUP))
/*   some more stuff omitted   */
             IF         COND(&SPLFNAM *EQ 'CHECK') THEN(DO)
NAMELOOP:         CHGVAR    VAR(&COUNTER) VALUE(&COUNTER + 1)
                                CHGVAR    VAR(%SST(&TOMBRNAM 1 3)) 
VALUE('CHK')
                                CHGVAR    VAR(%SST(&TOMBRNAM 4 7)) 
VALUE(&COUNTER)
                                CHGVAR    VAR(&STMFPATH) VALUE('/apchecks/')
                                CHGVAR    VAR(%SST(&STMFPATH 11 10)) 
VALUE(&TOMBRNAM)
                                CALL CHKIFSOBJ PARM(&STMFPATH &OBJTYPE)
                                IF         COND(&OBJTYP *NE 'NOT FND') 
THEN(DO)
                                   GOTO      CMDLBL(NAMELOOP)
                                ENDDO
                                CPYSPLF   FILE(&SPLFNAM) 
TOFILE(QTEMP/APCHECKS) +
                                        JOB(&JOBNBR/&USER/&JOBNAME) +
                                        SPLNBR(&FILENBR) TOMBR(&TOMBRNAM)
                                CPYTOIMPF FROMFILE(QTEMP/APCHECKS &TOMBRNAM) 
+
                                        TOSTMF(&STMFPATH) 
STMFCODPAG(*PCASCII) +
                                        RCDDLM(*CRLF) DTAFMT(*FIXED)
                                ENDDO
                                GOTO      CMDLBL(READFILE)
===================================================================================
Source for CHKIFSOBJ (CLLE):

             PGM        PARM(&IFSOBJ &OBJTYPE)

             DCL        VAR(&IFSOBJ) TYPE(*CHAR) LEN(256)
             DCL        VAR(&RTNVALBIN) TYPE(*CHAR) LEN(4)
             DCL        VAR(&RTNVALDEC) TYPE(*DEC) LEN(5 0)
             DCL        VAR(&RECEIVER) TYPE(*CHAR) LEN(4096)
             DCL        VAR(&NULL) TYPE(*CHAR) LEN(1) VALUE(X'00')
             DCL        VAR(&OBJTYPE) TYPE(*CHAR) LEN(7)

             CHGVAR     VAR(&IFSOBJ) VALUE(&IFSOBJ *TCAT &NULL)

             CALLPRC    PRC('stat') PARM(&IFSOBJ &RECEIVER) +
                          RTNVAL(%BIN(&RTNVALBIN))

             CHGVAR     VAR(&RTNVALDEC) VALUE(%BIN(&RTNVALBIN))

             IF         COND(&RTNVALDEC *NE 0) THEN(DO)
             CHGVAR     VAR(&OBJTYPE) VALUE('NOT FND')
             GOTO       CMDLBL(EOJ)
             ENDDO

             CHGVAR     VAR(&OBJTYPE) VALUE(%SST(&RECEIVER 49 7))

EOJ:         ENDPGM


"Bruce Vining" <bvining@xxxxxxxxxx> wrote in 
message 
news:OFDA864A5E.E65C6EA2-ON86256F66.005F4005-86256F66.005FAC21@xxxxxxxxxxxxx
>
>
>
>
> Quite often when you add a call to a *pgm and the caller starts to
> demonstrate "weird behavior" there is a mismatch between parameter
> definitions.  Can you provide your call to CHKIFSOBJ (along with the
> parameter definitions) and the code for CHGIFSOBJ?
>
>
>
>
>
>             "Steve McKay"
>             <nospammers1@yaho
>             o.com>                                                     To
>             Sent by: 
> midrange-l@xxxxxxxxxxxx
>             midrange-l-bounce                                          cc
>             s@xxxxxxxxxxxx
>                                                                   Subject
>                                       Weird CL behavior
>             12/10/2004 10:46
>             AM
>
>
>             Please respond to
>             Midrange Systems
>                 Technical
>                Discussion
>
>
>
>
>
>
> Bear with me - this one takes a little bit to explain -
>
> I have a CL program which does WRKOUTQ outqname *PRINT, then a CPYSPLF of
> the resulting print to a physical file, then reads the PF looking for a
> spool file with the name "CHECK".
>
> When the "CHECK" spool file is found, it is CPYSPLFed to another PF then
> the
> resulting PF member is CPYTOIMPFed to an IFS file.
>
> Since there may be multiple CHECK spool files, there is a RCVF loop which
> copies the multiple CHECK spools to multiple IFS files.  The IFS files are
> named CHK99999 where the 99999 is incremented by the program in a loop
> within the RCVF loop.
>
> All of the above process works fine - if there are 4 CHECK files in the
> outq, I get 4 IFS files named CHK00001, CHK00002, CHK00003, and CHK00004.
>
> I realized that there may already be an IFS file named CHK00001, etc. 
> prior
>
> to the execution of my program so I'm CALLing a CLLE program (CHKIFSOBJ)
> which CALLPRCs the 'stat' API to check for the existence of CHK00001 prior
> to the CPYSPLF and CPYTOIMPF and returns to the original CL program.
>
> When I add the CALL to CHKIFSOBJ to the original CL, it breaks something
> and
> when I loop back to RCVF the next record, I get the first record in the
> file!  If I take out the CALL CHKIFSOBJ and the IF statement which checks
> the returned parm, the program works fine (although it doesn't check for
> the
> existence of the IFS file before creating it).  When I put the CALL and IF
> back, the first CHK00001 IFS file gets created and the subsequent RCVF
> begins at the first record in the PF.
>
> There are 19 records in the PF which contains the output of the WRKSPLF 
> and
>
> subsquent copy to the PF.  The first CHECK record is record number 14.  So
> I
> read the first 13 records, the 14th record is a CHECK record which causes
> the program to call CHKIFSOBJ and create the IFS file then the next RCVF,
> which should read the 15th record, begins at record 1!
>
> Is this an activation group problem?  Or is there something weird about 
> the
>
> 'stat' C API?  Or is it just weird?
>
> Thanks for your comments or suggestions,
>
> Steve
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: 
> MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: 
> MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>