Re: Weird CL behavior -- MIDRANGE-L

Yup, mismatch - &STMFPATH is length 25 in the calling program, 256 in the 
called program.

-------------- Original message -------------- 

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