Re: Link to the September 16 refresh of the z/OS 2.2 manuals?

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>>The URL for the z/OS 2.2 manuals is
>>https://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SK4t-4949
>>I guess I should have said that I think that this is a mistake on IBM's part, 
>>and not an intentional change.

>That was before all the ado about .7z vs .zip format.  I don't know that 
>they're fully refreshed.

You probably missed Susan Shumway's reply about this on 21 September 2016.

Groete / Greetings
Elardus Engelbrecht

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Joseph Reichman]

I think I need SYSLIN for a plain assembly 

> On Sep 26, 2016, at 8:37 PM, Charles Mills  wrote:
> 
> Check my NOOBJ in the manuals -- I said that from memory.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Monday, September 26, 2016 5:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
> 
> I guess I'll specify both of them
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Charles Mills]

Check my NOOBJ in the manuals -- I said that from memory.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Monday, September 26, 2016 5:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO

I guess I'll specify both of them

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Joseph Reichman]

I guess I'll specify both of them

> On Sep 26, 2016, at 8:21 PM, Charles Mills  wrote:
> 
> As I said once, NODECK obviates the need for SYSPUNCH, not SYSLIN. You need
> NOOBJ (?) to turn off SYSLIN.
> 
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Reichman
> Sent: Monday, September 26, 2016 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
> 
> Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
> it got the Asssembly list  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Joseph Reichman]

Thanks

Joe Reichman
8045 Newell St Apt 403
Silver Spring MD 20910
Home (240) 863-3965
Cell (917) 748 -9693

> On Sep 26, 2016, at 8:21 PM, Charles Mills  wrote:
> 
> As I said once, NODECK obviates the need for SYSPUNCH, not SYSLIN. You need
> NOOBJ (?) to turn off SYSLIN.
> 
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Reichman
> Sent: Monday, September 26, 2016 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
> 
> Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
> it got the Asssembly list  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Charles Mills]

As I said once, NODECK obviates the need for SYSPUNCH, not SYSLIN. You need
NOOBJ (?) to turn off SYSLIN.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joe Reichman
Sent: Monday, September 26, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO

Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
it got the Asssembly list  

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Paul Gilmartin]

On Mon, 26 Sep 2016 17:49:47 -0400, Joseph Reichman wrote:

>I copied the JCL from SYS1.PROCLIB ASMAC
>
>As that is a proc just to Assemble
>
>> On Sep 26, 2016, at 5:44 PM, Edward Gould  wrote:
>> 
>> I will ask a question that should have been asked first time around.
>> Is there a valid unit name of VIO?
>>  
Of course that's tne prerogative of the customers' administrators, and tne
motivation for defining VIO is dwindling as DASD improves.

There's no gurantee that IBM samples will work; much less that the site
administrator will test them.  I've had IBM samples fail for reasons as
simple as that the PROC failed to specify enough REGION to run the
assembler.

-- gil

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Joseph Reichman]

I copied the JCL from SYS1.PROCLIB ASMAC

As that is a proc just to Assemble

> On Sep 26, 2016, at 5:44 PM, Edward Gould  wrote:
> 
> I will ask a question that should have been asked first time around.
> Is there a valid unit name of VIO?
> 
> Ed
>> On Sep 26, 2016, at 3:55 PM, Joe Reichman  wrote:
>> 
>> Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
>> it got the Asssembly list  
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Edward Gould
>> Sent: Monday, September 26, 2016 4:44 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
>> 
>> What options did you pass to the assembler?
>> 
>> Ed
>> 
 On Sep 25, 2016, at 7:00 AM, Joseph Reichman 
>>> wrote:
>>> 
>>> Well
>>> 
>>> I was able to allocate the datasets run Or BASSM to the assembler
>>> 
>>> But I cann't find the sysprint dataset
>>> 
>>> I had disp=(new,catlg)
>>> 
>>> Thanks
>>> 
>>> I am going to change the name and see
>>> 
 On Sep 25, 2016, at 7:52 AM, J R  wrote:
 
 SA23-1371-05
 
 z/OS V2R2 MVS Authorized Assembler Services Guide
 
 Chapter 26. Requesting dynamic allocation functions
 
 Page 646.
 
 Sent from my iPhone
 
 On Sep 25, 2016, at 00:38, Paul Gilmartin
