subject:"STOW macro Location"

In 1009418597484101.wa.elardus.engelbrechtsita.co...@bama.ua.edu, on
11/15/2011
   at 04:56 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za
said:

Ok, I must be confusing (having too much decaying braincells :D )
STOW with something else which can destroy a PDS / PDSE directory if
used incorrectly.

 //   EXEC  PGM=IEBGENER
 //SYSUT1   DD  *
 FOO
 //SYSUT2   DD  DSN=SYS1.MACLIB,DISP=OLD
 //SYSINDD  DUMMY
 //SYSPRINT DD  SYSOUT=A

used to destroy the directory; the equiovalent in Rexx would as well.

Agreed, this is why other callable services are available to Rexx or
Assembler, Cobol, etc.

No. ISPF services are available for ISPF dialogs. I'm not aware of any
equivalent callable services for non-ISPF applications in Rexx.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In 7i53c7thv9cglid3773mjl4k778pvp3...@4ax.com, on 11/15/2011
   at 12:30 AM, Binyamin Dissen bdis...@dissensoftware.com said:

Incorrect.

Closer than your answer.

The mapping macro has a parameter to indicate whether the BLDL or
directory format is desired.

Not for PDSE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Paul Gilmartin

On Tue, 15 Nov 2011 09:08:25 -0500, Shmuel Metz (Seymour J.) wrote:

In 1009418597484101.wa.elardus.engelbrechtsita.co...@bama.ua.edu, on
11/15/2011 at 04:56 AM, Elardus Engelbrecht said:

Ok, I must be confusing (having too much decaying braincells :D )
STOW with something else which can destroy a PDS / PDSE directory if
used incorrectly.

 //   EXEC  PGM=IEBGENER
 //SYSUT1   DD  *
 FOO
 //SYSUT2   DD  DSN=SYS1.MACLIB,DISP=OLD
 //SYSINDD  DUMMY
 //SYSPRINT DD  SYSOUT=A
 
used to destroy the directory; the equiovalent in Rexx would as well.
 
Certainly so if Rexx does address ATTCHMVS IEBGENER.  If Rexx
uses EXECIO, it reports an error.  But this can be bypassed with
,DSORG=PS in the JCL.  (But I've tried this only to read the
directory, not to write it.)

Agreed, this is why other callable services are available to Rexx or
Assembler, Cobol, etc.

No. ISPF services are available for ISPF dialogs. I'm not aware of any
equivalent callable services for non-ISPF applications in Rexx.
 
Indirectly.  Rexx (even in batch, under IKJEFT*) can invoke ISPF to
use ISPF services.  I do it regularly.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location


On 11/15/2011 5:56 AM, Elardus Engelbrecht wrote:

To Binyamin Dissen and Shmuel Metz:

Ok, I must be confusing (having too much decaying braincells
:D ) STOW with something else which can destroy a PDS / PDSE
directory if used incorrectly.


Or perhaps you were thinking of STOW ,,,I ?

Re your comment on using members as sequential data sets, that's 
fine as far as it goes. But sometimes you need an alias, or more 
frequently user data for a member.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Rick Fochtman


---snip


Ok, I must be confusing (having too much decaying braincells :D ) STOW with 
something else which can destroy a PDS / PDSE directory if used incorrectly.

Please educate and correct me what that thing was which was discussed on 
IBM-MAIN. I remember that if you don't use the services correctly you can 
damage the directory which could render a PDS unusable.

Thanks Binyamin and Shmuel for your help. 
 


---unsnip
Just my two cents' worth: trying to IEBGENER a member into a PDS and 
forgetting to specify the member name on the SYSUT2 DD statement will 
certainly clobber a PDS very effectively by over-writing the directory.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Bill Fairchild

STOW does not ever operate by hosing the directory.  It assumes the directory 
exists and is valid.  It finds the proper place in the directory for the member 
being STOWED and manipulates the directory as per the STOW parameters (add, 
delete, etc.).   If the directory has already been hosed before STOW is 
invoked, STOW will fail.  This is probably what Shmuel meant when he 
dogmatically stated that the services, i.e., STOW, cannot be used or misused to 
clobber a directory.

