Re: Page datasets
Yes, I saw this too. It is in the Execution Groups. They blindly seem to get some 400MB of virtual storage each and do nothing with it, which makes it get paged out to the page datasets. However, when bringing the EGs down, they suddenly need this storage which causes a lot of page-ins and delay in bringing them down. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Thursday, December 06, 2012 05:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Page datasets We have 9 mod-9 page datasets that are over 50% in useMQ Broker using most of this storage. Has anyone experienced anything like this? I seem to remember having seen something like this. All of those pages went out to AUX when MQ Broker was started (apparently having something to do with JAVA). It just sits on AUX until the broker gets terminated again. Or so I was told. At the time I thought 'What a crappy design.'. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BCPII question
Is this basic BCPii or het SA version? We do these things via SA and if you like, I can ask my colleague where he found his info. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ralf.zant...@generali.de Sent: Wednesday, December 05, 2012 16:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: BCPII question Hi all, I've developed a Assembler programs to change the system config via BCPII Interface. At the moment I'm able to query/change the weights, defined capacity, IRD-Management, Group-Capacity and some other fields. Now I try to activate OOCoD Records (perfom model conversation) but I can't find the information how to set a specific model, e.g going from Model 719 to 720 and back. The HWISET macro does not support the function and the HWICMD macro seems to support only the activation of the complete OOCoD record. Has somebody tried this and can give me a hint where to find the info? I'm running on z/OS 1.13 and the callable service book I used is SA22-7613-10 date 04/2012. Thanks in advance Ralf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Multiple HSM in one LPAR ?
Hi Thank you Lizette and Glenn. As we have a separate test LPAR, seems to me easier to test independent in a unique system. If we are here , maybe to ask Glenn how the the actual communication is working between a requester (RECALL or MIGRATE etc) and the HSM address space On 05.12.2012 22:27, Glenn Wilcock wrote: Hi Lizette, If the intent is to test a different version of an Exit, then there is a possibility. I've never verified that this works, but it's something that may be tried... Use the MASH support to start an AUXILIARY HSM. (Yes, I know, our documentation needs to be improved regarding MASH). For the AUXILIARY HSM host, define the startup procedure with a STEPLIB of a library containing the desired exits, that are unique from the STEPLIB specified for the MAIN HSM host. A second library would need to be specified that contains the other common modules (DFSMSdss, etc). This should enable the AUX HSM to use unique exits. If the Exits reference the MCVT control block, then they need to be updated to use the QCT to access the correct MCVT. Note that the Control Data Sets will be the active ones, so all testing will need to be mindful of any impact that will occur to the live CDSes. Glenn Wilcock DFSMShsm Architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAMDSET and SYSCATLG
In the 1.10 ADCD RACF database there were two group profiles named VSAMDSET and SYSCATLG. I was able to delete them in that database. With the 1.13 ADCD RACF database, these two profiles (defined 1995) are still (again) in there, but any attempt to delete consistently gives me: IKJ56702I INVALID GROUP, VSAMDSET How do I remove these two groups from the RACF database? I haven't even found them described anywhere in the 1.13 docs. Thanks, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAMDSET and SYSCATLG
Are you using these commands? Connect RACFADM to them and make RACFADM the owner. Delete the obsolete groups, for example: CONNECT RACFADM GROUP(SYS1) AUTH(JOIN) REMOVE IBMUSER GROUP(SYSCTLG) REMOVE IBMUSER GROUP(VSAMDSET) ALTGROUP SYS1 OWNER(RACFADM) DELGROUP SYSCTLG DELGROUP VSAMDSET To verify that the changes took place, issue the following commands: LISTGRP SYS1 LISTGRP SYSCTLG LISTGRP VSAMDSET -frank -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of nitz-...@gmx.net Sent: Thursday, December 06, 2012 7:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAMDSET and SYSCATLG In the 1.10 ADCD RACF database there were two group profiles named VSAMDSET and SYSCATLG. I was able to delete them in that database. With the 1.13 ADCD RACF database, these two profiles (defined 1995) are still (again) in there, but any attempt to delete consistently gives me: IKJ56702I INVALID GROUP, VSAMDSET How do I remove these two groups from the RACF database? I haven't even found them described anywhere in the 1.13 docs. Thanks, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Specific CSVQUERY question
CSVQUERY INEPNAME=INNAME,SEARCH=JPALPA,OUTMJNM=OUTNAME What is not clear about OUTMJNM being (from the CSVQUERY macro) the the major (member) name or (from the book) the major name (which is not an alias name) of the module? If the confusion lies with what is a major name, then I can understand, a bit. I think the macro description is a bit more to the point. To contents supervision, the major name is the member name, and aliases are minor names. If you use ISPF member list, you've undoubtedly seen the Alias-of column. The Alias-of information identifies the major name (member name) associated with that alis (minor name) Regarding CSVINFO vs CSVQUERY: CSVQUERY is a far better interface to use than CSVINFO if you are trying to find information about a specific thing. CSVINFO is for use if you are interested in information about lots of things (such as all modules on the job pack queue). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAMDSET and SYSCATLG
W dniu 2012-12-06 13:20, nitz-...@gmx.net pisze: In the 1.10 ADCD RACF database there were two group profiles named VSAMDSET and SYSCATLG. I was able to delete them in that database. With the 1.13 ADCD RACF database, these two profiles (defined 1995) are still (again) in there, but any attempt to delete consistently gives me: IKJ56702I INVALID GROUP, VSAMDSET How do I remove these two groups from the RACF database? I haven't even found them described anywhere in the 1.13 docs. Both group should not exist any longer. VSAMDSET had to do with VSAM sapces (unique vs SUBALLOCATION) SYSCATLG had to do with OS CVOL, even older Dodo bird. Good nes is you can live with them without any problems. ;-) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
I would rephrase Peter's formulation, (it better not have any 4-byte relocatable adcon's), slightly, changing it to it better be AMODE(64). I really did mean what I wrote. AMODE is irrelevant. The module is, after all, not executable in the case that is being discussed. And, in fact RMODE also is irrelevant. The module may identify RMODE 31 (or even RMODE 24) but if you provide an area above the bar, the system will happily load it there. It is in such cases that you might erroneously have a 4-byte adcon. (Ignoring of RMODE is an old behavior of LOAD with ADDR, continued onward for LOAD with ADDR64) It's kind of hard to squeeze an 8-byte relocated address above 4G into a 4-byte area. But the system will happily do what it can (just as it will for a 3-byte adcon for a module loaded above 16M). It is up to the user to do the right thing; the system will not protect (i.e., abend) this case, if I remember correctly. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAMDSET and SYSCATLG
Are you using these commands? Thanks Frank. I must have done too many RACF commands these past days. I had overlooked that IBMUSER was still joined. It was sufficient to remove IBMUSER from that group, and then I could delete. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAMDSET and SYSCATLG
This is WAD. You could use IRRRID00 (with a dummy SYSIN) to look out for phantom PERMITs for those 2 groups just to make sure they're not there anymore at all. I know. I should have remembered that I cannot delete a group that still has connections. As I said - I have done too much cleanup in the 1.13 IBM delivered ADCD RACF database, so my eyes must be crossing by now. Obsolete userids in racf resource classes are just a small thing. What really bothers me is that they apparently never got the memos what should have been done for a new release, so all old crap is still in there. (Cleanup? What's that? Can I eat that?) And when you get a new release of the ADCD, you get the same old crap again. At least this time around, I have everything in batch jobs, so the next cleanup to be done will be much easier (and faster). Add to that that I have given myself a crash course in being the RACF admin (never having had SPECIAL before), I think I can be forgiven for overlooking this. :-( rant off Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Specific CSVQUERY question
Peter, the issue is moot because -- and I assume you saw my other post -- the code is now all working. Secondly, I am only responding because you asked: my intention is NOT to turn this thread into one of those how dare you say one bad word about IBM documentation; MS is MUCH worse flame rants. I'm taking time out of a busy day in an attempt to help you make IBM documentation better. My confusion was twofold: First, as you correctly infer, I was a little fuzzy on the precise definition of major name. I recalled the general idea, but the specific definition was not at the front of my brain. (Note I am not alone; someone posted asking if CSVQUERY would return the CSECT name associated with an assembler ENTRY statement.) It came back to me as I worked, and you could argue that someone has no business using CSVQUERY if they do not know the exact definition of major name, but the fact is I work in a lot of areas and the precise relationship of member names and alias names was not at the top of my stack. It is obvious from the terms that major name is the big deal name and minor names are child names, but I had forgotten that the major name was specifically the member name, and not for example some name assigned by the binder that would stick with the loadmodule even if the member were renamed. My specific concern that led to this query was because I read the statement When you specify OUTEPNM with INADDR, CSVQUERY returns the module's major entry point name in entryname. The ABSENCE then of a specific statement When you specify OUTMJNM with INEPNAME, CSVQUERY returns the module's major entry point name in entryname caused me concern that perhaps I was falling into that programmer trap of assuming the OS function did what you wished it did, rather than what it was documented as doing. In addition, the CSVQUERY documentation suffers horribly from the lack of a single example, or any significant discussion in the A/S Guide. In the Reference, the description of the specific parameters is pretty good but there is very little big picture. The doc does a good job of saying you must specify one and only one of these inputs but fails to say explicitly you may specify any one or more of these outputs (except that X and Y are mutually exclusive and the following parameters (SEARCHMINOR, etc.) OTOH modify CSVQUERY's behavior with regard to the above inputs and outputs. What little overview there is is not helped by the following statement, which is IMHO wrong at worst and not very helpful or misleading at best: CSVQUERY returns information for the following types of entry points: ... Minor entry points specified on a LOAD, LINK(X), ATTACH(X), or XCTL(X) invocation the system is processing while CSVQUERY is running. Thanks for listening, thanks for z/OS, and thanks for your help over the years. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, December 06, 2012 4:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Specific CSVQUERY question CSVQUERY INEPNAME=INNAME,SEARCH=JPALPA,OUTMJNM=OUTNAME What is not clear about OUTMJNM being (from the CSVQUERY macro) the the major (member) name or (from the book) the major name (which is not an alias name) of the module? If the confusion lies with what is a major name, then I can understand, a bit. I think the macro description is a bit more to the point. To contents supervision, the major name is the member name, and aliases are minor names. If you use ISPF member list, you've undoubtedly seen the Alias-of column. The Alias-of information identifies the major name (member name) associated with that alis (minor name) Regarding CSVINFO vs CSVQUERY: CSVQUERY is a far better interface to use than CSVINFO if you are trying to find information about a specific thing. CSVINFO is for use if you are interested in information about lots of things (such as all modules on the job pack queue). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Peter, I take your point, and I of course believe you when you say that you meant what you wrote (ands tghat you object to my faulty paraphrase). Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. IBM has an understandably long history of omitting to enforce some eminently reasonable constraint until that point in time at which it judges it appropriate to do so; and marking an object, even a read-only one, that is destined to reside above the bar as AMODE(31) is, I think, an act of hubris. One may well get away with it for a time, and even take pleasure in having done so; but whom the gods would destroy they first make proud. (Nemesis, In the retelling of the Greek myth by Robert Graves, keeps the list of such acts of hubris, finally meting out mercilous and terrtible punishments for them.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAMDSET and SYSCATLG
Once completed, could this be posted to CBTTAPE? On Thu, Dec 6, 2012 at 7:41 AM, nitz-...@gmx.net nitz-...@gmx.net wrote: This is WAD. You could use IRRRID00 (with a dummy SYSIN) to look out for phantom PERMITs for those 2 groups just to make sure they're not there anymore at all. I know. I should have remembered that I cannot delete a group that still has connections. As I said - I have done too much cleanup in the 1.13 IBM delivered ADCD RACF database, so my eyes must be crossing by now. Obsolete userids in racf resource classes are just a small thing. What really bothers me is that they apparently never got the memos what should have been done for a new release, so all old crap is still in there. (Cleanup? What's that? Can I eat that?) And when you get a new release of the ADCD, you get the same old crap again. At least this time around, I have everything in batch jobs, so the next cleanup to be done will be much easier (and faster). Add to that that I have given myself a crash course in being the RACF admin (never having had SPECIAL before), I think I can be forgiven for overlooking this. :-( rant off Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VTOC index probls
Hello, I'm having this probl: ICK03091I EXISTING VOLUME SERIAL READ = XXX248 ICK01503I 177E REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK01504I 177E VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK01508A 177E SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T ICK31511I 177E CVAF ERROR: RETURN CODE= 00 ERROR CONDITION= 027 ICK31515I 177E BUILDIX COMMAND FAILED. 17:07:4112/06/12 how can I overcome this ?? do I need XXX248 offline ?? Any hint is appreciated asap. Many thx, A.Cecilio. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC index probls
This is a working example, with an EXISTING VTOCIX. ADD allocation if you need to CREATE the VTOCIX. The Parm avoids the ICK01508A message, need verify for some functions. //BLDIXEXEC PGM=ICKDSF,PARM='NOREPLYU' //LGK034 DD DSN=SYS1.VTOCIX.LGK034,DISP=(OLD), // VOL=(PRIVATE,SER=LGK034),UNIT=(DISK,,DEFER) //SYSPRINT DD SYSOUT=* //SYSINDD * BUILDIX DDNAME(LGK034) IX On Thu, Dec 6, 2012 at 11:10 AM, af dc acbi...@gmail.com wrote: Hello, I'm having this probl: ICK03091I EXISTING VOLUME SERIAL READ = XXX248 ICK01503I 177E REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK01504I 177E VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK01508A 177E SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T ICK31511I 177E CVAF ERROR: RETURN CODE= 00 ERROR CONDITION= 027 ICK31515I 177E BUILDIX COMMAND FAILED. 17:07:4112/06/12 how can I overcome this ?? do I need XXX248 offline ?? Any hint is appreciated asap. Many thx, A.Cecilio. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 10:44:43 -0500, John Gilmore wrote: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. Is there no RMODE(64)? This is complicated because programs may dynamically switch addressing modes in execution, and AMODE(64) with RMODE(31) seems a useful combination for programs which access above-the-bar data but need 4-byte VCONs to invoke existing services. Should there be an exception for paired +/- RLDs? Those should be algebraically valid for any module less than 2 GiB in size. Otherwise I believe such enforcement should be done by the Binder or even by the assembler, not deferred until ABEND at execution. IBM has an understandably long history of omitting to enforce some eminently reasonable constraint until that point in time at which it judges it appropriate to do so; and marking an object, even a read-only one, that is destined to reside above the bar as AMODE(31) is, I think, an act of hubris. And then prolonging the omission for the sake of compatibility with historic customer foolishness. For example, is REFRPROT yet not the default? How do you determine destined to reside? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Historical question regarding the stop command
On Wed, 5 Dec 2012 14:11:49 -0800, Charles Mills wrote: ... implying that TSO is TM'ing the CIB on the way by, not doing a WAIT ECBLIST on the ECB and the terminal. I could imagine an ISPF/TSO of the future doing a WAIT always on the communication ECB and additionally on the terminal when expecting input. When the communication ECB is posted it should read the entire screen and pop up a window saying such as System shutdown in 3 minutes. (Where would it get that information?) The programmer could dismiss the message and refresh the screen with PA2; SAVE; and logoff cleanly. (We shut down our lab systems frequently.) This would put ISPF technically ahead of e.g. Ubuntu Linux, which displays a shutdown mesage on serial PTYs but nothing on the graphic desktop at large. SIGTERM simply blows away the Unity window manager. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC index probls
Hello Mike, probl overcomed by executing the following cmds: 1) DElete OSFORMAT VTOC //STEP1 EXEC PGM=ICKDSF,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=XXX248), // DSN=SYS1.VTOCIX.XXX248,DISP=(OLD,DELETE) //SYSINDD* BUILDIX DDNAME(INVOL1) IXVTOC /* 2) Create IXFORMAT //STEP1 EXEC PGM=ICKDSF,REGION=4M //SYSPRINT DD SYSOUT=* //INVOL1 DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=XXX248), // DSN=SYS1.VTOCIX.XXX248,DISP=(NEW,KEEP), // SPACE=(TRK,178,,CONTIG) //SYSINDD* BUILDIX DDNAME(INVOL1) IXVTOC /* and I got: ICK03091I EXISTING VOLUME SERIAL READ = XXX248 ICK01503I 177E REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK01504I 177E VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK01508A 177E SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T ICK01513I 177E BUILDIX PROCESSING COMPLETED: VTOC IS NOW IN IXFORMAT ICK01317I VTOC-INDEX IS LOCATED AT CCHH=X'1D61 ' AND IS 178 TRACKS. 17:37:0112/06/12 ICKDSF - MVS/ESADEVICE SUPPORT FACILITIES 17.0 Many thx Mike, A.Cecilio. On Thu, Dec 6, 2012 at 5:18 PM, Mike Schwab mike.a.sch...@gmail.com wrote: This is a working example, with an EXISTING VTOCIX. ADD allocation if you need to CREATE the VTOCIX. The Parm avoids the ICK01508A message, need verify for some functions. //BLDIXEXEC PGM=ICKDSF,PARM='NOREPLYU' //LGK034 DD DSN=SYS1.VTOCIX.LGK034,DISP=(OLD), // VOL=(PRIVATE,SER=LGK034),UNIT=(DISK,,DEFER) //SYSPRINT DD SYSOUT=* //SYSINDD * BUILDIX DDNAME(LGK034) IX On Thu, Dec 6, 2012 at 11:10 AM, af dc acbi...@gmail.com wrote: Hello, I'm having this probl: ICK03091I EXISTING VOLUME SERIAL READ = XXX248 ICK01503I 177E REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK01504I 177E VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK01508A 177E SHOULD CONVERSION PROCEED? REPLY U TO CONTINUE, ELSE T ICK31511I 177E CVAF ERROR: RETURN CODE= 00 ERROR CONDITION= 027 ICK31515I 177E BUILDIX COMMAND FAILED. 17:07:4112/06/12 how can I overcome this ?? do I need XXX248 offline ?? Any hint is appreciated asap. Many thx, A.Cecilio. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta
OK, I take the conservative assertion back, and yes, SNOBOL was there first! I still own the book :) I would want to encourage all to use the current state of the art that I labored to port into the z/OS environment (and soon to z/VM as well.) Please, learn the concept, use it and advertise to everybody else! PCRE is the most Perl compatible library available and is actively maintained. I pledge to continue to maintain the port as well. At a certain point, pretty soon, once the process is stabilized, I will publish my porting scripts as well [as open source] so it will be as open as open source should be. I just have to warn you that the scripts are in Perl and use regular expressions naturally. One point about conservatism. We do not have 'make' on the mainframe, so instead of conservatively and manually creating the INCLUDE list for the binder, I'd automated the process by asking the binder what does it miss and resolving it for next time. Pretty conservative, indeed! Ze'ev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM - Migration datasets span MIGRAT1 volumes?
Hi, We recently converted some of our production data from tape to disk, for a different DR strategy. I setup MC's to send the -1 of the generation datasets to ML1 disk volumes, keep the 0 generation on disk and send the older GDS's to ML2 tapes. This works great, with the exception of the largest datasets. During Primary Spacemanagement I get following message: ARC1030I DATA SET PTP.DCD.DC80.IFMR.PURGE.ARC.G5261V00 OF 331660 TRACKS ELIGIBLE FOR MIGRATION/BACKUP TO AN OVERFLOW VOLUME HAS BEEN REDIRECTED TO A NOOVERFLOW VOLUME ARC0757I MIGRATION OF A DATA SET OF 331660 TRACKS TO ML1 VOLUME HSM004 FAILED FOR INADEQUATE SPACE I added 5 mod9 volumes as HSM ML1 overflow volumes and tried the migration of the dataset to ml1 again. It had the same result. A mod9 has 149519 trks to use, so the dataset above would have to span over 3 volumes. It just won't do it. I was trying to find information to see if datasets can't span over volumes if they are ML1, but had no luck. Can someone tell me if there are restrictions on dataset size, larger then a single volume, or how I can accomplish getting these large datasets to ML1? Any help would be appreciated. Judith Nelson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Historical question regarding the stop command
In 50bfa532.5070...@actionsoftware.com, on 12/05/2012 at 02:49 PM, Gord Tomlin gt.ibm.li...@actionsoftware.com said: I had never heard of the ability to issue a STOP command for a TSO session, so I tried it with one of my TSO sessions (which was in READY mode), and nothing happened. It would appear that as of z/OS 1.13 this ability no longer exists. Did you enter a TSO command after the STOP? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who loaded me?
In a6b9336cdb62bb46b9f8708e686a7ea0116565f...@nrhmms8p02.uicnrh.dom, on 12/05/2012 at 02:08 PM, McKown, John john.mck...@healthmarkets.com said: The CDE contains the load point of the program and its length. It didn't use to. Are you sure that you aren't thinking of the entry point address rather than the load addreess? Make sure the PSW is within this address range. Which address range? The module might be split. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Historical question regarding the stop command
In 9933640034959039.wa.markmzelden@listserv.ua.edu, on 12/05/2012 at 03:31 PM, Mark Zelden m...@mzelden.com said: Then that is the problem. You didn't read the OP carefully. You have to be in ISPF when the STOP command is issued and it keeps you from getting to the READY prompt, which is what the objective was. How is ISPF relevant? Either the TMP tests the COMM ECB or it doesn't. If you are already at the READY prompt it is too late. Again, if the code is there then it doesn't matter when you issue the STOP. If the code isn't there then it also doesn't matter. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In 8225406239778525.wa.paulgboulderaim@listserv.ua.edu, on 12/05/2012 at 04:51 PM, Paul Gilmartin paulgboul...@aim.com said: Yes. I can envision read-only data sections I can envision read-only modules containing a data section; I don't see any plausible reason for a split module with both a writable section and a read-only data section. Also the alternative you suggest: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on-write for one of the data sections. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who loaded me?
In 50c00985.6070...@valley.net, on 12/05/2012 at 09:57 PM, Gerhard Postpischil gerh...@valley.net said: True, but irrelevant. A user program locating its JSTCB isn't going to see the system tasks unless it chases beyond its own JSTCB, which was not required to satisfy the original post. The TMP does not attach commands in a separate JS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta
Ze'ev, z/OS Unix certainly does have make. Its not a problem building C and assembler source into a regular load module with make; you just have to put your source in a z/OS Unix directory. There is also a port of gmake available; some Posix FOSS software won't build with the z/OS make. Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Dec 6, 2012 at 2:24 PM, Zeev Atlas zatl...@yahoo.com wrote: One point about conservatism. We do not have 'make' on the mainframe, so instead of conservatively and manually creating the INCLUDE list for the binder, I'd automated the process by asking the binder what does it miss and resolving it for next time. Pretty conservative, indeed! Ze'ev -- 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: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 07:11:01 -0500, Shmuel Metz (Seymour J.) wrote: I can envision read-only modules containing a data section; I don't see any plausible reason for a split module with both a writable section and a read-only data section. Also the alternative you suggest: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on-write for one of the data sections. That's called fork(). (Well, sort of.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who loaded me?
My mistake. A major CDE points to a XTLST, IHAXTLST macro, which contains the load point and length. Interesting question on RMODE(SPLIT). Guess I'll need to code up something and ABEND it to get a dump to see what I can see. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, December 06, 2012 5:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Who loaded me? In a6b9336cdb62bb46b9f8708e686a7ea0116565f...@nrhmms8p02.uicnrh.dom, on 12/05/2012 at 02:08 PM, McKown, John john.mck...@healthmarkets.com said: The CDE contains the load point of the program and its length. It didn't use to. Are you sure that you aren't thinking of the entry point address rather than the load addreess? Make sure the PSW is within this address range. Which address range? The module might be split. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In CAE1XxDEaMWA=aMTmU8QXhzzeLKfPVCJUqgV=w5ycfgn+vz9...@mail.gmail.com, on 12/06/2012 at 10:44 AM, John Gilmore jwgli...@gmail.com said: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. AMODE(64) is not appropriate for a module that is not executable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
BCPII and activation profile
I have a friend who is wondering if there examples of a HWI BCPII that can alter the activation profile. He has some ec12s, and z114s, on z/OS V1.13 - Fairly current on most hardware as they have recently gone through a hardware upgrade which includes DS800's. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who loaded me?
On 12/6/2012 2:09 PM, McKown, John wrote: My mistake. A major CDE points to a XTLST, IHAXTLST macro, which contains the load point and length. Interesting question on RMODE(SPLIT). Guess I'll need to code up something and ABEND it to get a dump to see what I can see. XTLST is an extent *list* -- both extents are shown. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Shmuel says: | AMODE(64) is not appropriate for a module that is not executable. Peter Relson---I am now wary of paraphrasing him---appears to judge that AMODE is moot for tables. I have said and say that AMODE(64) is not just appropriate but desirable for a read-only module that contains doubleword ADCONs. Take your pick; or consult an augur, who will to wield his lituus in helping you make your choice. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Why put addresses in tables? One of my macros generates a table for glb- and lub-seeking binary-search operations. The lexicographic subscript of a bounding element is often of less interest than its entry sequence or another, arbitrary code value. This macro therefore optionally generates another table containing such values, making it accessible by providing its address. Or again, tabular-function tables are often compound ones containing two atomic tables, one of arguments and another of values, the addresses of both of which are stored in a stub. In general, there are many reasons for wishing to include addresses in generated tables, which can be and often are very much more complex in detail than hand-coded ones. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. On Thu, Dec 6, 2012 at 5:19 PM, John Gilmore jwgli...@gmail.com wrote: Shmuel says: | AMODE(64) is not appropriate for a module that is not executable. Peter Relson---I am now wary of paraphrasing him---appears to judge that AMODE is moot for tables. I have said and say that AMODE(64) is not just appropriate but desirable for a read-only module that contains doubleword ADCONs. Take your pick; or consult an augur, who will to wield his lituus in helping you make your choice. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta
I plan to do USS version when the native z/OS version is done ZA Connected by DROID on Verizon Wireless -Original message- From: Kirk Wolf k...@dovetail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, Dec 7, 2012 00:15:19 GMT+00:00 Subject: Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta Ze'ev, z/OS Unix certainly does have make. Its not a problem building C and assembler source into a regular load module with make; you just have to put your source in a z/OS Unix directory. There is also a port of gmake available; some Posix FOSS software won't build with the z/OS make. Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Dec 6, 2012 at 2:24 PM, Zeev Atlas zatl...@yahoo.com wrote: One point about conservatism. We do not have 'make' on the mainframe, so instead of conservatively and manually creating the INCLUDE list for the binder, I'd automated the process by asking the binder what does it miss and resolving it for next time. Pretty conservative, indeed! Ze'ev -- 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: CICS screen scrapping using biztalk
Timothy You've got a lot of things jumbled up in that question, Jake. I could hardly agree more! You can configure Enterprise Extender if you wish as your SNA vehicle, ... From HIS 2010, there's no wishing involved! ... and there are often good reasons to do that ... If using HIS 2010, there's your good reason! ... but it's an option. Perhaps not, from HIS 2010 any customer can use any DLC that he wants so long as it is IP-DLC[1], that is, Enterprise Extender. Microsoft Host Integration Server Getting Started with HIS 2010 What's New in HIS 2010 quote Removed Features The following features have been removed from Host Integration Server. Microsoft Data Link Control (DLC) network protocol and the DLC 802.2 Link Service have been removed from Host Integration Server. You should use the Internet Protocol-Data Link Control (IP-DLC) Link Service that is based on the industry-standard High Performance Routing over Internet Protocol (HPR/IP). /quote http://technet.microsoft.com/en-us/library/gg167635.aspx - [1] Paraphrasing Henry Ford. - Chris Mason On Thu, 6 Dec 2012 13:56:32 +0800, Timothy Sipples sipp...@sg.ibm.com wrote: You've got a lot of things jumbled up in that question, Jake. :-) OK, to connect to CICS Transaction Server you need to connect, so yes, you will need physical network connectivity of some kind. The preferred way to do that is with an OSA Express adapter, yes. In the past there were many channel-attached networking options, but those options are generally fairly antiquated at this point. Presumably you already have physical network connectivity to your mainframe. Otherwise you would have a very interesting mainframe. :-) You can use SNA protocols between Microsoft Host Integration Services and z/OS, assuming your network between those two will route SNA. You can configure Enterprise Extender if you wish as your SNA vehicle, and there are often good reasons to do that (such as network routing limitations), but it's an option. For the record, I've written previously -- and rather bluntly -- about the utility of Microsoft HIS (with or without BizTalk). You can find those past writings fairly easily. In short, in my view it's an expensive Rube Goldberg way to connect to z/OS and CICS. Timothy Sipples -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 18:09:37 -0600, Mike Schwab wrote: I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. Ever so slowly. I understand that 1.13 will let code run above the 4GiB (not 2) bar. (How does it get there?) It can even tolerate interrupts and redispatch from them. I suspect that from the developers' point that's a major advance. What goes in the IRB? Where does it keep the Grande OPSW? But no SVCs. Probably no system facilities understand 64-bit addresses. Likely the next step is SVCs, but the arguments will still need to reside below (even like access methods yet). The software bloat juggernaut will force IBM's hand. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E GIM37904E vs. GIM24504E
APPLY gives me: GIM37904E ** APPLY PROCESSING FAILED FOR SYSMOD xxx BECAUSE OF AN ERROR DURING A PREVIOUS ATTEMPT TO RESTORE xxx. RESTORE gives me: GIM24504E ** RESTORE PROCESSING FAILED FOR SYSMOD xxx BECAUSE xxx HAS NOT BEEN APPLIED. Can't go forwards; can't go backwards. Is there a way out of this? Well, sure; it's my test CSI. I can wipe it out and reinstall. The original failure was a utility (IEWL) error during APPLY, somewhat intentional error injection; APPLY CHECK would not have reported it. If I were more cautious I might have done RESTORE CHECK. (Does everyone do RESTORE CHECK?) Whatever. I'm not very happy with the bind SMP/E has left me in. At the GIM24504E point it ought to have left things alone, not made them worse. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
interrupted email resent Paul Gilmartin wrote: | But no SVCs. Probably no system facilities understand | 64-bit addresses. SVCs are at best obsolescent. We all perforce use them, but when I am beginning at square one I implement only PC-based schemes. - Show quoted text - -- John Gilmore, Ashland, MA 01721 - USA On 12/6/12, John Gilmore jwgli...@gmail.com wrote: Paul Gilmartin wrote: | But no SVCs. Probably no system facilities understand | 64-bit addresses. SVCs are obsolescent. We all perforce use them, but when I am beginning at sq On 12/6/12, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 6 Dec 2012 18:09:37 -0600, Mike Schwab wrote: I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. Ever so slowly. I understand that 1.13 will let code run above the 4GiB (not 2) bar. (How does it get there?) It can even tolerate interrupts and redispatch from them. I suspect that from the developers' point that's a major advance. What goes in the IRB? Where does it keep the Grande OPSW? But no SVCs. Probably no system facilities understand 64-bit addresses. Likely the next step is SVCs, but the arguments will still need to reside below (even like access methods yet). The software bloat juggernaut will force IBM's hand. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA t. -- John Gilmore, Ashland, MA 01721 - USA t. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Conditional Statement during Backup - Clarification
Hi, My question is going to be very general. Our shop has the policy of running daily back up from Mon-friday on a incremental basis(Volume Level). So we have been using this Keyword at sysin control card : DATASET(INCLUDE(**) BY(DSCHA,EQ,YES), which means that the backup would take place only if any changes have been occurred on a specific Volume. Recently in our Z/OS 1.13 Testing box we ended with Below error. ADR049E (001)-STEND(01), 2012.340 15:29:13 DFSMSDSS FUNCTION TASK ABEND RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0A13 REASON CODE=0010 and also followed by the below error : IEC151I A13-10,IFG0195H,TS1IN4$,STEP01,TAPE1,0890,TS1IN4,BACKUP.INC.MTWK05 IEC151I Explanation: The error occurred during processing of an OPEN macro instruction for a data set on magnetic tape. In the message text: rc Associates this message with system completion code A13 and with the return code. jjj The job name. sss The step name. ddname[-#] DDname (followed by a concatenation number if it is part of a concatenation and not the first DD statement in the concatenation). dev The device number. ser The volume serial number. mod The name of the module in which the error occurred. dsname The data set name. The explanation for the hex return code is as follows: Return Code Explanation: 10 A tape mark was read instead of a HDR1 label while forward spacing to the desired file on an SL or AL tape. Thus, the multifile tape ends before the desired file. When positioning to the end of file 1, this means the vol label is followed by a tape mark. Probable user error. Check the file sequence number and volume serial numbers and that the job that wrote the tape wrote all the files I believe that when there is no dataset on a particular Label then it will not proceed with the other LABEL and would end up with above error message. We have never had this issue in past even if a particular LABEL does not have a dataset and it obviously moves on to next label for backup. I hope as per the design it should work and I am totally confused by the above reply. The JCL which we are using like below : //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=VOL,DISP=SHR //TAPE1DD UNIT=890,VOL=(,RETAIN,SER=TAPE),DISP=(NEW,KEEP), //DSNAME=BACKUP.INC.VOL,LABEL=(LBL,SL) //SYSINDD DSN=JAKE.TEST.CNTL(CARD),DISP=SHR //BACKUP PEND //DASD01 EXEC BACKUP,VOL=TVX3A1,TAPE=TS1IN4,LBL=01 //DASD02 EXEC BACKUP,VOL=TVX3A2,TAPE=TS1IN4,LBL=02 //DASD03 EXEC BACKUP,VOL=MTWK05,TAPE=TS1IN4,LBL=03 Any suggestion are highly appreciated. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF Class PROGRAM
I know that this is not the RACF list, but I am not subscribed there, so I am hoping that someone can tell me what to do. I am reluctant to make changes in that class - if I am wrong, then I cannot get into my telnet session anymore because OMVS/TCPIP might have severe problems. ADCD 1.13 system. SETROPTS LIST ATTRIBUTES = INITSTATS WHEN(PROGRAM -- BASIC) ACTIVE CLASSES = DATASET USER GROUP ACCTNUM AIMS CBIND CDT CIMS DIMS DSNR EJBROLE FACILITY GEJBROLE GIMS GXFACILI IIMS JIMS LIMS LOGSTRM MIMS PTKTDATA PTKTVAL RIMS SERVAUTH SERVER STARTED SURROGAT TIMS TSOAUTH TSOPROC UNIXPRIV XFACILIT The book says that WHEN(PROGRAM) is always active in basic mode when FACILITY/IRR.PGMSECURITY is not defined. It is not defined. Would I also see PROGRAM under active classes or is class PROGRAM simply not active? In other words, are the definitions made in that class actually used? (I know I could test by activating enhanced-warning mode, but don't really want to dive deeper into this than necessary.) This was defined in 1996 (showing the ADDMEM part): 0503 *PROGRAM CEE.SCEERUN2 0503 *PROGRAM TCPIP.SEZALOAD 0503 *PROGRAM SYS1.SIEALNKE 0503 *PROGRAM SYS1.CSSLIB 0503 *PROGRAM TCPIP.SEZALPA 0503 *PROGRAM TCPIP.SEZALINK 0503 *PROGRAM SYS1.LINKLIB 0503 *PROGRAM CBC.SCLBDLL 0503 *PROGRAM CEE.SCEERUN 0503 *PROGRAM SYS1.SCEERUN 0503 BPXBINIT PROGRAM SYS1.LINKLIB 0503 BPXEV003 PROGRAM SYS1.LINKLIB 0503 BPXOLVD PROGRAM SYS1.LINKLIB 0503 BPXOVPROGRAM SYS1.LINKLIB 0503 BPXPLPKA PROGRAM SYS1.LINKLIB 0503 BPXUCSNM PROGRAM SYS1.LINKLIB 0503 BPXUEYI1 PROGRAM SYS1.LINKLIB 0503 BPXUI1EY PROGRAM SYS1.LINKLIB 0503 BPXZ24 PROGRAM SYS1.LINKLIB 0503 RLOGIND PROGRAM SYS1.LINKLIB If I read the book right (and the answer above is yes, they are used), then for sys1.linklib profile * will be used (and not the specific program names, never mind that there isn't any program named BPXOV in sys1.linklib these days). In other words, for sys1.linklib all the profiles with 'real' program names are obsolete, right? Thanks for any help before I shoot myself in the foot. Barbara ps: To answer Mike Schwabs question: Yes, I can sent my batch jobs to the cbttape once I am done. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
At 17:04 -0500 on 12/06/2012, Shmuel Metz (Seymour J.) wrote about Re: LOAD and DELETE macro instructions: In CAE1XxDEaMWA=aMTmU8QXhzzeLKfPVCJUqgV=w5ycfgn+vz9...@mail.gmail.com, on 12/06/2012 at 10:44 AM, John Gilmore jwgli...@gmail.com said: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. AMODE(64) is not appropriate for a module that is not executable. It is if the module contains relocatable doubleword pointers to locations within itself and these would not be resolved correctly if you just coded AMODE(31). Note that I am not sure what resolution would occur with AMODE(31) but the module residing above the bar - I am just suggesting that it is safer to code AMODE(64) even if AMODE(31) would still fill in the high word. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Conditional Statement during Backup - Clarification
On 6 Dec 2012 22:05:56 -0800, in bit.listserv.ibm-main (Message-ID:cahtvvrwwwaxf7tfzrhtvz9gf54-kxtmh60qb8jhmtbeuyxw...@mail.gmail.com) justmainfra...@gmail.com (Jake anderson) wrote: My question is going to be very general. Our shop has the policy of running daily back up from Mon-friday on a incremental basis(Volume Level). So we have been using this Keyword at sysin control card : DATASET(INCLUDE(**) BY(DSCHA,EQ,YES), which means that the backup would take place only if any changes have been occurred on a specific Volume. Recently in our Z/OS 1.13 Testing box we ended with Below error. ADR049E (001)-STEND(01), 2012.340 15:29:13 DFSMSDSS FUNCTION TASK ABEND RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0A13 REASON CODE=0010 much snippage Return Code Explanation: 10 A tape mark was read instead of a HDR1 label while forward spacing to the desired file on an SL or AL tape. Thus, the multifile tape ends before the desired file. When positioning to the end of file 1, this means the vol label is followed by a tape mark. Probable user error. Check the file sequence number and volume serial numbers and that the job that wrote the tape wrote all the files much snippage The JCL which we are using like below : //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //SYSPRINT DD SYSOUT=* //DASD1DD UNIT=3390,VOL=SER=VOL,DISP=SHR //TAPE1DD UNIT=890,VOL=(,RETAIN,SER=TAPE),DISP=(NEW,KEEP), //DSNAME=BACKUP.INC.VOL,LABEL=(LBL,SL) //SYSINDD DSN=JAKE.TEST.CNTL(CARD),DISP=SHR //BACKUP PEND //DASD01 EXEC BACKUP,VOL=TVX3A1,TAPE=TS1IN4,LBL=01 //DASD02 EXEC BACKUP,VOL=TVX3A2,TAPE=TS1IN4,LBL=02 //DASD03 EXEC BACKUP,VOL=MTWK05,TAPE=TS1IN4,LBL=03 I see three possibilities, one of which *might* be aparable: 1. The system is now properly checking that file one exists on a tape when you're specifying label=2. It seems unlikely to me that it wasn't in previous versions. But if this is the problem, you may be out of luck. 2. It may be that you never before had an occasion when there were no updated datasets on any (except maybe your last) disk. This would be unrelated to the upgrade, and would have been waiting to bite you. 3. It may be that previous versions of ADRDSSU would create an output file, even if there were no datasets being backed up. If you can show that this was the case, IBM might take an APAR to change the action back. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at pobox dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
