Disable DYNALLOC?

[Paul Gilmartin]

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible,
what would be the collateral damage? What fraction of production
jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Roger W. Suhr , GMail]

My 5 cents: Why do people always have to control everything. DYNALLOC is a beautiful thing. It has to be used properly, for sure and it's not a "one size fits all" tool, but it is very useful.
If you really have to control all allocations, then look into using and exit (DADSM,SMS comes to mind).

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, December 20, 2017 17:38
To: IBM-***@LISTSERV.UA.EDU
Subject: Disable DYNALLOC?

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically, DYNALLOC except by initiator is so harmful as to be prohibited in production jobs, is there any way to do so? If it were possible, what would be the collateral damage? What fraction of production jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

I don't have a problem with people controlling things. I have a major problem with people controlling things that they don't understand, especially if someone else takes the heat when the balloon goes up.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Roger W. Suhr (GMail) <***@GMAIL.COM>
Sent: Wednesday, December 20, 2017 5:43 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Disable DYNALLOC?

My 5 cents: Why do people always have to control everything. DYNALLOC is a beautiful thing. It has to be used properly, for sure and it's not a "one size fits all" tool, but it is very useful.
If you really have to control all allocations, then look into using and exit (DADSM,SMS comes to mind).

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, December 20, 2017 17:38
To: IBM-***@LISTSERV.UA.EDU
Subject: Disable DYNALLOC?

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically, DYNALLOC except by initiator is so harmful as to be prohibited in production jobs, is there any way to do so? If it were possible, what would be the collateral damage? What fraction of production jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Farley, Peter x23353]

Horsefeathers. Agreed that it bypasses JES3 resource pre-allocation, but aside from that the rest of that rant is bunkum. Sophisticated schemes for dynamically reading and collecting into one place asynchronous and only sometimes presented client transmissions into nightly production batch runs is one important use that would be impossible or at least difficult to automate without dynamic allocation.

It's all in the tools you use to control it flexibly and reliably. SMOP.

No security risk that I can see, presuming proper operation control and approval procedures of course.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, December 20, 2017 5:38 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Disable DYNALLOC?

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically, DYNALLOC except by initiator is so harmful as to be prohibited in production jobs, is there any way to do so? If it were possible, what would be the collateral damage? What fraction of production jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[CM Poncelet]

SVC 99 (aka macro DYNALLOC) allows doing much more than dataset
(de)allocations via its TUP list parms.
 
So yes - it should always remain available for use in systems programs,
irrespective of its being hypothetically "harmful" in production jobs
(whatever they are).
 
My ha'penny.
 
Chris Poncelet (retired sysprog consultant)
 

Post by Paul Gilmartin
... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...
Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible,
what would be the collateral damage? What fraction of production
jobs would work, unmodified, without using DYNALLOC?
Are code reviews a better technique? Other (specify)?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Steve Beaver]

To disable DYNALLOC would be to cause MGMT to delete you job plain and simple

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of CM Poncelet
Sent: Wednesday, December 20, 2017 7:25 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Disable DYNALLOC?

SVC 99 (aka macro DYNALLOC) allows doing much more than dataset (de)allocations via its TUP list parms.

So yes - it should always remain available for use in systems programs, irrespective of its being hypothetically "harmful" in production jobs (whatever they are).

My ha'penny.

Chris Poncelet (retired sysprog consultant)

Post by Paul Gilmartin
... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...
Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible, what
would be the collateral damage? What fraction of production jobs
would work, unmodified, without using DYNALLOC?
Are code reviews a better technique? Other (specify)?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

It's not just DYNALLOC, it's *any* code that explicitly or implicitly
waits. Who wrote the transaction that issued the SVC 99? Why didn't he run
it in a subtask? Presumably he is also doing OPEN, which would be a problem
even without the DYNALLOC.

