Re: Allocation problem with LMCOPY

[Jon Perryman]

I realized it was a REXX exec. Using a clist variable was a subtle way of 
asking the poster to post a legitimate example without making it a big deal. I 
personally think it's better to talk to people rather than down to them. 
Gilmartins method of commenting makes those who feel they are less experienced 
avoid posting for fear of making a mistake.

Thanks Shmuel doubt that I would make such a mistake.

Jon Perryman..  



>
> From: Shmuel Metz (Seymour J.) 
>
>
>
>In <5161261496916553.wa.paulgboulderaim@listserv.ua.edu>, on
>10/25/2013
>   at 05:05 PM, Paul Gilmartin  said:
>
>>On Fri, 25 Oct 2013 18:04:20 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>> on 10/23/2013 at 11:44 AM, Paul Gilmartin  said:
>>>
What's this ampersand business?
>>>
>>>"Assuming this is clist"
>>>
>>I considered that possibility but deemed the presence of the
>>"address" instruction a refutation.
>
>While Jon Perryman quoted Dave Hansen's message, he didn't himself use
>an address statement.
>

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

Re: Allocation problem with LMCOPY

[Shmuel Metz (Seymour J.)]

In <5161261496916553.wa.paulgboulderaim@listserv.ua.edu>, on
10/25/2013
   at 05:05 PM, Paul Gilmartin  said:

>On Fri, 25 Oct 2013 18:04:20 -0500, Shmuel Metz (Seymour J.) wrote:

>> on 10/23/2013 at 11:44 AM, Paul Gilmartin  said:
>>
>>>What's this ampersand business?
>>
>>"Assuming this is clist"
>>
>I considered that possibility but deemed the presence of the
>"address" instruction a refutation.

While Jon Perryman quoted Dave Hansen's message, he didn't himself use
an address statement.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Allocation problem with LMCOPY

[Paul Gilmartin]

On Fri, 25 Oct 2013 18:04:20 -0500, Shmuel Metz (Seymour J.) wrote:

> on 10/23/2013 at 11:44 AM, Paul Gilmartin  said:
>
>>What's this ampersand business?
>
>"Assuming this is clist"
>
I considered that possibility but deemed the presence of the "address"
instruction a refutation.

-- gil

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

Re: Allocation problem with LMCOPY

[Shmuel Metz (Seymour J.)]

In <9159676159882753.wa.paulgboulderaim@listserv.ua.edu>, on
10/23/2013
   at 11:44 AM, Paul Gilmartin  said:

>What's this ampersand business?

"Assuming this is clist"

>correct apostrophes

Assuming that it is REXX.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Allocation problem with LMCOPY

[Robert A. Rosenberg]

At 14:24 -0500 on 10/24/2013, Paul Gilmartin wrote about Re: 
Allocation problem with LMCOPY:



On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote:


This will also fix the INIT issue that if a JOB Step has a DISP=OLD
with further steps as DISP=SHR, the dataset remains exclusively held
until the last DISP=SHR step ends (since INIT can not downgrade the
EXC ENQ to the SHR ENQ used by DISP=SHR to allow other jobs access to
the dataset).


This has been announced as a long-awaited feature of z/OS 2.1.
I don't know how it plays with DYNALLOC.

-- gil

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


If the INIT can release the DISP=OLD (ie: EXC) ENQ at the end of the 
last step where there a need for the DISP=OLD while allowing 
subsequent steps where the dataset is declared as DISP=SHR to have a 
SHR ENQ, then this TO ME implies that ENQ support has been fixed to 
allow an EXC ENQ to be converted to a SHR ENQ and allow the ENQ chain 
to then allow subsequent ENQs in the chain to be satisfied so until 
the next EXC in the chain is encountered or the chain end is reached 
(IOW: If the first ENQ on the chain after the EXC being converted to 
SHR is a SHR, then it and all the following waiting SHR ENQs will be 
satisfied just like what occurs if the EXC ENQ is released via a DEQ).


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

Re: Allocation problem with LMCOPY