>> <000433f07816-dmarc-requ...@listserv.ua.edu> c-requ...@listserv.ua.edu>> wrote:
 
 On Sun, 25 Sep 2016 02:02:43 +, J R wrote:
 
 From the FM:
 
 Verb code 01 - Dsname allocation text units
 
 Dsname specification - Key = '0002'
 
 DALDSNAM specifies the name of the data set to be allocated. The data set
>> name can contain special characters, if the data set name is enclosed in
>> apostrophes. The system cannot catalog a data set name enclosed in
>> apostrophes; it will use a disposition of KEEP instead. The data set name
>> can contain system symbols. See the information on using system symbols in
>> z/OS MVS Initialization and Tuning Reference for more information.
 
 The maximum length of the data set name is 44 characters, excluding any
>> enclosing apostrophes and compressing any double apostrophes within the data
>> set name.
 
 Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
 
 0002   0001   0005   50 D3 D6 C1 C4
 
 Unless I'm badly missing the context (which FM?) this is an egregious 
 hodgepodge of Assembler syntax, JCL syntax, and DYNALLOC specification.
 By experiment several decades ago:
 
 o I could create data sets with outrageous names; internal blanks, 
 NUL characters ...  Administrators complained to me when they were 
 unable to scratch them with the utility they used.
 
 o I don't believe apostrophes, single or double, were necessary.
 I could have built the DALDSNAM TU with a sequence of AL1(nnn) 
 constants.
 
 o '&' means nothing to DYNALLOC.  The example simply refers to a data 
 set name beginning with the AL1(80) byte.  Temporary DSNs and 
 DISP=PASS are handled by JCL and the initiator.
 
 o I don't know whether DYNALLOC substitutes system symbols (it came 
 about after my experiments).  But I believe that's done (only?) by 
 JCL processing.
 
 o JCL, from an overabundance of caution, believes any data set name 
 surrounded by apostrophes is ineligible for catalog processing.
 (I need to try DSN='SYS1.MACLIB' to see whether it works.)
 
 o DISABLE(DSNCHECK) profoundly changes the rules.  I don't know which 
 services respect or enforce this.  I doubt that JCL will allow 
 catalog processing of data set names containing special characters or 
 even consecutive periods or qualifiers longer than 8 characters 
 despite DISABLE(DSNCHECK)'s being in effect.
 
 -- gil
 
 -
 - For IBM-MAIN subscribe / signoff / archive access instructions, 
 send email to 
 lists...@listserv.ua.edu with the 
 message: INFO IBM-MAIN
 
 -
 - For IBM-MAIN subscribe / signoff / archive access instructions, 
 send email to lists...@listserv.ua.edu with the message: INFO 
 IBM-MAIN
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions, send 
>>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / 

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Edward Gould]

I will ask a question that should have been asked first time around.
Is there a valid unit name of VIO?