Neither is a directory clobbered because of any failure in IEBGENER.  The 
clobbering occurs because the user is invoking some kind of access method to 
OPEN a file for output, the file is a PDS, and the user has not specified a 
member name.  I think the real culprit is the lack of user-friendliness in 
whatever OPEN executor module is blindly following the user's request to 
overwrite an entire file without checking for certain file types for which 
overwriting the whole file might not be appropriate.  This module, whichever 
one it is, could easily check if the user is attempting to use any access 
method other than BPAM to write into a PDS and has not specified a member name, 
and, if so, then this module should return an error condition.  Perhaps IBM 
reasoned that if a user really, really, seriously wants to do something this 
strange, they should let him.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Rick Fochtman
Sent: Tuesday, November 15, 2011 2:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: STOW macro Location

---snip

Ok, I must be confusing (having too much decaying braincells :D ) STOW with 
something else which can destroy a PDS / PDSE directory if used incorrectly.

Please educate and correct me what that thing was which was discussed on 
IBM-MAIN. I remember that if you don't use the services correctly you can 
damage the directory which could render a PDS unusable.

Thanks Binyamin and Shmuel for your help. 
  

---unsnip
Just my two cents' worth: trying to IEBGENER a member into a PDS and forgetting 
to specify the member name on the SYSUT2 DD statement will certainly clobber a 
PDS very effectively by over-writing the directory.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Jim Thomas

One small point if I may ... and perhaps this has been stated and if so, my
apologies .. 
STOW (if used generally) will ONLY 'UPDATE' the directory and then too, only
if the DS has
been OPENed OUTPUT, OUTIN or UPDAT...


Kind Regards

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Bill Fairchild
Sent: Tuesday, November 15, 2011 6:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: STOW macro Location

STOW does not ever operate by hosing the directory.  It assumes the
directory exists and is valid.  It finds the proper place in the directory
for the member being STOWED and manipulates the directory as per the STOW
parameters (add, delete, etc.).   If the directory has already been hosed
before STOW is invoked, STOW will fail.  This is probably what Shmuel meant
when he dogmatically stated that the services, i.e., STOW, cannot be used or
misused to clobber a directory.

Neither is a directory clobbered because of any failure in IEBGENER.  The
clobbering occurs because the user is invoking some kind of access method to
OPEN a file for output, the file is a PDS, and the user has not specified a
member name.  I think the real culprit is the lack of user-friendliness in
whatever OPEN executor module is blindly following the user's request to
overwrite an entire file without checking for certain file types for which
overwriting the whole file might not be appropriate.  This module, whichever
one it is, could easily check if the user is attempting to use any access
method other than BPAM to write into a PDS and has not specified a member
name, and, if so, then this module should return an error condition.
Perhaps IBM reasoned that if a user really, really, seriously wants to do
something this strange, they should let him.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Rick Fochtman
Sent: Tuesday, November 15, 2011 2:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: STOW macro Location

---snip

Ok, I must be confusing (having too much decaying braincells :D ) STOW with
something else which can destroy a PDS / PDSE directory if used incorrectly.

Please educate and correct me what that thing was which was discussed on
IBM-MAIN. I remember that if you don't use the services correctly you can
damage the directory which could render a PDS unusable.

Thanks Binyamin and Shmuel for your help. 
  

---unsnip-
---
Just my two cents' worth: trying to IEBGENER a member into a PDS and
forgetting to specify the member name on the SYSUT2 DD statement will
certainly clobber a PDS very effectively by over-writing the directory.

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1869 / Virus Database: 2092/4619 - Release Date: 11/15/11

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Shane

On Wed, 16 Nov 2011 00:38:34 + Bill Fairchild wrote:

 Perhaps IBM reasoned that if a user really, really,
 seriously wants to do something this strange, they should let him.