[Paul Gilmartin]

On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote:
>
>This will also fix the INIT issue that if a JOB Step has a DISP=OLD
>with further steps as DISP=SHR, the dataset remains exclusively held
>until the last DISP=SHR step ends (since INIT can not downgrade the
>EXC ENQ to the SHR ENQ used by DISP=SHR to allow other jobs access to
>the dataset).
> 
This has been announced as a long-awaited feature of z/OS 2.1.
I don't know how it plays with DYNALLOC.

-- gil

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

Re: Allocation problem with LMCOPY

[Robert A. Rosenberg]

At 11:59 -0500 on 10/24/2013, Paul Gilmartin wrote about Re: 
Allocation problem with LMCOPY:



Will 2.1 allow me to DYNALLOC a data set NEW, then immediately
downgrade the ENQ to SHR?  What command?  Assembler only?


I do not know but the lack of an ability to convert an EXC ENQ to a 
SHR one has been a bug/design flaw from day 1. You can convert a SHR 
ENQ to an EXC one (so long as you are the only SHR owner I assume) 
but not the other way. So far as I can tell the EXC->SHR conversion 
should be easy to do - all you need to do is alter the record to show 
the status as SHR and then drive the same routine as is used in DEQ 
(which will run the ENQ chain to unwait the entries until it hits an 
EXC or the end of the chain).


This will also fix the INIT issue that if a JOB Step has a DISP=OLD 
with further steps as DISP=SHR, the dataset remains exclusively held 
until the last DISP=SHR step ends (since INIT can not downgrade the 
EXC ENQ to the SHR ENQ used by DISP=SHR to allow other jobs access to 
the dataset).


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

Re: Allocation problem with LMCOPY

[Paul Gilmartin]

On Wed, 23 Oct 2013 21:47:34 -0700, Jon Perryman wrote:

>Sorry, I thought that the DD name was contained in the DATAID variable. It's 
>value was always in a format that ISPF uses for dynamic allocation. I always 
>assumed that it was the DD name.

When the dataset name is specified instead of DD name, then the dataset is 
allocated to the ISPn DD.
>
And I don't see that ISPF discloses that DDNAME to the programmer.  But
I guess the programmer isn't supposed to need it.

I don't know how I fell into the habit of LMINIT by DDNAME rather than by
DSNAME. Probably a mentor's code that I copied decades ago.

But what parameters are supported by ALLOCATE but not by LMINIT? 
I guess NEW, SPACE, RECFM, LRECL, ...  Others?  Having issued the
ALLOCATE it's simplest to LMINIT by DDNAME.  (I need to test whether
I can LMINIT a VIO data set.  Alas, not a DDNAME allocated to a UNIX
file.  That's *so* 20th Century!  It's a pain to copy a UNIX file to a
temporary data set merely so I can LMCOPY SHRW it to a library.
I suppose Kirk has a better idea.)

Hmmm.  Will 2.1 allow me to DYNALLOC a data set NEW, then immediately
downgrade the ENQ to SHR?  What command?  Assembler only?

Finally, I wonder why ISPF and SMP/E (perhaps others) generate DDNAMEs
with their component prefixes rather than allowing SVC 99 to generate
SYSn?  Perhaps more clarity reading dumps of the TIOT?

-- gil

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

Re: Allocation problem with LMCOPY

[Thomas Berg]