Ed
> On Sep 26, 2016, at 3:55 PM, Joe Reichman  wrote:
> 
> Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
> it got the Asssembly list  
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Edward Gould
> Sent: Monday, September 26, 2016 4:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO
> 
> What options did you pass to the assembler?
> 
> Ed
> 
>> On Sep 25, 2016, at 7:00 AM, Joseph Reichman 
> wrote:
>> 
>> Well
>> 
>> I was able to allocate the datasets run Or BASSM to the assembler
>> 
>> But I cann't find the sysprint dataset
>> 
>> I had disp=(new,catlg)
>> 
>> Thanks
>> 
>> I am going to change the name and see
>> 
>>> On Sep 25, 2016, at 7:52 AM, J R  wrote:
>>> 
>>> SA23-1371-05
>>> 
>>> z/OS V2R2 MVS Authorized Assembler Services Guide
>>> 
>>> Chapter 26. Requesting dynamic allocation functions
>>> 
>>> Page 646.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Sep 25, 2016, at 00:38, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu c-requ...@listserv.ua.edu>> wrote:
>>> 
>>> On Sun, 25 Sep 2016 02:02:43 +, J R wrote:
>>> 
>>> From the FM:
>>> 
>>> Verb code 01 - Dsname allocation text units
>>> 
>>> Dsname specification - Key = '0002'
>>> 
>>> DALDSNAM specifies the name of the data set to be allocated. The data set
> name can contain special characters, if the data set name is enclosed in
> apostrophes. The system cannot catalog a data set name enclosed in
> apostrophes; it will use a disposition of KEEP instead. The data set name
> can contain system symbols. See the information on using system symbols in
> z/OS MVS Initialization and Tuning Reference for more information.
>>> 
>>> The maximum length of the data set name is 44 characters, excluding any
> enclosing apostrophes and compressing any double apostrophes within the data
> set name.
>>> 
>>> Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
>>> 
>>>  0002   0001   0005   50 D3 D6 C1 C4
>>> 
>>> Unless I'm badly missing the context (which FM?) this is an egregious 
>>> hodgepodge of Assembler syntax, JCL syntax, and DYNALLOC specification.
>>> By experiment several decades ago:
>>> 
>>> o I could create data sets with outrageous names; internal blanks, 
>>> NUL characters ...  Administrators complained to me when they were 
>>> unable to scratch them with the utility they used.
>>> 
>>> o I don't believe apostrophes, single or double, were necessary.
>>> I could have built the DALDSNAM TU with a sequence of AL1(nnn) 
>>> constants.
>>> 
>>> o '&' means nothing to DYNALLOC.  The example simply refers to a data 
>>> set name beginning with the AL1(80) byte.  Temporary DSNs and 
>>> DISP=PASS are handled by JCL and the initiator.
>>> 
>>> o I don't know whether DYNALLOC substitutes system symbols (it came 
>>> about after my experiments).  But I believe that's done (only?) by 
>>> JCL processing.
>>> 
>>> o JCL, from an overabundance of caution, believes any data set name 
>>> surrounded by apostrophes is ineligible for catalog processing.
>>> (I need to try DSN='SYS1.MACLIB' to see whether it works.)
>>> 
>>> o DISABLE(DSNCHECK) profoundly changes the rules.  I don't know which 
>>> services respect or enforce this.  I doubt that JCL will allow 
>>> catalog processing of data set names containing special characters or 
>>> even consecutive periods or qualifiers longer than 8 characters 
>>> despite DISABLE(DSNCHECK)'s being in effect.
>>> 
>>> -- gil
>>> 
>>> -
>>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to 
>>> lists...@listserv.ua.edu with the 
>>> message: INFO IBM-MAIN
>>> 
>>> -
>>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to lists...@listserv.ua.edu with the message: INFO 
>>> IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send 
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lis

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Joe Reichman]

Just NODECK but it still looked for SYSLIN I allocated with VIO but dummied
it got the Asssembly list  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Edward Gould
Sent: Monday, September 26, 2016 4:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S99ERROR = 21C For &&OBJ UNIT=VIO

What options did you pass to the assembler?

Ed