Your gun, your foot ...
Maybe users in bygone times were made of sterner stuff and prepared to
take responsibility for their own actions.
Maybe IBM never put any thought into it at all.

Who knows.

Shane ..

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location


On 11/15/2011 7:38 PM, Bill Fairchild wrote:

I think the real culprit is the lack of user-friendliness in
whatever OPEN executor module is blindly following the user's
request to overwrite an entire file without checking for
certain file types for which overwriting the whole file might
not be appropriate.  This module, whichever one it is, could
easily check if the user is attempting to use any access
method other than BPAM to write into a PDS and has not
specified a member name, and, if so, then this module should
return an error condition.  Perhaps IBM reasoned that if a
user really, really, seriously wants to do something this
strange, they should let him.


IBM was in a big rush to get OS/360 out the door, and may not 
have considered that worth worrying about. The attitude seems 
endemic - just look at all the commands handled by the 
communications task that let the operator set and change things, 
with absolutely no feedback on the current status.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread John Gilmore

Shane's point is an important one.

In a private email to Bill earlier this evening I confessed that I had
(more than once) opened a PDS as a sequential data set using BSAM in
order to read a (mangled) directory.

On the occasion I remember best I got the information I needed without
[further] damaging the PDS, but I would not/do not think it reasonable
to complain to IBM after one got/gets into trouble bending the rules
because there was no policeman in place to prevent me from doing so.

Would I discourage a novice from doing this sort of thing?  Yes, but
Do what I say, not what I do is not always unreasonable, although it
is of course always perceived to be so.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location


On 11/15/2011 8:41 PM, Shane wrote:

Maybe users in bygone times were made of sterner stuff and prepared to
take responsibility for their own actions.


Not necessarily - we operated in a completely different 
environment. There were so few manuals that it was possible to 
read all of them, as well as their updates, and if you didn't 
understand something, it was easier to run tests until you 
determined what was happening. Stand-alone machine time was 
easier to get, and source code was available on microfiche and 
tape.



Maybe IBM never put any thought into it at all.


My guess that it was a typical IBM process - technical staff 
raises an issue, and a bean counter shoots it down for lack of a 
business case. After all, everyone backs up their files, right?


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-15 Thread Paul Gilmartin

On Tue, 15 Nov 2011 20:51:25 -0500, Gerhard Postpischil wrote:

On 11/15/2011 7:38 PM, Bill Fairchild wrote:
 I think the real culprit is the lack of user-friendliness in
 whatever OPEN executor module is blindly following the user's
 request to overwrite an entire file without checking for
 certain file types for which overwriting the whole file might
 not be appropriate.  This module, whichever one it is, could
 easily check if the user is attempting to use any access
 method other than BPAM to write into a PDS and has not
 specified a member name, and, if so, then this module should
 return an error condition.  Perhaps IBM reasoned that if a
 user really, really, seriously wants to do something this
 strange, they should let him.

IBM was in a big rush to get OS/360 out the door, and may not
have considered that worth worrying about. The attitude seems
endemic - ...
 
Resource constraint, whether development schedule or REGION
to accommodate the executable code is a plausible explanation.