You are right , I was thinking of the case when you use the format
'LMINIT DATAID(LMID) DATASET('dsn') ENQ(SHR)'
Here it allocates a ISPn dd.



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, October 23, 2013 10:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation problem with LMCOPY
> 
> On 2013-10-23 10:55, Thomas Berg wrote:
> >> -Original Message-
> >> From: Paul Gilmartin
> >> Sent: Wednesday, October 23, 2013 6:45 PM
> >>
> >> On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:
> >>
> >>> 1. LMINIT allocates a new DD. The DDNAME is placed in the variable
> >>> you specified in DATAID.
> >
> > LMINIT do really create a new allocation with a ddname in the format
> ISPn, e g ISP12345.
> > Presumably it frees it a LMFREE.
> >
> Not by my experiment.  The EXEC:
> 
> /* Rexx */ signal on novalue;  /*
> */
> trace R
> 
> RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
> 'dsn('userid()'.TEMP.LMTEST' ,
> 'dsorg(PS) recfm(V,B) lrecl(137) msg(WTP)' )
> 
> address 'ISPEXEC'
> 'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
> say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )
> 
> if RC==0 then do
> call GetIt
> 'LMOPEN DATAID('LMID') OPTION(OUTPUT)'
> call PutIt
> end
> 
> 'LMFREE DATAID('LMID')'
> exit( RC )
> 
> GetIt:
> address 'TSO'
> RC = outtrap("line.","*","NOCONCAT")
> 'LISTALC STATUS SYSNAMES'
> return( RC )
> 
> PutIt:
> do I = 1 to line.0
> LL = line.I
> 'LMPUT DATAID('LMID') MODE(INVAR) DATALOC(LL)' ,
> 'DATALEN('length( line.I )')' 'NOBSCAN'
> trace N
> end I
> return( RC )
> /* * */
> 
> ... runs with output:
> 
>   5 *-* RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
> 'dsn('userid()'.TEMP.LMTEST' ,'dsorg(PS) recfm(V,B) lrec
>  l(137) msg(WTP)' )
> >>>   "0"
>   9 *-* address 'ISPEXEC'
>  10 *-* 'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
> >>>   "LMINIT DATAID(LMID) DDNAME(SYS00048) ENQ(SHR)"
>  11 *-* say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )
> >>>   "SYS00048 WORK02 ISR00023"
>  SYS00048 WORK02 ISR00023
> ...
> and when I VIEW the content of TEMP.LMTEST, the only DDNAME allocated to
> that data set is the SYS00048 allocated by BPXWDYN.
> 
> -- 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

Re: Allocation problem with LMCOPY

[Jon Perryman]

Sorry, I thought that the DD name was contained in the DATAID variable. It's 
value was always in a format that ISPF uses for dynamic allocation. I always 
assumed that it was the DD name.

When the dataset name is specified instead of DD name, then the dataset is 
allocated to the ISPn DD.

Jon Perryman.



>
> From: Paul Gilmartin 
>
>
>
>On 2013-10-23 10:55, Thomas Berg wrote:
>>> -Original Message-
>>> From: Paul Gilmartin
>>> Sent: Wednesday, October 23, 2013 6:45 PM
>>>
>>> On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:
>>>
 1. LMINIT allocates a new DD. The DDNAME is placed in the variable you
 specified in DATAID.
>> 
>> LMINIT do really create a new allocation with a ddname in the format 
>> ISPn, e g ISP12345. 
>> Presumably it frees it a LMFREE. 
>> 
>Not by my experiment.  The EXEC:
>
>
>

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

Re: Allocation problem with LMCOPY

[Paul Gilmartin]

On 2013-10-23 10:55, Thomas Berg wrote:
>> -Original Message-
>> From: Paul Gilmartin
>> Sent: Wednesday, October 23, 2013 6:45 PM
>>
>> On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:
>>
>>> 1. LMINIT allocates a new DD. The DDNAME is placed in the variable you
>>> specified in DATAID.
> 
> LMINIT do really create a new allocation with a ddname in the format 
> ISPn, e g ISP12345. 
> Presumably it frees it a LMFREE. 
> 
Not by my experiment.  The EXEC:

/* Rexx */ signal on novalue;  /*
*/
trace R

RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
'dsn('userid()'.TEMP.LMTEST' ,
'dsorg(PS) recfm(V,B) lrecl(137) msg(WTP)' )

address 'ISPEXEC'
'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )

if RC==0 then do
call GetIt
'LMOPEN DATAID('LMID') OPTION(OUTPUT)'
call PutIt
end

'LMFREE DATAID('LMID')'
exit( RC )

