STOW macro Location
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
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
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
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
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
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: IBM-MAIN Digest - 12 Nov 2011 to 13 Nov 2011 (#2011-317)
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of IBM-MAIN automatic digest system Sent: Monday, November 14, 2011 12:00 AM To: IBM-MAIN@bama.ua.edu Subject: IBM-MAIN Digest - 12 Nov 2011 to 13 Nov 2011 (#2011-317) -- 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
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 -- 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 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. -- 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: 3270 archaeology (Was: TSO SCREENSIZE)
On Fri, 11 Nov 2011 15:34:21 -0500, Shmuel Metz (Seymour J.) wrote: You didn't have the STC (later STK) ... Actually, it was never STK during the independent existence of Storage Technology Corporation. The approved branding was StorageTek, and employees were instructed that STK was an NYSE stock ticker symbol, not to be used to identify the company in either external or external communications. Predictably, some StorageTek employes were careless and misused STK, even as some IBM employees have carelessly misused USS. I hope that you are fair in pedantry, recognizing that neither informal use constitutes official approval. Later, under Sun and Oracle ownership, employees and management have adopted the casual use with no fear of retribution. -- 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: The IBM Displays Memory Lane
In 4ebf9230.4030...@ldworen.net, on 11/13/2011 at 01:47 AM, Leonard D Woren ibm-ma...@ldworen.net said: Otherwise the 2250 was ignored because of the keyboard which could most charitably be described as clunky, even by 1973 standards. Well, the 360/91 itself could most charitably be described as clunky, even by 1973 standards. It was the same mechanical key-interlock keyboard as on the 2741 (?), where pressing a key pushed a bunch of machinery around inside the keyboard to prevent you from pressing two keys at once. As opposed to the 3277, where striking two keys in rapid succession lead to transposition if you released the second before releasing the first, at least in World Trade. Interestingly enough, MVT supported using the light pen to click on the MCS console for the functions of K D,F and K E,D, and I have a really vague recollection that there were numbers you could click on for the equivalent of PFK-assigned commands. Documented. As I recall, some of that was there before DIDOCS. -- 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
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: HSM Journal dataset is almost full
yes, every hsm instance sharing the journal dataset must be put in emergency mode (1), and also be stopped (3). Walter Marguccio Walter, very kind of you. I will go it this weekend before we IPL with the new time here in the US. We ran into problems. We put HSM in emergency in 3 LPARS (all of them sharing HSM). We ran the BACKVOL command in the main LPAR. Then, we stopped HSM in all 3 LPARS. But, for some reason, in the main LPAR, HSM would restart automatically everytime we stopped it. So I could not drop the existing Journal to switch to a bigger one. The procedure we followed: F DFSMSHSM, SETSYS EMERGENCY (in all 3 LPARS) F DFSMSHSM, BACKVOL CONTROLDATASETS (in main LPAR) F DFSMSHSM, STOP (in al 3 LPARS) But then we noticed that in the main LPAR, DFSMSHSM would just start by itself. I could not switch to a bigger Journal file so we issued the S DFSMSHSM command in the remaining 2 LPARS. Why is DFSMSHSM re-starting by itself? We successfully took DFSMSHSM down in the main LPAR earlier that day and it would stay down. Is the emergency request creating a situation where at least one of the LPARs must be running HSM? -- 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: HSM Journal dataset is almost full
Check with your automation folks. Thank You, Dave O'Brien NIH Contractor From: Uriel Carrasquilla [uriel.carrasqui...@mail.mcgill.ca] Sent: Monday, November 14, 2011 12:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: HSM Journal dataset is almost full yes, every hsm instance sharing the journal dataset must be put in emergency mode (1), and also be stopped (3). Walter Marguccio Walter, very kind of you. I will go it this weekend before we IPL with the new time here in the US. We ran into problems. We put HSM in emergency in 3 LPARS (all of them sharing HSM). We ran the BACKVOL command in the main LPAR. Then, we stopped HSM in all 3 LPARS. But, for some reason, in the main LPAR, HSM would restart automatically everytime we stopped it. So I could not drop the existing Journal to switch to a bigger one. The procedure we followed: F DFSMSHSM, SETSYS EMERGENCY (in all 3 LPARS) F DFSMSHSM, BACKVOL CONTROLDATASETS (in main LPAR) F DFSMSHSM, STOP (in al 3 LPARS) But then we noticed that in the main LPAR, DFSMSHSM would just start by itself. I could not switch to a bigger Journal file so we issued the S DFSMSHSM command in the remaining 2 LPARS. Why is DFSMSHSM re-starting by itself? We successfully took DFSMSHSM down in the main LPAR earlier that day and it would stay down. Is the emergency request creating a situation where at least one of the LPARs must be running HSM? -- 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: Data Areas?
In 132176.64681.yahoomail...@web161406.mail.bf1.yahoo.com, on 11/13/2011 at 02:11 PM, Ed Gould ps2...@yahoo.com said: That was a little bit before my time. Is there a possibility you could give a short paragraph or so on a stage 1 or (whatever it was called became a system), please? There are three different sets of tapes involved here: 1. A dump of a starter system with a documented set of predefined I/O addresses. It was intended only for doing the initial sysgen. 2. The install tape, containing a dump of the distribution library (DLIB) volume. Mostly load module libraries, with several f macro libraries. 3. Optional source tape, containing source code for programs shipped as load modules. Generally the first file on set of source tapes would be a private macro library. The sysgen manual described calling the macros for stage 1. You specified, e.g., the control program scheduler, optional utilities and I/O configuration, then assembled[1] using the macro definitions in SYS1.AGENLIB. The output was a stage 2 jobstream, which copied libraries from DLIB to target, assembled modules using SYS1.AMACLIB and SYS1.AMODGEN, link edited modules and ran a few miscellaneous utilities. [1] The stage 1 macros didn't generate any actual code, just PUNCH statements. -- 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 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: 3270 archaeology (Was: TSO SCREENSIZE)
In 6332589144814230.wa.paulgboulderaim@bama.ua.edu, on 11/14/2011 at 09:40 AM, Paul Gilmartin paulgboul...@aim.com said: Actually, it was never STK during the independent existence of Storage Technology Corporation. Ah, so! Thanks. I had been told that they changed the name due to a trademark infringement complaint. -- 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: Data Areas?
I sort of think I remember that the IOVT was added after OCO was in effect. I can't find any mention of the IOVT in my 1980s-vintage IOS logic manuals. One other possible source would be TMON/MVS. It has a control block storage display function that displays storage contents under control of a DSECT that maps the storage it is displaying. TMON/MVS may have an internal DSECT for the IOVT, but, if so, it would probably not be complete or up-to-date. If there is such a DSECT in TMON/MVS, I would probably be the person who created it from other sources and guesswork. One example is that we know that the IOVT + offset 24 points to the CDA, whatever that is, as was mentioned in another post in this thread. If enough clues like that could be garnered, a rudimentary DSECT mapping of the IOVT could have been built up. I just don't remember now whether I did that or not 22+ years ago. Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Horein Sent: Saturday, November 12, 2011 12:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Data Areas? Thanks for the tip! I did pass along the IPCS command LISTEDT DETAIL to the DASD guy the other day, but I'm not sure if that was a usable solution. On Nov 11, 2011 9:41 PM, Tony Harminc t...@harminc.net wrote: On 11 November 2011 19:56, Steve Horein steve.hor...@gmail.com wrote: I see. So while not imposs... It can be so, but it can also be educational and even at times, fun. Ordinarily it is unwise to build anything that matters on a base of undocumented and unsupported control blocks, but there are times when you just really need to know. One popular source (heh) for otherwise undocumented control block information is the mappings supplied for use by IPCS. These are in SYS1.MIGLIB (and possibly other places for some products), and the format is described in the IPCS Customization book. Well, there are at least two kinds of things in this dataset: executable routines of various sorts, and control block models defined using the BLS... macros described in the book. While I don't suggest trying to reverse-engineer any programs you may find, you can use IPCS itself to invoke the control block models using the CBF command. Many of these are invoked for you when you run component analysis (option 2.6), or the supplied VERBEXIT commands, and even the output from these analyses often provides useful information. In many cases you can use CBF to format an area of storage that is not the real thing, e.g. is just a piece of your own private area, using a formatting module with a name suggested by the component prefix you are interested in. Obviously the content of the output will be largely meaningless, but the field names may be useful to know. Need I repeat the warning to avoid relying on anything you may discover for any sort of production use, or indeed anything beyond satisfying your own curiosity? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu w... -- 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
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
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
NIP console message traffic logging / recording+
Hi, We have our z/OS NIP consoles (OSA ICC) in a remote data center. On an occasional initial part of IPL (NIP time) trouble we have a difficulty in reviewing the message traffic due to a (typically) re-IPL (after some correction and/or an IPL re-attempt, all messages are lost). Did somebody invent / figured out a way to record / log the NIP time messages for either immediate (a real time transport over a network to some host?) or later remote retrieval? A Standalone Dump would likely have a message record/log however we do not perform it routinely. Most of the time a correction is made and a z/OS host is re-IPLed. A solution would likely have be external to z/OS via either 3270 emulator (our OSA ICC consoles use PCOMM 3270 emulator) or other means. Thank you... -- 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: NIP console message traffic logging / recording+
Remove all consoles from the NIP definition in the IOCP, and watch the messages come across the HMC console. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jakubek, Jan Sent: Monday, November 14, 2011 2:34 PM To: IBM-MAIN@bama.ua.edu Subject: NIP console message traffic logging / recording+ Hi, We have our z/OS NIP consoles (OSA ICC) in a remote data center. On an occasional initial part of IPL (NIP time) trouble we have a difficulty in reviewing the message traffic due to a (typically) re-IPL (after some correction and/or an IPL re-attempt, all messages are lost). Did somebody invent / figured out a way to record / log the NIP time messages for either immediate (a real time transport over a network to some host?) or later remote retrieval? A Standalone Dump would likely have a message record/log however we do not perform it routinely. Most of the time a correction is made and a z/OS host is re-IPLed. A solution would likely have be external to z/OS via either 3270 emulator (our OSA ICC consoles use PCOMM 3270 emulator) or other means. Thank you... This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: NIP console message traffic logging / recording+
... Dave Jousma ... Remove all consoles from the NIP definition in the IOCP, and watch the messages come across the HMC console. These are desperate, last resort means, difficult on a production host, in case a problem can't be otherwise resolved. In such a case we'd likely do a SAD. Typically we do not have a remote access to the HMC. Thank you... -- 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: NIP console message traffic logging / recording+
For my sandbox system, I don't have any NIPCONS. Why bother? I always IPL it from the HMC Web interface. I use the system messages functionality which looks a bit like an old line console. I get all the IPL and NIP messages there. I, personally, see no need for NIPCONS. It's not as if an operator does the IPLs any more. We no longer have __any__ operators. Our production control people are quite smart and they use SMCS consoles at their desk. Most of the people in the NOC, where the NIPCONS are located, are Windows-weenies who don't know anything about running z/OS. I would like to eliminate the NIPCONS from our production images too. But everybody else on my team actually drives in to work to do any IPL. And wants those screens for some reason. Each to his own, I guess. I have an alternate loadparm that I can use which has a different IOCDS specified with no NIPCONS in it so that when I IPL, if I don't get any messages in a reasonable time, I can reIPL with that and watch the IPL/NIP messages on the HMC system messages screen. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jakubek, Jan Sent: Monday, November 14, 2011 1:34 PM To: IBM-MAIN@bama.ua.edu Subject: NIP console message traffic logging / recording+ Hi, We have our z/OS NIP consoles (OSA ICC) in a remote data center. On an occasional initial part of IPL (NIP time) trouble we have a difficulty in reviewing the message traffic due to a (typically) re-IPL (after some correction and/or an IPL re-attempt, all messages are lost). Did somebody invent / figured out a way to record / log the NIP time messages for either immediate (a real time transport over a network to some host?) or later remote retrieval? A Standalone Dump would likely have a message record/log however we do not perform it routinely. Most of the time a correction is made and a z/OS host is re-IPLed. A solution would likely have be external to z/OS via either 3270 emulator (our OSA ICC consoles use PCOMM 3270 emulator) or other means. Thank you... -- 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
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 -- 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 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? -- 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 77142d37c0c3c34da0d7b1da7d7ca3433225e...@nwt-s-mbx2.rocketsoftware.com, on 11/14/2011 at 06:06 PM, Bill Fairchild bfairch...@rocketsoftware.com said: 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. No. It maps the directory entry used by the interface, but not what is actually stored in a PDSE. As I recall it is almost the same as the the directory entry in a PDS, but has some additional information. e.g., concatenation number. -- 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: 3270 archaeology (Was: TSO SCREENSIZE)
On January 14 1970, DPD rolls out IBM DATA/360, a new program product that simulates the functions of the IBM 29 keypunch and IBM 59 verifier to enter data from an IBM 2260 display station to an IBM 2311 or 2314 direct access storage device, bypassing punched cards; we used this w/2270-1 s a few years after this. product was renamed but google can't find the new name. I remembered ENTRY/370 but not found. Our greatest danger in life is in permitting the urgent things to crowd out the important. - Charles E. Hummel Efforts and courage are not enough without purpose and direction. - John F. Kennedy The probability of error in a change is inversely proportional to the size of the change. - B.I Kahn's First Law The probability of error in a one character change is approximately 100%. If the possibility of collateral damage exists, the probably of error can appear to exceed 100%. - corollary to B.I Kahn's First Law - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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 Mon, 14 Nov 2011 14:58:29 -0500 Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: :In :77142d37c0c3c34da0d7b1da7d7ca3433225e...@nwt-s-mbx2.rocketsoftware.com, :on 11/14/2011 : at 06:06 PM, Bill Fairchild bfairch...@rocketsoftware.com said: :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. :No. It maps the directory entry used by the interface, but not what is :actually stored in a PDSE. As I recall it is almost the same as the :the directory entry in a PDS, but has some additional information. :e.g., concatenation number. Incorrect. The mapping macro has a parameter to indicate whether the BLDL or directory format is desired. -- 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
