Re: zero-initialization of variables

[David W Noon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 25 Aug 2011 11:02:08 +0200 (CEST), Nomen Nescio wrote about Re:
zero-initialization of variables:

I have cross-posted this to comp.lang.asm370, where it is on-topic. I
have also set follow-ups to that newsgroup.

>That was a very interesting post. You responded to several people in
>one post though which is confusing.
>
>I may not be quoting you accurately but you say in response to Glen SVC
>forms of various macros don't load to previously GETMAINed areas. I'm
>not sure what you were getting at there. LOAD uses SVC entry and both
>the ADDR and ADRNAPF parameters load the module to storage previously
>GETMAINed by the caller.

Of those two, I only ever used the ADDR= option and that could only be
used in an APF authorized scenario: supervisor state and/or system
protect key. I don't recall the ADRNAPF= option for non-APF usage, so I
suspect it is fairly recent (i.e. < 15 or so years), but it could be
that I simply neglected it.

>I found your comments interesting and I'd like to set up a test of your
>assertion the linkage editor did not clear the load module and that
>this can be proven by linking multiple load modules. Do you have a
>scenario in mind? If so I'll try and run it on MVS 3.8J. You did not
>explain sufficiently why the first (only) load module is created
>properly with zeros in uninitialized areas and only 2nd thru nth load
>module has leftover data at least not that I could understand.

The linkage editor reused the work area without resetting it to
zeroes. You simply need to link 2 or more programs in a single run of
the linker, separated by NAME cards. Put the larger/largest one through
first. Note that you should not use code that contains large expanses
of binary zeroes. It is best to use COBOL, as that uses EBCDIC
characters all over the place.

>GETMAIN does not supply storage cleared to binary zeros except under
>specific limited circumstances but perhaps the linkage editor
>fulfilled those (full page or more of specific subpools, etc.) and the
>first time it used the storage it was indeed clean.

I actually wrote "VSM", not "GETMAIN". The distinction is important
here. It is VSM, more specifically RSM, that zeroes out a new page of
virtual storage backed in CSTOR. This occurs before GETMAIN returns
any of it to the calling program.

If GETMAIN can reuse an area of storage, it can return one filled with
junk. But that does not apply here, as the linkage editor requests
this memory during start-up, so the pages are new and freshly zeroed by
VSM/RSM.

>Sorry for not quoting your post directly but my newsreader barfed on
>your encoding when I tried to reply.

Claws-Mail always uses Base64 encoding for NNTP messages, regardless of
configuration options. It is a bug, but I can live with it.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply by e-mail.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk5WmzwACgkQ9MqaUJQw2MmZdgCfWotJrJTCt28WSqqQwV8Jmy4d
AT4An1bYr2nVOtY1Th1oPNs6pbMqPA6y
=ZwgE
-----END PGP SIGNATURE-----