GetIt:
address 'TSO'
RC = outtrap("line.","*","NOCONCAT")
'LISTALC STATUS SYSNAMES'
return( RC )

PutIt:
do I = 1 to line.0
LL = line.I
'LMPUT DATAID('LMID') MODE(INVAR) DATALOC(LL)' ,
'DATALEN('length( line.I )')' 'NOBSCAN'
trace N
end I
return( RC )
/* * */

... runs with output:

  5 *-* RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
'dsn('userid()'.TEMP.LMTEST' ,'dsorg(PS) recfm(V,B) lrec
 l(137) msg(WTP)' )
>>>   "0"
  9 *-* address 'ISPEXEC'
 10 *-* 'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
>>>   "LMINIT DATAID(LMID) DDNAME(SYS00048) ENQ(SHR)"
 11 *-* say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )
>>>   "SYS00048 WORK02 ISR00023"
 SYS00048 WORK02 ISR00023
...
and when I VIEW the content of TEMP.LMTEST, the only DDNAME allocated
to that data set is the SYS00048 allocated by BPXWDYN.

-- gil

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

Re: Allocation problem with LMCOPY

[Hansen, Dave L - Eagan, MN]

Jon,  Thank you for the write up.  I used the DATASET and this works fine.

George, Paul and Tom, Thank you for also pointing out the ddnames.  Yes, I 
retyped the exec and see an incorrect "DNAME".
 

This is my new EXEC:

'LMINIT DATAID(INDD) DATASET('PMSBDH.LIB.DOC') ENQ(EXCLU)'
'LMINIT DATAID(OUTDD) DATASET('VPS.WORKSPC') ENQ(EXCLU)'

'LMCOPY FROMID('INDD') TODATAID('OUTDD')
   FROMMEM(VPSBYNET) TOMEM(VPSBYNET)
   REPLACE'

'LMCOPY FROMID('INDD') TODATAID('OUTDD')
   FROMMEM(VPSBYDST) TOMEM(VPSBYDST)
   REPLACE'

'LMCOPY FROMID('INDD') TODATAID('OUTDD')
   FROMMEM(XESPRTRS) TOMEM(XESPRTRS)
   REPLACE'

'LMFREE DATAID('INDD')'
'LMFREE DATAID('OUTDD')'


   Thanks again to all that helped,  Dave



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Berg
Sent: Wednesday, October 23, 2013 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Allocation problem with LMCOPY

BTW, I see that you wrote:

LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)

it should be:

LMINIT DATAID(INDD) DDNAME(LMIN) ENQ(SHRW)   (NOTE DDname, not Dname.)



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Thomas Berg
> Sent: Wednesday, October 23, 2013 5:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation problem with LMCOPY
> 
> Do:
> 
> Address TSO FREE FI(LMIN LMOUT)  (NOTE the ddnames...)
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> > -Original Message-----
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - 
> > Eagan, MN
> > Sent: Wednesday, October 23, 2013 5:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Allocation problem with LMCOPY
> >
> > CROSS POSTED to ISPF-L and IBM-MAIN
> >
> > Dear Helpers,
> >
> >LMFREE doesn't have any extra parameters.  I keep getting a 
> > message about "ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED 
> > TO ANOTHER JOB OR USER".  GRS shows I'm doing this to myself.  This 
> > is my LMCOPY
> > EXEC:
> >
> >ALLOC FI(LMIN)DA('file1') OLD REUSE
> >ALLOC FI(LMOUT) DA('file2') OLD REUSE
> >Address ISPEXEC
> >LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
> >LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
> >LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) 
> > REPLACE
> >LMFREE DATAID('INDD')
> >LMFREE DATAID('OUTDD')
> >
> >The LMFREE does not generate an error.  I get no errors running 
> > the EXEC and it does what I want.  Except it's doesn't free my dataset.
> >
> >I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error 
> > "FILE INDD NOT FREED, IS NOT ALLOCATED".
> >
> >
> > Q).  Do I need to OPEN and CLOSE to do an LMFREE correctly?
> >
> >
> >
> >   Thank you,  Dave
> >
> > 
> > -- 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: Allocation problem with LMCOPY

