Dump Failing - Aux Shortage
Hello, I am trying to take a dump of NET address space but it fails with CODE 08 REASON X'46'. Manual says that there is shortage of AuxillIary Storage. When I did D ASM TYPE FULL STAT DEV DATASET NAME PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 SCM 94% OK N/A N/A I dont see a shortage and there were no IRA related error message in the syslog. Also, from RMF, I see : ECSA 73% ESQA 88% SQA 52% CSA 74% I did AUXMGMT=OFF but again the Dump fails with same error message. z/OS 2.1 Could someone please provide me your guidance. Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
The clue could be in "SCM 94% full" but it still seems odd to me. Can you fill us in on page data set sizes? Thanks, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Nathan Astle To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 10:20 Subject:Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List Hello, I am trying to take a dump of NET address space but it fails with CODE 08 REASON X'46'. Manual says that there is shortage of AuxillIary Storage. When I did D ASM TYPE FULL STAT DEV DATASET NAME PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 SCM 94% OK N/A N/A I dont see a shortage and there were no IRA related error message in the syslog. Also, from RMF, I see : ECSA 73% ESQA 88% SQA 52% CSA 74% I did AUXMGMT=OFF but again the Dump fails with same error message. z/OS 2.1 Could someone please provide me your guidance. Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Hi, PageIOTotal 120m Active 0 Datasets Total40 Used 11 SCM Size 128G Used120G 94.02% LOCAL Size 61.9G Used 3.45G 5.57% NONVIO Used 3.32G 5.36% VIO Used133M 0.21% Type Status Size UsedPct% VIO PLPA ACTIVE 70.3M 60.9M 86.62% COMMON ACTIVE 703M 320K 0.04% SCMACTIVE 128G 120G 94.02% LOCAL ACTIVE 6.88G 386M 5.49% VIO LOCAL ACTIVE 6.88G 388M 5.51% VIO LOCAL ACTIVE 6.88G 394M 5.60% VIO LOCAL ACTIVE 6.88G 402M 5.71% VIO LOCAL ACTIVE 6.88G 399M 5.67% VIO LOCAL ACTIVE 6.88G 401M 5.70% VIO LOCAL ACTIVE 6.88G 385M 5.48% VIO LOCAL ACTIVE 6.88G 402M 5.72% VIO LOCAL ACTIVE 6.88G 383M 5.45% VIO Regards, Nathan On Fri, Jul 17, 2015 at 2:54 PM, Martin Packer wrote: > The clue could be in "SCM 94% full" but it still seems odd to me. Can you > fill us in on page data set sizes? > > Thanks, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Banking Center of Excellence, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > > > From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 17/07/2015 10:20 > Subject:Dump Failing - Aux Shortage > Sent by:IBM Mainframe Discussion List > > > > Hello, > > I am trying to take a dump of NET address space but it fails with CODE 08 > REASON X'46'. > > Manual says that there is shortage of AuxillIary Storage. > > When I did D ASM > > TYPE FULL STAT DEV DATASET NAME > PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA > COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON > LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 > LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 > LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 > LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 > LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 > LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 > LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 > LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 > LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 > SCM 94% OK N/A N/A > > > I dont see a shortage and there were no IRA related error message in the > syslog. > > Also, from RMF, I see : > > ECSA 73% > ESQA 88% > SQA 52% > CSA 74% > > I did AUXMGMT=OFF but again the Dump fails with same error message. > > z/OS 2.1 > > Could someone please provide me your guidance. > > Nathan > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > -- > 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
Join the IBM z Systems team for a Reddit AMA on July 30
Come join the IBM z Systems team for a live chat session on Reddit! Join us on Reddit and bring your questions for our experts about IBM’s newest z/OS operating system. Date:July 30th, 2015 Time:11:00 AM – 1:00 PM Eastern Place:Visit this page July 30th at 11 AM EDT for a z/OS “Ask Us Anything” session on Reddit https://ibm.biz/zos_ama The above link will update about 15 minutes before the session starts. You will need to register in order to comment. -- Anthony Giorgio Advisory Software Engineer IBM z Systems Platform Performance Manager Twitter: @a_giorgio -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF List User access
Hello Group, One of my customer want to have access for list user command for one particular id.Is it possible to give him this selective access. Please suggest -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Not understanding COBOL diagnostic
Charles, Point taken. However, it is possible to show an eighty byte record in this forum without wrapping: =COLS> +1+2+3+4+5+6+7-- Cheers, Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF List User access
Mainframe Mainframe wrote: >One of my customer want to have access for list user command for one >particular id.Is it possible to give him this selective access. Yes. and it is easy, but did you RTFM before asking here? Look at for example there: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/paluis.htm (Article is about 'Delegating the authority to list user information in only selected user profiles') (watch the URL wrap) 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
What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
I am processing a list of datasetnames and want to calculate the amount of
space used for ONLY those files which are not MIGRATED.
The program currently uses
R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset Name
Because there is no NORECALL parameter, each file gets RECALLED before
continuing. The overhead is terrible.
LISTDSI will return "dataset is migrated" if NORECALL is specified and the
dataset is currently Migrated.
I appreciate your assistance.
Mike Kovach
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
I use code similar to this:
#rc = ListDSI("'"Strip(dsn)"' NORECALL SMSINFO");
If (#rc /= 0) & (sysreason /= 30) Then
Do
End
...
This gives me info on the dataset and on the SMS parameters used for a
file. The sysreason 30 says that the file is not SMS-managed. If you get a
sysreason 9 or 25, this indicates that the file is migrated and not
recalled due to the "NORECALL" setting.
If you use QuickRef, you can look up LISTDSI in the Z/OS REXX SYNTAX manual
to find all the return cods and sysreason codes.
Hope this gets you going in the right direction.
Billy
On Fri, Jul 17, 2015 at 8:15 AM, Mike Kovach <
00bf72527320-dmarc-requ...@listserv.ua.edu> wrote:
> I am processing a list of datasetnames and want to calculate the amount of
> space used for ONLY those files which are not MIGRATED.
> The program currently uses
> R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset
> Name
> Because there is no NORECALL parameter, each file gets RECALLED before
> continuing. The overhead is terrible.
> LISTDSI will return "dataset is migrated" if NORECALL is specified and the
> dataset is currently Migrated.
>
> I appreciate your assistance.
> Mike Kovach
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Thank you and best regards,
*Billy Ashton*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
opinion? LISTCAT (equivalent) with XML / JSON output
I imagine that many here, like myself, are guilty of "scraping" an IDCAMS LISTCAT report using something like REXX to produce information. I do it in a REXX program to recreate DEFINE decks for VSAM data sets which have been lost. I am aware of the IGGCSI00 interface whcih can be used with REXX and other language. I have used it myself in a C program. But I am wondering if others think that it might be nice to have a program which can write the data in a LISTCAT which is formatted as XML, or maybe even JSON. I am considering writing such a program, which I will put on the CBT. Of course, it will use the IGGCSI00 callable service internally. I am posting this here just to get an idea about how popular (or not) such a program might be. I guess I'm looking for a bit of encouragement that it would be worth my while. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
What clients do you expect to use this API? XML is old hat and being deprecated and JSON is only useful in a language that can encode/decode into an internal object. JSON is better but only if you are using a language that can encode/decode in JSON seamlessly. On 17/07/2015 8:39 PM, John McKown wrote: I imagine that many here, like myself, are guilty of "scraping" an IDCAMS LISTCAT report using something like REXX to produce information. I do it in a REXX program to recreate DEFINE decks for VSAM data sets which have been lost. I am aware of the IGGCSI00 interface whcih can be used with REXX and other language. I have used it myself in a C program. But I am wondering if others think that it might be nice to have a program which can write the data in a LISTCAT which is formatted as XML, or maybe even JSON. I am considering writing such a program, which I will put on the CBT. Of course, it will use the IGGCSI00 callable service internally. I am posting this here just to get an idea about how popular (or not) such a program might be. I guess I'm looking for a bit of encouragement that it would be worth my while. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I need a little help using LISTDSI in a REXX program
Thanks Chuck,
That did it. TOO many Quotes Not enough Quotes Wrong type of Quotes.
I appreciate you input.
Mike
From: retired mainframer
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, July 16, 2015 5:26 PM
Subject: Re: I need a little help using LISTDSI in a REXX program
It sure would help if you separated your single and double quotes. The first
single quote below should be a double quote. (The string preceding FN1 should
match the string following.) The REXX statement should be
SRC = LISTDSI(" ' " FN1 " ' " "NORECALL")
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Thursday, July 16, 2015 11:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I need a little help using LISTDSI in a REXX program
>
> I believe you want SRC = LISTDSI(''"FN1"'" "NORECALL")
>
> I'm not where I can get to some of my rexx routines to confirm this to be
> sure.
>
>
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> EAS Information Technology
>
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com | www.thermofisher.com
>
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of
> this e-mail or the information herein by anyone other than the intended
> recipient, or an
> employee or agent of a system responsible for delivering the message to the
> intended
> recipient, is prohibited. If you are not the intended recipient, please
> inform the sender and
> delete all copies.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Kovach
> Sent: Thursday, July 16, 2015 2:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: I need a little help using LISTDSI in a REXX program
>
> I have a REXX program which includes the following:
> SRC = LISTDSI(''"FN1"'") where FN1 = a fully qualified datasetname.
> The results of the invoke of LISTDSI provide the number of tracks used by the
> file in the
> SYSUSED SYSTEM variable.
> Unfortunately, if the dataset is Migrated, it must be RECALLED before this
> can be done. I
> want to add the NORECALL option of the LISTDSI command to avoid the RECALLS,
> but I cannot get the syntax correct.
> TSO LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL works fine on the TSO
> 6 Panel or on the CMD line
> Help out there?
> Thanks in advance for your responses.
>
> Regards,Mike Kovach
>
> --
> 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: I need a little help using LISTDSI in a REXX program
Mike Kovach wrote: >That did it. TOO many Quotes Not enough Quotes Wrong type of Quotes. >I appreciate you input. Hmmm, can we quote you on that? ;-) I'm glad you got the help you deserved. 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: RACF List User access
If you have not done so, you may want to join the RACF list for questions like this. They are more focused on all things RACF and Security. To join, use this URL RACFhttp://www.listserv.uga.edu/archives/racf-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mainframe Mainframe > Sent: Friday, July 17, 2015 4:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RACF List User access > > Hello Group, >One of my customer want to have access for list user command > for > one particular id.Is it possible to give him this selective access. > > Please suggest > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: [MVS-OE] Join the IBM z Systems team for a Reddit AMA on July 30
I thought I would pass this over from the MVS OE List in case there were some that might be interested in this Lizette -Original Message- From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of Anthony Giorgio Sent: Friday, July 17, 2015 3:35 AM To: mvs...@vm.marist.edu Subject: [MVS-OE] Join the IBM z Systems team for a Reddit AMA on July 30 Come join the IBM z Systems team for a live chat session on Reddit! Join us on Reddit and bring your questions for our experts about IBM’s newest z/OS operating system. Date:July 30th, 2015 Time:11:00 AM – 1:00 PM Eastern Place:Visit this page July 30th at 11 AM EDT for a z/OS “Ask Us Anything” session on Reddit https://ibm.biz/zos_ama The above link will update about 15 minutes before the session starts. You will need to register in order to comment. -- Anthony Giorgio Advisory Software Engineer IBM z Systems Platform Performance Manager Twitter: @a_giorgio -- For MVS-OE subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO MVS-OE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
DCOLLECT + program or Rexx... ?
I am processing a list of datasetnames and want to calculate the amount of
space used for ONLY those files which are not MIGRATED.
The program currently uses
R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset Name
Because there is no NORECALL parameter, each file gets RECALLED before
continuing. The overhead is terrible. LISTDSI will return "dataset is
migrated" if NORECALL is specified and the dataset is currently Migrated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Could you post the D D,O command (Dump Options?) I would like to see what your MAXSPACE is set at Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Nathan Astle > Sent: Friday, July 17, 2015 2:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dump Failing - Aux Shortage > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > Regards, > Nathan > > On Fri, Jul 17, 2015 at 2:54 PM, Martin Packer > wrote: > > > The clue could be in "SCM 94% full" but it still seems odd to me. Can > > you fill us in on page data set sizes? > > > > Thanks, Martin > > > > Martin Packer, > > zChampion, Principal Systems Investigator, Worldwide Banking Center of > > Excellence, IBM > > > > +44-7802-245-584 > > > > email: martin_pac...@uk.ibm.com > > > > Twitter / Facebook IDs: MartinPacker > > Blog: > > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPa > cker > > > > > > > > From: Nathan Astle > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 17/07/2015 10:20 > > Subject:Dump Failing - Aux Shortage > > Sent by:IBM Mainframe Discussion List m...@listserv.ua.edu> > > > > > > > > Hello, > > > > I am trying to take a dump of NET address space but it fails with CODE > > 08 REASON X'46'. > > > > Manual says that there is shortage of AuxillIary Storage. > > > > When I did D ASM > > > > TYPE FULL STAT DEV DATASET NAME > > PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA > > COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON > > LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 > > LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 > > LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 > > LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 > > LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 > > LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 > > LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 > > LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 > > LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 > > SCM 94% OK N/A N/A > > > > > > I dont see a shortage and there were no IRA related error message in > > the syslog. > > > > Also, from RMF, I see : > > > > ECSA 73% > > ESQA 88% > > SQA 52% > > CSA 74% > > > > I did AUXMGMT=OFF but again the Dump fails with same error message. > > > > z/OS 2.1 > > > > Could someone please provide me your guidance. > > > > Nathan > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
On Fri, Jul 17, 2015 at 7:57 AM, David Crayford wrote: > What clients do you expect to use this API? XML is old hat and being > deprecated and JSON is only useful in a language that can encode/decode > into an internal object. > I don't actually have any clients in mind. This is just for my amusement at present. I was thinking XML simply because z/OS has System XML and IBM has not articulated a z/OS policy for JSON. Examples of this is the COBOL PARSE XML verb, and the use of XML in CICS. Neither COBOL nor CICS "natively" support JSON. Also, although XML is not as popular as JSON (thanks mainly to JavaScript), it is still a major player. What would be a better output format? Most of my current programming is done on Linux (not z/OS), so I'm becoming "fond" of UNIX standard output such as XML and JSON. > > JSON is better but only if you are using a language that can encode/decode > in JSON seamlessly. JSON is indeed very popular right now. And anything that I can encode in XML can be equivalently encoded in JSON. And vice-versa. XML is "nice" thanks to utilities such as XPATH and xslt. In fact, a person could use xslt to transform XML into JSON rather painlessly. XML is easy to read in Java. And it _can_ be read in JavaScript, python, ruby, and most other UNIX scripting languages. I appreciate the feedback. If you have a standard format that I should consider beyond XML and JSON, I'd appreciate a pointer to the documentation on it. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
I'm also thinking a 120GB+ dump is pretty large, even nowadays. Else what other stuff is filling SCM (Flash) to the brim? Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 14:27 Subject:Re: Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List Could you post the D D,O command (Dump Options?) I would like to see what your MAXSPACE is set at Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Nathan Astle > Sent: Friday, July 17, 2015 2:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dump Failing - Aux Shortage > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > Regards, > Nathan > > On Fri, Jul 17, 2015 at 2:54 PM, Martin Packer > wrote: > > > The clue could be in "SCM 94% full" but it still seems odd to me. Can > > you fill us in on page data set sizes? > > > > Thanks, Martin > > > > Martin Packer, > > zChampion, Principal Systems Investigator, Worldwide Banking Center of > > Excellence, IBM > > > > +44-7802-245-584 > > > > email: martin_pac...@uk.ibm.com > > > > Twitter / Facebook IDs: MartinPacker > > Blog: > > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPa > cker > > > > > > > > From: Nathan Astle > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 17/07/2015 10:20 > > Subject:Dump Failing - Aux Shortage > > Sent by:IBM Mainframe Discussion List m...@listserv.ua.edu> > > > > > > > > Hello, > > > > I am trying to take a dump of NET address space but it fails with CODE > > 08 REASON X'46'. > > > > Manual says that there is shortage of AuxillIary Storage. > > > > When I did D ASM > > > > TYPE FULL STAT DEV DATASET NAME > > PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA > > COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON > > LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 > > LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 > > LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 > > LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 > > LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 > > LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 > > LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 > > LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 > > LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 > > SCM 94% OK N/A N/A > > > > > > I dont see a shortage and there were no IRA related error message in > > the syslog. > > > > Also, from RMF, I see : > > > > ECSA 73% > > ESQA 88% > > SQA 52% > > CSA 74% > > > > I did AUXMGMT=OFF but again the Dump fails with same error message. > > > > z/OS 2.1 > > > > Could someone please provide me your guidance. > > > > Nathan > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EMCS Console identities
Terry, for that reason we wrapped invocation from SDSF to create correct console name before going to SDSF /* Define default console name */ ISFCONS = "T" || mvsvar(sysclone) || sysvar(sysuid) "ISPEXEC VPUT (ISFCONS)" /* Define default console name */ Regards Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
IBM are going after JSON big time with the new z/OS Connect tooling which transforms JSON into data structures like COBOL copybooks etc. That's all good but is JSON always the best choice when a simple text protocol can do the same job without the bloat https://github.com/influxdb/influxdb/pull/2696. XML is even worse. On 17/07/2015 9:45 PM, John McKown wrote: On Fri, Jul 17, 2015 at 7:57 AM, David Crayford wrote: What clients do you expect to use this API? XML is old hat and being deprecated and JSON is only useful in a language that can encode/decode into an internal object. I don't actually have any clients in mind. This is just for my amusement at present. I was thinking XML simply because z/OS has System XML and IBM has not articulated a z/OS policy for JSON. Examples of this is the COBOL PARSE XML verb, and the use of XML in CICS. Neither COBOL nor CICS "natively" support JSON. Also, although XML is not as popular as JSON (thanks mainly to JavaScript), it is still a major player. What would be a better output format? Most of my current programming is done on Linux (not z/OS), so I'm becoming "fond" of UNIX standard output such as XML and JSON. JSON is better but only if you are using a language that can encode/decode in JSON seamlessly. JSON is indeed very popular right now. And anything that I can encode in XML can be equivalently encoded in JSON. And vice-versa. XML is "nice" thanks to utilities such as XPATH and xslt. In fact, a person could use xslt to transform XML into JSON rather painlessly. XML is easy to read in Java. And it _can_ be read in JavaScript, python, ruby, and most other UNIX scripting languages. I appreciate the feedback. If you have a standard format that I should consider beyond XML and JSON, I'd appreciate a pointer to the documentation on it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Not understanding COBOL diagnostic
Thank you. I should have known better but I somehow pictured the folding taking place somewhere in the SMTP, listserve or receive process. No, it's a sender configuration issue. I just changed mine from 76 characters to 85. =COLS> +1+2+3+4+5+6+7-- Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Butler Sent: Friday, July 17, 2015 4:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Not understanding COBOL diagnostic Charles, Point taken. However, it is possible to show an eighty byte record in this forum without wrapping: =COLS> +1+2+3+4+5+6+7-- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Hi Liz, Value for MAXSPACE is set : MAXSPACE=00015000M Nathan On Fri, Jul 17, 2015 at 6:56 PM, Lizette Koehler wrote: > Could you post the D D,O command (Dump Options?) > > I would like to see what your MAXSPACE is set at > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Nathan Astle > > Sent: Friday, July 17, 2015 2:27 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Dump Failing - Aux Shortage > > > > Hi, > > > > PageIOTotal 120m Active 0 > > Datasets Total40 Used 11 > > SCM Size 128G Used120G 94.02% > > LOCAL Size 61.9G Used 3.45G 5.57% > > NONVIO Used 3.32G 5.36% > > VIO Used133M 0.21% > > > > > > Type Status Size UsedPct% VIO > > PLPA ACTIVE 70.3M 60.9M 86.62% > > COMMON ACTIVE 703M 320K 0.04% > > SCMACTIVE 128G 120G 94.02% > > LOCAL ACTIVE 6.88G 386M 5.49% VIO > > LOCAL ACTIVE 6.88G 388M 5.51% VIO > > LOCAL ACTIVE 6.88G 394M 5.60% VIO > > LOCAL ACTIVE 6.88G 402M 5.71% VIO > > LOCAL ACTIVE 6.88G 399M 5.67% VIO > > LOCAL ACTIVE 6.88G 401M 5.70% VIO > > LOCAL ACTIVE 6.88G 385M 5.48% VIO > > LOCAL ACTIVE 6.88G 402M 5.72% VIO > > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > > > Regards, > > Nathan > > > > On Fri, Jul 17, 2015 at 2:54 PM, Martin Packer > > > wrote: > > > > > The clue could be in "SCM 94% full" but it still seems odd to me. Can > > > you fill us in on page data set sizes? > > > > > > Thanks, Martin > > > > > > Martin Packer, > > > zChampion, Principal Systems Investigator, Worldwide Banking Center of > > > Excellence, IBM > > > > > > +44-7802-245-584 > > > > > > email: martin_pac...@uk.ibm.com > > > > > > Twitter / Facebook IDs: MartinPacker > > > Blog: > > > > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPa > > cker > > > > > > > > > > > > From: Nathan Astle > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Date: 17/07/2015 10:20 > > > Subject:Dump Failing - Aux Shortage > > > Sent by:IBM Mainframe Discussion List > m...@listserv.ua.edu> > > > > > > > > > > > > Hello, > > > > > > I am trying to take a dump of NET address space but it fails with CODE > > > 08 REASON X'46'. > > > > > > Manual says that there is shortage of AuxillIary Storage. > > > > > > When I did D ASM > > > > > > TYPE FULL STAT DEV DATASET NAME > > > PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA > > > COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON > > > LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 > > > LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 > > > LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 > > > LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 > > > LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 > > > LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 > > > LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 > > > LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 > > > LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 > > > SCM 94% OK N/A N/A > > > > > > > > > I dont see a shortage and there were no IRA related error message in > > > the syslog. > > > > > > Also, from RMF, I see : > > > > > > ECSA 73% > > > ESQA 88% > > > SQA 52% > > > CSA 74% > > > > > > I did AUXMGMT=OFF but again the Dump fails with same error message. > > > > > > z/OS 2.1 > > > > > > Could someone please provide me your guidance. > > > > > > Nathan > > > > > -- > 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: opinion? LISTCAT (equivalent) with XML / JSON output
On Fri, Jul 17, 2015 at 9:03 AM, David Crayford wrote: > IBM are going after JSON big time with the new z/OS Connect tooling which > transforms JSON into data structures like COBOL copybooks etc. > I hadn't heard of the "z/OS Connect" tooling. Sounds interesting. I see what I can find on it. > That's all good but is JSON always the best choice when a simple text > protocol can do the same job without the bloat > https://github.com/influxdb/influxdb/pull/2696. XML is even worse. Thanks for the URL. I'll be looking at that. One reason that I was looking at JSON or XML is that not every entry in a LISTCAT has the same information in it. The referenced format does seem to accommodate this because it appears to me that each line is "ad hoc" formatted. One thing that I, personally, like about XML is that you have have a DTD which precisely defines what is and what is not acceptable as input. And, at least for me, the size of the data is not overly important. Given that I have a 2 TiB HD in my at home (and more on two separate NAS boxes), and most data centers have space in the 100s of TiB (or even more), I don't know if JSON's "bloat", compared to the referenced format, is all that terrible. And, of course, for "at rest" data, the XML/JSON can be compressed (gzip, bzip, xz). If I were truly worried about it, I would probably use some sort of "delimited" format where the first field of each line identified the "schema" for the rest of the line. Such as: VL (VSAM LDS), VK (VSAM KSDS), VR (VSAM RRDS), VE (VSAM ESDS), AL (ALIAS), NV (NONVSAM), VV (VSAM VVRDS), and so on. I guess I was more trying to go with something which is current and standardized. The referenced format appears to be "in flux" and is not an ISO standard. Which reminds me that I really should go over to the ISO site(s) and see if they have had other "textual format" standard. -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
Would be very cool to have a tool that called IGGCSI00 with parameters like: - dsn and/or catalog filter - list of fields to emit - output format (JSON, pipe-delimited, XML) ( IMO pipe-delimited would be the most useful for piping into awk ) Its pretty easy to call IGGCSI00 from C / C++ / Metal C if you like that sort of thing. Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
What happens if you lower it to 1000M and then try the DUMP command again? This is dynamic and for this one dump you could try setting it lower and then retrying the dump. You can use the CHGDMP command to alter this parameter. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Nathan Astle > Sent: Friday, July 17, 2015 7:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dump Failing - Aux Shortage > > Hi Liz, > > Value for MAXSPACE is set : MAXSPACE=00015000M > > Nathan > > On Fri, Jul 17, 2015 at 6:56 PM, Lizette Koehler > wrote: > > > Could you post the D D,O command (Dump Options?) > > > > I would like to see what your MAXSPACE is set at > > > > Lizette > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan Astle > > > Sent: Friday, July 17, 2015 2:27 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Dump Failing - Aux Shortage > > > > > > Hi, > > > > > > PageIOTotal 120m Active 0 > > > Datasets Total40 Used 11 > > > SCM Size 128G Used120G 94.02% > > > LOCAL Size 61.9G Used 3.45G 5.57% > > > NONVIO Used 3.32G 5.36% > > > VIO Used133M 0.21% > > > > > > > > > Type Status Size UsedPct% VIO > > > PLPA ACTIVE 70.3M 60.9M 86.62% > > > COMMON ACTIVE 703M 320K 0.04% > > > SCMACTIVE 128G 120G 94.02% > > > LOCAL ACTIVE 6.88G 386M 5.49% VIO > > > LOCAL ACTIVE 6.88G 388M 5.51% VIO > > > LOCAL ACTIVE 6.88G 394M 5.60% VIO > > > LOCAL ACTIVE 6.88G 402M 5.71% VIO > > > LOCAL ACTIVE 6.88G 399M 5.67% VIO > > > LOCAL ACTIVE 6.88G 401M 5.70% VIO > > > LOCAL ACTIVE 6.88G 385M 5.48% VIO > > > LOCAL ACTIVE 6.88G 402M 5.72% VIO > > > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > > > > > Regards, > > > Nathan > > > > > > On Fri, Jul 17, 2015 at 2:54 PM, Martin Packer > > > > > > > > wrote: > > > > > > > The clue could be in "SCM 94% full" but it still seems odd to me. > > > > Can you fill us in on page data set sizes? > > > > > > > > Thanks, Martin > > > > > > > > Martin Packer, > > > > zChampion, Principal Systems Investigator, Worldwide Banking > > > > Center of Excellence, IBM > > > > > > > > +44-7802-245-584 > > > > > > > > email: martin_pac...@uk.ibm.com > > > > > > > > Twitter / Facebook IDs: MartinPacker > > > > Blog: > > > > > > > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPa > > > cker > > > > > > > > > > > > > > > > From: Nathan Astle > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Date: 17/07/2015 10:20 > > > > Subject:Dump Failing - Aux Shortage > > > > Sent by:IBM Mainframe Discussion List > > m...@listserv.ua.edu> > > > > > > > > > > > > > > > > Hello, > > > > > > > > I am trying to take a dump of NET address space but it fails with > > > > CODE > > > > 08 REASON X'46'. > > > > > > > > Manual says that there is shortage of AuxillIary Storage. > > > > > > > > When I did D ASM > > > > > > > > TYPE FULL STAT DEV DATASET NAME > > > > PLPA 86% OK 4D4C PAGE.VMVPZ33.PLPA > > > > COMMON 0% OK 4D4C PAGE.VMVPZ33.COMMON > > > > LOCAL 5% OK 9902 PAGE.VMVZ331.LOCAL1 > > > > LOCAL 5% OK 9903 PAGE.VMVZ332.LOCAL2 > > > > LOCAL 5% OK 9904 PAGE.VMVZ333.LOCAL3 > > > > LOCAL 5% OK 9905 PAGE.VMVZ334.LOCAL4 > > > > LOCAL 5% OK 9906 PAGE.VMVZ335.LOCAL5 > > > > LOCAL 5% OK 9907 PAGE.VMVZ336.LOCAL6 > > > > LOCAL 5% OK 9908 PAGE.VMVZ337.LOCAL7 > > > > LOCAL 5% OK 9909 PAGE.VMVZ338.LOCAL8 > > > > LOCAL 5% OK 991A PAGE.VMVZ339.LOCAL9 > > > > SCM 94% OK N/A N/A > > > > > > > > > > > > I dont see a shortage and there were no IRA related error message > > > > in the syslog. > > > > > > > > Also, from RMF, I see : > > > > > > > > ECSA 73% > > > > ESQA 88% > > > > SQA 52% > > > > CSA 74% > > > > > > > > I did AUXMGMT=OFF but again the Dump fails with same error > message. > > > > > > > > z/OS 2.1 > > > > > > > > Could someone please provide me your guidance. > > > > > > > > Nathan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
On Fri, Jul 17, 2015 at 9:54 AM, Kirk Wolf wrote: > Would be very cool to have a tool that called IGGCSI00 with parameters > like: > > - dsn and/or catalog filter > - list of fields to emit > - output format (JSON, pipe-delimited, XML) > ( IMO pipe-delimited would be the most useful for piping into awk ) > > Its pretty easy to call IGGCSI00 from C / C++ / Metal C if you like that > sort of thing. > I've written a very simple C program which uses IGGCSI00. My language options (in no particular order) are: HLASM - difficult to program in, but fairly performant, most shops have HLASM. REXX - interface is a bit difficult (to me), not very performant, beloved of my manager. C - fairly easy to program in, performant, getting more popular on z/OS?, PL/I - my first love, I think it's still performant, not popular at all as best as I can tell. COBOL - beloved of business programmers, middle performance, wordy. FORTRAN - the less said the better. Java - an interesting idea, performant on an zAAP, "write everywhere, run nowhere" according to the critics. I'll most likely go with C. I'm a mid-level programmer in it, and I can use my Linux tools for editing and syntax checking. C++ would be interesting if I were going to distribute a IGGCSI00 "class" for other C++ programmers to use. But I'm not really very good with C++, no experience at all. > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
Maybe also output format CSV (which could be either comma- or tab-separated) for direct input to spreadsheet software. If we had GNU awk 4.1+ available in z/OS Unix we would also have the gawk extension API which could be used to write a C program to invoke IGGCSI00 which could be invoked directly from an awk script (like the gawk XML extension). Then we would be in really nice shape. One can dream . . . Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Friday, July 17, 2015 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: opinion? LISTCAT (equivalent) with XML / JSON output Would be very cool to have a tool that called IGGCSI00 with parameters like: - dsn and/or catalog filter - list of fields to emit - output format (JSON, pipe-delimited, XML) ( IMO pipe-delimited would be the most useful for piping into awk ) Its pretty easy to call IGGCSI00 from C / C++ / Metal C if you like that sort of thing. Kirk Wolf Dovetailed Technologies http://dovetail.com -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
On Fri, Jul 17, 2015 at 10:19 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Maybe also output format CSV (which could be either comma- or > tab-separated) for direct input to spreadsheet software. > > If we had GNU awk 4.1+ available in z/OS Unix we would also have the gawk > extension API which could be used to write a C program to invoke IGGCSI00 > which could be invoked directly from an awk script (like the gawk XML > extension). Then we would be in really nice shape. > One can dream . . . > Yes. I would love that. My manager would then kill me. He dislikes z/OS UNIX. It may be due to the fact that we are getting close to retirement and he doesn't really want to be bothered with it. Also, the company is "cloud sourcing" as much of IT as it can (all the infrastructure it can including the z/OS machine, all Intel machines (Windows & Linux), with the z/OS processes being converted to Windows ). This makes it difficult to be very interested in "new" things that we'll never see. He's a very good programmer, an excellent manager, but not a computer geek. He has truly said that he'd prefer to dig ditches, if it just paid as well. I, OTOH, and a computer nerd and have been since college (mucho years ago). > > Peter > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: opinion? LISTCAT (equivalent) with XML / JSON output
You could use the IGGCSI00 Java wrapper that is already in the z/OS Java SDK: http://www-01.ibm.com/support/knowledgecenter/api/content/SSYKE2_8.0.0/com.ibm.java.zsecurity.api.80.doc/com.ibm.jzos/com/ibm/jzos/CatalogSearch.html It allows full access to IGGCSI00 functionality. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jul 17, 2015 at 10:14 AM, John McKown wrote: > On Fri, Jul 17, 2015 at 9:54 AM, Kirk Wolf wrote: > > > Would be very cool to have a tool that called IGGCSI00 with parameters > > like: > > > > - dsn and/or catalog filter > > - list of fields to emit > > - output format (JSON, pipe-delimited, XML) > > ( IMO pipe-delimited would be the most useful for piping into awk ) > > > > Its pretty easy to call IGGCSI00 from C / C++ / Metal C if you like that > > sort of thing. > > > > I've written a very simple C program which uses IGGCSI00. My language > options (in no particular order) are: > > HLASM - difficult to program in, but fairly performant, most shops have > HLASM. > REXX - interface is a bit difficult (to me), not very performant, beloved > of my manager. > C - fairly easy to program in, performant, getting more popular on z/OS?, > PL/I - my first love, I think it's still performant, not popular at all as > best as I can tell. > COBOL - beloved of business programmers, middle performance, wordy. > FORTRAN - the less said the better. > Java - an interesting idea, performant on an zAAP, "write everywhere, run > nowhere" according to the critics. > > I'll most likely go with C. I'm a mid-level programmer in it, and I can use > my Linux tools for editing and syntax checking. C++ would be interesting > if I were going to distribute a IGGCSI00 "class" for other C++ programmers > to use. But I'm not really very good with C++, no experience at all. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
LISTDSI will return either a 0, 4, or 16. It also sets one of a few dozen
reason codes, which indicate whether the data set is cataloged, migrated, if
the directory is readable, or several other useful pieces of information. This
is why the request takes more time than simply reading a VTOC entry. One way
to reduce overhead is to supply the volume. In that case, LISTDSI uses an
allocate instead of catalog locate.
Going through the reason codes, it indicates RC=12 means VSAM is not supported.
That may reduce the usefulness of LISTDSI in gathering space statistics.
LISTDSI Return Codes:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm
LISTDSI Reason Codes:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm
Bob Longabaugh
CA Technologies
Storage Management QA
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Staller, Allan
Sent: Friday, July 17, 2015 8:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI
'FULLY.QUAL.DATASET.NAME' NORECALL
DCOLLECT + program or Rexx... ?
I am processing a list of datasetnames and want to calculate the amount of
space used for ONLY those files which are not MIGRATED.
The program currently uses
R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset Name
Because there is no NORECALL parameter, each file gets RECALLED before
continuing. The overhead is terrible. LISTDSI will return "dataset is
migrated" if NORECALL is specified and the dataset is currently Migrated.
--
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: opinion? LISTCAT (equivalent) with XML / JSON output
On Fri, Jul 17, 2015 at 10:39 AM, Kirk Wolf wrote: > You could use the IGGCSI00 Java wrapper that is already in the z/OS Java > SDK: > > > http://www-01.ibm.com/support/knowledgecenter/api/content/SSYKE2_8.0.0/com.ibm.java.zsecurity.api.80.doc/com.ibm.jzos/com/ibm/jzos/CatalogSearch.html > > It allows full access to IGGCSI00 functionality. > > Great idea. Thanks for the URL. > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
That is true. However the OP wanted the amount of storage required by each
dataset. So that would not work very well for VTOC listings if the files are
spread over several volumes.
A DCOLLECT + reporting would be faster than REXX + LISTDSI, IMHO
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Longabaugh, Robert E
> Sent: Friday, July 17, 2015 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI
> 'FULLY.QUAL.DATASET.NAME' NORECALL
>
> LISTDSI will return either a 0, 4, or 16. It also sets one of a few dozen
> reason
> codes, which indicate whether the data set is cataloged, migrated, if the
> directory is readable, or several other useful pieces of information. This is
> why the request takes more time than simply reading a VTOC entry. One
> way to reduce overhead is to supply the volume. In that case, LISTDSI uses
> an allocate instead of catalog locate.
>
> Going through the reason codes, it indicates RC=12 means VSAM is not
> supported. That may reduce the usefulness of LISTDSI in gathering space
> statistics.
>
> LISTDSI Return Codes: http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb
> 800/ikjb800159.htm
> LISTDSI Reason Codes: http://www-
> 01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb
> 800/ikjb800159.htm
>
> Bob Longabaugh
> CA Technologies
> Storage Management QA
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Staller, Allan
> Sent: Friday, July 17, 2015 8:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI
> 'FULLY.QUAL.DATASET.NAME' NORECALL
>
> DCOLLECT + program or Rexx... ?
>
>
> I am processing a list of datasetnames and want to calculate the amount of
> space used for ONLY those files which are not MIGRATED.
> The program currently uses
> R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset Name
> Because there is no NORECALL parameter, each file gets RECALLED before
> continuing. The overhead is terrible. LISTDSI will return "dataset is
> migrated"
> if NORECALL is specified and the dataset is currently Migrated.
>
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
> From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 11:49 AM > Subject: Re: Dump Failing - Aux Shortage > Sent by: IBM Mainframe Discussion List > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) (123.45 * 100) / 189.9 = 65% That is over the %(aux used) threshold for allowing a dump to start. MAXSPACE has nothing to do with it. You would get a different reason code for MAXSPACE. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Jim, Thanks for the clarification. I did not realize the difference with MAXSPACE. I am going to add this to my notes. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jim Mulder > Sent: Friday, July 17, 2015 8:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dump Failing - Aux Shortage > > > From: Nathan Astle > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 07/17/2015 11:49 AM > > Subject: Re: Dump Failing - Aux Shortage Sent by: IBM Mainframe > > Discussion List > > > > Hi, > > > > PageIOTotal 120m Active 0 > > Datasets Total40 Used 11 > > SCM Size 128G Used120G 94.02% > > LOCAL Size 61.9G Used 3.45G 5.57% > > NONVIO Used 3.32G 5.36% > > VIO Used133M 0.21% > > > > > > Type Status Size UsedPct% VIO > > PLPA ACTIVE 70.3M 60.9M 86.62% > > COMMON ACTIVE 703M 320K 0.04% > > SCMACTIVE 128G 120G 94.02% > > LOCAL ACTIVE 6.88G 386M 5.49% VIO > > LOCAL ACTIVE 6.88G 388M 5.51% VIO > > LOCAL ACTIVE 6.88G 394M 5.60% VIO > > LOCAL ACTIVE 6.88G 402M 5.71% VIO > > LOCAL ACTIVE 6.88G 399M 5.67% VIO > > LOCAL ACTIVE 6.88G 401M 5.70% VIO > > LOCAL ACTIVE 6.88G 385M 5.48% VIO > > LOCAL ACTIVE 6.88G 402M 5.72% VIO > > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) > 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) > > (123.45 * 100) / 189.9 = 65% > > That is over the %(aux used) threshold for allowing a dump to start. > MAXSPACE has nothing to do with it. You would get a different reason code > for MAXSPACE. > > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > -- > 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: Dump Failing - Aux Shortage
Jim, I forgot to ask. Is there a link to " That is over the %(aux used) threshold for allowing a dump to start" that was stated? Lizette > -Original Message- > From: Lizette Koehler [mailto:stars...@mindspring.com] > Sent: Friday, July 17, 2015 9:10 AM > To: 'IBM Mainframe Discussion List' > Subject: RE: Dump Failing - Aux Shortage > > Jim, > > Thanks for the clarification. I did not realize the difference with MAXSPACE. > > I am going to add this to my notes. > > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Jim Mulder > > Sent: Friday, July 17, 2015 8:58 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Dump Failing - Aux Shortage > > > > > From: Nathan Astle > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Date: 07/17/2015 11:49 AM > > > Subject: Re: Dump Failing - Aux Shortage Sent by: IBM Mainframe > > > Discussion List > > > > > > Hi, > > > > > > PageIOTotal 120m Active 0 > > > Datasets Total40 Used 11 > > > SCM Size 128G Used120G 94.02% > > > LOCAL Size 61.9G Used 3.45G 5.57% > > > NONVIO Used 3.32G 5.36% > > > VIO Used133M 0.21% > > > > > > > > > Type Status Size UsedPct% VIO > > > PLPA ACTIVE 70.3M 60.9M 86.62% > > > COMMON ACTIVE 703M 320K 0.04% > > > SCMACTIVE 128G 120G 94.02% > > > LOCAL ACTIVE 6.88G 386M 5.49% VIO > > > LOCAL ACTIVE 6.88G 388M 5.51% VIO > > > LOCAL ACTIVE 6.88G 394M 5.60% VIO > > > LOCAL ACTIVE 6.88G 402M 5.71% VIO > > > LOCAL ACTIVE 6.88G 399M 5.67% VIO > > > LOCAL ACTIVE 6.88G 401M 5.70% VIO > > > LOCAL ACTIVE 6.88G 385M 5.48% VIO > > > LOCAL ACTIVE 6.88G 402M 5.72% VIO > > > LOCAL ACTIVE 6.88G 383M 5.45% VIO > > > > 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) > > 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) > > > > (123.45 * 100) / 189.9 = 65% > > > > That is over the %(aux used) threshold for allowing a dump to start. > > MAXSPACE has nothing to do with it. You would get a different reason > > code for MAXSPACE. > > > > > > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
Thanks Bob.
From: "Longabaugh, Robert E"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, July 17, 2015 11:39 AM
Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI
'FULLY.QUAL.DATASET.NAME' NORECALL
LISTDSI will return either a 0, 4, or 16. It also sets one of a few dozen
reason codes, which indicate whether the data set is cataloged, migrated, if
the directory is readable, or several other useful pieces of information. This
is why the request takes more time than simply reading a VTOC entry. One way
to reduce overhead is to supply the volume. In that case, LISTDSI uses an
allocate instead of catalog locate.
Going through the reason codes, it indicates RC=12 means VSAM is not supported.
That may reduce the usefulness of LISTDSI in gathering space statistics.
LISTDSI Return Codes:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm
LISTDSI Reason Codes:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb800/ikjb800159.htm
Bob Longabaugh
CA Technologies
Storage Management QA
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Staller, Allan
Sent: Friday, July 17, 2015 8:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the proper REXX syntax to accomplish this LISTDSI
'FULLY.QUAL.DATASET.NAME' NORECALL
DCOLLECT + program or Rexx... ?
I am processing a list of datasetnames and want to calculate the amount of
space used for ONLY those files which are not MIGRATED.
The program currently uses
R = LISTDSI ("'"FQSN'"') where FQSN is the Fully Qualified Dataset Name
Because there is no NORECALL parameter, each file gets RECALLED before
continuing. The overhead is terrible. LISTDSI will return "dataset is
migrated" if NORECALL is specified and the dataset is currently Migrated.
--
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: RACF List User access
Take a look at http://www.rshconsulting.com/RSHpres/RSH_Consulting__FACILITY_Class__June_2012.pdf Do a find for IRR.LISTUSER. It has some restrictions. Robert has many handy papers on RACF. Dennis Roach, CISSP, PMP IT Security Administration Senior Analyst 2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019 Work: 713-831-8799 Cell: 713-591-1059 Email: dennis.ro...@aig.com Report information security incidents to: aiglr_security_incide...@aig.com and (818) 673-4030 All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, July 17, 2015 8:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF List User access If you have not done so, you may want to join the RACF list for questions like this. They are more focused on all things RACF and Security. To join, use this URL RACFhttp://www.listserv.uga.edu/archives/racf-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mainframe Mainframe > Sent: Friday, July 17, 2015 4:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RACF List User access > > Hello Group, >One of my customer want to have access for list user > command for one particular id.Is it possible to give him this selective > access. > > Please suggest > -- 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: Dump Failing - Aux Shortage
> From: Lizette Koehler > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 12:31 PM > Subject: Re: Dump Failing - Aux Shortage > Sent by: IBM Mainframe Discussion List > > Jim, > > I forgot to ask. > > Is there a link to " That is over the %(aux used) threshold for allowing a > dump to start" that was stated? > > Lizette > https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag100/c3set.htm See the discussion of SDUMP,AUXMGMT=ON or OFF Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Jim Even after trying SDUMP,AUXMGMT=OFF it failed with the same error code On Friday 17 July 2015, Jim Mulder wrote: > > From: Lizette Koehler > > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 07/17/2015 12:31 PM > > Subject: Re: Dump Failing - Aux Shortage > > Sent by: IBM Mainframe Discussion List > > > > > Jim, > > > > I forgot to ask. > > > > Is there a link to " That is over the %(aux used) threshold for allowing > a > > dump to start" that was stated? > > > > Lizette > > > > > https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag100/c3set.htm > > See the discussion of SDUMP,AUXMGMT=ON or OFF > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > -- > 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: What is the proper REXX syntax to accomplish this LISTDSI 'FULLY.QUAL.DATASET.NAME' NORECALL
Since the statement you provided has mismatched quotes (obvious after inserting spaces between them as noted below), it probably is not what you are actually using. I suggest using cut and paste instead of retyping when requesting this kind of help. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Kovach > Sent: Friday, July 17, 2015 5:15 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: What is the proper REXX syntax to accomplish this LISTDSI > 'FULLY.QUAL.DATASET.NAME' NORECALL > > I am processing a list of datasetnames and want to calculate the amount of > space used for > ONLY those files which are not MIGRATED. > The program currently uses > R = LISTDSI ( " ' " FQSN ' " ') where FQSN is the Fully Qualified > Dataset Name > Because there is no NORECALL parameter, each file gets RECALLED before > continuing. The overhead is terrible. > LISTDSI will return "dataset is migrated" if NORECALL is specified and the > dataset is > currently Migrated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
So the real question, I submit, gets to be "how come there's so much of SCM tied up?" Are we trying to capture dumps into an already overly-full memory / SCM situation? This thread (and a SEPARATE customer situation) prompted a discussion today in my team about doing more with the SMF 75 (and 71) data now that SCM is quite commonplace. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Jim Mulder To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 16:58 Subject:Re: Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List > From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 11:49 AM > Subject: Re: Dump Failing - Aux Shortage > Sent by: IBM Mainframe Discussion List > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) (123.45 * 100) / 189.9 = 65% That is over the %(aux used) threshold for allowing a dump to start. MAXSPACE has nothing to do with it. You would get a different reason code for MAXSPACE. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
> From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 02:59 PM > Subject: Re: Dump Failing - Aux Shortage > Sent by: IBM Mainframe Discussion List > > Jim > > Even after trying SDUMP,AUXMGMT=OFF > it failed with the same error code As stated in the documentation: 2. Once SVC dump processing has detected a shortage, the auxiliary storage utilization must drop below 35% before new SVC dump requests will be honored. The condition cannot be removed by simply changing the setting of AUXMGMT from ON to OFF. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dump Failing - Aux Shortage
Don't overlook the type 74 subtype 4 Structure data where the SCM statistics per Structure are reported. TYPE74ST in MXG 33.07 has all of these new R744M variables: /* TYPE 74 SUBTYPE 4 MO SECTION*/ R744MAEC='SCM*AUXILIARY*ENABLED*COMMANDS' R744MALG='SCM*ALGORITHM*TYPE' R744MEMA='EST MAX*ASSIGNED*AUGMENTM SPACE' R744MEME='EST MAX*LIST*ELEMENTS*IN SCM' R744MEML='EST MAX*LIST*ENTRIES*IN SCM' R744MENE='EXISTING*LIST*ELEMENTS*IN SCM' R744MENL='EXISTING*LIST*ENTRIES*IN SCM' R744MFAU='FIXED*AUGMENTED*SPACE' R744MIUA='AUGMENTED*SPACE*IN USE*BY THIS STRUCTURE' R744MIUS='SCM*IN USE*BY THIS*STRUCTURE' R744MMBE='MAX*LIST ELEMENTS*PER SCM*BUFFER' R744MNEL='MIN*LIST ELEMENTS*MUST BE*AVAILABLE' R744MNEC='MIN*LIST ENTRIES*MUST BE*AVAILABLE' R744NSRK='REFERENCES*FOR MIGRATING*KEY-RANGE' R744MMBL='MAX*LIST ENTRIES*PER SCM*BUFFER' R744MRBT='SCM*READ*BYTES*TRANSFERRED' R744MRFC='SCM*READ OPS*LIST*REFERENCE' R744MRPC='SCM*READ OPS*PREFETCH OP' R744MRSQ='SQUARES OF*R744MRST' R744MRST='SCM*READ OPS*SERVICE*TIME' R744MSLR='PCT*LIST COUNTS*LOWER*REGULATOR' R744MSLT='PCT*LIST COUNTS*LOWER*THRESHOLD' R744MSMA='MAX*SCM*STRUCTURE*CAN USE' R744MSRL='SCM*REFERENCES*LIST*STRUCTURE' R744MSRM='SCM*REFERENCES*MIGRATION' R744MSRR='SCM*REFERENCES*LIST*HASHING' R744MSUR='PCT*LIST COUNTS*UPPER*REGULATOR' R744MSUT='PCT*LIST COUNTS*UPPER*THRESHOLD' R744MSWC='SCM LIST WRITES' R744MWBT='SCM*WRITE*BYTES*TRANSFERRED' R744MWSQ='SQUARES OF*R744MWST' R744MWST='SCM*WRITE OPS*SERVICE*TIME' Barry Herbert W. "Barry" Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 - Still works, received as email Tel: 214 351 1966 - Unreliable, please use email www.mxg.comHomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.comTechnical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Friday, July 17, 2015 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dump Failing - Aux Shortage So the real question, I submit, gets to be "how come there's so much of SCM tied up?" Are we trying to capture dumps into an already overly-full memory / SCM situation? This thread (and a SEPARATE customer situation) prompted a discussion today in my team about doing more with the SMF 75 (and 71) data now that SCM is quite commonplace. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Jim Mulder To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 16:58 Subject:Re: Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List > From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 11:49 AM > Subject: Re: Dump Failing - Aux Shortage Sent by: IBM Mainframe > Discussion List > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) (123.45 * 100) / 189.9 = 65% That is over the %(aux used) threshold for allowing a dump to start. MAXSPACE has nothing to do with it. You would get a different reason code for MAXSPACE. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---
Re: Dump Failing - Aux Shortage
Yes but those are for a SEPARATE LPAR - the CF one, not the z/OS one. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Barry Merrill To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 20:03 Subject:Re: Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List Don't overlook the type 74 subtype 4 Structure data where the SCM statistics per Structure are reported. TYPE74ST in MXG 33.07 has all of these new R744M variables: /* TYPE 74 SUBTYPE 4 MO SECTION*/ R744MAEC='SCM*AUXILIARY*ENABLED*COMMANDS' R744MALG='SCM*ALGORITHM*TYPE' R744MEMA='EST MAX*ASSIGNED*AUGMENTM SPACE' R744MEME='EST MAX*LIST*ELEMENTS*IN SCM' R744MEML='EST MAX*LIST*ENTRIES*IN SCM' R744MENE='EXISTING*LIST*ELEMENTS*IN SCM' R744MENL='EXISTING*LIST*ENTRIES*IN SCM' R744MFAU='FIXED*AUGMENTED*SPACE' R744MIUA='AUGMENTED*SPACE*IN USE*BY THIS STRUCTURE' R744MIUS='SCM*IN USE*BY THIS*STRUCTURE' R744MMBE='MAX*LIST ELEMENTS*PER SCM*BUFFER' R744MNEL='MIN*LIST ELEMENTS*MUST BE*AVAILABLE' R744MNEC='MIN*LIST ENTRIES*MUST BE*AVAILABLE' R744NSRK='REFERENCES*FOR MIGRATING*KEY-RANGE' R744MMBL='MAX*LIST ENTRIES*PER SCM*BUFFER' R744MRBT='SCM*READ*BYTES*TRANSFERRED' R744MRFC='SCM*READ OPS*LIST*REFERENCE' R744MRPC='SCM*READ OPS*PREFETCH OP' R744MRSQ='SQUARES OF*R744MRST' R744MRST='SCM*READ OPS*SERVICE*TIME' R744MSLR='PCT*LIST COUNTS*LOWER*REGULATOR' R744MSLT='PCT*LIST COUNTS*LOWER*THRESHOLD' R744MSMA='MAX*SCM*STRUCTURE*CAN USE' R744MSRL='SCM*REFERENCES*LIST*STRUCTURE' R744MSRM='SCM*REFERENCES*MIGRATION' R744MSRR='SCM*REFERENCES*LIST*HASHING' R744MSUR='PCT*LIST COUNTS*UPPER*REGULATOR' R744MSUT='PCT*LIST COUNTS*UPPER*THRESHOLD' R744MSWC='SCM LIST WRITES' R744MWBT='SCM*WRITE*BYTES*TRANSFERRED' R744MWSQ='SQUARES OF*R744MWST' R744MWST='SCM*WRITE OPS*SERVICE*TIME' Barry Herbert W. "Barry" Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 - Still works, received as email Tel: 214 351 1966 - Unreliable, please use email www.mxg.comHomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.comTechnical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Friday, July 17, 2015 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dump Failing - Aux Shortage So the real question, I submit, gets to be "how come there's so much of SCM tied up?" Are we trying to capture dumps into an already overly-full memory / SCM situation? This thread (and a SEPARATE customer situation) prompted a discussion today in my team about doing more with the SMF 75 (and 71) data now that SCM is quite commonplace. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Jim Mulder To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/07/2015 16:58 Subject:Re: Dump Failing - Aux Shortage Sent by:IBM Mainframe Discussion List > From: Nathan Astle > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 11:49 AM > Subject: Re: Dump Failing - Aux Shortage Sent by: IBM Mainframe > Discussion List > > Hi, > > PageIOTotal 120m Active 0 > Datasets Total40 Used 11 > SCM Size 128G Used120G 94.02% > LOCAL Size 61.9G Used 3.45G 5.57% > NONVIO Used 3.32G 5.36% > VIO Used133M 0.21% > > > Type Status Size UsedPct% VIO > PLPA ACTIVE 70.3M 60.9M 86.62% > COMMON ACTIVE 703M 320K 0.04% > SCMACTIVE 128G 120G 94.02% > LOCAL ACTIVE 6.88G 386M 5.49% VIO > LOCAL ACTIVE 6.88G 388M 5.51% VIO > LOCAL ACTIVE 6.88G 394M 5.60% VIO > LOCAL ACTIVE 6.88G 402M 5.71% VIO > LOCAL ACTIVE 6.88G 399M 5.67% VIO > LOCAL ACTIVE 6.88G 401M 5.70% VIO > LOCAL ACTIVE 6.88G 385M 5.48% VIO > LOCAL ACTIVE 6.88G 402M 5.72% VIO > LOCAL ACTIVE 6.88G 383M 5.45% VIO 3.45G (used local) + 120G (used SCM) = 123.45G (used Aux) 61.9G (size local) + 128G (size SCM) = 189.9 (size Aux) (123.45 * 100) / 189.9 = 65% That is over the %(aux used) threshold for allowing a dump to start. MAXSPACE has nothing to do with it. You would get a different reason code for MAXSPACE. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---
HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
This JCL... //STEP01 EXEC PGM=IEFBR14 //ALC DD DSN=&&XX00500, // DISP=(NEW,CATLG,DELETE), // DSNTYPE=LIBRARY, // UNIT=VIO, // DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), // SPACE=(CYL,(25,5,200)) works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails with the following error messages: IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING RETURN CODE 12 REASON CODE 144 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 It seems the key message is... HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 Which seems to suggest that PDSE cannot be allocated on VIO. So why does it work on one LPAR but not the other? It's making me a little crazy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
When I run your JCL, I get: IEFC620I UNIDENTIFIABLE CHARACTER ; ON THE DD STATEMENT Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roland Kinsman Sent: Friday, July 17, 2015 4:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 This JCL... //STEP01 EXEC PGM=IEFBR14 //ALC DD DSN=&&XX00500, // DISP=(NEW,CATLG,DELETE), // DSNTYPE=LIBRARY, // UNIT=VIO, // DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), // SPACE=(CYL,(25,5,200)) works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails with the following error messages: IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING RETURN CODE 12 REASON CODE 144 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 It seems the key message is... HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 Which seems to suggest that PDSE cannot be allocated on VIO. So why does it work on one LPAR but not the other? It's making me a little crazy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
&& needs to be && (char translation) Next, I am not sure you can allocate a TEMP dataset like that If I use a real name, it runs better. HLQ.XX00500 And why use VIO? Lizette -Original Message- >From: Greg Shirey >Sent: Jul 17, 2015 2:56 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >When I run your JCL, I get: >IEFC620I UNIDENTIFIABLE CHARACTER ; ON THE DD STATEMENT > >Greg Shirey >Ben E. Keith Company > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Roland Kinsman >Sent: Friday, July 17, 2015 4:42 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >This JCL... > >//STEP01 EXEC PGM=IEFBR14 >//ALC DD DSN=&&XX00500, >// DISP=(NEW,CATLG,DELETE), >// DSNTYPE=LIBRARY, >// UNIT=VIO, >// DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), >// SPACE=(CYL,(25,5,200)) > >works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails >with the following error messages: > >IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET > SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 > HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 IGD306I > UNEXPECTED ERROR DURING IGGDAC02 PROCESSING RETURN CODE 12 REASON CODE 144 > THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA > VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 > >It seems the key message is... >HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >Which seems to suggest that PDSE cannot be allocated on VIO. > >So why does it work on one LPAR but not the other? > >It's making me a little crazy. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
>>> Which seems to suggest that PDSE cannot be allocated on VIO. So why does it work on one LPAR but not the other? That is true. You cannot allocate PDSE on VIO. On the LPAR that the JCL ran fine is the PDSE allocated to VIO or to a regular volume? Can you show us the JESYSMSG for the successful job? Thanks, Kolusu IBM Mainframe Discussion List wrote on 07/17/2015 02:42:25 PM: > From: Roland Kinsman > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 02:52 PM > Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > Sent by: IBM Mainframe Discussion List > > This JCL... > > //STEP01 EXEC PGM=IEFBR14 > //ALC DD DSN=&&XX00500, > // DISP=(NEW,CATLG,DELETE), > // DSNTYPE=LIBRARY, > // UNIT=VIO, > // DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), > // SPACE=(CYL,(25,5,200)) > > works fine on one LPAR. On another LPAR, which happens to be a > zPDT, it fails with the following error messages: > > IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET > SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 > HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING > RETURN CODE 12 REASON CODE 144 > THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA > SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT > SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 > > It seems the key message is... > HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > > Which seems to suggest that PDSE cannot be allocated on VIO. > > So why does it work on one LPAR but not the other? > > It's making me a little crazy. > > -- > 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: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
Some shops use ACS routines to convert UNIT=VIO to a "real" DASD allocation, preferring to use outboard DASD (with all their built-in memory-based cache) in preference to CEC memory. Perhaps the first LPAR has that policy and your zPDT is configured to use memory for VIO? Not sure if there really is a restriction from allocating PDSE on VIO, but it would not surprise me. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roland Kinsman Sent: Friday, July 17, 2015 5:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 This JCL... //STEP01 EXEC PGM=IEFBR14 //ALC DD DSN=&&XX00500, // DISP=(NEW,CATLG,DELETE), // DSNTYPE=LIBRARY, // UNIT=VIO, // DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), // SPACE=(CYL,(25,5,200)) works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails with the following error messages: IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING RETURN CODE 12 REASON CODE 144 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 It seems the key message is... HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 Which seems to suggest that PDSE cannot be allocated on VIO. So why does it work on one LPAR but not the other? It's making me a little crazy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
So I ran a test with the JCL and change VIO to SYSDA and it worked fine. I suspect the answer about SMS in your shop redirecting from VIO to DASD may be true. Lizette -Original Message- >From: "Farley, Peter x23353" >Sent: Jul 17, 2015 3:13 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >Some shops use ACS routines to convert UNIT=VIO to a "real" DASD allocation, >preferring to use outboard DASD (with all their built-in memory-based cache) >in preference to CEC memory. > >Perhaps the first LPAR has that policy and your zPDT is configured to use >memory for VIO? > >Not sure if there really is a restriction from allocating PDSE on VIO, but it >would not surprise me. > >HTH > >Peter > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Roland Kinsman >Sent: Friday, July 17, 2015 5:42 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >This JCL... > >//STEP01 EXEC PGM=IEFBR14 >//ALC DD DSN=&&XX00500, >// DISP=(NEW,CATLG,DELETE), >// DSNTYPE=LIBRARY, >// UNIT=VIO, >// DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), >// SPACE=(CYL,(25,5,200)) > >works fine on one LPAR. On another LPAR, which happens to be a zPDT, it fails >with the following error messages: > >IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET > SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 > HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING > RETURN CODE 12 REASON CODE 144 > THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA > SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT > SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 > >It seems the key message is... >HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >Which seems to suggest that PDSE cannot be allocated on VIO. > >So why does it work on one LPAR but not the other? > >It's making me a little crazy. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
I found this APAR PK13789: IGD17040I ERROR IN DADSM PROCESSING SAMPLE JOBS CLB3JIV1 AND CLB3JIV2 UNIT=VIO IS FORBIDDEN WITH DSNTYPE=LIBRARY http://www-01.ibm.com/support/docview.wss?uid=isg1PK13789 Lizette -Original Message- >From: Lizette Koehler >Sent: Jul 17, 2015 3:17 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 > >So I ran a test with the JCL and change VIO to SYSDA and it worked fine. > >I suspect the answer about SMS in your shop redirecting from VIO to DASD may >be true. > >Lizette > > >-Original Message- >>From: "Farley, Peter x23353" >>Sent: Jul 17, 2015 3:13 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 >> >>Some shops use ACS routines to convert UNIT=VIO to a "real" DASD allocation, >>preferring to use outboard DASD (with all their built-in memory-based cache) >>in preference to CEC memory. >> >>Perhaps the first LPAR has that policy and your zPDT is configured to use >>memory for VIO? >> >>Not sure if there really is a restriction from allocating PDSE on VIO, but it >>would not surprise me. >> >>HTH >> >>Peter >> >>-Original Message- >>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>Behalf Of Roland Kinsman >>Sent: Friday, July 17, 2015 5:42 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 >> >>This JCL... >> >>//STEP01 EXEC PGM=IEFBR14 >>//ALC DD DSN=&&XX00500, >>// DISP=(NEW,CATLG,DELETE), >>// DSNTYPE=LIBRARY, >>// UNIT=VIO, >>// DCB=(RECFM=U,LRECL=0,BLKSIZE=27998,DSORG=PO), >>// SPACE=(CYL,(25,5,200)) >> >>works fine on one LPAR. On another LPAR, which happens to be a zPDT, it >>fails with the following error messages: >> >>IGD17040I ERROR IN DADSM PROCESSING ON VOLUME UNKNWN FOR DATA SET >> SYS15198.T160706.RA000.HCHRJK0A.XX00500.H01 >> HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 >> IGD306I UNEXPECTED ERROR DURING IGGDAC02 PROCESSING >> RETURN CODE 12 REASON CODE 144 >> THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA >> SMS MODULE TRACE BACK - VTSDA VTSCR SSIRT >> SYMPTOM RECORD CREATED, PROBLEM ID IS IGD0 >> >>It seems the key message is... >>HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090 >> >>Which seems to suggest that PDSE cannot be allocated on VIO. >> >>So why does it work on one LPAR but not the other? >> >>It's making me a little crazy. >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
Also, from the JCL Manual z/OS 2.1.0>z/OS MVS>z/OS MVS JCL User's Guide>Tasks for requesting data set resources>Data set resources - allocation>Allocation of virtual I/O http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab500/dsvio.htm?lang=en You cannot use VIO for permanent data sets, VSAM data sets, or partitioned data sets extended (PDSEs). Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
64 bit ICMxx ?
Recently got into some real 64-bit coding. Noticed that there is no 64-bit version of ICM. I am used to doing ICM R1,B'',FIELD and then a JZ. It seems for a 64 bit register, there is no ICMxx R1,B'',64bitfield equivalent. I have to do a LG R1,64bitfield and then a LTGR R1,R1 and then the JZ. I'm sure this was not overlooked by the engineers, so am I missing something? Or is this just a new paradigm going forward with 64 bit code? Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64 bit ICMxx ?
Paul, Did you try ICMH (Insert Characters Under Mask High) ? Thanks, Kolusu IBM Mainframe Discussion List wrote on 07/17/2015 05:03:56 PM: > From: Paul Schuster > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 07/17/2015 05:04 PM > Subject: 64 bit ICMxx ? > Sent by: IBM Mainframe Discussion List > > Recently got into some real 64-bit coding. Noticed that there is no > 64-bit version of ICM. I am used to doing ICM R1,B'',FIELD and then a JZ. > > It seems for a 64 bit register, there is no ICMxx R1,B'',64bitfield > equivalent. I have to do a LG R1,64bitfield and then a LTGR R1,R1 > and then the JZ. > > I'm sure this was not overlooked by the engineers, so am I missing > something? Or > is this just a new paradigm going forward with 64 bit code? > > Thank you. > > Paul > > -- > 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: 64 bit ICMxx ?
Paul, There is an ICMH instruction, for which the mask bits indicate bit positions 0-7, 8-15, 16-23, and 24-31 of a 64-bit register. This instruction uses a 20-bit signed offset. There is also an ICMY instruction, which is equivalent to the ICM instruction except that this instruction uses a 20-bit signed offset. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Schuster Sent: Friday, July 17, 2015 8:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 64 bit ICMxx ? Recently got into some real 64-bit coding. Noticed that there is no 64-bit version of ICM. I am used to doing ICM R1,B'',FIELD and then a JZ. It seems for a 64 bit register, there is no ICMxx R1,B'',64bitfield equivalent. I have to do a LG R1,64bitfield and then a LTGR R1,R1 and then the JZ. I'm sure this was not overlooked by the engineers, so am I missing something? Or is this just a new paradigm going forward with 64 bit code? Thank you. Paul -- 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: HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
Here is the JESYSMSG from the successful job, and I can see that sure enough, it's getting allocated to a real DASD volume. I will check with my DASD administrator. STMT NO. MESSAGE - 4 IEF648I INVALID DISP FIELD- PASS SUBSTITUTED ICH70001I HCHRJK0 LAST ACCESS AT 17:04:25 ON FRIDAY, JULY 17, 2015 IEF236I ALLOC. FOR HCHRJK0A STEP01 IGD101I SMS ALLOCATED TO DDNAME (ALC ) DSN (SYS15198.T170510.RA000.HCHRJK0A.XX00500.H01 ) STORCLAS (TMPVIO) MGMTCLAS () DATACLAS () VOL SER NOS= PRD919 IEF142I HCHRJK0A STEP01 - STEP WAS EXECUTED - COND CODE IEF373I STEP/STEP01 /START 2015198.1705 IEF032I STEP/STEP01 /STOP 2015198.1705 CPU: 0 HR 00 MIN 00.01 SECSRB: 0 HR 00 MIN 00.00 SEC VIRT: 8K SYS: 276K EXT:8K SYS: 9860K ATB- REAL: 0K SLOTS: 0K VIRT- ALLOC: 0M SHRD: 0M IGD103I SMS ALLOCATED TO DDNAME SYS1 IGD104I SYS15198.T170510.RA000.HCHRJK0A.R0174128 RETAINED, DDNAME=SYS1 IGD105I SYS15198.T170510.RA000.HCHRJK0A.XX00500.H01 DELETED, DDNAME=ALC IEF375I JOB/HCHRJK0A/START 2015198.1705 IEF033I JOB/HCHRJK0A/STOP 2015198.1705 CPU: 0 HR 00 MIN 00.01 SECSRB: 0 HR 00 MIN 00.00 SEC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64 bit ICMxx ?
> Recently got into some real 64-bit coding. Noticed that there is no > 64-bit version of ICM. I am used to doing ICM R1,B'',FIELD and then a JZ. > > It seems for a 64 bit register, there is no ICMxx R1,B'',64bitfield > equivalent. I have to do a LG R1,64bitfield and then a LTGR R1,R1 > and then the JZ. > > I'm sure this was not overlooked by the engineers, so am I missing > something? Or > is this just a new paradigm going forward with 64 bit code? On z9 and later machines, there is LT/LTG. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64 bit ICMxx ?
> Recently got into some real 64-bit coding. Noticed that there is no > 64-bit version of ICM. I am used to doing ICM R1,B'',FIELD and then a JZ. > > It seems for a 64 bit register, there is no ICMxx R1,B'',64bitfield > equivalent. I have to do a LG R1,64bitfield and then a LTGR R1,R1 > and then the JZ. > > I'm sure this was not overlooked by the engineers, so am I missing > something? Or > is this just a new paradigm going forward with 64 bit code? > On z9 and later machines, there is LT/LTG. >Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY Yes thank you I see that now I was not looking at a high enough dash version of the POO. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
