|
midrange.com
CALL CHKIFSOBJ PARM(&STMFPATH &OBJTYPE)
PGM PARM(&IFSOBJ &OBJTYPE)
&STMFPATH is *CHAR 25, while &IFSOBJ is *CHAR 256. I'd start by making
those the same.
> -------- Original Message --------
> Subject: Re: Weird CL behavior
> From: "Steve McKay" <nospammers1@xxxxxxxxx>
> Date: Fri, December 10, 2004 2:01 pm
> To: midrange-l@xxxxxxxxxxxx
>
> 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.
> >
> >
>
>
>
> --
> 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.