[Thomas Berg]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, October 23, 2013 6:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation problem with LMCOPY
> 
> On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:
> 
> >1. LMINIT allocates a new DD. The DDNAME is placed in the variable you
> >specified in DATAID.
> >
> I hadn't known this; I still don't believe it; rather LMINIT uses the
> DDNAME given and places a generated name in the variable specified in
> DATAID.

LMINIT do really create a new allocation with a ddname in the format ISPn, 
e g ISP12345. 
Presumably it frees it a LMFREE. 



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


 

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

Re: Allocation problem with LMCOPY

[Thomas Berg]

BTW, I see that you wrote:

LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)

it should be:

LMINIT DATAID(INDD) DDNAME(LMIN) ENQ(SHRW)   (NOTE DDname, not Dname.)



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas Berg
> Sent: Wednesday, October 23, 2013 5:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Allocation problem with LMCOPY
> 
> Do:
> 
> Address TSO FREE FI(LMIN LMOUT)  (NOTE the ddnames...)
> 
> 
> 
> Best Regards
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Hansen, Dave L - Eagan, MN
> > Sent: Wednesday, October 23, 2013 5:04 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Allocation problem with LMCOPY
> >
> > CROSS POSTED to ISPF-L and IBM-MAIN
> >
> > Dear Helpers,
> >
> >LMFREE doesn't have any extra parameters.  I keep getting a message
> > about "ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER
> > JOB OR USER".  GRS shows I'm doing this to myself.  This is my LMCOPY
> > EXEC:
> >
> >ALLOC FI(LMIN)DA('file1') OLD REUSE
> >ALLOC FI(LMOUT) DA('file2') OLD REUSE
> >Address ISPEXEC
> >LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
> >LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
> >LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema)
> > REPLACE
> >LMFREE DATAID('INDD')
> >LMFREE DATAID('OUTDD')
> >
> >The LMFREE does not generate an error.  I get no errors running the
> > EXEC and it does what I want.  Except it's doesn't free my dataset.
> >
> >I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error
> > "FILE INDD NOT FREED, IS NOT ALLOCATED".
> >
> >
> > Q).  Do I need to OPEN and CLOSE to do an LMFREE correctly?
> >
> >
> >
> >   Thank you,  Dave
> >
> > --
> > 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: Allocation problem with LMCOPY

[Paul Gilmartin]

On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:

>1. LMINIT allocates a new DD. The DDNAME is placed in the variable you 
>specified in DATAID.�
>
I hadn't known this; I still don't believe it; rather LMINIT uses the DDNAME
given and places a generated name in the variable specified in DATAID.

2. If a DD is allocated DISP=OLD, then this dataset cannot be allocated in 
another DD. This is why LMINIT fails. You can change the ALLOC to SHR and it 
will succeed.
>
I agree.

3. LMINIT allows dsn and DISP to be specified. The ALLOC's are not necessary 
�unless you have them for another reason. LMINIT DATAID(XXX) DATASET('xxx') 
ENQ(EXCLU). EXCLU is DISP=OLD.

4. LMCOPY and LMFREE must use a variable in the dataid. Assuming this is clist, 
you would code LMCOPY FROMID(&INDD) TOID(&OUTDD). LMINIT does NOT use a 
varialbe (it specifies a variable name where it will store the allocated DD).
>
What's this ampersand business?  I agree (once the correct apostrophes are
added) with the OP's:

'LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) REPLACE'

