OS/390 release test periods Re: default variable initialization under os/390 v2r8 
Author Message
 OS/390 release test periods Re: default variable initialization under os/390 v2r8

Quote:

> Some applications here have encountered the same problem with
> unitialized automatic variables on some LE version upgrades.
> As I understand it, automatic storage is recycled under the covers by
> the run-time environment to avoid the overhead of getmain/freemain.
> Freshly getmained storage would have hex zeroes in it which would not
> generate data exceptions; recycled storage could have anything in it.
> You can use the STORAGE run-time option to force the storage to be
> re-initialized, but then you take a performance hit. The trouble is
> that, by not initializing these variables, the program becomes dependent
> on how the run-time manages this storage which is not part
> of the supported programming interface.

I'm not trying to make a case that the PL/I code shouldn't be corrected.

Part of my concern about lack of notice is that our ISP assured us that
their extensive testing for other clients on other OS/390s reduced the
chance of a {*filter*} surprise to near zero. We had a grand total of 8 hours
to test everything in this massive ROLL of software changes before they
committed it.

How common is it to roll in new versions of OS/390, LE, and other MVS
products without an extended period, minimum 1 week, of availability
for application testing in non-production migration levels? I'm not up
to trying to shoehorn a complete application verification test through
an 8 hour window several times a year.



Sun, 20 Apr 2003 07:03:57 GMT  
 OS/390 release test periods Re: default variable initialization under os/390 v2r8
It wasn't LE that was responsible.

8 hours of testing is clearly inadequate for anything but a toy operation
where stability is of no importance. You need to talk with your IT
management. They need to set up test systems (partitions), to give you
adequate testing time. They also need to be prepared to consider that they
may need to await fixes to bugs your encounter (APARs), especially with a
big OS/390 release.



Quote:

> > Some applications here have encountered the same problem with
> > unitialized automatic variables on some LE version upgrades.
> > As I understand it, automatic storage is recycled under the covers by
> > the run-time environment to avoid the overhead of getmain/freemain.
> > Freshly getmained storage would have hex zeroes in it which would not
> > generate data exceptions; recycled storage could have anything in it.
> > You can use the STORAGE run-time option to force the storage to be
> > re-initialized, but then you take a performance hit. The trouble is
> > that, by not initializing these variables, the program becomes dependent
> > on how the run-time manages this storage which is not part
> > of the supported programming interface.

> I'm not trying to make a case that the PL/I code shouldn't be corrected.

> Part of my concern about lack of notice is that our ISP assured us that
> their extensive testing for other clients on other OS/390s reduced the
> chance of a {*filter*} surprise to near zero. We had a grand total of 8 hours
> to test everything in this massive ROLL of software changes before they
> committed it.

> How common is it to roll in new versions of OS/390, LE, and other MVS
> products without an extended period, minimum 1 week, of availability
> for application testing in non-production migration levels? I'm not up
> to trying to shoehorn a complete application verification test through
> an 8 hour window several times a year.



Sun, 20 Apr 2003 14:57:45 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. default variable initialization under os/390 v2r8

2. PL/I style (was: default variable initialization under os/390 v2r8)

3. Cobol OS/390 to C OS/390 V2R6

4. IBM announces new release of z/OS (OS/390) compiler

5. CobAnal for MVS, OS/390 and z/OS New version

6. Python for IBM OS/400 OS/390

7. OS/390 Release 2 Year 2000 discussion

8. Cobol for OS/390 Heap storage and LE release

9. Initializing a Linkage Section variable (On OS/390)

10. any pointers to using COBOL for OS/390 TEST(,,SEPARATE)

11. Books on os/390

12. JNI and OS 390 C/C++

 

 
Powered by phpBB® Forum Software