> On Sep 25, 2016, at 7:00 AM, Joseph Reichman 
wrote:
> 
> Well
> 
> I was able to allocate the datasets run Or BASSM to the assembler
> 
> But I cann't find the sysprint dataset
> 
> I had disp=(new,catlg)
> 
> Thanks
> 
> I am going to change the name and see
> 
>> On Sep 25, 2016, at 7:52 AM, J R  wrote:
>> 
>> SA23-1371-05
>> 
>> z/OS V2R2 MVS Authorized Assembler Services Guide
>> 
>> Chapter 26. Requesting dynamic allocation functions
>> 
>> Page 646.
>> 
>> Sent from my iPhone
>> 
>> On Sep 25, 2016, at 00:38, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Sun, 25 Sep 2016 02:02:43 +, J R wrote:
>> 
>> From the FM:
>> 
>> Verb code 01 - Dsname allocation text units
>> 
>> Dsname specification - Key = '0002'
>> 
>> DALDSNAM specifies the name of the data set to be allocated. The data set
name can contain special characters, if the data set name is enclosed in
apostrophes. The system cannot catalog a data set name enclosed in
apostrophes; it will use a disposition of KEEP instead. The data set name
can contain system symbols. See the information on using system symbols in
z/OS MVS Initialization and Tuning Reference for more information.
>> 
>> The maximum length of the data set name is 44 characters, excluding any
enclosing apostrophes and compressing any double apostrophes within the data
set name.
>> 
>> Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
>> 
>>   0002   0001   0005   50 D3 D6 C1 C4
>> 
>> Unless I'm badly missing the context (which FM?) this is an egregious 
>> hodgepodge of Assembler syntax, JCL syntax, and DYNALLOC specification.
>> By experiment several decades ago:
>> 
>> o I could create data sets with outrageous names; internal blanks, 
>> NUL characters ...  Administrators complained to me when they were 
>> unable to scratch them with the utility they used.
>> 
>> o I don't believe apostrophes, single or double, were necessary.
>> I could have built the DALDSNAM TU with a sequence of AL1(nnn) 
>> constants.
>> 
>> o '&' means nothing to DYNALLOC.  The example simply refers to a data 
>> set name beginning with the AL1(80) byte.  Temporary DSNs and 
>> DISP=PASS are handled by JCL and the initiator.
>> 
>> o I don't know whether DYNALLOC substitutes system symbols (it came 
>> about after my experiments).  But I believe that's done (only?) by 
>> JCL processing.
>> 
>> o JCL, from an overabundance of caution, believes any data set name 
>> surrounded by apostrophes is ineligible for catalog processing.
>> (I need to try DSN='SYS1.MACLIB' to see whether it works.)
>> 
>> o DISABLE(DSNCHECK) profoundly changes the rules.  I don't know which 
>> services respect or enforce this.  I doubt that JCL will allow 
>> catalog processing of data set names containing special characters or 
>> even consecutive periods or qualifiers longer than 8 characters 
>> despite DISABLE(DSNCHECK)'s being in effect.
>> 
>> -- gil
>> 
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to 
>> lists...@listserv.ua.edu with the 
>> message: INFO IBM-MAIN
>> 
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: S99ERROR = 21C For &&OBJ UNIT=VIO

[Edward Gould]

What options did you pass to the assembler?

Ed

> On Sep 25, 2016, at 7:00 AM, Joseph Reichman  wrote:
> 
> Well 
> 
> I was able to allocate the datasets run 
> Or BASSM to the assembler 
> 
> But I cann't find the sysprint dataset
> 
> I had disp=(new,catlg)
> 
> Thanks 
> 
> I am going to change the name and see
> 
>> On Sep 25, 2016, at 7:52 AM, J R  wrote:
>> 
>> SA23-1371-05
>> 
>> z/OS V2R2 MVS Authorized Assembler Services Guide
>> 
>> Chapter 26. Requesting dynamic allocation functions
>> 
>> Page 646.
>> 
>> Sent from my iPhone
>> 
>> On Sep 25, 2016, at 00:38, Paul Gilmartin 
>> <000433f07816-dmarc-requ...@listserv.ua.edu>
>>  wrote:
>> 
>> On Sun, 25 Sep 2016 02:02:43 +, J R wrote:
>> 
>> From the FM:
>> 
>> Verb code 01 - Dsname allocation text units
>> 
>> Dsname specification - Key = '0002'
>> 
>> DALDSNAM specifies the name of the data set to be allocated. The data set 
>> name can contain special characters, if the data set name is enclosed in 
>> apostrophes. The system cannot catalog a data set name enclosed in 
>> apostrophes; it will use a disposition of KEEP instead. The data set name 
>> can contain system symbols. See the information on using system symbols in 
>> z/OS MVS Initialization and Tuning Reference for more information.
>> 
>> The maximum length of the data set name is 44 characters, excluding any 
>> enclosing apostrophes and compressing any double apostrophes within the data 
>> set name.
>> 
>> Example: To specify the temporary dsname &LOAD, code: KEY # LEN PARM
>> 
>>   0002   0001   0005   50 D3 D6 C1 C4
>> 
>> Unless I'm badly missing the context (which FM?) this is an egregious
>> hodgepodge of Assembler syntax, JCL syntax, and DYNALLOC specification.
>> By experiment several decades ago:
>> 
>> o I could create data sets with outrageous names; internal blanks,
>> NUL characters ...  Administrators complained to me when they
>> were unable to scratch them with the utility they used.
>> 
>> o I don't believe apostrophes, single or double, were necessary.
>> I could have built the DALDSNAM TU with a sequence of AL1(nnn)
>> constants.
>> 
>> o '&' means nothing to DYNALLOC.  The example simply refers to
>> a data set name beginning with the AL1(80) byte.  Temporary
>> DSNs and DISP=PASS are handled by JCL and the initiator.
>> 
>> o I don't know whether DYNALLOC substitutes system symbols (it
>> came about after my experiments).  But I believe that's done (only?)
>> by JCL processing.
>> 
>> o JCL, from an overabundance of caution, believes any data set name
>> surrounded by apostrophes is ineligible for catalog processing.
>> (I need to try DSN='SYS1.MACLIB' to see whether it works.)
>> 
>> o DISABLE(DSNCHECK) profoundly changes the rules.  I don't know
>> which services respect or enforce this.  I doubt that JCL will allow
>> catalog processing of data set names containing special characters
>> or even consecutive periods or qualifiers longer than 8 characters
>> despite DISABLE(DSNCHECK)'s being in effect.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with 
>> the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Link to the September 16 refresh of the z/OS 2.2 manuals?

