Denis,
Thanks. The system does *not* use the library list to search for files.
I'm reluctant to change it so I won't.
Your memory regarding the second point seems to be working. Douglas pointed
this out, too.
Jerry C. Adams
IBM i Programmer/Analyst
You can observe a lot by watching. - Yogi Berra
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Denis Robitaille
Sent: Monday, July 11, 2011 8:41 AM
To: Midrange-L
Subject: Rép. : 36 Environment Library Issue
It has been a long time but here is my 2c.
- first check the s36 environment configuration (dsps36). You will see ther
if you are using the library list to access system 36 files. If so, this has
precedence over the FLIB value.
- If memory serves ne well, when you change the FLIB, it only works for the
following OCL program, not the current one (I am not sure of this). If so,
you will need to split your program and have the first one call the second
one after the change of FLIB.
hope this help
"Jerry C. Adams" <midrange@xxxxxxxx> 2011-07-11 08:44 >>>
This is old school (36 environment), but hoopefully someone can help.
The default Files Library (?FLIB?) is, as usualy, QS36F, but I am trying to
run a test from TSTQS36F. In the OCL there is a statement (FLIB TSTQS36F)
to change the files library. Prior to that there is a CL that physically
removes QS36F from the library list.
There is another CL that copies production files (QS36F) to test (TSTQS36F).
After that there is a step in the OCL that prints the DSPLIBL, which chows
TSTQS36F but no reference to QS36F.
The OCL bombs, though, when it tests whether the test file has records or
not (// IFF ?F'A,?L'1,1'?.WKLINE'?/00000000 GOTO GOTREC), but the test fails
because it does not branch to the tag (// * 'FILE ?L'1,1'?.WKLINE HAS 0
RECORDS, JOB CANNOT RUN!').
All of this runs under a user profile, which uses TSTQS36F as the files
library.
The file tested does exist in TSTQS36F and it does have records. The only
thing I can imagine is that the test is looking in QS36F or some other
library because, if the file cannot be found, the OCL defaults to *Zero
records.
The complete OCL in question: Notes afterwards
DSPLIBL OUTPUT(*PRINT) [1]
CALL PGM(PROJ0013/DTOLIBL) [2]
FLIB TSTQS36F [3]
// LOCAL OFFSET-1,DATA-'J'
// IF ?FLIB?=TSTQS36F EVALUATE P58=DTOOE200
// ELSE EVALUATE P58=TDTOOE
DSPLIBL OUTPUT(*PRINT) [4]
CALL PGM(PROJ0013/CLRWKFILES) [5]
DSPLIBL OUTPUT(*PRINT) [6]
*
* IF FILE HAS 0 RECORDS DO NOT LET JOB RUN
// IFF ?F'A,?L'1,1'?.WKLINE'?/00000000 GOTO GOTREC
// * 'FILE ?L'1,1'?.WKLINE HAS 0 RECORDS, JOB CANNOT RUN!' [7]
[1] Shows QS36F in the USRLIBL,
[2] Removes QS36F and adds TSTQS36F to the USRLIBL.
[3] The 36EE command to change the files library
[4] Shows TSTQS36F in the USRLIBL. No reference to QS36F
[5] Copies the production files (A.WKxxxx) to TSTQS36F (J.WKxxxx) and clears
the production files.
[6] Shows TSTQS36F in the USRLIBL. No reference to QS36F.
[7] Procedure blows off here.
This morning I verified that the J.WKxxxx files exist in TSTQS36F and that
they have records. So why does the procedure crash and burn at note [7]?
Jerry C. Adams
IBM i Programmer/Analyst
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
midrange.com