But that was then; this is the 21st Century.  A reasonable
compromise which allows the user to do something this strange
would be to allow the operation if the user overrides to DSORG=PS,
in either JCL or SVC 99 arguments but forbid it for DSORG=PO.
(It's probably a bad idea to permit this override for PDSE.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In 1149164858762620.wa.paulgboulderaim@bama.ua.edu, on
11/15/2011
   at 09:39 AM, Paul Gilmartin paulgboul...@aim.com said:

Indirectly.

Right answer to wrong question.

Rexx (even in batch, under IKJEFT*) can invoke ISPF to
use ISPF services.

You're still talking about ISPF services, not general Data Management
services.

I do it regularly.

Only you and 10^10 other people.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In 2016114137.2cca11dd@xpfs, on 11/16/2011
   at 11:41 AM, Shane ibm-m...@tpg.com.au said:

Maybe IBM never put any thought into it at all.

That would certain account for absolute track 0 not available when
you forgot a SPACE keyword for a new data set.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In
CAPD5F5qvUFtSVX3WoWvHNmTfPObydZuusnbx+MV0mAWS=fq...@mail.gmail.com,
on 11/15/2011
   at 09:01 PM, John Gilmore johnwgilmore0...@gmail.com said:

Would I discourage a novice from doing this sort of thing?  Yes, but
Do what I say, not what I do is not always unreasonable, although
it is of course always perceived to be so.

FSVO what I do

If what you do is to only do, carefully, the things that you fully
understand and if what you say is to not do it unless you fully
understand it then I don't see a conflict.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location


On 11/15/2011 9:24 PM, Paul Gilmartin wrote:

Resource constraint, whether development schedule or REGION
to accommodate the executable code is a plausible explanation.


All of the OPEN code was in a type 4 SVC, with a 1K constraint 
on each transient. While OPEN had a lot of overlays, it didn't 
exhaust all valid names, and if necessary, an extra one for the 
member name check could have been added. The REGION doesn't come 
into it.



But that was then; this is the 21st Century.  A reasonable
compromise which allows the user to do something this strange
would be to allow the operation if the user overrides to DSORG=PS,
in either JCL or SVC 99 arguments but forbid it for DSORG=PO.
(It's probably a bad idea to permit this override for PDSE.)


Agreed.

Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

STOW macro Location

2011-11-14 Thread jagadishan perumal

Hi,

Could anyone please point me to the STOW macro Library location in Z/os.
Where I can see the Assembler codes Responsible for PDS/PDSE directory
update by STOW.

I referred this Link :
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
but
Not able to find any information on its Code.

Regards,
Jags

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread Lizette Koehler

  Hi,
 
  Could anyone please point me to the STOW macro Library location in Z/os.
  Where I can see the Assembler codes Responsible for PDS/PDSE directory
  update by STOW.
 
  I referred this Link :
  http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com
  .ibm.zos.r9.ie
  ab200/destow.htm
  but
  Not able to find any information on its Code.
 
  Regards,
  Jags
 
 
 I was not aware that the STOW would also work on a PDSE.  A PDSE is a not
like a
 PDS in structure.  So I am not clear on how the STOW would work for a
PDSE.
 
 What specifically are you trying to do with the STOW macro?
 
 It would be helpful to know what problem you are trying to solve so that
we can
 provide more accurate answers.
 


I retract what I stated about STOW and PDSE. I did some research and found
that you probably need to read the following manual

z/OS DFSMS Using Data Sets  SC26-7410-09


Still provide the information on what you are trying to accomplish.  It will
reduce the number of guesses to just what you are looking for.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread Lizette Koehler

 Hi,
 
 Could anyone please point me to the STOW macro Library location in Z/os.
 Where I can see the Assembler codes Responsible for PDS/PDSE directory
update by
 STOW.
 
 I referred this Link :

http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.z
os.r9.ie
 ab200/destow.htm
 but
 Not able to find any information on its Code.
 
 Regards,
 Jags


I was not aware that the STOW would also work on a PDSE.  A PDSE is a not
like a PDS in structure.  So I am not clear on how the STOW would work for a
PDSE.

What specifically are you trying to do with the STOW macro?

It would be helpful to know what problem you are trying to solve so that we
can provide more accurate answers.


Within the book you cite is the following

PDSE directory entry returned by DESERV (SMDE data area)

z/OS V1R9.0 MVS Program Management Advanced Facilities
SA22-7644-07

This section describes the format of a PDSE entry returned by the DESERV
macro. This is the SMDE data area, which is mapped by the IGWSMDE mapping
macro. The formats shown here are specific to PDSE program libraries.

The system managed directory entry (SMDE) can represent either a program
object in a PDSE or a load module in a PDS. The SMDE also represents both
primary (member) entries and aliases. The SMDE consists of several sections
that appear depending on the type of directory entry being provided:

* Primary entry for a load module: BASIC+NAME+PMAR (including PMARR)
* Alias entry for a load module: BASIC+NAME+PNAME+PMAR (including PMARR)
* Primary entry for a program object: BASIC+NAME+TOKEN+PMAR (including
PMARL)
* Alias entry for a program object: BASIC+NAME+PNAME+TOKEN+PMAR
(including PMARL)
Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread Binyamin Dissen

On Mon, 14 Nov 2011 15:31:46 +0530 jagadishan perumal jagadish...@gmail.com
wrote:

:Could anyone please point me to the STOW macro Library location in Z/os.

SYS1.MACLIB

:Where I can see the Assembler codes Responsible for PDS/PDSE directory
:update by STOW.

:I referred this Link :
:http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
:but
:Not able to find any information on its Code.

What are you trying to do?

How familiar are you with BSAM?

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread J R

I'm not in my office right now and don't have MVS handy ...

Does this information help?
MVS Diagnosis:
Referencehttp://publibz.boulder.ibm.com/epubs/pdf/iea2v2c0.pdfSVC 21 (0A15)
STOW macro - is type 3, gets no lock.
Calls module IGC0002A.
GTF data is:
R15 No applicable data.
R0 Address of the parameter list.
R1 Address of the associated DCB.
The sign of R0 and R1 indicate the directory action STOW is to take:
R0 R1 Action.
+ + ADD.
+ - REPLACE.
- + DELETE.
- - CHANGE.
0 + INIT.
DDNAME name of the associated DD statement.
PLIST The parameter list is of variable length, depending on the directory
action
being performed: For ADD or REPLACE — 12 bytes of the parameter list
will be dumped. The first 8 bytes contain the member name; the next 3
bytes contain the member's TTR; and the next byte contains the alias bit,
number of TTRNs in the user data area, and the length of the user data
area in halfwords. (The user data area varies from 0-62 bytes in length and
does not appear.) For DELETE — 8 bytes long and contains the member
name or alias of the PDS directory entry being acted upon. For CHANGE
— 16 bytes long; first 8 bytes contain the old member name or alias;
second 8 bytes contain the new member name or alias. Date: Mon, 14 Nov 2011
15:31:46 +0530
From: jagadish...@gmail.com
Subject: STOW macro Location
To: IBM-MAIN@bama.ua.edu

Hi,

Could anyone please point me to the STOW macro Library location in Z/os.
Where I can see the Assembler codes Responsible for PDS/PDSE directory
update by STOW.

I referred this Link :
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
but
Not able to find any information on its Code.

Regards,
Jags

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread John McKown

Most of the macros that are z/OS BCP (Base Control Program) related
reside either in SYS1.MACLIB or SYS1.MODGEN. STOW is in SYS1.MACLIB. 

On Mon, 2011-11-14 at 15:31 +0530, jagadishan perumal wrote:
 Hi,
 
 Could anyone please point me to the STOW macro Library location in Z/os.
 Where I can see the Assembler codes Responsible for PDS/PDSE directory
 update by STOW.
 
 I referred this Link :
 http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
 but
 Not able to find any information on its Code.
 
 Regards,
 Jags
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
-- 
John McKown
Maranatha! 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread Elardus Engelbrecht

jagadishan perumal wrote:

Could anyone please point me to the STOW macro Library location in Z/os. Where
I can see the Assembler codes Responsible for PDS/PDSE directory update by
STOW.

Why? What are you trying to achieve? One little error and you whole PDS/PDSE is
destroyed and it is goodbye to your nice PDS/PDSE ...

This macro is not for faint hearted and details for usage of that macro are
somewhat detailed.

Is it perhaps possible to use other services instead? Like LMMADD, LMMFIND,
LMMDEL, LMMREN, LMMREP, etc.

Or just use REXX!!! :-D

What I use, if applicable and needed/suitable/etc, I refer to PDS members via
JCL DD statements, but refer to them as sequential datasets.

Like this quick and dirty example (together with standard OPEN, PUT, GET and
CLOSE macros to process records):

INPUTDCB DSORG=PS,MACRF=GM,DDNAME=INPUT,EODAD=EOF
OUTPUT DCB DSORG=PS,MACRF=PM,DDNAME=OUTPUT

I referred this Link :
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
but Not able to find any information on its Code.

There are two books with some sources:

z/OS V1R12 DFSMS Using Data Sets
z/OS V1R12.0 DFSMS Macro Instructions for Data Sets

AFAIK after my quick browsing, it appears to me the source codes are just mere
snippets and may need a lot of reworking to your need.

There are some source codes available on CBT Tape if you can search this
wonderful resource.

Groete / Greetings
Elardus Engelbrecht

Re: STOW macro Location

2011-11-14 Thread Binyamin Dissen

On Mon, 14 Nov 2011 07:26:14 -0600 Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:

:jagadishan perumal wrote:

:Could anyone please point me to the STOW macro Library location in Z/os.
Where I can see the Assembler codes Responsible for PDS/PDSE directory update
by STOW.

:Why? What are you trying to achieve? One little error and you whole PDS/PDSE
is destroyed and it is goodbye to your nice PDS/PDSE ...

Thru a STOW macro? Other than the PDS(E?) clear, all STOW can affect is the
named member.

:This macro is not for faint hearted and details for usage of that macro are
somewhat detailed.

It is not THAT special.

:Is it perhaps possible to use other services instead? Like LMMADD, LMMFIND,
LMMDEL, LMMREN, LMMREP, etc.

Adds a requirement of running under TSO and ISPF.

:Or just use REXX!!! :-D

Depends on what the requirements are.

:What I use, if applicable and needed/suitable/etc, I refer to PDS members via
JCL DD statements, but refer to them as sequential datasets.

:Like this quick and dirty example (together with standard OPEN, PUT, GET and
CLOSE macros to process records):
:
:INPUTDCB DSORG=PS,MACRF=GM,DDNAME=INPUT,EODAD=EOF
:OUTPUT DCB DSORG=PS,MACRF=PM,DDNAME=OUTPUT
:
:
:I referred this Link :
:http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm
:but Not able to find any information on its Code.
:
:There are two books with some sources:
:
: z/OS V1R12 DFSMS Using Data Sets
: z/OS V1R12.0 DFSMS Macro Instructions for Data Sets
:
:AFAIK after my quick browsing, it appears to me the source codes are just
mere snippets and may need a lot of reworking to your need.
:
:There are some source codes available on CBT Tape if you can search this
wonderful resource.
:
:Groete / Greetings
:Elardus Engelbrecht
:
:--
:For IBM-MAIN subscribe / signoff / archive access instructions,
:send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
:Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Re: STOW macro location

2011-11-14 Thread John Gilmore

reposted from the assembler list, where I put it first in error:

I suspect that what Jagadishan wants to know is where, physically, in
what crypto-DASD PDS[E], the STOW macro definition is to be found.

 Is it, say in SYS!.MACLIB?  Elsewhere with other data-management macros?

Such questions are common, too common, here.

The LIBMAC assembler option will yield a copy of STOW in an HLASM
listing if STOW is used in the source program assembled; and this is
perhaps the easiest way for a novice to obtain a copy of it for study.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In
canhhcytp0vz+uzu3r-ibjqejw4t8v-kyoahkuyzdk_u0rjm...@mail.gmail.com,
on 11/14/2011
   at 03:31 PM, jagadishan perumal jagadish...@gmail.com said:

Could anyone please point me to the STOW macro Library location in
Z/os.

SYS1.MACLIB.


Where I can see the Assembler codes Responsible for PDS/PDSE
directory update by STOW.

That's not in the macro, which is just an interface. The actual STOW
object code is not available to customers.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In 012b01cca2bd$61013710$2303a530$@mindspring.com, on 11/14/2011
   at 06:05 AM, Lizette Koehler stars...@mindspring.com said:

I was not aware that the STOW would also work on a PDSE.

How could it not? There would be no upward compatibility without it.

PDSE directory entry returned by DESERV (SMDE data area)

Also PDS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

In 5909987196980741.wa.elardus.engelbrechtsita.co...@bama.ua.edu, on
11/14/2011
   at 07:26 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za
said:

Why? What are you trying to achieve? One little error and you whole
PDS/PDSE is destroyed and it is goodbye to your nice PDS/PDSE ...

What gives you that idea? I'm all for warning newbies away from
dangerous facilities, but STOW isn't one of them.

This macro is not for faint hearted and details for usage of that
macro are somewhat detailed.

Actually, it's a fairly simple service.

Is it perhaps possible to use other services instead?

There is no alternative Data Management service unless you RYO, which
would be dangerous.

Like LMMADD, LMMFIND, LMMDEL, LMMREN, LMMREP, etc.

Those are ISPF.

Or just use REXX!!! :-D

That would be far more dangerous than using STOW. Rexx does not have
PDS support.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread Bill Fairchild

All that the STOW macro itself does is build the parameter list that is passed 
to SVC 21.  The parameter list is described in  chapter 4 of the book MVS 
Diagnosis:  Reference, GA22-7588-10 (vintage April, 2008; the version that I 
have).

The Assembler code that updates the PDS or PDSE directory to correspond with 
the parameter list request is not currently available to customers.

The results of a STOW macro's having executed can be seen in the mapping macro 
IHAPDS, which maps the directory entry for a PDS or a PDSE.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Monday, November 14, 2011 11:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: STOW macro Location

In
canhhcytp0vz+uzu3r-ibjqejw4t8v-kyoahkuyzdk_u0rjm...@mail.gmail.com,
on 11/14/2011
   at 03:31 PM, jagadishan perumal jagadish...@gmail.com said:

Could anyone please point me to the STOW macro Library location in 
Z/os.

SYS1.MACLIB.


Where I can see the Assembler codes Responsible for PDS/PDSE directory 
update by STOW.

That's not in the macro, which is just an interface. The actual STOW object 
code is not available to customers.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: STOW macro Location

2011-11-14 Thread tony's netbook

On 11/14/2011 7:26 AM, Elardus Engelbrecht wrote:

jagadishan perumal wrote:

Could anyone please point me to the STOW macro Library location in Z/os. Where
I can see the Assembler codes Responsible for PDS/PDSE directory update by STOW.

Why? What are you trying to achieve? One little error and you whole PDS/PDSE is
destroyed and it is goodbye to your nice PDS/PDSE ...

This macro is not for faint hearted and details for usage of that macro are
somewhat detailed.

Is it perhaps possible to use other services instead? Like LMMADD, LMMFIND,
LMMDEL, LMMREN, LMMREP, etc.

Or just use REXX!!! :-D

What I use, if applicable and needed/suitable/etc, I refer to PDS members via
JCL DD statements, but refer to them as sequential datasets.

Like this quick and dirty example (together with standard OPEN, PUT, GET and
CLOSE macros to process records):

INPUTDCB DSORG=PS,MACRF=GM,DDNAME=INPUT,EODAD=EOF
OUTPUT DCB DSORG=PS,MACRF=PM,DDNAME=OUTPUT

I referred this Link :
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/index.jsp?topic=/com.ibm.zos.r9.ieab200/destow.htm

but Not able to find any information on its Code.

There are two books with some sources:

z/OS V1R12 DFSMS Using Data Sets
z/OS V1R12.0 DFSMS Macro Instructions for Data Sets

AFAIK after my quick browsing, it appears to me the source codes are just mere
snippets and may need a lot of reworking to your need.

There are some source codes available on CBT Tape if you can search this
wonderful resource.

Groete / Greetings
Elardus Engelbrecht

Reminds me of a time years ago when my young son came up from the
basement workshop and asked

Gee dad, what else do you need sawed in half?

Re: STOW macro Location