​Yeah, long ago we purchased a company. They had a rarely run transaction
which used a COBOL subroutine which did an OPEN / R​EAD / CLOSE on a
sequential DSN. For some reason, when we were doing the processing, we ran
the transaction a LOT. And exhausted the region; which resulted in a S80A
(iirc) abend which took the CICS down. I "cheated" and updated the CICS SRT
(System Recovery Table) to basically "do nothing" when an S80A happened.
The transaction would then fail until we scheduled a recycle of the CICS.
This "moved" the problem from a "CICS is broken" problem to "the
transaction is broken" so that applications would fix it.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Vernooij, Kees - KLM , ITOPT1]

Forgotten to do a FREEBUFF dcbaddr after CLOSE?

Grtn,
Kees.

Post by Roger W. Suhr , GMail
-----Original Message-----
Behalf Of John McKown
Sent: 21 December, 2017 18:02
Subject: Re: Disable DYNALLOC?

It's not just DYNALLOC, it's *any* code that explicitly or implicitly
waits. Who wrote the transaction that issued the SVC 99? Why didn't he

run

it in a subtask? Presumably he is also doing OPEN, which would be a

problem

even without the DYNALLOC.

​Yeah, long ago we purchased a company. They had a rarely run transaction
which used a COBOL subroutine which did an OPEN / R​EAD / CLOSE on a
sequential DSN. For some reason, when we were doing the processing, we ran
the transaction a LOT. And exhausted the region; which resulted in a S80A
(iirc) abend which took the CICS down. I "cheated" and updated the CICS SRT
(System Recovery Table) to basically "do nothing" when an S80A happened.
The transaction would then fail until we scheduled a recycle of the CICS.
This "moved" the problem from a "CICS is broken" problem to "the
transaction is broken" so that applications would fix it.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

--
I have a theory that it's impossible to prove anything, but I can't prove
it.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

On Fri, Dec 22, 2017 at 1:12 AM, Vernooij, Kees (ITOPT1) - KLM <

Post by Vernooij, Kees - KLM , ITOPT1
Forgotten to do a FREEBUFF dcbaddr after CLOSE?

​No way to do that in a VS COBOL II program.​ (long ago)

Post by Vernooij, Kees - KLM , ITOPT1
Grtn,
Kees.

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Steve Beaver]

The whole OS uses Dynalloc everywhere

Sent from my iPhone

Sorry for the autocorrect issues

Doesn't CICS itself primarily use dynamic allocation for most files?
________________________________
Sent: Wednesday, December 20, 2017 11:14 PM
Subject: Re: Disable DYNALLOC?

Post by Paul Gilmartin
... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...
Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible,
what would be the collateral damage? What fraction of production
jobs would work, unmodified, without using DYNALLOC?
Are code reviews a better technique? Other (specify)?
— gil

Gil,
I won’t go into the details as I am not sure I know all of them. We had a fairly large CICS system of at least 1400 users. One of the illustrious consultants got involved in a data center issue and decided to bypass the DC issue by attaching the OCR document reader from CICS and read the OCR documents directly. We had no real idea that this was going on. This was also during our trials and tribulation with the infamous (to us) enque problem. I get a call saying that CICS is having an issue and that I should investigate. I am sitting at the system console and the operators get a phone call to

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Russell Witt]

My 2-cents; can you imagine if you had to hard-code all user-catalog's into the CATALOG started task correctly. The chance of missing one, or defining a new user-catalog and not including it in the JCL for the started task would be horrible. And if you are using a modern security product (RACF, ACF2, Top Secret) what security risk unless you have a wide-open security system already in place? No, there is no "security risk" with dynamic allocation that doesn't exist for standard DD allocations and the advantages for system-level applications far out-weigh any JES3 resource management controls.

Russell (speaking for myself, not my employeer) Witt

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, December 20, 2017 4:38 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Disable DYNALLOC?

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically, DYNALLOC except by initiator is so harmful as to be prohibited in production jobs, is there any way to do so? If it were possible, what would be the collateral damage? What fraction of production jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Vernooij, Kees - KLM , ITOPT1]

