PK64372 (was: SMS NONSMS difference)
Paul Gilmartin
>
>We are writing from a multthread C/C++ application to a dataset
>,allocated with (RECFM=F,LRECL=133,BUFNO=1).
>If it is non SMS managed we got all the outputs from the different
>threads, but if SMS managed the last close overwrite the previous
>Can we do something against this ?
>
This feels vaguely similar to PK64372. The APAR is peculiarly
uninformative, but IBM might share more with you. The associated
PMR is Record 79232,033,000. I hope IBM doesn't share PMRs with
the general public, but if you want, I'll scrape it and mail it
to you.
NF? This really should be PER, though IBM might make a case for
PER/FIN given the behavior change they suggest in the PMR.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Miklos Szigetvari
If you would mail to me
miklos.s...@isis-papyrus.com
Thank you.
Paul Gilmartin wrote:
--
Miklos Szigetvari
Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081
E-mail: miklos.s...@isis-papyrus.com
Info: in...@isis-papyrus.com
Hotline: +43-2236-27551-111
Visit our Website: http://www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------
Paul Gilmartin
>
>If you would mail to me
>
>Paul Gilmartin wrote:
>>>
>>This feels vaguely similar to PK64372. The APAR is peculiarly
>>uninformative, but IBM might share more with you. The associated
>>PMR is Record 79232,033,000. I hope IBM doesn't share PMRs with
>>the general public, but if you want, I'll scrape it and mail it
>>to you.
>>
>>NF? This really should be PER, though IBM might make a case for
>>PER/FIN given the behavior change they suggest in the PMR.
>>
This is similar to your problem only in that it involves unexpected
behavior of OPEN/CLOSE. But, to explain, in my case, I did:
exec cp -B
-PRECFM=FB,LRECL=80,BLKSIZE=0,SPACE=(10000,(10000,1)) supr610.ptf
//SMI.supr610.ptf
And the program failed with ABEND SB37 with only 2 blocks in
the primary extent.
Kirk Wolf deduced the explanation, and IBM confirms/expands:
When SPACE is specified, CRTL/LE adds a RELEASE option (Why?)
then opens the data set once to create it; closes it, causing
the RELEASE to take effect; then opens it again to write the
data. Bingo! SB37.
This is just plain wrong; fixing it is not New Function except
by the strained reasoning that correct operation of a function
that has operated incorrectly is "new". By such reasoning,
repairing any aboriginal defect is introducing "New Function".
IBM _might_ argue that the behavior change of no longer truncating
mandates deferring the change to a release boundary.
It's easy to suspect that some coder got his branch mask
complemented and the intent was to truncate when a default
SPACE is used, not when the programmer specifies SPACE. But
in either case, the RELEASE should be performed after the data
are written, rather than before.
IBM says it's extraordinarily difficult to fix. Feels like
dreadful layering of functions in CRTL/LE.
Don Imbriale
--
--
Don Imbriale
temporarily retired
----------------------------------------------------------------------
Paul Gilmartin
>In the SPACE parameter, reverse the primary and secondary quantities.
>
Irrelevant. Please don't claim that the existence of even an obvious
alternative refutes the observation of the original problem. It
might demote it from a SEV2 to a SEV3 (I reported it initially as
SEV3), but it should be PER, regardless.
IBM does this far too often: I report a problem; they recode my
test case to one that does not exhibit the problem, then say,
"Oh, no problem!" Sometimes they claim that my test case,
purposely coded to exhibit the problem with mimimal code, performs
no useful function had it worked, so I shouldn't consider it a
problem.
>On Fri, Dec 18, 2009 at 8:43 PM, Paul Gilmartin wrote:
>> >>
>> >>NF? This really should be PER, though IBM might make a case for
>> >>PER/FIN given the behavior change they suggest in the PMR.
>>
>> exec cp -B
>> -PRECFM=FB,LRECL=80,BLKSIZE=0,SPACE=(10000,(10000,1)) supr610.ptf
>> //SMI.supr610.ptf
>>
>> And the program failed with ABEND SB37 with only 2 blocks in
>> the primary extent.
-- gil
Don Imbriale
suggestion may help until the fix is in.
--
--
Don Imbriale
temporarily retired
On Sat, Dec 19, 2009 at 10:50 AM, Paul Gilmartin <PaulGB...@aim.com>wrote:
> On Sat, 19 Dec 2009 09:14:05 -0500, Don Imbriale wrote:
>
> >In the SPACE parameter, reverse the primary and secondary quantities.
> >
> Irrelevant. Please don't claim that the existence of even an obvious
> alternative refutes the observation of the original problem. It
> might demote it from a SEV2 to a SEV3 (I reported it initially as
> SEV3), but it should be PER, regardless.
>
> IBM does this far too often: I report a problem; they recode my
> test case to one that does not exhibit the problem, then say,
> "Oh, no problem!" Sometimes they claim that my test case,
> purposely coded to exhibit the problem with mimimal code, performs
> no useful function had it worked, so I shouldn't consider it a
> problem.
>
> >On Fri, Dec 18, 2009 at 8:43 PM, Paul Gilmartin wrote:
> >> >>
> >> >>NF? This really should be PER, though IBM might make a case for
> >> >>PER/FIN given the behavior change they suggest in the PMR.
> >>
> >> exec cp -B
> >> -PRECFM=FB,LRECL=80,BLKSIZE=0,SPACE=(10000,(10000,1)) supr610.ptf
> >> //SMI.supr610.ptf
> >>
> >> And the program failed with ABEND SB37 with only 2 blocks in
> >> the primary extent.
>
>
>
----------------------------------------------------------------------
Paul Gilmartin
>I agree that the RLSE is unneeded and should be corrected. But my
>suggestion may help until the fix is in.
>
I suppose you were trying to be helpful. Thanks for that.
But I get weary of being told, when I report that "X" doesn't work,
that if I had done "Y" instead it would have worked. If "X" is
documented in the manuals it should simply work; the user shouldn't
be required to resort to a process of trial and error until he
stumbles upon "Y" that actually works.
And I'm dismayed that IBM deems my report that primary allocations
are released _before_ writing the data a request for "New Function",
not PER. But this gives them an excuse for not providing a
PROBLEM DESCRIPTION in the APAR.
-- gil
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, December 21, 2009 10:05 AM
To: IBM-...@bama.ua.edu
Subject: Re: PK64372 (was: SMS NONSMS difference)
<SNIPPAGE>
And I'm dismayed that IBM deems my report that primary allocations
are released _before_ writing the data a request for "New Function",
not PER. But this gives them an excuse for not providing a
PROBLEM DESCRIPTION in the APAR.
<SNIP>
If your PMR/ETR is still open, you might want to ask for a duty manager.
Some times it takes that kind of escalation to get people to understand
that something is broken.
Regards,
Steve Thompson