5. You should not use TSO FREE(&INDD &OUTDD). LMFREE should be used for this 
functionality because it will also clean up ISPF information about the 
allocated datasets.
>
If you use TSO ALLOCATE (as in the OP's example), you should use TSO FREE.

6. You could theoretically use the DDNAMES in the variables for TSO commands 
but I always use TSO ALLOC for TSO functionality. The advantage of LMINIT is 
the dynamic DD name generated avoids possible collisions.
>
BPXWDYN has a similar capability.  I'd have used that.

>
> From: "Hansen, Dave L - Eagan, MN"
>
>
>�  LMFREE doesn't have any extra parameters.� I keep getting a message about 
>"ALREADY IN USE,� TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER JOB OR 
>USER".� GRS shows I'm doing this to myself.� This is my LMCOPY EXEC:
>
>�  ALLOC FI(LMIN)� � DA('file1') OLD REUSE
>�  ALLOC FI(LMOUT) DA('file2') OLD REUSE
>�  Address ISPEXEC
>�  LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
>�  LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
>�  LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) REPLACE
>�  LMFREE DATAID('INDD')
>�  LMFREE DATAID('OUTDD')
>
>�  The LMFREE does not generate an error.� I get no errors running the EXEC 
>and it does what I want.� Except it's doesn't free my dataset.
>
>�  I added:� Address TSO FREE FI(INDD OUTDD).� It generated an error "FILE 
>INDD NOT FREED, IS NOT ALLOCATED".

-- gil

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

Re: Allocation problem with LMCOPY

[Jon Perryman]

1. LMINIT allocates a new DD. The DDNAME is placed in the variable you 
specified in DATAID. 

2. If a DD is allocated DISP=OLD, then this dataset cannot be allocated in 
another DD. This is why LMINIT fails. You can change the ALLOC to SHR and it 
will succeed.

3. LMINIT allows dsn and DISP to be specified. The ALLOC's are not necessary  
unless you have them for another reason. LMINIT DATAID(XXX) DATASET('xxx') 
ENQ(EXCLU). EXCLU is DISP=OLD.

4. LMCOPY and LMFREE must use a variable in the dataid. Assuming this is clist, 
you would code LMCOPY FROMID(&INDD) TOID(&OUTDD). LMINIT does NOT use a 
varialbe (it specifies a variable name where it will store the allocated DD).

5. You should not use TSO FREE(&INDD &OUTDD). LMFREE should be used for this 
functionality because it will also clean up ISPF information about the 
allocated datasets.

6. You could theoretically use the DDNAMES in the variables for TSO commands 
but I always use TSO ALLOC for TSO functionality. The advantage of LMINIT is 
the dynamic DD name generated avoids possible collisions.

Jon Perryman.



>
> From: "Hansen, Dave L - Eagan, MN" 
>
>
>   LMFREE doesn't have any extra parameters.  I keep getting a message about 
>"ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER JOB OR USER". 
> GRS shows I'm doing this to myself.  This is my LMCOPY EXEC:
>
>   ALLOC FI(LMIN)    DA('file1') OLD REUSE
>   ALLOC FI(LMOUT) DA('file2') OLD REUSE
>   Address ISPEXEC
>   LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
>   LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
>   LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) REPLACE
>   LMFREE DATAID('INDD')
>   LMFREE DATAID('OUTDD')
>
>   The LMFREE does not generate an error.  I get no errors running the EXEC 
>and it does what I want.  Except it's doesn't free my dataset.
>
>   I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error "FILE 
>INDD NOT FREED, IS NOT ALLOCATED".
>

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

Re: Allocation problem with LMCOPY

[Paul Gilmartin]

On Wed, 23 Oct 2013 17:23:09 +0200, Thomas Berg  wrote:
>
>Address TSO FREE FI(LMIN LMOUT)  (NOTE the ddnames...)
>
Yes, on careful reading, but, ugh!


>> -Original Message-
>> Behalf Of Hansen, Dave L - Eagan, MN
>> Sent: Wednesday, October 23, 2013 5:04 PM
>>   ...
>>LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
>>LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
>>
I think if I had been doing this I would have tried to reduce the
likelihood of confusion by using DDNAMEs containing the particle,
"DD" and DATAIDs containing the particle "LM", rather than
vice-versa.

-- gil

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

Re: Allocation problem with LMCOPY

[Thomas Berg]

Do:

Address TSO FREE FI(LMIN LMOUT)  (NOTE the ddnames...)