Apart from the unreal idea to disable DYNALLOC fully, you have full control over the DYNALLOC functions via exit IEGDB401. We did and do beautiful things in it, like our own SMS-like volume pooling before we converted to SMS.

Grtn,
Kees.

Post by Roger W. Suhr , GMail
-----Original Message-----
Behalf Of Paul Gilmartin
Sent: 20 December, 2017 23:38
Subject: Disable DYNALLOC?
... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates
production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...
Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible,
what would be the collateral damage? What fraction of production
jobs would work, unmodified, without using DYNALLOC?
Are code reviews a better technique? Other (specify)?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Schuster]

IEFDB401 — Dynamic Allocation Input Validation
Routine Exit allows you to fail a request.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

Yes, you could disable DYNALLOC in production jobs, but it would be a CLM. A good rule of thumb is to not disable anything unless you thoroughly understand the need and consequences, you have a solid rollout plan and you have a solid fallback plan. But it's not my dog.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Wednesday, December 20, 2017 5:38 PM
To: IBM-***@listserv.ua.edu
Subject: Disable DYNALLOC?

From a recent thread (rant?) in ASSEMBLER-LIST:

... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...

Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible,
what would be the collateral damage? What fraction of production
jobs would work, unmodified, without using DYNALLOC?

Are code reviews a better technique? Other (specify)?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

Post by Seymour J Metz
Yes, you could disable DYNALLOC in production jobs, but it would be a CLM.
A good rule of thumb is to not disable anything unless you thoroughly
understand the need and consequences, you have a solid rollout plan and you
have a solid fallback plan. But it's not my dog.

​Around here using the DYNALLOC in, say, COBOL would be "frowned upon" is
because CA-11 (restart package) could not "clean up" any DSN created using
it. Also, CA-7 would not be able to "track" the DSN back to the creating or
using job stream. Our production person uses the CA-7 data set "tracking"
to answer questions about "which job uses DSN ...?".​ It's amazing to me
that the system designers (programmers) actually ask the production people
"what does job ... do?". Mainly because their management, historically, has
never required any kind of system documentation from them.
--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Jesse 1 Robinson]

Maybe I'm just too darned skeptical. The claim of a historical relationship between DYNALLOC and MVS Unix is not merely anachronistic; it's patently absurd. I used a fully documented DYNALLOC as a new system programmer in the late 1970s. When a grand case for any proposition is marred by an obvious falsehood, I get suspicious about other elements of the argument that I may not be so familiar with. "Oh that part was wrong, but the rest was right" is a weasel move that induces me to change the channel.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Beaver
Sent: Thursday, December 21, 2017 6:14 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Disable DYNALLOC?

To disable DYNALLOC would be to cause MGMT to delete you job plain and simple

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of CM Poncelet
Sent: Wednesday, December 20, 2017 7:25 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Disable DYNALLOC?

SVC 99 (aka macro DYNALLOC) allows doing much more than dataset (de)allocations via its TUP list parms.

So yes - it should always remain available for use in systems programs, irrespective of its being hypothetically "harmful" in production jobs (whatever they are).

My ha'penny.

Chris Poncelet (retired sysprog consultant)

Post by Paul Gilmartin
... Do you stand by "SVC 99 for good measure"? Generally, products
do not implement it for good reason. Irrelevant in CICS and IMS.
In batch, it bypasses job scheduler, job restart, violates production
control requirements, bypasses JES3 resource management
and potentially poses a production security risk. TSO has the
alloc command which can easily be used in clists. It exists
because of MVS UNIX. ...
Disregard the anachronism in the last sentence. If, hypothetically,
DYNALLOC except by initiator is so harmful as to be prohibited in
production jobs, is there any way to do so? If it were possible, what
would be the collateral damage? What fraction of production jobs
would work, unmodified, without using DYNALLOC?
Are code reviews a better technique? Other (specify)?
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN