Re: Possible to get DCB address after C fopen()

[David Crayford]

On 7/05/2015 1:34 AM, Charles Mills wrote:

Annoying that BPXWDYN cannot return a DD name. Have to do some serious thinking 
about the implications of a hard DD name.


I generate my own unique DDnames. It's as simple as keeping a static 
counter and incrementing it on each call to getNextNameToken(), which 
returns a string in the form CNNN. I use those tokens for all sorts 
of things that require unique standard MVS names.



Resigned to the possibility of having to use C dynalloc(). I remember it as 
being a PITA but the only other time I used it I was brand new to C and 
especially C on Z and so it may not be so bad as I recall
dynalloc() is not without it's flaws. I don't like the way it uses char 
* for parameter strings. You can easily get burned with dangling 
pointers. One of the problems with using fopen() magic allocation is 
that if it fails it's hard to debug. All you can do is check the __amrc 
structure and try to make sense of it. I've seen cases where a RACF 
violation was reported as a failure in CAMLST. Better to use dynalloc() 
IMO. If you setup dynalloc to use the S99RBX extension you can get back 
the IKJ* error messages if it fails. I've got a C++ dynalloc() wrapper 
that throws and exception with those messages. Contact me offlist if 
you're interested.


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

Re: Basic question on TSO commands and other executables

[Ed Gould]