[Paul Gilmartin]

On Mon, 26 Sep 2016 16:37:14 -0300, Horacio Villa wrote:

> I've searched IBM Publications Center with no success.
>Could someone tell me where is the refresh?
>
On Sat, 17 Sep 2016 21:41:49 -0500, John Laubenheimer wrote:

>The URL for the z/OS 2.2 manuals is
>https://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SK4t-4949
>
>I guess I should have said that I think that this is a mistake on IBM's part, 
>and not an intentional change.
>
That was before all the ado about .7z vs .zip format.  I don't know that they're
fully refreshed.

-- gil

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

Re: Link to the September 16 refresh of the z/OS 2.2 manuals?

[J R]

Is this what you're looking for?
https://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SK4t-4949

Sent from my iPhone

On Sep 26, 2016, at 15:38, Horacio Villa 
mailto:hvi...@ar.ibm.com>> wrote:

I've searched IBM Publications Center with no success.
Could someone tell me where is the refresh?
Thanks,
Horacio Villa











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

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

Link to the September 16 refresh of the z/OS 2.2 manuals?

[Horacio Villa]

 I've searched IBM Publications Center with no success.
Could someone tell me where is the refresh?
Thanks,
Horacio Villa











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

Re: Documentation for TSO DELETE MASK operand?

[Farley, Peter x23353]

<*Doh!*>

I removed the parentheses around the DSN with masking and it worked with the 
quoted and masked DSN.

Thanks for pointing to the documentation, I did find it there.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roach, Dennis
Sent: Monday, September 26, 2016 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Documentation for TSO DELETE MASK operand?

It is defined in the IDCMS manual (DFSMS Access Method Services Commands). 
I would say no quotes on a masked data set.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Monday, September 26, 2016 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Documentation for TSO DELETE MASK operand?

Check the IDCAMS manuals. This is actually a DFSMS command, not a native TSO 
command.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, September 26, 2016 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Documentation for TSO DELETE MASK operand?

z/OS 2.1 here.  In trying the following example DELETE with a MASK operand from 
a TSO READY prompt, I get the same error no matter whether I use asterisk or 
double-asterisk as the MASK value.

I have not found any documentation of the MASK keyword in the online TSO/E 
Commands Reference for either z/OS V2.1 or z/OS V2.2, but TSO HELP DELETE 
yields the description that follows the example below, indicating that MASK is 
a valid keyword.

Where can I RTFM about the MASK operand please?

Peter

Example DELETE with MASK operand and TSO HELP DELETE:

READY
  DELETE('TSOUSER.TEST.DATA.*')  PURGE MASK
IDC3239I INVALID DELETE MASK KEY - '('TSOUSER.TEST.DATA.*') IDC0014I LASTCC=12 
READY
  TSO HELP DELETE

Function -
  The DELETE command is used to delete either VSAM objects or NONVSAM
  data sets from a VSAM or ICF catalog and to free space occupied by
  the objects or data sets. Also the free space of VSAM data components
  can be overwritten with zeros. The DELETE command also deletes
  GDG bases and VSAM USERCATALOGS.

Syntax -
 DELETE('entryname/password' ...)
   CATALOG('catname/password')
   FILE('dname')
   PURGE | NOPURGE
   ERASE | NOERASE
   SCRATCH | NOSCRATCH
   FORCE | NOFORCE
   RECOVERY | NORECOVERY
   MASK | NOMASK
   CLUSTER | SPACE | USERCATALOG |
   ALIAS | GENERATIONDATAGROUP | PAGESPACE |
   NONVSAM | PATH | ALTERNATEINDEX | TRUENAME |
   NVR | VVR | VOLUMEENTRY | LIBRARYENTRY . . .
   MASK - The entryname is a MASK filter used to select a range
  of catalog entries to be deleted.

