Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Yes.
When you send a message to a JES2 data set, the message is added to any messages already in the data set.
In your arrangement, the first program opened, then closed the data set, and then the second program did the same. When you have a real data set (as opposed to a JES data set, which is a little different) the second use of the data set restarts output to the data set. In other words, the data already in the data set is trashed, as you observed.
One possible fix, provided MY.OUTPUT does not actually exist, is to specify DISP=(MOD.CATLG) rather than DISP=(NEW,CATLG)
For what it's worth, I suspect JES2 would tell you it's working as designed. Whether the design is appropriate is another question, and probably goes back to the design history of HASP and was forwarded to JES2. When HASP developed the idea of data sets, when the JCL specified SYSOUT=X, the DD statement was allocated to a pseudo printer, and OPEN/CLOSE boundaries were effectively ignored and HASP treated the device like a real printer. Come JES2, they decided it should behave the same way.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Don't have time to test this now, in a few minute we're off to the Netherlands for a birthday, but I find it very strange that printing to a file would not gave the same results as printing to sysout. and in the 32+ years I've used PL/I, I've never had to resort to using FLUSH, even for programs with dozens of external subroutines.
What you might try is opening myfile explicitly in your main program. Files are by default external, so if the definitions in each module are the same, there should be no problems.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Enterprise PL/I Language Reference wrote:
The FLUSH statement flushes the buffers associated with an open output file (or with all open output files if * is specified). This normally happens when the file is closed or the program ends, but the FLUSH statement ensures the buffers are flushed before any other processing occurs.
The manual seems to me to be saying the FLUSH statement accomplishes this task by immediately closing a PL/I file.
Now I mostly work in Assembler, and I've noticed when using QSAM "locate mode" PUT macros that a line in progress does not actually get written until the related DCB is closed or the next PUT macro is issued. This makes sense: "locate mode" PUT returns the address of an I/O area to fill and the only way to be certain this is complete is to issue a new PUT or to close the DCB. "Move mode" PUTs usually seem to be more immediate. Even so, if it's filling an I/O buffer the buffer won't get written until it's filled or the related DCB is closed.
SDSF JOB DATA SET DISPLAY - JOB PRINOCOM (JOB14398) LINE 1-9 (9)
COMMAND INPUT ===>
PREFIX=* DEST=(ALL) OWNER=PRINO SYSNAME=
NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt Page-Cnt Byte-Cnt
JESMSGLG JES2 2 PRINO H LOCAL 16 888
JESJCL JES2 3 PRINO H LOCAL 109 4,403
JESYSMSG JES2 4 PRINO H LOCAL 103 5,499
SYSPRINT IBMZPLI 106 PRINO H LOCAL 414 13,830
SYSPRINT IBMZPLI 107 PRINO H LOCAL 240 7,658
SYSPRINT IEWL 108 PRINO H LOCAL 270 20,001
SYSPRINT GO 109 PRINO H LOCAL 3 48
OSTREAM GO 110 PRINO H LOCAL 3 48
ORECORD GO 111 PRINO H LOCAL 3 45
1test 1
test 2
test 3
1test 1
test 2
test 3
test 1
test 2
test 3
In other words, (and expecting nothing else), perfectly OK.
ORECORD (obviously) doesn't have the leading ASA character.
Changing //OSTREAM to a temporary dataset and following that with a SORT (SORT FIELDS=COPY) to SORTSOUT DD SYSOUT=* will add additional blank lines to the output, caused by the SKIP in the "put skip file(ostream) list(orec);" statements.
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
I probably have multiple problems... at least one problem is that when the second program is called, it receives an undefined file condition.
I issue a PUT statement right before calling the second program (I see it in the data set) and the first statement in the second program is a PUT, which I do not get.
fyi. I am adding a new function to existing PLI programs, several of which are 10K lines of code or more. I think something in the complexity of the setup is interfering with the PUT functions / file allocations.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Pedro wrote:
I probably have multiple problems... at least one problem is that when the second program is called, it receives an undefined file condition.
And the file is declared the same as in the main procedure?
Pedro wrote:
I issue a PUT statement right before calling the second program (I see it in the data set) and the first statement in the second program is a PUT, which I do not get.
You have an
Code:
on error
begin;
on error system
"put whatever message"
close file(sysprint);
end;
Pedro wrote:
fyi. I am adding a new function to existing PLI programs, several of which are 10K lines of code or more. I think something in the complexity of the setup is interfering with the PUT functions / file allocations.
Highly unlikely, but you might try compiling "OPT(0)" and run the program again, although it's only once, using the old OS compiler, that this actually solved the problem. Enterprise PL/I can handle programs with 40k lines, we have someone on "that" system with a program that long, still using EPLI V3.3!
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
I have separately linked programs, with several separate load modules.
There was some improvement after I closed the file before calling the second program, then opening it again later after the return. That was probably the origin of the problem. Now I have to figure out where else I need to do the same.