Charles:
The TSO command to receive data (not the tso transmit/receive) is  
document in a small booklet (can't remember the number) but IIRC it  
was a 3 ring binder. This small booklet was a wealth of information  
and if you look hard enough there is "help" (s/b in sys1.help) but  
since it was never a supported program  (it was in the SMP4 era  
believe it or not) there was never an FMID (AFAIK) just a 3.5" floppy .


Ed
On May 6, 2015, at 7:50 PM, Charles Mills wrote:

just about everyone wrote a CALLCP command to do this, often with  
variations. I'll bet there are several on the CBT site.


Does anyone know of one? I can't find one looking at the one-line  
descriptions and it is kind of a PITA to download and RECV a file  
just to find out that it's not at all relevant. I thought File #  
325 TSO Command Processor Programs from Wells Fargo looked  
promising but it's not this.


Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On Behalf Of Tony Harminc

Sent: Tuesday, May 05, 2015 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Basic question on TSO commands and other executables

On 5 May 2015 at 18:47, Charles Mills  wrote:

Assume a program in userid.MY.LOAD named FOO. Assume TSOLIB ADD
DSN(MY.LOAD) which implies Ready prompt, not ISPF. Is the  
following correct?


- If I type FOO SOME OPERANDS then FOO will be entered "as a TSO  
command"

with R1 pointing to a 4-word CPPL. The doc is pretty clear on that.


Yes.


- OTOH if I enter CALL MY(FOO) 'SOME OPERANDS' then FOO will be
entered with normal z/OS linkage, e.g. R1 pointing to a word that
points to a halfword length and the character string 'SOME OPERANDS'
(without the quotes). Is that correct? The doc is not very clear  
to me.


Yes.

I'm surprised the doc isn't clear, but it's one of those "everyone  
knows that" sort of things, so I don't doubt you.


A corollary question: is there any way to execute FOO as a TSO  
command

but specify that I want the FOO in userid.MY.LOAD, not some other FOO
that might be ahead of it in the STEPLIB concatenation? Can I get the
explicit load library of CALL with the linkage of a command  
processor?

(Excluding solutions that involve writing programs to search the
libraries, de-concatenating, and so forth. I want to just execute FOO
from a specified load library without changing the whole  
environment.)


 READY
test my(foo) cp
 IKJ57090A ENTER COMMAND FOR CP
foo some operands
 TEST
run

 READY

Over the decades just about everyone wrote a CALLCP command to do  
this, often with variations. I'll bet there are several on the CBT  
site. But of course *that* command has to be in some sense  
installed, or of course you can run *it* under TEST...


--
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: Basic question on TSO commands and other executables

[Charles Mills]

> just about everyone wrote a CALLCP command to do this, often with variations. 
> I'll bet there are several on the CBT site.

Does anyone know of one? I can't find one looking at the one-line descriptions 
and it is kind of a PITA to download and RECV a file just to find out that it's 
not at all relevant. I thought File # 325 TSO Command Processor Programs from 
Wells Fargo looked promising but it's not this.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, May 05, 2015 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Basic question on TSO commands and other executables

On 5 May 2015 at 18:47, Charles Mills  wrote:
> Assume a program in userid.MY.LOAD named FOO. Assume TSOLIB ADD 
> DSN(MY.LOAD) which implies Ready prompt, not ISPF. Is the following correct?
>
> - If I type FOO SOME OPERANDS then FOO will be entered "as a TSO command"
> with R1 pointing to a 4-word CPPL. The doc is pretty clear on that.

Yes.

> - OTOH if I enter CALL MY(FOO) 'SOME OPERANDS' then FOO will be 
> entered with normal z/OS linkage, e.g. R1 pointing to a word that 
> points to a halfword length and the character string 'SOME OPERANDS' 
> (without the quotes). Is that correct? The doc is not very clear to me.

Yes.

I'm surprised the doc isn't clear, but it's one of those "everyone knows that" 
sort of things, so I don't doubt you.

> A corollary question: is there any way to execute FOO as a TSO command 
> but specify that I want the FOO in userid.MY.LOAD, not some other FOO 
> that might be ahead of it in the STEPLIB concatenation? Can I get the 
> explicit load library of CALL with the linkage of a command processor? 
> (Excluding solutions that involve writing programs to search the 
> libraries, de-concatenating, and so forth. I want to just execute FOO 
> from a specified load library without changing the whole environment.)

 READY
test my(foo) cp
 IKJ57090A ENTER COMMAND FOR CP
foo some operands
 TEST
run

 READY

Over the decades just about everyone wrote a CALLCP command to do this, often 
with variations. I'll bet there are several on the CBT site. But of course 
*that* command has to be in some sense installed, or of course you can run *it* 
under TEST...

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

Re: Primary allocation of a dataset

[Mike Schwab]

To consolidate a multi volume dataset to one (or fewer) volume(s)
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2250.htm?lang=en

//JOB4 JOB  accounting information,REGION=K
//STEP1EXEC PGM=ADRDSSU
//SYSPRINT DD   SYSOUT=A
//SYSINDD   *
 COPY DATASET( -
   INCLUDE(data.set.name))  /* FILTER ON DS W/1ST LEV Q USER1  */ -
   OUTDYNAM(volser)/* ALLOC VOL 338001 DYNAMICALLY*/ -
   DELETE CATALOG FORCE -
   TGTALLOC(SOURCE)
/*

A single volume dataset you can just do a dataset consolidate.
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/cnsex.htm?lang=en

//JOB1 JOB   accounting information,REGION=K
//STEP1EXEC  PGM=ADRDSSU
//SYSPRINT DDSYSOUT=A
//DASD DDUNIT=3390,VOL=(PRIVATE,SER=volser),DISP=OLD
//SYSINDD*

  CONSOLIDATE DATASET(INCLUDE(data.set.name) -
 EXCLUDE(data.set.name)) -
 PHYSINDDNAME(DASD)
/*

On Wed, May 6, 2015 at 5:21 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On 2015-05-06 16:18, Mike Schwab wrote:
>> I would be more worried about specifying enough space for the current
>> contents and calculating a nice secondary space value.  10% for a 16
>> extent type.  Maybe 1% for a 1## extent type.
>>
> Oh, be done with it!  HMIGRATE it; HRECALL it.  HSM coalesces everything
> into one neat extent and RLSEs everything else.  (But I wish there were a
> way to achieve this with half the I/Os.)
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Primary allocation of a dataset

[Webster, Chris]

As was suggested before the extension contains the allocation amount 'type'.  
DS1SCXTF contains the indicators for mega/kilo/bytes etc.  Old school (okay, 
the usual) allocation request types are in DS1SCAL1.

Is this what you are asking?

...chris.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, May 06, 2015 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

On 6 May 2015 at 16:54, Walt Farrell  wrote:
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As 
> far as I know (and as others have said) nothing will show you the 
> original _number_ of those units requested for the primary allocation, which 
> seems to be the OP's desire.

Sure - I get all that. But I don't know how ISPF displays 
cylinders/tracks/megabytes for various datasets. Is it just always displaying 
average blocks as megabytes? Maybe it's that simple; it's not something I've 
investigated - just noticed what seems like inconsistent output. Ah - maybe 
"megabytes" are only for PDSEs, even if they were allocated by tracks or 
cylinders. Well, no, I have a PDSE that shows current allocation in cylinders, 
so it's not that simple.

Tony H.

--
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: Basic question on TSO commands and other executables

[Charles Mills]

> you've checked all the pointers in the CPPL, i.e. the ECT really is the one 
> you received.

Well, I checked. To err is human. I think it's good. I don't touch the ECT 
itself; just copy the pointer CPPL to CPPL.

> When does it occur

Not certain at this point. Had started in another direction.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, May 06, 2015 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Basic question on TSO commands and other executables

On 6 May 2015 at 18:05, Charles Mills  wrote:
> Does anyone know the answer to my question at the end of the note 
> below? Is it possible to call from one TSO command to another just passing 
> the same CPPL with a new command buffer? Any
> known gotchas? I have this all coded and I am getting SYSTEM ABEND CODE 66D   
> REASON
> CODE 0002 which is documented as a bad pointer in the ECT. I am passing 
> my entry ECT.

It has worked for me in the past, but as I said, more and more of this 
interface is becoming undocumented.

This is an abend related to the input stack. When does it occur - when the new 
FOO command tries to read from the terminal? Merely LINKing or CALLing FOO 
would not abend; some TSO/E service routine must be being called. Or is it on 
return after you have called FOO? Or...?

I'm sure it goes without saying that you've checked all the pointers in the 
CPPL, i.e. the ECT really is the one you received.

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

Re: Primary allocation of a dataset

[Tony Harminc]

On 6 May 2015 at 16:54, Walt Farrell  wrote:
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as 
> I know (and as others
> have said) nothing will show you the original _number_ of those units 
> requested for the primary
> allocation, which seems to be the OP's desire.

Sure - I get all that. But I don't know how ISPF displays
cylinders/tracks/megabytes for various datasets. Is it just always
displaying average blocks as megabytes? Maybe it's that simple; it's
not something I've investigated - just noticed what seems like
inconsistent output. Ah - maybe "megabytes" are only for PDSEs, even
if they were allocated by tracks or cylinders. Well, no, I have a PDSE
that shows current allocation in cylinders, so it's not that simple.

Tony H.

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

Re: Basic question on TSO commands and other executables

[Tony Harminc]

On 6 May 2015 at 18:05, Charles Mills  wrote:
> Does anyone know the answer to my question at the end of the note below? Is 
> it possible to call
> from one TSO command to another just passing the same CPPL with a new command 
> buffer? Any
> known gotchas? I have this all coded and I am getting SYSTEM ABEND CODE 66D   
> REASON
> CODE 0002 which is documented as a bad pointer in the ECT. I am passing 
> my entry ECT.

It has worked for me in the past, but as I said, more and more of this
interface is becoming undocumented.

This is an abend related to the input stack. When does it occur - when
the new FOO command tries to read from the terminal? Merely LINKing or
CALLing FOO would not abend; some TSO/E service routine must be being
called. Or is it on return after you have called FOO? Or...?

I'm sure it goes without saying that you've checked all the pointers
in the CPPL, i.e. the ECT really is the one you received.

Tony H.

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

Re: Primary allocation of a dataset

[Paul Gilmartin]

On 2015-05-06 16:18, Mike Schwab wrote:
> I would be more worried about specifying enough space for the current
> contents and calculating a nice secondary space value.  10% for a 16
> extent type.  Maybe 1% for a 1## extent type.
> 
Oh, be done with it!  HMIGRATE it; HRECALL it.  HSM coalesces everything
into one neat extent and RLSEs everything else.  (But I wish there were a
way to achieve this with half the I/Os.)

-- gil

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

Re: Primary allocation of a dataset

[Mike Schwab]

I would be more worried about specifying enough space for the current
contents and calculating a nice secondary space value.  10% for a 16
extent type.  Maybe 1% for a 1## extent type.

On Wed, May 6, 2015 at 3:54 PM, Walt Farrell  wrote:
> On Wed, 6 May 2015 16:19:31 -0400, Tony Harminc  wrote:
>
>>On 6 May 2015 at 15:07, John Eells  wrote:
>>> I never actually checked, but I "assume" that ISPF and other things that
>>> show used space in allocation request units other than tracks or cylinders
>>> use the DS1DSPAC fields and track length to calculate space in those
>>> original request units.
>>
>>But how does it know what those original units were?
>
> DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as 
> I know (and as others have said) nothing will show you the original _number_ 
> of those units requested for the primary allocation, which seems to be the 
> OP's desire.
>
> Even ISPF does not claim to show you the _primary_ allocation. It shows, as 
> mentioned by the OP earlier, the value of the "1st extent". The primary 
> allocation is made up of a first extent and up to 4 other extents. ISPF just 
> shows the size of the first extent, which in many cases will be some value 
> less than or equal to the requested primary space. (But if adjacent extents 
> have been collapsed together it could, I suppose, be a value greater than the 
> requested primary space.)
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Basic question on TSO commands and other executables

[Charles Mills]

Does anyone know the answer to my question at the end of the note below? Is it 
possible to call from one TSO command to another just passing the same CPPL 
with a new command buffer? Any known gotchas? I have this all coded and I am 
getting SYSTEM ABEND CODE 66D   REASON CODE 0002 which is documented as a 
bad pointer in the ECT. I am passing my entry ECT.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, May 05, 2015 5:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Basic question on TSO commands and other executables

Thanks much.

> I'm surprised the doc isn't clear, but it's one of those "everyone knows 
> that" sort of things, so I don't doubt you.

Notice I said "not very clear to me" LOL. I've written a lot of programs in my 
career but never a TSO command or the like. What can I say?

OK, I "get" your TEST example. You bring foo into memory from a specified 
library telling TEST it's a CP and then run it. Thanks.

> Over the decades just about everyone wrote a CALLCP command to do this, often 
> with variations. I'll bet there are several on the CBT site.

Hmmm. I'm actually wishing to do this from within a command I will write. Is 
there any reason I cannot use normal MVS functions such as LOAD to find a 
particular FOO and then pass my own "constructed" CPPL:

CPPLCBUF: Pointer to a buffer in my program containing H'21',H'4',C'FOO SOME 
OPERANDS'
CPPLUPT: Copied from my entry CPPL.
CPPLPSCB: Copied from my entry CPPL.
CPPLECT: Copied from my entry CPPL.

Will that work (assuming no screw-ups) or is there some "magic" that TSO 
performs for a CP that will be missing if I do a LOAD and BASSM or BALR? I was 
thinking there was (some TSO magic necessary) but perhaps there is not?

Note: all unauthorized. No APF considerations here.

Thanks again,

Charles

--
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: Possible to get DCB address after C fopen()

[Charles Mills]

Thanks. Struggling with a different issue at the moment.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, May 06, 2015 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible to get DCB address after C fopen()

Hi Charles,

We use a routine that calls dynalloc() that allocates and returns a DUMMY 
DDNAME, and then use it in BPXWDYN with "reuse".  (See also JZOS:
 ZFIle.allocDummyDDName() )

Bill Schoen was discussing allowing for return of variables outside of REXX in 
a 2006 MVS-OE thread "use of bpxwdyn outside of rexx".
I suggest asking your question on MVS-OE.

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

Re: Primary allocation of a dataset

[Walt Farrell]

On Wed, 6 May 2015 16:19:31 -0400, Tony Harminc  wrote:

>On 6 May 2015 at 15:07, John Eells  wrote:
>> I never actually checked, but I "assume" that ISPF and other things that
>> show used space in allocation request units other than tracks or cylinders
>> use the DS1DSPAC fields and track length to calculate space in those
>> original request units.
>
>But how does it know what those original units were?

DS1DSPAC shows you the original _units_ (trk, cyl, average block). As far as I 
know (and as others have said) nothing will show you the original _number_ of 
those units requested for the primary allocation, which seems to be the OP's 
desire.

Even ISPF does not claim to show you the _primary_ allocation. It shows, as 
mentioned by the OP earlier, the value of the "1st extent". The primary 
allocation is made up of a first extent and up to 4 other extents. ISPF just 
shows the size of the first extent, which in many cases will be some value less 
than or equal to the requested primary space. (But if adjacent extents have 
been collapsed together it could, I suppose, be a value greater than the 
requested primary space.)

-- 
Walt

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

Re: Primary allocation of a dataset

[Fred van der Windt]

When you allocatie a dataset you specify space (blocks, tracks cylinders, MB or 
whatever) and a primary and secondary amount. The space and secondary amount is 
preserved in The DSCB1/8. The space was also used to allocate the primary 
extent(s). It is just the primary amount (as specified in the allocation 
command) that does not seem to be available anymore.

Fred!

Sent from my new iPad

> On May 6, 2015, at 22:19, Tony Harminc  wrote:
> 
>> On 6 May 2015 at 15:07, John Eells  wrote:
>> I never actually checked, but I "assume" that ISPF and other things that
>> show used space in allocation request units other than tracks or cylinders
>> use the DS1DSPAC fields and track length to calculate space in those
>> original request units.
> 
> But how does it know what those original units were?
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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

Re: Primary allocation of a dataset

[Tony Harminc]

On 6 May 2015 at 15:07, John Eells  wrote:
> I never actually checked, but I "assume" that ISPF and other things that
> show used space in allocation request units other than tracks or cylinders
> use the DS1DSPAC fields and track length to calculate space in those
> original request units.

But how does it know what those original units were?

Tony H.

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

Re: ICSF and EMV

[Sri h Kolusu]

May be this would help? 

APPENDIX 1.6.8 Visa and EMV-related smart card formats and processes 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CSFB4ZB0/APPENDIX1.6?

Kolusu
IBM Mainframe Discussion List  wrote on 
05/06/2015 11:46:31 AM:

> From: Frank Swarbrick <002782105f5c-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/06/2015 12:00 PM
> Subject: ICSF and EMV
> Sent by: IBM Mainframe Discussion List 
> 
> I am looking to know what ICSF services can be used (and how they 
> are to be used) to validate an EMV Application Cryptogram that is 
> part of a request from an ATM or POS device.  Where can I find 
> details on this?  I can't find anything in the ICSF manuals that 
> specifically talks about this.
> 
> Thanks,
> Frank
> 
> --
> 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: Primary allocation of a dataset

[John Eells]

fred.van.der.wi...@mail.ing.nl (Fred van der Windt) wrote:

I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?


As I think you found, the primary allocation is represented in the F1 or 
F8 DSCB by DS1EXT1 and following fields, and perhaps by "extension 
DSCBs" that contain additional extent descriptions, which if present 
should be pointed to by DS1PTRDS.


So far as allocation units go, what is in DSCBs is cylinder and head 
(track) information.  Eventually, it all boils down to the physical 
allocation units* the system supports for data sets, which are tracks, 
though you can choose to begin allocation on a cylinder boundary (which 
is indicated by DS1CYL) and allocate in numbers of cylinders, or use 
other units the system supports for the specification of disk space.  At 
allocation time, the system converts anything other than tracks to 
tracks, basically.  The type of specification is saved, but not used.


I never actually checked, but I "assume" that ISPF and other things that 
show used space in allocation request units other than tracks or 
cylinders use the DS1DSPAC fields and track length to calculate space in 
those original request units.  These are necessarily fuzzy numbers for 
some kinds of data sets in comparison to the actual numbers of blocks 
contained or the actual number of KB or MB actually written.  I think 
they're about as useful as they can be when allocating a new data set 
using the same number the tool displays yields the same size data set as 
the original (smile), and I believe this to be the case for ISPF a very 
high percentage of the time (if not 100% of the time).


How much of this is documented?  No idea...

* Not truly physical any more, post-3390, but rather emulated on modern 
disk; however, the logical architecture remains the same even though the 
physical layer varies underneath it.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Possible to get DCB address after C fopen()

[Kirk Wolf]

Hi Charles,

We use a routine that calls dynalloc() that allocates and returns a DUMMY
DDNAME, and then use it in BPXWDYN with "reuse".  (See also JZOS:
 ZFIle.allocDummyDDName() )

Bill Schoen was discussing allowing for return of variables outside of REXX
in a 2006 MVS-OE thread "use of bpxwdyn outside of rexx".
I suggest asking your question on MVS-OE.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 6, 2015 at 12:34 PM, Charles Mills  wrote:

> Thanks for your help. Yeah, I checked LE Vendor Interfaces before I
> posted. I have finally learned "when you can't find it where you think it
> ought to be, look in Vendor Interfaces."
>
> Yeah, pretty much resigned now to my own dynalloc and OPEN. Good
> suggestion on chasing the DEB chain, but that's not going to be any easier
> than doing it "right."
>
> Annoying that BPXWDYN cannot return a DD name. Have to do some serious
> thinking about the implications of a hard DD name. Resigned to the
> possibility of having to use C dynalloc(). I remember it as being a PITA
> but the only other time I used it I was brand new to C and especially C on
> Z and so it may not be so bad as I recall. (I have used assembler SVC 99
> extensively, back in the bad old days when I wrote everything in Assembler.)
>
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Harminc
> Sent: Wednesday, May 06, 2015 9:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Possible to get DCB address after C fopen()
>
> On 6 May 2015 at 09:50, Charles Mills  wrote:
> > I suspect I know the answer to this question. Is there any
> > generally-accepted way to get the DCB address following a C fopen()?
> > (I say "generally accepted" because I assume there is no supported
> > way. I could live with something with some risk, but not a total
> > hack.)
>
> The supported (in the sense that all fields and control blocks are PI or
> at least very well known for decades) is to chase the DEB chain.
> Each DEB points to an open DCB (or ACB) and each such xCB has a TIOT
> offset to the DDNAME entry. So if you know the DDNAME you can find any open
> DCBs for it without reference to any C or LE control blocks.
>
> But if it was dynalloc'd then you won't know the DDNAME, presumably.
> You can go a step further and do the same thing with DSNAMEs, though it's
> trickier. If you know the DSNAME, obviously.
>
> Otherwise I'd check the LE Vendor Interfaces book. Though the more I think
> about it, the more I think I/O in general is probably language dependant,
> and may not be handled by LE. And there is no C/C++ Vendor Interfaces book,
> afaik.
>
> --
> 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

ICSF and EMV

[Frank Swarbrick]

I am looking to know what ICSF services can be used (and how they are to be 
used) to validate an EMV Application Cryptogram that is part of a request from 
an ATM or POS device.  Where can I find details on this?  I can't find anything 
in the ICSF manuals that specifically talks about this.

Thanks,
Frank

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

Re: Did I really need a CLIST???

[Itschak Mugzach]

I would check the status of the TSO profile PROMPT variable. When prompt is
ON (PROF PROMPT), the command will read the stack. If PROD NOPMROMT is set,
it will not. may be this is your case. Clist controls that with PROMPT
DATA-ENDDATA pair.

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Wed, May 6, 2015 at 9:09 PM, J O Skip Robinson 
wrote:

> Sorry for not making the issue clear. SPACE was likely written elsewhere
> long ago but modified here over the years. The problem is not how to trap
> output. It uses PUTLINE, so both REXX OUTTRAP and CLIST &SYSOUTTRAP work
> fine. The problem is 'subcommand mode'. Some standard IBM command
> processors work this way: OPER and TEST for example. You enter the command,
> then enter various subcommands until you're done, then type END. The PDS
> command runs in subcommand mode.
>
> I cannot get a REXX to work in subcommand mode. For example,
>
> x = OUTTRAP("cmdl.")
>
> QUEUE Vx
> QUEUE END
> SPACE
>
> In REXX, the SPACE command is entered but does not read from the stack. It
> just sits and waits forever for terminal input. Whatever is entered breaks
> the process. The corresponding CLIST works fine.
>
> SET &SYSOUTTRAP = 1000
> SPACE
> V&VOL_SER_PREFIX
> SET l = &SYSOUTLINE
> SET &SYSOUTTRAP = 0
> SET i = 1
>
> DO WHILE &i <= &l
>   SET line = &STR(&&SYSOUTLINE&i)
>   ...
> ENDO
>
> Of course I could rewrite SPACE to work differently, but I'm asking
> whether there is a REXX solution to handle subcommand mode.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, May 06, 2015 10:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Did I really need a CLIST???
>
> Is this a SPACE command processor from cbttape.org or something home
> grown?
> Is SPACE using TPUTS/TGETS?  It might make this behavior understandable.
>
> I know with CLIST you can send an END command.  I will have to check out
> rexx.  You may wish to post on the TSO/REXX list.  They may have more ideas.
> Both CLIST and REXX discussed there.  Along with native TSO stuff.  ;-D
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of J O Skip Robinson
> > Sent: Wednesday, May 06, 2015 9:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Did I really need a CLIST???
> >
> > Users needed a simple way to display percentage free space on a set of
> > DASD volumes identified by volser prefix. Simplest solution was to run
> > our own SPACE command, trap the output, do some calculations, and
> > display the answer. SPACE runs in subcommand mode, so issue SPACE
> > followed by subcommands to get desired output.
> >
> > I could not get this to work in REXX. As soon SPACE was entered, no
> > subcommands would be read from the stack until I manually entered 'end'.
> > That exited the SPACE command and lost all further processing
> opportunity.
> >
> > So I wrote a CLIST-first brand new one decades. I had to read the
> > manual a lot, made many mistakes, but got it working because CLIST
> > handles subcommand mode just fine. Question: did I really need to do
> that?
>
> --
> 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: Did I really need a CLIST???

[J O Skip Robinson]

Sorry for not making the issue clear. SPACE was likely written elsewhere long 
ago but modified here over the years. The problem is not how to trap output. It 
uses PUTLINE, so both REXX OUTTRAP and CLIST &SYSOUTTRAP work fine. The problem 
is 'subcommand mode'. Some standard IBM command processors work this way: OPER 
and TEST for example. You enter the command, then enter various subcommands 
until you're done, then type END. The PDS command runs in subcommand mode. 

I cannot get a REXX to work in subcommand mode. For example, 

x = OUTTRAP("cmdl.") 

QUEUE Vx
QUEUE END
SPACE 

In REXX, the SPACE command is entered but does not read from the stack. It just 
sits and waits forever for terminal input. Whatever is entered breaks the 
process. The corresponding CLIST works fine.

SET &SYSOUTTRAP = 1000
SPACE 
V&VOL_SER_PREFIX  
SET l = &SYSOUTLINE 
SET &SYSOUTTRAP = 0
SET i = 1   
  
DO WHILE &i <= &l 
  SET line = &STR(&&SYSOUTLINE&i)
  ...
ENDO

Of course I could rewrite SPACE to work differently, but I'm asking whether 
there is a REXX solution to handle subcommand mode.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, May 06, 2015 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Did I really need a CLIST???

Is this a SPACE command processor from cbttape.org or something home grown?
Is SPACE using TPUTS/TGETS?  It might make this behavior understandable.

I know with CLIST you can send an END command.  I will have to check out rexx.  
You may wish to post on the TSO/REXX list.  They may have more ideas.
Both CLIST and REXX discussed there.  Along with native TSO stuff.  ;-D

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of J O Skip Robinson
> Sent: Wednesday, May 06, 2015 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Did I really need a CLIST???
> 
> Users needed a simple way to display percentage free space on a set of 
> DASD volumes identified by volser prefix. Simplest solution was to run 
> our own SPACE command, trap the output, do some calculations, and 
> display the answer. SPACE runs in subcommand mode, so issue SPACE 
> followed by subcommands to get desired output.
> 
> I could not get this to work in REXX. As soon SPACE was entered, no 
> subcommands would be read from the stack until I manually entered 'end'.
> That exited the SPACE command and lost all further processing opportunity.
> 
> So I wrote a CLIST-first brand new one decades. I had to read the 
> manual a lot, made many mistakes, but got it working because CLIST 
> handles subcommand mode just fine. Question: did I really need to do that?

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

Re: Basic question on TSO commands and other executables

[Tony Harminc]

On 5 May 2015 at 19:59, Charles Mills  wrote:

> Hmmm. I'm actually wishing to do this from within a command I will write. Is 
> there any reason I
> cannot use normal MVS functions such as LOAD to find a particular FOO and 
> then pass my own
> "constructed" CPPL:
>
> CPPLCBUF: Pointer to a buffer in my program containing H'21',H'4',C'FOO SOME 
> OPERANDS'
> CPPLUPT: Copied from my entry CPPL.
> CPPLPSCB: Copied from my entry CPPL.
> CPPLECT: Copied from my entry CPPL.

In many cases that works fine, with a few caveats.

> Will that work (assuming no screw-ups) or is there some "magic" that TSO 
> performs for a CP that
> will be missing if I do a LOAD and BASSM or BALR? I was thinking there was 
> (some TSO magic
> necessary) but perhaps there is not?

No great magic. Perhaps some bit twiddling.

> Note: all unauthorized. No APF considerations here.

I'm glad you said that. :-)

There are several models you can follow here. But first, is FOO *your*
command, or one of a number of commands you know a lot about, or is it
more general than that, i.e. can the user select commands somehow?
Even without APF considerations, there is room for things to go wrong.

The first model is the TMP itself. IBM used to document this in a book
called Guide to Writing a Terminal Monitor Program or a Command
Processor, but that book was discontinued after MVS/XA, I believe. You
can find an old copy on bitsavers or the like, and it is still mostly
valid and remains quite useful. At the time IBM discontinued that
book, they added OCO elements to the TMP:Command interface, and these
have been further added to over time, so things like integrated REXX
support and authorized commands are not fully documented. In other
words it is no longer possible to write your own full-function TMP
using supported interfaces.

Second, that book, and its replacements TSO/E Programming Guide and
TSO/E Programming Services also describe the subcommand interface.
This is/was used by TSO commands like EDIT, which have subcommands
that are distinct load modules. As luck(?) would have it, the
subcommand interface is essentially identical to the command
interface, and is well documented.

Both these interfaces involve ATTACHing the [sub]command, and there
are some rules for that, including careful use of storage subpools
(e.g. do NOT share SP 0, and DO share SP 78). If your FOO is a single
load module that implements more than one command (say module ABCFOO
has aliases FOO and BAR), then you should copy the command name (not
the load module name) into the ECTPCMD field of the ECT. Some IBM
commands, notably the AMS ones like  DEFINE, DELETE, PRINT etc. depend
on this. Of course if it's your FOO, then this isn't needed.

The third approach is to just LINK (or BALR etc) to the command
module, which I think is what you are suggesting. It will probably
work fine; considerations are abend handling and storage use. If you
are invoking FOO many times, it has no obligation to release subpool 0
storage, and you may run out.

And finally, there are the official approaches, which are the somewhat
overlapping TSO/E services IKJTSOEV and IKJEFTSR. Higher overhead,
lots of features, and supported. Read all about them in the books
above.

Good luck.

Tony H.

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

Re: Did I really need a CLIST???

[Lizette Koehler]

Is this a SPACE command processor from cbttape.org or something home grown?
Is SPACE using TPUTS/TGETS?  It might make this behavior understandable.

I know with CLIST you can send an END command.  I will have to check out
rexx.  You may wish to post on the TSO/REXX list.  They may have more ideas.
Both CLIST and REXX discussed there.  Along with native TSO stuff.  ;-D

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of J O Skip Robinson
> Sent: Wednesday, May 06, 2015 9:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Did I really need a CLIST???
> 
> Users needed a simple way to display percentage free space on a set of
> DASD volumes identified by volser prefix. Simplest solution was to run our
> own SPACE command, trap the output, do some calculations, and display the
> answer. SPACE runs in subcommand mode, so issue SPACE followed by
> subcommands to get desired output.
> 
> I could not get this to work in REXX. As soon SPACE was entered, no
> subcommands would be read from the stack until I manually entered 'end'.
> That exited the SPACE command and lost all further processing opportunity.
> 
> So I wrote a CLIST-first brand new one decades. I had to read the manual a
> lot, made many mistakes, but got it working because CLIST handles
> subcommand mode just fine. Question: did I really need to do that?
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 

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

Re: Did I really need a CLIST???

[Elardus Engelbrecht]

J O Skip Robinson wrote:

>Users needed a simple way to display percentage free space on a set of DASD 
>volumes identified by volser prefix. Simplest solution was to run our own 
>SPACE command, trap the output, do some calculations, and display the answer. 
>SPACE runs in subcommand mode, so issue SPACE followed by subcommands to get 
>desired output.

Uhhh, sorry, but what is 'subcommand mode'. This is certainly something I never 
heard of.

>I could not get this to work in REXX. As soon SPACE was entered, no 
>subcommands would be read from the stack until I manually entered 'end'. That 
>exited the SPACE command and lost all further processing opportunity.

>So I wrote a CLIST-first brand new one decades. I had to read the manual a 
>lot, made many mistakes, but got it working because CLIST handles subcommand 
>mode just fine. Question: did I really need to do that?

Ouch. You can use REXX to trap output. Perhaps if you can give me your 
sanitized version of SPACE and your CLIST, I could try to conjure up a REXX 
thing. No guarantees of course...

There are many examples of REXX programs floating around trapping output of 
another program or CLIST/REXX.

Alternatively, could you try something in REXX on a list of volsers in ISMF? Or 
REXX on a report of available space from ISMF?

Or could you rewrite SPACE to accept parameters instead of 'subcommands'? Then 
it is just one call and REXX/CLIST can trap everything for you.

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: Possible to get DCB address after C fopen()

[Charles Mills]

Thanks for your help. Yeah, I checked LE Vendor Interfaces before I posted. I 
have finally learned "when you can't find it where you think it ought to be, 
look in Vendor Interfaces."

Yeah, pretty much resigned now to my own dynalloc and OPEN. Good suggestion on 
chasing the DEB chain, but that's not going to be any easier than doing it 
"right."

Annoying that BPXWDYN cannot return a DD name. Have to do some serious thinking 
about the implications of a hard DD name. Resigned to the possibility of having 
to use C dynalloc(). I remember it as being a PITA but the only other time I 
used it I was brand new to C and especially C on Z and so it may not be so bad 
as I recall. (I have used assembler SVC 99 extensively, back in the bad old 
days when I wrote everything in Assembler.)

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, May 06, 2015 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible to get DCB address after C fopen()

On 6 May 2015 at 09:50, Charles Mills  wrote:
> I suspect I know the answer to this question. Is there any 
> generally-accepted way to get the DCB address following a C fopen()? 
> (I say "generally accepted" because I assume there is no supported 
> way. I could live with something with some risk, but not a total 
> hack.)

The supported (in the sense that all fields and control blocks are PI or at 
least very well known for decades) is to chase the DEB chain.
Each DEB points to an open DCB (or ACB) and each such xCB has a TIOT offset to 
the DDNAME entry. So if you know the DDNAME you can find any open DCBs for it 
without reference to any C or LE control blocks.

But if it was dynalloc'd then you won't know the DDNAME, presumably.
You can go a step further and do the same thing with DSNAMEs, though it's 
trickier. If you know the DSNAME, obviously.

Otherwise I'd check the LE Vendor Interfaces book. Though the more I think 
about it, the more I think I/O in general is probably language dependant, and 
may not be handled by LE. And there is no C/C++ Vendor Interfaces book, afaik.

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

Re: Did I really need a CLIST???

[Ed Finnell]

pds vol zzz public|private|stor
 
 
In a message dated 5/6/2015 11:48:38 A.M. Central Daylight Time,  
jo.skip.robin...@sce.com writes:

Question: did I really need to do  that?


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

Did I really need a CLIST???

[J O Skip Robinson]

Users needed a simple way to display percentage free space on a set of DASD 
volumes identified by volser prefix. Simplest solution was to run our own SPACE 
command, trap the output, do some calculations, and display the answer. SPACE 
runs in subcommand mode, so issue SPACE followed by subcommands to get desired 
output.

I could not get this to work in REXX. As soon SPACE was entered, no subcommands 
would be read from the stack until I manually entered 'end'. That exited the 
SPACE command and lost all further processing opportunity.

So I wrote a CLIST-first brand new one decades. I had to read the manual a lot, 
made many mistakes, but got it working because CLIST handles subcommand mode 
just fine. Question: did I really need to do that?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com


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

Re: Possible to get DCB address after C fopen()

[Tony Harminc]

On 6 May 2015 at 09:50, Charles Mills  wrote:
> I suspect I know the answer to this question. Is there any
> generally-accepted way to get the DCB address following a C fopen()? (I say
> "generally accepted" because I assume there is no supported way. I could
> live with something with some risk, but not a total hack.)

The supported (in the sense that all fields and control blocks are PI
or at least very well known for decades) is to chase the DEB chain.
Each DEB points to an open DCB (or ACB) and each such xCB has a TIOT
offset to the DDNAME entry. So if you know the DDNAME you can find any
open DCBs for it without reference to any C or LE control blocks.

But if it was dynalloc'd then you won't know the DDNAME, presumably.
You can go a step further and do the same thing with DSNAMEs, though
it's trickier. If you know the DSNAME, obviously.

Otherwise I'd check the LE Vendor Interfaces book. Though the more I
think about it, the more I think I/O in general is probably language
dependant, and may not be handled by LE. And there is no C/C++ Vendor
Interfaces book, afaik.

> Why? I'd like to be able to use the terrific features of C fopen()
> (transparent dynamic allocation, etc.) but use the DCB with LINK (in an
> assembler function called from C).

My, you are pressing things hard. There are warnings about mixing OS
services with those of LE, and presumably of C itself. But it's a neat
idea.

Tony H.

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

Re: HSM full vol dump question

[Glenn Wilcock]

Hi,

You can also try LIST PRIMARYVOLUME ALLDUMPS BCDS.  (You may have to specify a 
specific volser).

Glenn Wilcock
DFSMShsm Architect

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

Re: IDCAMS vs IDC3194I

[Neil Duffee]

Caveat:  yeah, you know the routine, digest delay, already answered, etc.

Esmie:  when using ListDS (=3.4) for SYS2.CA1.TMSA.**, is ACTQUE the 1st entry? 
 My suspicion is that IdcAms stopped processing when it encountered the 
IDC3194I which happens to be the first of the bunch.

>  signature = 6 lines follows  <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585  fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?"  Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent"  John Norgauer 2004

-Original Message-
From: esmie moo [mailto:esm..mo...@yah...ca] 
Sent: May 5, 2015 13:55
Subject: Re: IDCAMS QUESTION

The dsns are all SMS managed except for SYS2.CA1.TMSA.ACTQUE.  This dsn is on a 
non-SMS volume.  Since IDCAMS encountered this dsn did it prevent the ALTER of 
the other dsns?
The SYS2.CA1.TMSA dsns are from an older version of CA1.  The current versions 
are on non-SMS vols.


On Tue, 5/5/15, Lizette Koehler  wrote:
Received: Tuesday, May 5, 2015, 1:06 PM
 
 Your dataset is not  managed by SMS - So you cannot alter the management  class
 
 IDC3194I  SMS CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS  MANAGED  
 
 Did you place  your SYS2.CA1.TMSA on SMS managed volumes?  Do you have  the  
under control of SMS? - This is  something I would not do for CA1 TMC.
 
 > 
 > On Tue, 5/5/15, esmie moo   wrote:
 >
>  Received: Tuesday, May 5, 2015, 11:31  AM  
>  [snip] trying to alter the Management Class of the the  following  dsns  
> using  
> IDCAMS:  SYS2.CA1 .TMSA.**.  [snip] The message error  
> posted  for one dsn is self explanatory,  however when I check all  the  dsns 
> it  
> shows that the alter did not work.  Is  it  because it detected a problem  
> with  
> one dsn and doesn't  process any of  the dsns?  Below is the output of the 
> job :
 >
 >  IDCAMS  SYSTEM SERVICES
 >      ALTER SYS2.CA1 .TMSA.*  -
 >            MGMTCLAS (NOMIG)
 >
>  IDC3194I SMS CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS MANAGED  
 > IDC3194I OBJECT  
 >  IDC0532I **ENTRY SYS2.CA1 .TMSA.ACTQUE NOT ALTERED

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

Re: Basic question on TSO commands and other executables

[Hobart Spitz]

Before I get too much static, I ask that you read all the way to the end
before replying.

If it were me, my solution would be to run under ISPF and use [ADDRESS
ISPEXEC] "SELECT CMD(FOO ...)" .

Here is my thinking and approach:

   - ISPF has a huge number of highly useful and valuable facilities, which
   are expensive or impractical to forego.
   - It is impractical and costly to write software that is either :
  - Dual pathed for both ISPF and non-ISPF execution environments.
  - Not dependent on ISPF.

Yes, for a single module, dual pathing is no big deal, but if you are
reusing common code, you rapidly reach the point where the common code
costs of dual pathing cause code bloat.

Therefore, I create a single JCL proc that executes any TSO command in
batch with ISPF active.  This proc includes allocations that match the
online environment.  While this is non-trivial, it is a one-time cost.
 (You have to deal with command and return code passing at two levels.  See
ZISPFRC.)  That cost is more than offset (by many orders of magniture) by
the benefit of being able to write modules that work unchanged in both
foreground or batch.

Note:  One of the most important allocations for ISPF batch is:

//ISPLOG   DD  SYSOUT=*

even if you disable the ISPF log in foreground.  There are situations where
you need the log messages.

YMMV.

On Tue, May 5, 2015 at 7:59 PM, Charles Mills  wrote:

> Thanks much.
>
> > I'm surprised the doc isn't clear, but it's one of those "everyone knows
> that" sort of things, so I don't doubt you.
>
> Notice I said "not very clear to me" LOL. I've written a lot of programs
> in my career but never a TSO command or the like. What can I say?
>
> OK, I "get" your TEST example. You bring foo into memory from a specified
> library telling TEST it's a CP and then run it. Thanks.
>
> > Over the decades just about everyone wrote a CALLCP command to do this,
> often with variations. I'll bet there are several on the CBT site.
>
> Hmmm. I'm actually wishing to do this from within a command I will write.
> Is there any reason I cannot use normal MVS functions such as LOAD to find
> a particular FOO and then pass my own "constructed" CPPL:
>
> CPPLCBUF: Pointer to a buffer in my program containing H'21',H'4',C'FOO
> SOME OPERANDS'
> CPPLUPT: Copied from my entry CPPL.
> CPPLPSCB: Copied from my entry CPPL.
> CPPLECT: Copied from my entry CPPL.
>
> Will that work (assuming no screw-ups) or is there some "magic" that TSO
> performs for a CP that will be missing if I do a LOAD and BASSM or BALR? I
> was thinking there was (some TSO magic necessary) but perhaps there is not?
>
> Note: all unauthorized. No APF considerations here.
>
> Thanks again,
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
OREXXMan

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

AW: Stop RELEASE of a tape

[Christian Birr]

Well, glad I could help. HSM just did what you told him to do: release a tape, 
regardless of its expiration date. Now back to my EOD beer ;-)
Christian

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Mittwoch, 6. Mai 2015 17:30
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Stop RELEASE of a tape

Thank you, that did indeed fix it.  Seems counter-intuitive to me since it was 
already to not expire.

On Wed, May 6, 2015 at 11:17 AM, Christian Birr < 
christian.b...@birrconsulting.de> wrote:

> Set the expiration date to a value in the future, this should clear 
> the "pending release" state...
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> Im Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 17:12
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Stop RELEASE of a tape
>
> Thanks, Christian - but entering CH takes me to the Change Volume 
> panel - and I don't see what it is I change to stop the release.  The 
> expiration date is set to 1999/365.  The tape did not expire.
>
> On Wed, May 6, 2015 at 11:00 AM, Christian Birr < 
> christian.b...@birrconsulting.de> wrote:
>
> > Put an S in front of SCRATCH and the volumes will be listed...
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > Im Auftrag von Mark Pace
> > Gesendet: Mittwoch, 6. Mai 2015 16:58
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Re: Stop RELEASE of a tape
> >
> > Odd on my Confirm panel I don't have a list of volumes.  And only 
> > one character for Selection.
> >
> > S Action   Location ination  Move Type Status
> > -    - -
> >   ERASEUNKNOWN
> >   INIT UNKNOWN
> >   NOTIFY   UNKNOWN
> >   REPLACE  UNKNOWN
> >   RETURN   UNKNOWN
> >   SCRATCH  PENDING
> >
> > And the options are these.
> >
> > C - Confirm the required action.
> > U - Unconfirm the already confirmed action.
> > S - Create the volume entry summary list.
> >
> > On Wed, May 6, 2015 at 10:53 AM, Christian Birr < 
> > christian.b...@birrconsulting.de> wrote:
> >
> > > Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), 
> > > then
> > > 8
> > > (confirm) and CH in front of the volume(s) you want to preserve 
> > > should do the trick Christian
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Mark Pace
> > > Gesendet: Mittwoch, 6. Mai 2015 16:38
> > > An: IBM-MAIN@LISTSERV.UA.EDU
> > > Betreff: Stop RELEASE of a tape
> > >
> > > I screwed up and released a tape that I should not have.  I have 
> > > not yet run the process that actually puts the tape in SCRATCH 
> > > status - so currently it is PENDING RELEASE.
> > >
> > > Is there some way to reverse that RELEASE?
> > >
> > > --
> > > The postings on this site are my own and don’t necessarily 
> > > represent Mainline’s positions or opinions
> > >
> > > Mark D Pace
> > > Senior Systems Engineer
> > > Mainline Information Systems
> > >
> > > --
> > > --
> > > -- 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
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent 
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > 
> > -- 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
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent 
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> --
>

Re: Stop RELEASE of a tape

[Mark Pace]

Thank you, that did indeed fix it.  Seems counter-intuitive to me since it
was already to not expire.

On Wed, May 6, 2015 at 11:17 AM, Christian Birr <
christian.b...@birrconsulting.de> wrote:

> Set the expiration date to a value in the future, this should clear the
> "pending release" state...
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 17:12
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Stop RELEASE of a tape
>
> Thanks, Christian - but entering CH takes me to the Change Volume panel -
> and I don't see what it is I change to stop the release.  The expiration
> date is set to 1999/365.  The tape did not expire.
>
> On Wed, May 6, 2015 at 11:00 AM, Christian Birr <
> christian.b...@birrconsulting.de> wrote:
>
> > Put an S in front of SCRATCH and the volumes will be listed...
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > Im Auftrag von Mark Pace
> > Gesendet: Mittwoch, 6. Mai 2015 16:58
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Re: Stop RELEASE of a tape
> >
> > Odd on my Confirm panel I don't have a list of volumes.  And only one
> > character for Selection.
> >
> > S Action   Location ination  Move Type Status
> > -    - -
> >   ERASEUNKNOWN
> >   INIT UNKNOWN
> >   NOTIFY   UNKNOWN
> >   REPLACE  UNKNOWN
> >   RETURN   UNKNOWN
> >   SCRATCH  PENDING
> >
> > And the options are these.
> >
> > C - Confirm the required action.
> > U - Unconfirm the already confirmed action.
> > S - Create the volume entry summary list.
> >
> > On Wed, May 6, 2015 at 10:53 AM, Christian Birr <
> > christian.b...@birrconsulting.de> wrote:
> >
> > > Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume),
> > > then
> > > 8
> > > (confirm) and CH in front of the volume(s) you want to preserve
> > > should do the trick Christian
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > Im Auftrag von Mark Pace
> > > Gesendet: Mittwoch, 6. Mai 2015 16:38
> > > An: IBM-MAIN@LISTSERV.UA.EDU
> > > Betreff: Stop RELEASE of a tape
> > >
> > > I screwed up and released a tape that I should not have.  I have not
> > > yet run the process that actually puts the tape in SCRATCH status -
> > > so currently it is PENDING RELEASE.
> > >
> > > Is there some way to reverse that RELEASE?
> > >
> > > --
> > > The postings on this site are my own and don’t necessarily represent
> > > Mainline’s positions or opinions
> > >
> > > Mark D Pace
> > > Senior Systems Engineer
> > > Mainline Information Systems
> > >
> > > 
> > > -- 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
> > >
> >
> >
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > 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
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
For IBM-MAIN subscribe / signoff / archive access i

Re: IDCAMS QUESTION

[Lizette Koehler]

I would have probably done the LISTC on an entry before and after where the
error occurred and verified the MGMTCLAS.

This would show whether or not IDCAMS stopped or continued and just flagged
the one file 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of esmie moo
> Sent: Wednesday, May 06, 2015 8:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IDCAMS QUESTION
> 
> I tried out your suggestion.  I renamed the offending dsn and re-ran the
alter
> successfully.  Seems that IDCAMS stop processing when it hits a dsn which
is
> not SMS managed.
> 
> Thanks for the help.
> 
>  MAIN" 
>   >  Received: Tuesday, May 5, 2015,
>  11:31
>   AM
>   >
>   >  Gentle
>   Readers,
>   >
>   >  I am
>   trying to alter the Management Class of the  the  following
>   dsns
> 
>  using
>   > IDCAMS:
> 
>  SYS2.CA1 .TMSA.**.  I have  done this in the past and  it
>   used to
>   > work
>  however for some  reason
>   I am unable to do
>  so.  The message error
>   > posted  for
>  one dsn is self explanatory,
>   however when I
>  check all  the
>   dsns it
> 
>  > shows that the alter did not work.  Is
>   it  because it detected a problem
>   with
>   > one dsn and
>  doesn't  process any of
>   the dsns?  If
>  so, is there a work
>   around
> 
>  > it?  Below is the output of the job :
> 
>  >
>   >  IDCAMS  SYSTEM
>   SERVICES
>   >
>   >
>   >
> 
>  >
>   >
>   >
>  ALTER
>   SYS2.CA1 .TMSA.*  -
> 
>  >
>   >
>   >
>   >            MGMTCLAS (NOMIG)
>   >
>   >
> 
>  >
>   >  IDC3194I SMS
> 
>  CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS
>   > MANAGED  IDC3194I OBJECT
>   >
>   >
> 
>  >
>   >  IDC0532I **ENTRY
>   SYS2.CA1 .TMSA.ACTQUE NOT ALTERED
>   >
>   >
> 
>  >  IDC3003I FUNCTION
>   TERMINATED.
>  CONDITION CODE IS 12
>   >
> 
>  >
>   >
>   >
>   >  IDC0002I IDCAMS
> 
>  PROCESSING COMPLETE. MAXIMUM CONDITION CODE
> 
>  > WAS 12
>   >

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

Re: IDCAMS QUESTION

[esmie moo]

I tried out your suggestion.  I renamed the offending dsn and re-ran the alter 
successfully.  Seems that IDCAMS stop processing when it hits a dsn which is 
not SMS managed.

Thanks for the help.

On Tue, 5/5/15, Pommier, Rex  wrote:

 Subject: Re: IDCAMS QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 5, 2015, 2:59 PM
 
 Try renaming the non-SMS
 one to something outside your mask and trying it again.  If
 it works, you have your answer and your SMS datasets
 altered.  Then just rename the non-SMS one back. 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of esmie moo
 Sent: Tuesday, May
 05, 2015 12:55 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: IDCAMS QUESTION
 
 The dsns are all SMS managed
 except for SYS2.CA1 .TMSA.ACTQUE.  This dsn is on a non-SMS
 volume.  Since IDCAMS encountered this dsn did it prevent
 the ALTER of the other dsns?
 The
 SYS2.CA1.TMSA dsns are from an older version of CA1.  The
 current versions are on non-SMS vols.
 
 
 On Tue, 5/5/15, Lizette Koehler 
 wrote:
 
  Subject: Re: IDCAMS
 QUESTION
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Tuesday, May 5, 2015, 1:06 PM
  
  Your dataset is not
  managed by SMS - So you cannot alter the
 management
  class
  
  IDC3194I
  SMS CONSTRUCT
 MANAGEMENTCLASS SPECIFIED FOR NON-SMS
 
 MANAGED  
  
  Did you
 place
  your SYS2.CA1.TMSA on SMS managed
 volumes?  Do you have
  the
 
 under control of SMS? - This is
  something I
 would not do for CA1 TMC.
  
 
 
  Lizette
  
 
 
  > -Original Message-
  > From: IBM Mainframe Discussion List
  [mailto:IBM-MAIN@LISTSERV.UA.EDU]
  > On Behalf Of esmie moo
 
 > Sent: Tuesday, May 05, 2015 9:01 AM
 
 > To: IBM-MAIN@LISTSERV.UA.EDU
  > Subject: Re: IDCAMS QUESTION
  > 
  > Just to confirm
 that
  there is no space between the CA1
 & .TMSA.  The
  error
 
 > occurred when I performed the
 
 copy/paste.
  > 
  >
  Sorry.
  >
 
 
  > On Tue, 5/5/15, esmie moo 
  wrote:
  > 
 
 >  Subject:
  IDCAMS QUESTION
  >  To: "IBM
 
 MAIN" 
  >  Received: Tuesday, May 5, 2015,
 11:31
  AM
  > 
  >  Gentle
  Readers,
  > 
  >  I am
  trying to alter the Management Class of the
 the  following
  dsns
 
 using
  > IDCAMS:
 
 SYS2.CA1 .TMSA.**.  I have  done this in the past and
 it
  used to
  > work
 however for some  reason
  I am unable to do
 so.  The message error
  > posted  for
 one dsn is self explanatory,
  however when I
 check all  the
  dsns it
 
 > shows that the alter did not work.  Is
  it  because it detected a problem
  with
  > one dsn and
 doesn't  process any of
  the dsns?  If
 so, is there a work
  around
 
 > it?  Below is the output of the job :
 
 > 
  >  IDCAMS  SYSTEM
  SERVICES
  > 
  > 
  > 
 
 > 
  > 
  >     
 ALTER
  SYS2.CA1 .TMSA.*  -
 
 > 
  > 
  > 
  >            MGMTCLAS (NOMIG)
  > 
  > 
 
 > 
  >  IDC3194I SMS
 
 CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS
  > MANAGED  IDC3194I OBJECT
  > 
  > 
 
 > 
  >  IDC0532I **ENTRY
  SYS2.CA1 .TMSA.ACTQUE NOT ALTERED
  > 
  > 
 
 >  IDC3003I FUNCTION
  TERMINATED.
 CONDITION CODE IS 12
  > 
 
 > 
  > 
  > 
  >  IDC0002I IDCAMS
 
 PROCESSING COMPLETE. MAXIMUM CONDITION CODE
 
 > WAS 12
  > 
  > 
  
 
 --
  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
 
 
 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: IEFBR14 question

[Joel Ewing]

On 05/05/2015 09:28 AM, Scott Ford wrote:
> All,
> 
> Since I started this "question", so how is "one" to check for the existence
> of datasets if we can't really trust IEFBR14 ? Yeah, I can write an
> Assembler routine, by why, when BR14 is supposed to work...I have staging
> datasets we use to build our product, my first step is the IEFBR14 , to
> delete these datasets if they exist, if not fine give me a return code I
> can test for and proceed on with the other steps.
> 
> Regards,
> 
> Scott
> 
> On Tuesday, May 5, 2015, Elardus Engelbrecht 
> wrote:
> 
>> John Eells wrote:
>>
>>> The recurring confusion about what IEFBR14 itself actually does (clear
>> GPR15 and return) and what people seem to think it does from the odd post
>> here and their (not yours) is one reason I call IEFBR14 the "most misused
>> program in the history of z/OS."
>>
>> ... and also in the history of MVS and OS/390.
>>
>> and Lizette Koehler said really really tongue in cheek this (and confusing
>> a person who replied on her post):
>>
>> "And IEFBR14 is more that return on R14.  It does stuff.  Just look how
>> big it is."
>>
>> and I said earlier: 'IEFBR14 is just a lazy program setting a RC=00 and
>> nothing else.'
>>
>> Hmmm, I *always* ( ;-D ) wanted to sign IEFBR14 with a (program) digital
>> certificate with RACF, but PDS datasets (at least the SYS1.LINKLIB) are not
>> supported for this stunt. 
>>
>> Has a patent been taken out on IEFBR14 (or its queer position in MVS,
>> OS390, z/OS)? If not, I want to register it, but I am too broke. ;-D
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>>
...
A trivial two-instruction program like IEFBR14 that is totally unaware
of any data sets can obviously not set different return codes based on
the status of some data set.  You can always trust IEFBR14 to do what it
was designed to do -- nothing except setting a RC of 0. That IEFBR14 as
a job step program ever appears to do something more than that is an
illusion and purely an artifact of Initiator actions before passing
control to the job step program and Initiator actions after the job step
program sets its return code and completes.  Those other effects are an
effect of the job step and its JCL as a whole, not some effect of
IEFBR14.  By design, if a job step return code exists it is based solely
on the job step program results (trivial in case of IEFBR14) and not on
any pre-step or post-step actions done by the initiator.

For the purpose of setting a job step RC based on data set status
(existence, size, whatever), we always used a Batch TSO step that would
run an installation REXX EXEC with a data set name parameter, letting
the REXX Exec check internally on status of the data set in some way
(LISTDSI, LISTC, etc.) and based on that status set a return code that
would become the job step RC.  Such an EXEC is fairly trivial for an
installation to set up and document.  Writing Assembler code to get this
functionality would IMO be considerable overkill.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

AW: Stop RELEASE of a tape

[Christian Birr]

Set the expiration date to a value in the future, this should clear the 
"pending release" state...

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Mittwoch, 6. Mai 2015 17:12
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Stop RELEASE of a tape

Thanks, Christian - but entering CH takes me to the Change Volume panel - and I 
don't see what it is I change to stop the release.  The expiration date is set 
to 1999/365.  The tape did not expire.

On Wed, May 6, 2015 at 11:00 AM, Christian Birr < 
christian.b...@birrconsulting.de> wrote:

> Put an S in front of SCRATCH and the volumes will be listed...
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> Im Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 16:58
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Stop RELEASE of a tape
>
> Odd on my Confirm panel I don't have a list of volumes.  And only one 
> character for Selection.
>
> S Action   Location ination  Move Type Status
> -    - -
>   ERASEUNKNOWN
>   INIT UNKNOWN
>   NOTIFY   UNKNOWN
>   REPLACE  UNKNOWN
>   RETURN   UNKNOWN
>   SCRATCH  PENDING
>
> And the options are these.
>
> C - Confirm the required action.
> U - Unconfirm the already confirmed action.
> S - Create the volume entry summary list.
>
> On Wed, May 6, 2015 at 10:53 AM, Christian Birr < 
> christian.b...@birrconsulting.de> wrote:
>
> > Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), 
> > then
> > 8
> > (confirm) and CH in front of the volume(s) you want to preserve 
> > should do the trick Christian
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > Im Auftrag von Mark Pace
> > Gesendet: Mittwoch, 6. Mai 2015 16:38
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Stop RELEASE of a tape
> >
> > I screwed up and released a tape that I should not have.  I have not 
> > yet run the process that actually puts the tape in SCRATCH status - 
> > so currently it is PENDING RELEASE.
> >
> > Is there some way to reverse that RELEASE?
> >
> > --
> > The postings on this site are my own and don’t necessarily represent 
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > 
> > -- 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
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent 
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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
>



--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Stop RELEASE of a tape

[Mark Pace]

Thanks, Christian - but entering CH takes me to the Change Volume panel -
and I don't see what it is I change to stop the release.  The expiration
date is set to 1999/365.  The tape did not expire.

On Wed, May 6, 2015 at 11:00 AM, Christian Birr <
christian.b...@birrconsulting.de> wrote:

> Put an S in front of SCRATCH and the volumes will be listed...
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 16:58
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Stop RELEASE of a tape
>
> Odd on my Confirm panel I don't have a list of volumes.  And only one
> character for Selection.
>
> S Action   Location ination  Move Type Status
> -    - -
>   ERASEUNKNOWN
>   INIT UNKNOWN
>   NOTIFY   UNKNOWN
>   REPLACE  UNKNOWN
>   RETURN   UNKNOWN
>   SCRATCH  PENDING
>
> And the options are these.
>
> C - Confirm the required action.
> U - Unconfirm the already confirmed action.
> S - Create the volume entry summary list.
>
> On Wed, May 6, 2015 at 10:53 AM, Christian Birr <
> christian.b...@birrconsulting.de> wrote:
>
> > Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), then
> > 8
> > (confirm) and CH in front of the volume(s) you want to preserve should
> > do the trick Christian
> >
> > -Ursprüngliche Nachricht-
> > Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > Im Auftrag von Mark Pace
> > Gesendet: Mittwoch, 6. Mai 2015 16:38
> > An: IBM-MAIN@LISTSERV.UA.EDU
> > Betreff: Stop RELEASE of a tape
> >
> > I screwed up and released a tape that I should not have.  I have not
> > yet run the process that actually puts the tape in SCRATCH status - so
> > currently it is PENDING RELEASE.
> >
> > Is there some way to reverse that RELEASE?
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > 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
> >
>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

AW: Stop RELEASE of a tape

[Christian Birr]

Put an S in front of SCRATCH and the volumes will be listed...

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Mittwoch, 6. Mai 2015 16:58
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Stop RELEASE of a tape

Odd on my Confirm panel I don't have a list of volumes.  And only one character 
for Selection.

S Action   Location ination  Move Type Status
-    - -
  ERASEUNKNOWN
  INIT UNKNOWN
  NOTIFY   UNKNOWN
  REPLACE  UNKNOWN
  RETURN   UNKNOWN
  SCRATCH  PENDING

And the options are these.

C - Confirm the required action.
U - Unconfirm the already confirmed action.
S - Create the volume entry summary list.

On Wed, May 6, 2015 at 10:53 AM, Christian Birr < 
christian.b...@birrconsulting.de> wrote:

> Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), then 
> 8
> (confirm) and CH in front of the volume(s) you want to preserve should 
> do the trick Christian
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> Im Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 16:38
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Stop RELEASE of a tape
>
> I screwed up and released a tape that I should not have.  I have not 
> yet run the process that actually puts the tape in SCRATCH status - so 
> currently it is PENDING RELEASE.
>
> Is there some way to reverse that RELEASE?
>
> --
> The postings on this site are my own and don’t necessarily represent 
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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
>



--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Stop RELEASE of a tape

[Mark Pace]

Odd on my Confirm panel I don't have a list of volumes.  And only one
character for Selection.

S Action   Location ination  Move Type Status
-    - -
  ERASEUNKNOWN
  INIT UNKNOWN
  NOTIFY   UNKNOWN
  REPLACE  UNKNOWN
  RETURN   UNKNOWN
  SCRATCH  PENDING

And the options are these.

C - Confirm the required action.
U - Unconfirm the already confirmed action.
S - Create the volume entry summary list.

On Wed, May 6, 2015 at 10:53 AM, Christian Birr <
christian.b...@birrconsulting.de> wrote:

> Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), then 8
> (confirm) and CH in front of the volume(s) you want to preserve should do
> the trick
> Christian
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Mark Pace
> Gesendet: Mittwoch, 6. Mai 2015 16:38
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Stop RELEASE of a tape
>
> I screwed up and released a tape that I should not have.  I have not yet
> run the process that actually puts the tape in SCRATCH status - so
> currently it is PENDING RELEASE.
>
> Is there some way to reverse that RELEASE?
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> 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
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

AW: Stop RELEASE of a tape

[Christian Birr]

Sorry, and don't forget to change the expiration date, faulty brain, I'm on the 
road right now

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Mittwoch, 6. Mai 2015 16:38
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Stop RELEASE of a tape

I screwed up and released a tape that I should not have.  I have not yet run 
the process that actually puts the tape in SCRATCH status - so currently it is 
PENDING RELEASE.

Is there some way to reverse that RELEASE?

--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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

AW: Stop RELEASE of a tape

[Christian Birr]

Mark, in ISMF, option R, then 3 (adminsitrator), then 1 (volume), then 8 
(confirm) and CH in front of the volume(s) you want to preserve should do the 
trick
Christian

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag 
von Mark Pace
Gesendet: Mittwoch, 6. Mai 2015 16:38
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Stop RELEASE of a tape

I screwed up and released a tape that I should not have.  I have not yet run 
the process that actually puts the tape in SCRATCH status - so currently it is 
PENDING RELEASE.

Is there some way to reverse that RELEASE?

--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Stop RELEASE of a tape

[Mark Pace]

It's RMM.   It's pending release because I screwed up and issued a release
against that volser.

On Wed, May 6, 2015 at 10:48 AM, R.S. 
wrote:

> W dniu 2015-05-06 o 16:37, Mark Pace pisze:
>
>> I screwed up and released a tape that I should not have.  I have not yet
>> run the process that actually puts the tape in SCRATCH status - so
>> currently it is PENDING RELEASE.
>>
>> Is there some way to reverse that RELEASE?
>>
>>  What is your TMS?
> (TMS - Tape Mgmt System, like CA1, RMM, etc.)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
> 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.840.228 złotych.
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Stop RELEASE of a tape

[R.S.]

W dniu 2015-05-06 o 16:37, Mark Pace pisze:

I screwed up and released a tape that I should not have.  I have not yet
run the process that actually puts the tape in SCRATCH status - so
currently it is PENDING RELEASE.

Is there some way to reverse that RELEASE?


What is your TMS?
(TMS - Tape Mgmt System, like CA1, RMM, etc.)

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Stop RELEASE of a tape

[Craig Pace]

Depends on how it is "pending release".

1)  If Expiration Date, just manually update the date to the new future
2)  If VRS rule, then update the VRS rule and rerun VRSEL


Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Wednesday, May 06, 2015 09:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Stop RELEASE of a tape

I screwed up and released a tape that I should not have.  I have not yet run 
the process that actually puts the tape in SCRATCH status - so currently it is 
PENDING RELEASE.

Is there some way to reverse that RELEASE?

--
The postings on this site are my own and don’t necessarily represent Mainline’s 
positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: Stop RELEASE of a tape

[Joe Testa]

>From DFSMSrmm Guide and Reference

Changing Pending Actions 
To reclaim volumes: 
  a.. From pending release, use the CHANGEVOLUME subcommand with a volume 
serial number and either the RETPD or EXPDT operands.
-- jat


-Original Message- 
From: Mark Pace 
Sent: Wednesday, May 06, 2015 10:37 AM Newsgroups: bit.listserv.ibm-main 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Stop RELEASE of a tape 

I screwed up and released a tape that I should not have.  I have not yet
run the process that actually puts the tape in SCRATCH status - so
currently it is PENDING RELEASE.

Is there some way to reverse that RELEASE?

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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

Stop RELEASE of a tape

[Mark Pace]

I screwed up and released a tape that I should not have.  I have not yet
run the process that actually puts the tape in SCRATCH status - so
currently it is PENDING RELEASE.

Is there some way to reverse that RELEASE?

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Primary allocation of a dataset

[Vernooij, CP (ITOPT1) - KLM]

Even in the case of CONTIG, allocation would create the primary space as 
requested, but subsequent merged contiguous extents and/or the RLSE option, 
could also leave behind a different primary extent after CLOSE.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Terry Sambrooks
Sent: 06 May, 2015 16:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Primary allocation of a dataset

Hi 

As several people have already alluded IT IS NOT POSSIBLE to retrieve the
Primary Request for SPACE as it IS NOT recorded in the DSCB.

There is no need to store this information as it is either available and
used or it is not in which case the data set is not created. The Secondary
Request has to be stored in the DSCB for subsequent use if the need arises.

The FIRST EXTENT will only equate to the Primary Request if CONTIG were
specified at allocation time. If CONTIG is not specified then the system
will attempt to allocate the Primary in up to 5 extents. When LISTDSI and
ISPF 3.2 are used they only report the first extent, which may only be a
subset of the Primary Request.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

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

Re: Primary allocation of a dataset

[Terry Sambrooks]

Hi 

As several people have already alluded IT IS NOT POSSIBLE to retrieve the
Primary Request for SPACE as it IS NOT recorded in the DSCB.

There is no need to store this information as it is either available and
used or it is not in which case the data set is not created. The Secondary
Request has to be stored in the DSCB for subsequent use if the need arises.

The FIRST EXTENT will only equate to the Primary Request if CONTIG were
specified at allocation time. If CONTIG is not specified then the system
will attempt to allocate the Primary in up to 5 extents. When LISTDSI and
ISPF 3.2 are used they only report the first extent, which may only be a
subset of the Primary Request.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

Re: Primary allocation of a dataset

[Lizette Koehler]

There are probably several items on cbttape.org that may already do some of
what you are looking to do.

What problem are you trying to solve?  Would it be better to use something
already created or are you looking to understand some function better?

REXX has some built-ins, SAS has some functions, ISPF Services, and so
forth.

Could you provide more details on what is driving this question?  There
might be better solutions.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Fred van der Windt
> Sent: Wednesday, May 06, 2015 4:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Primary allocation of a dataset
> 
> I want to retrieve the primary allocation of a dataset. Sofar I've used
OBTAIN
> to retrieve the DCSBs for the dataset. The DSCB1 contains information
about
> the secondary allocation size for the dataset but does not contain any
> information about the primary allocation. If the dataset had a primary
> allocation in tracks or cylinders I can retrieve the necessary information
from
> the extent information in the DSCB1: the first extent can be converted
back
> to tracks or cylinders and that should be the primary allocation.
> 
> But how can one recreate the primary allocation if some other form was
> used, for instance an amount in blocks, records or KB or something like
that?
> Is this documented anywhere?
> 
> Fred!

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

Possible to get DCB address after C fopen()

[Charles Mills]

I suspect I know the answer to this question. Is there any
generally-accepted way to get the DCB address following a C fopen()? (I say
"generally accepted" because I assume there is no supported way. I could
live with something with some risk, but not a total hack.)

Why? I'd like to be able to use the terrific features of C fopen()
(transparent dynamic allocation, etc.) but use the DCB with LINK (in an
assembler function called from C).

Charles 

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

BPXWDYN, C and returned DD name

[Charles Mills]

Am I correct in my reading of the BPXWDYN documentation that it is not
possible to get a generated and returned DD name on DSname allocation unless
one is calling BPXWDYN from Rexx (or were to set up a Rexx environment)?

Charles 

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

Re: IDCAMS QUESTION

[esmie moo]

Rex,

Thanks for the suggestion.  I will try out your suggestion.  I have seen in the 
past that when IDCAMS encounters an error it continues processing.

Thanks to all who assisted me.

On Tue, 5/5/15, Pommier, Rex  wrote:

 Subject: Re: IDCAMS QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 5, 2015, 2:59 PM
 
 Try renaming the non-SMS
 one to something outside your mask and trying it again.  If
 it works, you have your answer and your SMS datasets
 altered.  Then just rename the non-SMS one back. 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of esmie moo
 Sent: Tuesday, May
 05, 2015 12:55 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: IDCAMS QUESTION
 
 The dsns are all SMS managed
 except for SYS2.CA1 .TMSA.ACTQUE.  This dsn is on a non-SMS
 volume.  Since IDCAMS encountered this dsn did it prevent
 the ALTER of the other dsns?
 The
 SYS2.CA1.TMSA dsns are from an older version of CA1.  The
 current versions are on non-SMS vols.
 
 
 On Tue, 5/5/15, Lizette Koehler 
 wrote:
 
  Subject: Re: IDCAMS
 QUESTION
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Tuesday, May 5, 2015, 1:06 PM
  
  Your dataset is not
  managed by SMS - So you cannot alter the
 management
  class
  
  IDC3194I
  SMS CONSTRUCT
 MANAGEMENTCLASS SPECIFIED FOR NON-SMS
 
 MANAGED  
  
  Did you
 place
  your SYS2.CA1.TMSA on SMS managed
 volumes?  Do you have
  the
 
 under control of SMS? - This is
  something I
 would not do for CA1 TMC.
  
 
 
  Lizette
  
 
 
  > -Original Message-
  > From: IBM Mainframe Discussion List
  [mailto:IBM-MAIN@LISTSERV.UA.EDU]
  > On Behalf Of esmie moo
 
 > Sent: Tuesday, May 05, 2015 9:01 AM
 
 > To: IBM-MAIN@LISTSERV.UA.EDU
  > Subject: Re: IDCAMS QUESTION
  > 
  > Just to confirm
 that
  there is no space between the CA1
 & .TMSA.  The
  error
 
 > occurred when I performed the
 
 copy/paste.
  > 
  >
  Sorry.
  >
 
 
  > On Tue, 5/5/15, esmie moo 
  wrote:
  > 
 
 >  Subject:
  IDCAMS QUESTION
  >  To: "IBM
 
 MAIN" 
  >  Received: Tuesday, May 5, 2015,
 11:31
  AM
  > 
  >  Gentle
  Readers,
  > 
  >  I am
  trying to alter the Management Class of the
 the  following
  dsns
 
 using
  > IDCAMS:
 
 SYS2.CA1 .TMSA.**.  I have  done this in the past and
 it
  used to
  > work
 however for some  reason
  I am unable to do
 so.  The message error
  > posted  for
 one dsn is self explanatory,
  however when I
 check all  the
  dsns it
 
 > shows that the alter did not work.  Is
  it  because it detected a problem
  with
  > one dsn and
 doesn't  process any of
  the dsns?  If
 so, is there a work
  around
 
 > it?  Below is the output of the job :
 
 > 
  >  IDCAMS  SYSTEM
  SERVICES
  > 
  > 
  > 
 
 > 
  > 
  >     
 ALTER
  SYS2.CA1 .TMSA.*  -
 
 > 
  > 
  > 
  >            MGMTCLAS (NOMIG)
  > 
  > 
 
 > 
  >  IDC3194I SMS
 
 CONSTRUCT MANAGEMENTCLASS SPECIFIED FOR NON-SMS
  > MANAGED  IDC3194I OBJECT
  > 
  > 
 
 > 
  >  IDC0532I **ENTRY
  SYS2.CA1 .TMSA.ACTQUE NOT ALTERED
  > 
  > 
 
 >  IDC3003I FUNCTION
  TERMINATED.
 CONDITION CODE IS 12
  > 
 
 > 
  > 
  > 
  >  IDC0002I IDCAMS
 
 PROCESSING COMPLETE. MAXIMUM CONDITION CODE
 
 > WAS 12
  > 
  > 
  
 
 --
  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
 
 
 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: IEFBR14 question

[Craig Pace]

We have our own "IEFBR14" that does exactly that, it just reads input from 
SYSIN and performs the required SCRATCH or not depending on the status and then 
reports on what it did.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Wednesday, May 06, 2015 08:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEFBR14 question

Paul,

I like that, why not or at the least provide a mechanism that works.

Regards,
Scott

On Wednesday, May 6, 2015, Scheuer, Paul  wrote:

> Sure! Can you drop them by Marcello 4406 around 8am?
>
> Sent from

my Android phone using TouchDown (www.nitrodesk.com)
>
> -Original Message-
> From: Dave Barry [00a5644c6d08-dmarc-requ...@listserv.ua.edu
> ]
> Received: Tuesday, 05 May 2015, 3:54PM
> To: IBM-MAIN@LISTSERV.UA.EDU  [IBM-MAIN@LISTSERV.UA.EDU
> ]
> Subject: Re: IEFBR14 question
>
> Some third-party software in use here at UPS has used this technique
> for years.  The assumption is perfectly valid.
>
> Think about it:  If an initiator allocates a migrated dataset
> specifically on behalf of IEFBR14 -- which cannot even open it, much
> less use it -- just to process a normal disposition of DELETE, why
> waste HSM resources and tie up the initiator while waiting for the
> recall to complete?  The O/S might just as well schedule an HDELETE and be 
> done with it.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Paul Gilmartin
> Sent: Tuesday, May 05, 2015 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IEFBR14 question
>
> On 2015-05-05, at 10:16, Greg Shirey wrote:
>
> > The O/S may never "use" the data set after the step runs, but
> > perhaps
> "using" the data set wasn't the point of running the step.   I'd prefer the
> O/S not make that assumption for me.
> >
> And yet, lately, the O/S makes such an assumption when the data set is
> migrated.  Yes, as R.S. says, you can turn it off.
> It should be possible to override it within a particular job, not
> system-wide.  OS/360 was not designed as a multi-user system.  Its
> descendants inherit that original sin.
>
> -- 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


This communication contains information which is confidential and may also be 
privileged. It is for the exclusive use of the intended recipient(s). If you 
are not the intended recipient(s), please note that any distribution, copying 
or use of this communication or the information in it is strictly prohibited. 
If you have received this communication in error, please notify the sender 
immediately and then destroy any copies of it.



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

Re: IEFBR14 question

[Scott Ford]

Paul,

I like that, why not or at the least provide a mechanism that works.

Regards,
Scott

On Wednesday, May 6, 2015, Scheuer, Paul  wrote:

> Sure! Can you drop them by Marcello 4406 around 8am?
>
> Sent from

my Android phone using TouchDown (www.nitrodesk.com)
>
> -Original Message-
> From: Dave Barry [00a5644c6d08-dmarc-requ...@listserv.ua.edu
> ]
> Received: Tuesday, 05 May 2015, 3:54PM
> To: IBM-MAIN@LISTSERV.UA.EDU  [IBM-MAIN@LISTSERV.UA.EDU
> ]
> Subject: Re: IEFBR14 question
>
> Some third-party software in use here at UPS has used this technique for
> years.  The assumption is perfectly valid.
>
> Think about it:  If an initiator allocates a migrated dataset specifically
> on behalf of IEFBR14 -- which cannot even open it, much less use it -- just
> to process a normal disposition of DELETE, why waste HSM resources and tie
> up the initiator while waiting for the recall to complete?  The O/S might
> just as well schedule an HDELETE and be done with it.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Paul Gilmartin
> Sent: Tuesday, May 05, 2015 12:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IEFBR14 question
>
> On 2015-05-05, at 10:16, Greg Shirey wrote:
>
> > The O/S may never "use" the data set after the step runs, but perhaps
> "using" the data set wasn't the point of running the step.   I'd prefer the
> O/S not make that assumption for me.
> >
> And yet, lately, the O/S makes such an assumption when the data set is
> migrated.  Yes, as R.S. says, you can turn it off.
> It should be possible to override it within a particular job, not
> system-wide.  OS/360 was not designed as a multi-user system.  Its
> descendants inherit that original sin.
>
> -- 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: Primary allocation of a dataset

[Staller, Allan]

That is *NOT NECESSARILY* the primary allocation. That is the *current*  
allocation of the 1st extent. This may have been changed by SMS, Allocation 
space-(xx,rlse) or other.
As was previously stated, once the dataset has been successfully created, the 
amount of primary space requested is no longer available.


> You will never be able to determine the original primary allocation 
> amount, because it is not recorded. When the primary allocation is 
> done, it can be done in one or more extents and adjacent secondary 
> extents can be merged together into 1 extent. Furthermore after close 
> of the dataset, idle space can be released. From that moment on, all 
> what is left is the status of the dataset at that moment, which is the 
> result of any or all of the above actions, but you cannot determine the 
> requested primary allocation from it.

The strange part is that TSO 3.2 option seems to be able to recreate this info. 
If I allocate a dataset with a recordlength and blocksize of 100 bytes, a 
primary allocation of 14 KB and a secondary allocation of 2KB it is reported as:

1st extent kilobytes: 14
Secondary kilobytes : 2

Current Allocation
Allocated kilobytes : 14
Allocated extents . : 1

The DSCBs in the VTOC contains a secondary allocation of 2K and an allocation 
in one extent of 2 tracks. Where did 3.2 find my primary allocation of 14K?


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

Re: Primary allocation of a dataset

[Roberto Halais]

I don't know if this is what the OP wants.

I have a rexx utility that uses: X = CALL LISTDSI(DSNAME DIRECTORY SMSINFO
NORECALL)

and I get back:

DSNAME==>  SYSPROG.CBT.FILE805.LIB
VOLSER==>  COS101
DSORG ==>  PO   TYPE ==>  PDS
RECFM ==>  FB   SEQ TYPE ==>
LRECL ==>  80
BLKSIZE   ==>  5600
DIR BLKS  ==>  10
USED DIR B==>  5
MEMBERS   ==>  29
ALLOC UNIT==>  BLOCK
ALLOC ==>  234
USED  ==>  180
USED PAGES==> PDSE USED 4K PAGES
EXTENTS   ==>  1
PRIMARY   ==>  234
SECONDARY ==>  58
UNIT  ==>  3390   Tracks/Cyl: 15  Blks/TRK: 9
CRE DATE  ==>  05/05/2015
REF DATE  ==>  05/06/2015
UPDATED   ==>  YES
SAF Prof  ==>  GENERIC

On Wed, May 6, 2015 at 8:11 AM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> You will never be able to determine the original primary allocation
> amount, because it is not recorded. When the primary allocation is done, it
> can be done in one or more extents and adjacent secondary extents can be
> merged together into 1 extent. Furthermore after close of the dataset, idle
> space can be released. From that moment on, all what is left is the status
> of the dataset at that moment, which is the result of any or all of the
> above actions, but you cannot determine the requested primary allocation
> from it.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Fred van der Windt
> Sent: 06 May, 2015 13:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Primary allocation of a dataset
>
> I want to retrieve the primary allocation of a dataset. Sofar I've used
> OBTAIN to retrieve the DCSBs for the dataset. The DSCB1 contains
> information about the secondary allocation size for the dataset but does
> not contain any information about the primary allocation. If the dataset
> had a primary allocation in tracks or cylinders I can retrieve the
> necessary information from the extent information in the DSCB1: the first
> extent can be converted back to tracks or cylinders and that should be the
> primary allocation.
>
> But how can one recreate the primary allocation if some other form was
> used, for instance an amount in blocks, records or KB or something like
> that? Is this documented anywhere?
>
> Fred!
> -
> ATTENTION:
> The information in this electronic mail message is private and
> confidential, and only intended for the addressee. Should you
> receive this message by mistake, you are hereby notified that
> any disclosure, reproduction, distribution or use of this
> message is strictly prohibited. Please inform the sender by
> reply transmission and delete the message without copying or
> opening it.
>
> Messages and attachments are scanned for all viruses known.
> If this message contains password-protected attachments, the
> files have NOT been scanned for viruses by the ING mail domain.
> Always scan attachments before opening them.
> -
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 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 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: Primary allocation of a dataset

[Fred van der Windt]

> You will never be able to determine the original primary allocation amount,
> because it is not recorded. When the primary allocation is done, it can be
> done in one or more extents and adjacent secondary extents can be merged
> together into 1 extent. Furthermore after close of the dataset, idle space can
> be released. From that moment on, all what is left is the status of the 
> dataset
> at that moment, which is the result of any or all of the above actions, but 
> you
> cannot determine the requested primary allocation from it.

The strange part is that TSO 3.2 option seems to be able to recreate this info. 
If I allocate a dataset with a recordlength and blocksize of 100 bytes, a 
primary allocation of 14 KB and a secondary allocation of 2KB it is reported as:

1st extent kilobytes: 14
Secondary kilobytes : 2

Current Allocation
Allocated kilobytes : 14
Allocated extents . : 1

The DSCBs in the VTOC contains a secondary allocation of 2K and an allocation 
in one extent of 2 tracks. Where did 3.2 find my primary allocation of 14K?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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

Re: Primary allocation of a dataset

[Vernooij, CP (ITOPT1) - KLM]

You will never be able to determine the original primary allocation amount, 
because it is not recorded. When the primary allocation is done, it can be done 
in one or more extents and adjacent secondary extents can be merged together 
into 1 extent. Furthermore after close of the dataset, idle space can be 
released. From that moment on, all what is left is the status of the dataset at 
that moment, which is the result of any or all of the above actions, but you 
cannot determine the requested primary allocation from it.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred van der Windt
Sent: 06 May, 2015 13:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Primary allocation of a dataset

I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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

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

Primary allocation of a dataset

[Fred van der Windt]

I want to retrieve the primary allocation of a dataset. Sofar I've used OBTAIN 
to retrieve the DCSBs for the dataset. The DSCB1 contains information about the 
secondary allocation size for the dataset but does not contain any information 
about the primary allocation. If the dataset had a primary allocation in tracks 
or cylinders I can retrieve the necessary information from the extent 
information in the DSCB1: the first extent can be converted back to tracks or 
cylinders and that should be the primary allocation.

But how can one recreate the primary allocation if some other form was used, 
for instance an amount in blocks, records or KB or something like that? Is this 
documented anywhere?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

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

does anyone here uses speedware report generator?

[Itschak Mugzach]

?

ITschak

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