NOMASK   - the entryname is the name of a catalog entry to be
   deleted.
. . .

--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Documentation for TSO DELETE MASK operand?

[Roach, Dennis]

It is defined in the IDCMS manual (DFSMS Access Method Services Commands). 
I would say no quotes on a masked data set.

Dennis Roach, CISSP, PMP
AIG
IAM Access Administration - Consumer | Identity & Access Management

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-831-8799

dennis.ro...@aig.com | www.aig.com 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Monday, September 26, 2016 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Documentation for TSO DELETE MASK operand?

Check the IDCAMS manuals. This is actually a DFSMS command, not a native TSO 
command.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, September 26, 2016 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Documentation for TSO DELETE MASK operand?

z/OS 2.1 here.  In trying the following example DELETE with a MASK operand from 
a TSO READY prompt, I get the same error no matter whether I use asterisk or 
double-asterisk as the MASK value.

I have not found any documentation of the MASK keyword in the online TSO/E 
Commands Reference for either z/OS V2.1 or z/OS V2.2, but TSO HELP DELETE 
yields the description that follows the example below, indicating that MASK is 
a valid keyword.

Where can I RTFM about the MASK operand please?

Peter

Example DELETE with MASK operand and TSO HELP DELETE:

READY
  DELETE('TSOUSER.TEST.DATA.*')  PURGE MASK
IDC3239I INVALID DELETE MASK KEY - '('TSOUSER.TEST.DATA.*') IDC0014I LASTCC=12 
READY
  TSO HELP DELETE

Function -
  The DELETE command is used to delete either VSAM objects or NONVSAM
  data sets from a VSAM or ICF catalog and to free space occupied by
  the objects or data sets. Also the free space of VSAM data components
  can be overwritten with zeros. The DELETE command also deletes
  GDG bases and VSAM USERCATALOGS.

Syntax -
 DELETE('entryname/password' ...)
   CATALOG('catname/password')
   FILE('dname')
   PURGE | NOPURGE
   ERASE | NOERASE
   SCRATCH | NOSCRATCH
   FORCE | NOFORCE
   RECOVERY | NORECOVERY
   MASK | NOMASK
   CLUSTER | SPACE | USERCATALOG |
   ALIAS | GENERATIONDATAGROUP | PAGESPACE |
   NONVSAM | PATH | ALTERNATEINDEX | TRUENAME |
   NVR | VVR | VOLUMEENTRY | LIBRARYENTRY . . .
   MASK - The entryname is a MASK filter used to select a range
  of catalog entries to be deleted.

NOMASK   - the entryname is the name of a catalog entry to be
   deleted.
. . .

--


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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

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

Re: Documentation for TSO DELETE MASK operand?

[Pommier, Rex]

Check the IDCAMS manuals. This is actually a DFSMS command, not a native TSO 
command.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, September 26, 2016 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Documentation for TSO DELETE MASK operand?

z/OS 2.1 here.  In trying the following example DELETE with a MASK operand from 
a TSO READY prompt, I get the same error no matter whether I use asterisk or 
double-asterisk as the MASK value.

I have not found any documentation of the MASK keyword in the online TSO/E 
Commands Reference for either z/OS V2.1 or z/OS V2.2, but TSO HELP DELETE 
yields the description that follows the example below, indicating that MASK is 
a valid keyword.

Where can I RTFM about the MASK operand please?

Peter

Example DELETE with MASK operand and TSO HELP DELETE:

READY
  DELETE('TSOUSER.TEST.DATA.*')  PURGE MASK
IDC3239I INVALID DELETE MASK KEY - '('TSOUSER.TEST.DATA.*') IDC0014I LASTCC=12 
READY
  TSO HELP DELETE

Function -
  The DELETE command is used to delete either VSAM objects or NONVSAM
  data sets from a VSAM or ICF catalog and to free space occupied by
  the objects or data sets. Also the free space of VSAM data components
  can be overwritten with zeros. The DELETE command also deletes
  GDG bases and VSAM USERCATALOGS.

