Lizette Koehler wrote:
>Thanks. I removed the encoding section and it worked. I have been banging my
>head for 3 weeks on this issue.
Excellent! Thanks John McKown for your kind and amazing help to Lizette
Koehler! You're one in a thousand!
I am also interested in this, just in case I get a
FYI, here's a table that compares features of BPXBATCH, BPXBATSL, AOPBATCH
(and COZBATCH).
https://dovetail.com/products/cozbatch.html
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Sat, Jun 10, 2017 at 7:20 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
I was very surprised by Chris Poncelet's post, so I used Goggle to find this
doc:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab100/iea3b1_Module_reusability.htm
Blew me away. I knew the definition of RENT and REFR, but I believed that both
attributes were set
They are not technically the same.
A REFR program can be reloaded at any time. Therefore it cannot self modify as
it cannot know if it has been reloaded. But if it uses common/global areas
without serialization it is not reentrant.
A RENT program is one that can be executed concurrently by multip
A refreshable program cannot modify itself (or if it can, it would be a
very interesting and perhaps self-limiting testcase). A reentrant program
can, if written carefully, modify itself, although it is rarely a good
idea.
LPA modules are generally, in effect, refreshable.
As to "why", think ab
On Sun, 11 Jun 2017 08:07:47 -0500, Kirk Wolf wrote:
>FYI, here's a table that compares features of BPXBATCH, BPXBATSL, AOPBATCH
> (and COZBATCH).
>
>https://dovetail.com/products/cozbatch.html
>
Hmmm ... For BPXBATCH:
"PARM= args support quoting"
o For "PARM='SH ''string''', I see no restric
On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
>A refreshable program cannot modify itself (or if it can, it would be a
>very interesting and perhaps self-limiting testcase).
>
I believe that if a program is marked REFR but loaded from a
non-authorized library and REFRPROT is not in effe
RENT means only one copy of a module needs to be loaded for a job.
REFR means the module doesn't need to be paged out.
All else is implications and assumptions. Note that neither of the above
strictly require a non-modifiable module. The idea is that the results are
always the same regardless of
On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin wrote:
>In the Program Management UG and Ref, I see:
>RENT
>... A reenterable module is ordinarily expected not to modify
>its own code. In some cases, MVS protects the reentrant module's
>virtual storage so that it cannot be modified
[Default] On 11 Jun 2017 13:39:47 -0700, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:
>On Sun, 11 Jun 2017 14:13:17 -0400, Peter Relson wrote:
>
>>A refreshable program cannot modify itself (or if it can, it would be a
>>very interesting and perh
On 06/11/2017 05:33 PM, Walt Farrell wrote:
On Sun, 11 Jun 2017 15:40:49 -0500, Paul Gilmartin wrote:
In the Program Management UG and Ref, I see:
RENT
... A reenterable module is ordinarily expected not to modify
its own code. In some cases, MVS protects the reentrant module's
vir
Another question: Wasn't REFR for SVC type 3/4 modules so that they could be
refreshed in the transient area following preemption without fear that they may
have been modified prior to being preempted?
Sent from my iPhone
> On Jun 11, 2017, at 20:52, Steve Thompson wrote:
>
>> On 06/11/201
Another question: Wasn't REFR for SVC type 3/4 modules so that they could be
refreshed in the transient area following preemption without fear that they may
have been modified prior to being preempted?
Sent from my iPhone
> On Jun 11, 2017, at 20:52, Steve Thompson wrote:
>
> Question: Was
I got tired of guessing. I wrote a little program that saves registers into
itself via STM. I linked it with AC(1) and RENT. Did not specify either REUS or
REFR. The result according to StarTool is
-- ATTRIBUTES - APF
RENT REUS AC
As suggested in the KC doc, REUS is set automatic
In article <2376347398828975.wa.paulgboulderaim@listserv.ua.edu> you write:
> Point taken. But it's not clear why the designers chose to allow a program
> to be both modifyable and reloadable. This leads to dreadful
> unpredictability:
> Behavior may differ depending on whether the program
Hello,
Customer is currently using CPACF to encrypt his data before writing to
disks.
Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing to the disks,
Are there any compatibility issues ?
Are there any know documents which deals/explai
The attributes are to allow the system to take care of the infrastructure,
such as loading a new copy if a program is non-reentrant and serializing use
if the program is described as reusable.
But if you lie to zOS and assert that a non-reentrant program is reentrant,
zOS will not stop you from wa
On Mon, 12 Jun 2017 00:31:28 -0400 Randy Hudson wrote:
:>In article <2376347398828975.wa.paulgboulderaim@listserv.ua.edu> you
write:
:>
:>> Point taken. But it's not clear why the designers chose to allow a program
:>> to be both modifyable and reloadable. This leads to dreadful
unpredict
18 matches
Mail list logo
