|
midrange.com
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.
>
>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
