And when somebody would specify large buffers, then the compiler would
cause a large paging spike due to initializing a couple of
meg(?) of storage to x'00'.
With today's memory-rich environment, is this still an issue?
IHMO, it should never be necessary to initialize neither large
buffers
Have to chime in on this one:
The ONLY way to find all of the programs that make erroneous assumptions
about the initial contents of acquired storage is to test with the
IgvInitGetmain DIAG trap enabled. I repeat, it's the ONLY way!
I agree wholeheartedly. And I am not talking about bad code
On Thu, 5 Feb 2009 16:01:37 EST (IBM Mainframe Discussion List)
dasdbi...@aol.com wrote:
:In a message dated 2/5/2009 12:04:24 P.M. Central Standard Time,
:dennis.ro...@lmco.com writes:
:I had always been taught that
:the ONLY time storage is cleared is when RSM assigns a real page to a
On Thu, 5 Feb 2009 22:41:41 -0800 Edward Jaffe edja...@phoenixsoftware.com
wrote:
:Binyamin Dissen wrote:
: I wonder if VSM is smart enough to recognize that a paged out page is all
zero
: and to just mark it as not assigned yet so that a page fault will not
require
: a page in.
:I seriously
On Thu, Feb 5, 2009 at 4:54 PM, Tom Marchant m42tom-ibmm...@yahoo.comwrote:
..snip
To single out this one
class of error as inexcusable or bad programming is absurd.
That's my opinion.
..snip
It's absurd to RTFM before you code a macro? Any ISV product that has this
problem would make
On Thu, 5 Feb 2009 11:02:42 -0700, Roach, Dennis (N-GHG)
dennis.ro...@lmco.com wrote:
I never knew about the 4096 or 8192 rules. I had always been taught that
the ONLY time storage is cleared is when RSM assigns a real page to a
virtual page that is not already backed by one in aux storage.
I
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe
Guy Gardoit wrote:
For the life of me, I can't understand why this is such a surprise
or
problem. How many bad programmers were-there/are-there anyway?
Sorry, but one who breaks the rules, end
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of John McKown
On Fri, 6 Feb 2009 07:53:03 -0600, Chase, John wrote:
snip
This thread should also reinforce the notion, If you want it done
right, do it yourself. IOW, if you want GETMAINed storage to be
clean,
This performance issue is what was fixed in LE at some point. IBM did
have a well documented option that would make it work like it used to.
Dennis Roach
GHG Corporation
Lockheed Marten Mission Services
FDOC Contract
2100 Space Park Drive
LM-15-4BH
Houston, Texas 77058
Voice: (281) 336-5027
To single out this one class of error as inexcusable or bad programming is
absurd.
That's my opinion.
Of course, you're entitled to your opinion.
But, not initialising is the worst mistake a programmer can make!
The first thing I was taught, in the early 1970's, was always ensure your data
Vernooy, C.P. - SPLXM wrote:
What worries me is the fact that the fix sets default processing to
UseZosV1R9Rules(Yes).
You don't have to do anything to remain in the safe pre-1.10 mode, so
many customers will probably overlook this 1.10 enhancement.
The pre-1.10 mode is not safe--just a
On Fri, 6 Feb 2009 07:53:03 -0600, Chase, John jch...@ussco.com wrote:
snip
This thread should also reinforce the notion, If you want it done
right, do it yourself. IOW, if you want GETMAINed storage to be
clean, then clean it yourself, every time you GETMAIN.
-jc-
I generally agree.
This thread should also reinforce the notion, If you want it done right, do
it yourself. IOW, if you want GETMAINed storage to be clean, then clean
it yourself, every time you GETMAIN.
100% in agreement.
The first programme I wrote (1971 -- High School) was in FORTRAN, and we
learned about DO
I generally agree. However, IIRC, the PL/I compiler did this type of operation
long ago. And when somebody would specify large buffers, then the compiler
would cause a large paging spike due to initializing a couple of
meg(?) of storage to x'00'.
With today's memory-rich environment, is this
FWIW...the z/OS R10 Migration book has been recently refreshed and is
available on the z/OS R10 bookshelves. The reason I mention this, is
because we added a migration action for OA27291. There's some good
information in there also, I daresay.
(Here's a link to the BOOK:
Assumptions about the state of uninitialized storage can bite the best
of us. Last year we ran into a problem with the Cobol code generated
by the SQL Coprocessor using Enterprise Cobol 3.3 under DB2 V8.
In the SQL---PLIST it was generating the following FILLER area:
02 SQL---STMT-NUMPIC
For the archives
http://www.ibm.com/support/docview.wss?uid=isg1OA27291
OA27291 is closed with some good information included in the APAR text.
Thanks, Sam Knutson
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and
Knutson, Sam wrote:
http://www.ibm.com/support/docview.wss?uid=isg1OA27291
OA27291 is closed with some good information included in the APAR text.
Hopefully, people understand that this APAR doesn't fix the failing
programs. They still make erroneous assumptions about the initial
I never knew about the 4096 or 8192 rules. I had always been taught that
the ONLY time storage is cleared is when RSM assigns a real page to a
virtual page that is not already backed by one in aux storage.
Otherwise, the page contains whatever residual is in real or aux
storage. I have never found
On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis (N-GHG) dennis.ro...@lmco.com
wrote:
...snip
Bottom line - *it is the programmers responsibility initialize storage as
needed.* Changes in LE have bit us in C++ and PL/I code in this area in
the past.
...snip
For the life of me, I can't
Guy,
While your analysis is correct, that does not help the user that goes to a new
release and suddenly has things blowing up. It is not always a case of a bad
programmer, it can just be a case of forgetting to init and it never caused a
problem in the past.
I agree with Ed that IBM should
How many of the programs that run in your installation were written by
you? We have 20+ year old programs running. How can we determine if the
programmer coded them correctly?
Jon L. Veilleux
veilleu...@aetna.com
(860) 636-2683
-Original Message-
From: IBM Mainframe Discussion
On Thu, 5 Feb 2009 13:39:32 -0500, Guy Gardoit ggard...@gmail.com wrote:
For the life of me, I can't understand why this is such a surprise or
problem. How many bad programmers were-there/are-there anyway?
Sorry, but one who breaks the rules, end ups broken.
Guy Gardoit
z/OS Systems
For the life of me, I can't understand why this is such a surprise or problem.
I agree!
In 1976, I was taught, whether getmain, malloc, or whatever the memory
allocation method was, to always initialise, unless the function specifically
stated it would do it.
That was my first year university
Just as a side note, I remember learning long ago to always initialize
static areas, for example:
use DC instead of DS wherever possible (same equivalents for
all languages).
It follows that the rule same rule would be wise for dynamic storage.
Seemed simple enough at the time.
I
How many of the programs that run in your installation were written by you?
Non sequitor!
We have 20+ year old programs running. How can we determine if the programmer
coded them correctly?
Probably more likely than today's code.
At the risk of sounding like an old f*rt, we were more careful
It is not always a case of a bad programmer, it can just be a case of
forgetting to init and it never caused a problem in the past.
Well slap me rosey!
I don't see the difference between bad programming, and forgetting to init!
-
Too busy driving to stop for gas!
We installed a new release of CA/TMS. Tape processing checked out,
regression testing was good, we went into production. Within a few days
we had a broken PL/I program and TMS had to be the problem because the
code has worked without change for years. We IPLd the old release and it
did work. Set a
Just as a side note, I remember learning long ago to always initialize static
areas
Again, basic.
Again, I agree.
And, I can't understand the defensive stants, of those who don't/won't believe
that basic programming is wrong!
Forgetting to init is inexcusable!
-
Too busy driving to stop for
I don't think that anyone is defending bad programming practices, but
not all of us have the luxury of knowing what every program running on
our production systems is doing. Some were written long ago, some by
vendors, and some by just bad programmers. As a systems person I have to
make sure that
On Thu, 5 Feb 2009 19:44:51 +, Ted MacNEIL
eamacn...@yahoo.ca wrote:
Just as a side note, I remember learning long ago to always
initialize static areas
Again, basic.
Again, I agree.
And, I can't understand the defensive stants, of those who
don't/won't believe that basic programming is
In a message dated 2/5/2009 12:04:24 P.M. Central Standard Time,
dennis.ro...@lmco.com writes:
I had always been taught that
the ONLY time storage is cleared is when RSM assigns a real page to a
virtual page that is not already backed by one in aux storage.
And how is a programmer
Guy Gardoit wrote:
For the life of me, I can't understand why this is such a surprise or
problem. How many bad programmers were-there/are-there anyway?
Sorry, but one who breaks the rules, end ups broken.
Even good programmers make mistakes. That's why we have testing. What's
needed are
Ted MacNEIL wrote:
I don't see the difference between bad programming, and forgetting to init!
Good programmers design thoughtful, elegant algorithms and well
organized programs. Bad programmers write poorly designed algorithms and
disorganized programs.
Both good and bad programmers
Roach, Dennis (N-GHG) wrote:
On the other hand, people make use of bugs in compilers. We still have
an old FORTRAN compiler because of code that relies on a bug with the
handling of common.
Anything interesting? The only thing I can recall that might
apply is the ability to initialize with a
On Thu, 5 Feb 2009 13:39:32 -0500, Guy Gardoit wrote:
On Thu, Feb 5, 2009 at 1:02 PM, Roach, Dennis wrote:
Bottom line - *it is the programmers responsibility initialize storage as
needed.* Changes in LE have bit us in C++ and PL/I code in this area in
the past.
Of course, along with many
On Thu, 5 Feb 2009 11:02:42 -0700 Roach, Dennis (N-GHG)
dennis.ro...@lmco.com wrote:
:I never knew about the 4096 or 8192 rules. I had always been taught that
:the ONLY time storage is cleared is when RSM assigns a real page to a
:virtual page that is not already backed by one in aux storage.
Binyamin Dissen wrote:
I wonder if VSM is smart enough to recognize that a paged out page is all zero
and to just mark it as not assigned yet so that a page fault will not require
a page in.
I seriously doubt VSM is the least bit aware of the contents of the
pages. Of course, the
Edward Jaffe edja...@phoenixsoftware.com wrote in message
news:498b1c64.1030...@phoenixsoftware.com...
Knutson, Sam wrote:
http://www.ibm.com/support/docview.wss?uid=isg1OA27291
OA27291 is closed with some good information included in the APAR
text.
Hopefully, people understand
Roland here you go: ZEBB PTF E320ATBA
Jon L. Veilleux
veilleu...@aetna.com
(860) 636-2683
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Roland Schiradin
Sent: Thursday, December 11, 2008 6:02 PM
To: IBM-MAIN@bama.ua.edu
Subject:
Ed Jaffe wrote
If this behavior isn't documented, then what difference does it make? A
program that depends on this behavior is no different than one that
depended on undocumented alignment properties from pre-z/OS 1.10 GETMAIN
behavior.
What you wrote is certainly true. But it was exactly this
Not only that, but CICS is developed--and I assume tested--in Hursley. I
suspect they, as well as Bvblingen, San Jose, Rochester, Perth, Raleigh,
Rome and other labs play from a different rule book than do the folks
in POK.
Not really different in this regard. The word about dirty getmain was
Peter Relson wrote:
Our standard position with respect to ISVs is that if they encounter an IBM
problem due to their use of dirty getmain, we will try to fix it. The CICS
situation that Jim Mulder mentioned is, I hope, more the exception than the
rule. Clearly if problems do not get fixed, then
In
4a25f3adc7d4cd4388704e36280459c308f9f...@mddp-exch-003.aeth.aetna.com,
on 12/09/2008
at 07:30 AM, Veilleux, Jon L veilleu...@aetna.com said:
Jim, as I stated in our problem record, the change to GETMAIN caused us
downtime which is unacceptable in a business environment.
IMHO, poor
In of6f28edcb.889430cf-on8525751c.004f270c-8525751c.0050f...@us.ibm.com,
on 12/11/2008
at 09:44 AM, Peter Relson rel...@us.ibm.com said:
Please note also that dirty getmain does not try to be omniscient. It is
a fact (but not a documented promise) that the first getmain done under a
job for a
Shmuel wrote:
IMHO, poor programming caused the outage, and your enterprise is far
more at risk from that than it is from changes to undocumented
interfaces. This scenario reminds me of the wailing and gnashing of
teeth when programs that were working fine[1] under OS/360 started
taking S0C4's
My main complaint was that the change was undocumented
I don't know whether the change is documented, but it was disclosed to vendors
at the TDM. IMO you shouldn't have spent any time trying to debug vendor code.
Bob Shannon
Rocket Software
The bad program caused an overlay in another vendor's code, so I had to
determine what caused the overlay. Once I determined who caused the
overlay it was up to the vendor to fix it, but it was not a trivial
task.
Jon L. Veilleux
veilleu...@aetna.com
(860) 636-2683
-Original
On Thu, 11 Dec 2008 15:14:52 -0500, Bob Shannon
bshan...@rocketsoftware.com wrote:
My main complaint was that the change was undocumented
I don't know whether the change is documented, but it was disclosed to
vendors at the TDM. IMO you shouldn't have spent any time trying to debug
vendor code.
Jon,
could you post the ISV/Software and the ptf?
The bad program caused an overlay in another vendor's code, so I had to
determine what caused the overlay. Once I determined who caused the
overlay it was up to the vendor to fix it, but it was not a trivial
task.
Ed Jaffe wrote
And, if IBM, ISV, and customer in-house developers would use
IgvInitGetmain and IgvInitFreemain on their test/development systems--as
we do--nobody would have experienced this issue to begin with. Of
course, it's hard to fault someone for not using an undocumented
feature. These
Peter Relson wrote:
Ed Jaffe wrote
And, if IBM, ISV, and customer in-house developers would use
IgvInitGetmain and IgvInitFreemain on their test/development systems--as
we do--nobody would have experienced this issue to begin with. Of
course, it's hard to fault someone for not using an
In a message dated 12/10/2008 10:36:19 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
testing organizations to use various TRAPs. The last time we exchanged
notes about what she was recommending, IgvInitGetmain was definitely
*not* on her list!
Haven't done development since S/1
On Tue, 9 Dec 2008 07:30:32 -0800, Edward Jaffe wrote:
And, if IBM, ISV, and customer in-house developers would use
IgvInitGetmain and IgvInitFreemain on their test/development systems--as
we do--nobody would have experienced this issue to begin with. Of
course, it's hard to fault someone for not
Edward Jaffe wrote:
I have suffered through damaged HSM control data sets and other
corrupted files, PSF abends, TCP/IP and VTAM issues, RMF problems, JES
problems, systems that won't IPL or crash shortly after IPL, and
dozens of subtle and bizarre behaviors that eventually led to a
discovery
Paul Gilmartin wrote:
What are we on this list allowed to know about what the IgvInit*
traps do?
WE on this list? YOU are an ISV. Thus, you should already know all about
what these, and dozens of other, TRAPs do. They should already be
enabled on the systems where you develop and test your
What are we on this list allowed to know about what the IgvInit*
traps do? Realistically, the most one could expect is that
at GETMAIN/FREEMAIN (or newer counterparts?) random, unpredictable
data would be written over the affected storage with the intent
of causing program checks.
Since
I realize this is an evolving space. And, it's always possible that
things have changed enough, since I last asked, that your blanket
statement IBM does use these traps is now accurate. But, knowing IBM
as I do, I have my doubts. Case in point: If IBM was religiously using
IgvInitGetmain
Jim Mulder wrote:
In particular, IPCS-related code tends to be adept at avoiding being
tested with the traps. Since such code does not require authorization,
and can be run on any supported release via STEPLIB/TSOLIB, it tends
to get done on what you might call a development system. But
Not only that, but CICS is developed--and I assume tested--in Hursley. I
suspect they, as well as Bvblingen, San Jose, Rochester, Perth, Raleigh,
Rome and other labs play from a different rule book than do the folks
in POK.
I don't know much about what goes on test-wise in Hursley. We
On Wed, 10 Dec 2008 13:49:19 -0500, Jim Mulder
[EMAIL PROTECTED] wrote:
...
...we consider those to be production systems,
and the systems programming and operations is contracted out to
IBM Global Services, and so we don't activate the traps on those
systems.
While not stated, I suspect IGS
Jim Mulder wrote:
There is one incorrect thing in the APAR text - VSM development
(and as designer and developer for this change, that includes me)
has *not* at this time decided to restore the pre-release
1.10 behavior as the default to prevent impact to the
unsuspecting program or user.
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/09/2008
10:30:32 AM:
Jim Mulder wrote:
The lesson here is that, if a change has been observed to cause
unexpected surprise wrong behaviors in some IBM components during
testing, then similar problems should be expected after
Jim, as I stated in our problem record, the change to GETMAIN caused us
downtime which is unacceptable in a business environment. Even though
the interface to GETMAIN didn't change and, if programmers correctly
initialized their workareas there wouldn't be a problem, the REALITY is
that not all
Hi,
OA2729 is a very interesting APAR and one that early adopters of z/OS 1.10
probably want to be aware of. DIAGxx option NUCLABEL ENABLE|DISABLE(IGVGPVTN)
provides an immediate option for relief.
Best Regards,
Sam Knutson, GEICO
System z
The fix to this APAR will restore the pre-release 1.10 behavior
as the default to prevent impact to the unsuspecting program
or user. A new DIAGxx trap will be documented by which
those environments which will benefit from the new means of
allocating storage for user private subpools can
66 matches
Mail list logo