Best Regards
Thomas Berg
___
Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hansen, Dave L - Eagan, MN
> Sent: Wednesday, October 23, 2013 5:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Allocation problem with LMCOPY
> 
> CROSS POSTED to ISPF-L and IBM-MAIN
> 
> Dear Helpers,
> 
>LMFREE doesn't have any extra parameters.  I keep getting a message
> about "ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER
> JOB OR USER".  GRS shows I'm doing this to myself.  This is my LMCOPY
> EXEC:
> 
>ALLOC FI(LMIN)DA('file1') OLD REUSE
>ALLOC FI(LMOUT) DA('file2') OLD REUSE
>Address ISPEXEC
>LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
>LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
>LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema)
> REPLACE
>LMFREE DATAID('INDD')
>LMFREE DATAID('OUTDD')
> 
>The LMFREE does not generate an error.  I get no errors running the
> EXEC and it does what I want.  Except it's doesn't free my dataset.
> 
>I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error
> "FILE INDD NOT FREED, IS NOT ALLOCATED".
> 
> 
> Q).  Do I need to OPEN and CLOSE to do an LMFREE correctly?
> 
> 
> 
>   Thank you,  Dave
> 
> --
> 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: Allocation problem with LMCOPY

[Paul Gilmartin]

On 2013-10-23, at 09:04, Hansen, Dave L - Eagan, MN wrote:

> CROSS POSTED to ISPF-L and IBM-MAIN
> 
>   LMFREE doesn't have any extra parameters.  I keep getting a message about 
> "ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER JOB OR 
> USER".  GRS shows I'm doing this to myself.  This is my LMCOPY EXEC:
> 
>   ALLOC FI(LMIN)DA('file1') OLD REUSE
>   ALLOC FI(LMOUT) DA('file2') OLD REUSE
>   Address ISPEXEC
>   LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
>   LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
>   LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) REPLACE
>   LMFREE DATAID('INDD')
>   LMFREE DATAID('OUTDD')
> 
>   The LMFREE does not generate an error.  I get no errors running the EXEC 
> and it does what I want.  Except it's doesn't free my dataset.
> 
>   I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error "FILE 
> INDD NOT FREED, IS NOT ALLOCATED".
> 
> Q).  Do I need to OPEN and CLOSE to do an LMFREE correctly?
>  
o I believe that ISPF LM services are designed to do their own
  ENQueues; it is sufficient to ALLOCATE SHR.

o To undo the ALLOCATE, you need do ADDRESS TSO FREE ... after each
  LMFREE.

-- gil

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

Allocation problem with LMCOPY

[Hansen, Dave L - Eagan, MN]

CROSS POSTED to ISPF-L and IBM-MAIN

Dear Helpers,

   LMFREE doesn't have any extra parameters.  I keep getting a message about 
"ALREADY IN USE,  TRY LATER+", "DATA SET IS ALLOCATED TO ANOTHER JOB OR USER".  
GRS shows I'm doing this to myself.  This is my LMCOPY EXEC:

   ALLOC FI(LMIN)DA('file1') OLD REUSE
   ALLOC FI(LMOUT) DA('file2') OLD REUSE
   Address ISPEXEC
   LMINIT DATAID(INDD) DNAME(LMIN) ENQ(SHRW)
   LMINT DATAID(OUTDD) DDNAME(LMOUT) ENQ(SHRW)
   LMCOPY FROMID('INDD') TODATAID('OUTDD') FROMMEM(mema) TOMEM(mema) REPLACE
   LMFREE DATAID('INDD')
   LMFREE DATAID('OUTDD')

   The LMFREE does not generate an error.  I get no errors running the EXEC and 
it does what I want.  Except it's doesn't free my dataset.

   I added:  Address TSO FREE FI(INDD OUTDD).  It generated an error "FILE INDD 
NOT FREED, IS NOT ALLOCATED".


Q).  Do I need to OPEN and CLOSE to do an LMFREE correctly?



  Thank you,  Dave

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