Syntax -
 DELETE('entryname/password' ...)
   CATALOG('catname/password')
   FILE('dname')
   PURGE | NOPURGE
   ERASE | NOERASE
   SCRATCH | NOSCRATCH
   FORCE | NOFORCE
   RECOVERY | NORECOVERY
   MASK | NOMASK
   CLUSTER | SPACE | USERCATALOG |
   ALIAS | GENERATIONDATAGROUP | PAGESPACE |
   NONVSAM | PATH | ALTERNATEINDEX | TRUENAME |
   NVR | VVR | VOLUMEENTRY | LIBRARYENTRY . . .
   MASK - The entryname is a MASK filter used to select a range
  of catalog entries to be deleted.

NOMASK   - the entryname is the name of a catalog entry to be
   deleted.
. . .

--


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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Documentation for TSO DELETE MASK operand?

[Farley, Peter x23353]

z/OS 2.1 here.  In trying the following example DELETE with a MASK operand from 
a TSO READY prompt, I get the same error no matter whether I use asterisk or 
double-asterisk as the MASK value.

I have not found any documentation of the MASK keyword in the online TSO/E 
Commands Reference for either z/OS V2.1 or z/OS V2.2, but TSO HELP DELETE 
yields the description that follows the example below, indicating that MASK is 
a valid keyword.

Where can I RTFM about the MASK operand please?

Peter

Example DELETE with MASK operand and TSO HELP DELETE:

READY
  DELETE('TSOUSER.TEST.DATA.*')  PURGE MASK
IDC3239I INVALID DELETE MASK KEY - '('TSOUSER.TEST.DATA.*')
IDC0014I LASTCC=12
READY
  TSO HELP DELETE

Function -
  The DELETE command is used to delete either VSAM objects or NONVSAM
  data sets from a VSAM or ICF catalog and to free space occupied by
  the objects or data sets. Also the free space of VSAM data components
  can be overwritten with zeros. The DELETE command also deletes
  GDG bases and VSAM USERCATALOGS.

Syntax -
 DELETE('entryname/password' ...)
   CATALOG('catname/password')
   FILE('dname')
   PURGE | NOPURGE
   ERASE | NOERASE
   SCRATCH | NOSCRATCH
   FORCE | NOFORCE
   RECOVERY | NORECOVERY
   MASK | NOMASK
   CLUSTER | SPACE | USERCATALOG |
   ALIAS | GENERATIONDATAGROUP | PAGESPACE |
   NONVSAM | PATH | ALTERNATEINDEX | TRUENAME |
   NVR | VVR | VOLUMEENTRY | LIBRARYENTRY
. . .
   MASK - The entryname is a MASK filter used to select a range
  of catalog entries to be deleted.

NOMASK   - the entryname is the name of a catalog entry to be
   deleted.
. . .

--


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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PSF/AFP use wit COBOL

[Howard Turetzky]

The AFPAPI was withdrawn in 2005, replaced by AFP Toolbox for Multiple 
Operating Systems (now down to one operating system...). 

  "The AFP API component of PSF/MVS V2.2 is no longer provided with PSF V4. It 
is functionally replaced by AFP Toolbox for MVS, program product 5655-A25. 
Customers using the PSF/MVS V2.2 API can continue to use their existing program 
modules on an "as-is" basis or migrate to AFP Toolbox for MVS."

The interface mappings are similar, but not identical. You can define fonts by 
attribute, attribute with scaling (outline fonts), and by name (AFPDFNTAT, 
AFPDFNTSC, AFPDFNTNM). The Toolbox does not support OpenType fonts, but then 
neither did the API.

Here are a few differences:
AFPQATT = AFPQUERY
AFPSICS = AFPMSTR
AFPSLIB is replaced by JCL (FNTLIBDD)
AFPSWSB = no equivalent
 AFPXFREE, AFPXGET, AFPXLOAD, AFPXSRVI, AFPXSRVN,  AFPXUNLD= no equivalent. The 
functions don't exist in the last version of the API books from 1996.

Howard Turetzky
Ricoh Production Print

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

Re: Reloading a member of ELPA

[Mark Jacobs - Listserv]

MLPA is rather obsolete and can only be created at IPL.

Mark Jacobs


Steve 
September 26, 2016 at 10:50 AM
Why not put it MLPA if its being called thousands of times a day?



