Hi,
i think I should give my final feedback on this issue to complete this
topic.
After we updated our LE runtime library, all problems got solved!
It means, for the load modules generated using 'Enterprise PL/I v3r1m0' ,
they work normally now under the new LE without re-compiling and
On Mon, 28 Aug 2006 19:32:15 -0500, Ed Gould [EMAIL PROTECTED]
wrote:
Finally, you should always report your problems (including performance
problems) to IBM service so that it will come to us directly. Our PL/I
service people can help you identify this type of performance
problem and
its
Now I would give the latest feedback on this topic.
After I switched from 'Enterprise PL/I for Z/OS v3r1m0' to 'IBM PL/I
for MVSVM V1R1M1', my problem has been solved.
And I would say thanks to Barry Merrill. He kindly took my SMF dump
data set duing my test and gave me the analysis:
The two
In [EMAIL PROTECTED], on
08/27/2006
at 09:49 AM, Johnny Luo [EMAIL PROTECTED] said:
IBM said it's a problem that 'VisualAge and Enterprise PL/I
sometimes use BSAM for record I/O, while the older PL/I always used
QSAM.
That's wrong; even PL/1 (F) supported BSAM.
So, what I should do?
Get
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Johnny Luo
Sent: Monday, August 28, 2006 7:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Z/os Performance issue: REWRITE a sequential data set
snip
So it's really because of BSAM
LE as used by COBOL and LE as used by PL/1 are wildly different. The
functionality is the same but many of the interfaces and defaults are
different. For examle, I had a problem whtere the old cobol II runtime was
in the joblist - PL/1 ran just fine - COBOL did NOT.
MIke
On 8/28/06, Johnny Luo
From: Johnny Luo [EMAIL PROTECTED]
Ok, ADCD 1.4 is old and maybe is lack of maintenance so its PL/I compiler
is 'buggy'. But how about the compiler of my friend's site? It's the newer
version and is under normal maintenance( built on 20051017) .
I doubt that IBM would accept your
This performance problem was addressed in December 2004 (APAR PQ95212)
when we did the I/O rewrite. We have made substantial improvements in
Enterprise PL/I I/O during the past couple of years and we are in the
process of making more. For example, PQ95212 (12/2004) improved PL/I's
record I/O
On Aug 28, 2006, at 5:14 PM, Rick Arellanes wrote:
SNIP___
Finally, you should always report your problems (including performance
problems) to IBM service so that it will come to us directly. Our PL/I
service people can help you identify this type of performance
I got confused earlier in this thread. I thought the original report was
that running the original PL/I program on you PC caused performance
problems. I now think the report was that using COBOL caused the problem.
If it is COBOL having the problem, then check the following compiler
options:
to verify.
On 8/27/06, Robert A. Rosenberg [EMAIL PROTECTED] wrote:
At 09:49 +0800 on 08/27/2006, Johnny Luo wrote about Re: Z/os
Performance issue: REWRITE a sequential data set:
So i think the problem is just what Robert said : QSAM and BSAM.
Score one for me g. It was just a SWAG (Scientific
Bill, all these performance problems are concering Pl/i programs
and it's because of our 'buggy' pl/i compiler.
On 8/27/06, Bill Klein [EMAIL PROTECTED] wrote:
I got confused earlier in this thread. I thought the original report was
that running the original PL/I program on you PC caused
Robert A. Rosenberg wrote:
At 23:15 +0800 on 08/26/2006, Johnny Luo wrote about Re: Z/os
Performance issue: REWRITE a sequential data set:
Because the pl/i program is simple, i'll put its main logic here:
(It's our customer's production program)
DO WHILE (!EOF_FILEA !EOF_FILEB);
DO WHILE
Johnny Luo wrote:
My god...thanks a lot!!
I've done a small test:
1, First create a (vb,1024,27998,ps) data set on zos and write many records
to it.
All records with the same actual length: 8
so the data set is actually small.
2, Then I code a PL/I program to update first 40,000
On Sun, 27 Aug 2006 09:19:44 -0600 Steve Comstock [EMAIL PROTECTED]
wrote:
:One alternative might be to code MACRF=PL in the
:DD statement for the file you are updating in place;
:not sure though; would like to see the FD first.
Unless thing have DRASTICALLY changed, MACRF does not go on the DD
Binyamin Dissen wrote:
On Sun, 27 Aug 2006 09:19:44 -0600 Steve Comstock [EMAIL PROTECTED]
wrote:
:One alternative might be to code MACRF=PL in the
:DD statement for the file you are updating in place;
:not sure though; would like to see the FD first.
Unless thing have DRASTICALLY changed,
Hi,
I don't know whether this is really a 'performance issue' because it occurs
on
our company's ADCD ZOS1.4 system running on an pc.
We recently converted some pl/i batch programs to cobol for a customer.
(Enterprise Z/os PL/I 3.1) Then they sent us with some input data sets
for testing
Here is the step log for first program :
S t e p E n d S t a t i s t i c s
Step Name: INP185 Cond Code: Start: 26-Aug-2006
05:16:15 PM
Step Num: 4 PGM Name: INP185 End: 26-Aug-2006
06:47:49 PM
CPU (TCB): 01:07:56.54
I thik I should supply more information :)
CIACIDX is the input-only file which has 100,000 records.
INFILE is the I-O mode file which has 50,000 records and it's the file
the program will rewrite.
The Excp Count for CIACIDX is only 99 but for INFILE it's
3,175,403!!!
On 8/26/06, Johnny
Sorry for so many mails.
If I just remove the REWRITE statement, the log will be like :
S t e p E n d S t a t i s t i c s
Step Name: INP185 Cond Code: Start: 26-Aug-2006
07:02:57 PM
Step Num: 4 PGM Name: INP185 End:
PC hardware shouldn't be the problem, since z/OS is reporting 3 million
EXCPs. That's a lot of I/O.
Could it be that you REWRITE with a different record length and COBOL has to
shift the whole file? Perhaps a GTF trace will help you figure out what is
happening.
You might do better to write a
On 8/26/06, Tom Marchant [EMAIL PROTECTED] wrote:
PC hardware shouldn't be the problem, since z/OS is reporting 3 million
EXCPs. That's a lot of I/O.
Tom, thanks a lot
Because I never worked on a real z machine(except for some small work),
I'm not sure about the
Johnny Luo wrote:
On 8/26/06, Tom Marchant [EMAIL PROTECTED] wrote:
PC hardware shouldn't be the problem, since z/OS is reporting 3 million
EXCPs. That's a lot of I/O.
Tom, thanks a lot
Because I never worked on a real z machine(except for some small work),
I'm
On 8/27/06, Steve Comstock [EMAIL PROTECTED] wrote:
So your equivalent COBOL logic is something like this?
perform until end-filea or end-fileb
perform until end-fileb or filea-act fileb-act
if filea-act = fileb-act
move filea-amt to fileb-amt
rewrite fileb-rec
end-if
Johnny Luo wrote:
On 8/27/06, Steve Comstock [EMAIL PROTECTED] wrote:
So your equivalent COBOL logic is something like this?
perform until end-filea or end-fileb
perform until end-fileb or filea-act fileb-act
if filea-act = fileb-act
move filea-amt to fileb-amt
rewrite
At 23:15 +0800 on 08/26/2006, Johnny Luo wrote about Re: Z/os
Performance issue: REWRITE a sequential data set:
Because the pl/i program is simple, i'll put its main logic here:
(It's our customer's production program)
DO WHILE (!EOF_FILEA !EOF_FILEB);
DO WHILE (!EOF_FILEB FILEA_ACT
On 26 Aug 2006 06:56:15 -0700, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (Tom Marchant) wrote:
Could it be that you REWRITE with a different record
length and COBOL has to
shift the whole file? Perhaps a GTF trace will help you
figure out what is
happening.
My god...thanks a lot!!
I've done a small test:
1, First create a (vb,1024,27998,ps) data set on zos and write many records
to it.
All records with the same actual length: 8
so the data set is actually small.
2, Then I code a PL/I program to update first 40,000 records.
The program
At 09:49 +0800 on 08/27/2006, Johnny Luo wrote about Re: Z/os
Performance issue: REWRITE a sequential data set:
So i think the problem is just what Robert said : QSAM and BSAM.
Score one for me g. It was just a SWAG (Scientific/Stupid Wild Ass
Guess) analysis on my part. Sometimes you just
29 matches
Mail list logo