Steve Beaver
st...@stevebeaver.com

Office : 806-368-3859
Cell : 806-300-9481



This electronic mail (including any attachments) may contain 
information that is privileged, confidential, and/or otherwise 
protected from disclosure to anyone other than its intended 
recipient(s). Any dissemination or use of this electronic email or its 
contents (including any attachments) by persons other than the 
intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so 
that we may correct our internal records. Please then delete the 
original message (including any attachments) in its entirety. Thank you



-Original Message-
From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, September 26, 2016 10:48am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reloading a member of ELPA




I agree with Mark's comments, and I would add that the old copy of the 
Natural nucleus must remain where it is unless you can be absolutely 
certain that there is no address space in the system that is using it.


You don't say how much space is taken by the Natural nucleus. That 
makes a difference as to whether or not you have available ECSA for it.


--
Tom Marchant

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

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Tom Marchant 
September 26, 2016 at 10:48 AM

I agree with Mark's comments, and I would add that the old copy of the 
Natural nucleus must remain where it is unless you can be absolutely 
certain that there is no address space in the system that is using it.


You don't say how much space is taken by the Natural nucleus. That 
makes a difference as to whether or not you have available ECSA for it.


--
Tom Marchant

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Re: Reloading a member of ELPA

[Steve]

Why not put it MLPA if its being called thousands of times a day?
 
 
 
Steve Beaver
st...@stevebeaver.com

Office : 806-368-3859
Cell : 806-300-9481



This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you


-Original Message-
From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Monday, September 26, 2016 10:48am
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reloading a member of ELPA



On Mon, 26 Sep 2016 10:44:43 +, Hilary Hurwitz wrote:

>Our shared Natural nucleus (SAG products site here) sits in ELPA .
>
>I need it to be reloaded due to some urgent fixes we applied, but my advisor 
>in System group tells me that is impossible, 
>apart from an IPL, since the reload will not release the space it previously 
>used.

I agree with Mark's comments, and I would add that the old copy of the Natural 
nucleus must remain where it is unless you can be absolutely certain that there 
is no address space in the system that is using it.

You don't say how much space is taken by the Natural nucleus. That makes a 
difference as to whether or not you have available ECSA for it.

-- 
Tom Marchant

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

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

Re: Reloading a member of ELPA

[Tom Marchant]

On Mon, 26 Sep 2016 10:44:43 +, Hilary Hurwitz wrote:

>Our shared Natural nucleus (SAG products site here) sits in  ELPA .
>
>I need it to be reloaded due to some urgent fixes we applied, but my advisor 
>in System group tells me that is impossible, 
>apart from an IPL, since the reload will not release the space it previously 
>used.

I agree with Mark's comments, and I would add that the old copy of the Natural 
nucleus must remain where it is unless you can be absolutely certain that there 
is no address space in the system that is using it.

You don't say how much space is taken by the Natural nucleus. That makes a 
difference as to whether or not you have available ECSA for it.

-- 
Tom Marchant

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

Re: Reloading a member of ELPA

[Mark Jacobs - Listserv]

True, it won't reuse the space in ELPA, but will use some space in ECSA 
for the new module. Unless you're very short on ECSA, it's not a concern 
to do so.


Mark Jacobs


Hilary Hurwitz 
September 26, 2016 at 6:44 AM
Our shared Natural nucleus (SAG products site here) sits in ELPA .

I need it to be reloaded due to some urgent fixes we applied, but my 
advisor in System group tells me that is impossible, apart from an 
IPL, since the reload will not release the space it previously used.

And we will overfill the Extended storage.

Is this your experience ?
If so - how do you overcome the problem ?
Our next scheduled IPL is in over a month.

Ideas welcome.

Hilary
(DBA - ADABAS/NATURAL)

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Reloading a member of ELPA

[Hilary Hurwitz]

Our shared Natural nucleus (SAG products site here) sits in  ELPA .

I need it to be reloaded due to some urgent fixes we applied, but my advisor in 
System group tells me that is impossible, apart from an IPL, since the reload 
will not release the space it previously used.
And we will overfill the Extended storage.

Is this your experience ?
If so - how do you overcome the problem ?
Our next scheduled IPL is in over a month.

Ideas welcome.

Hilary
(DBA - ADABAS/NATURAL)

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