Re: bpxwdyn("INFO DD(UFSOUT) INRTPATH(dir)") truncates directory names containing spaces
On Fri, 2 Nov 2018 13:01:05 -0500, Chris Bowen wrote: > >Customers are free to use such circumventions, vendors have to assume that >their customers would prefer not to. > >Full disclosure - I have no idea if my colleague's original code was intended >to run on customer systems or is for internal use only. > IBM should, of course, assume its code is intended to run on customer systems. IBM's customers are unduly desensitized to the adverse consequences of Conway's law because of IBM's careless design practices. Consider: From: z/OSIBM UNIX System Services User's Guide Version 2 Release 3 SA23-2279-30 ... A path name can be up to 1023 characters long, ... But from: z/OSIBM MVS JCL Reference Version 2 Release 3 SA23-1385-30 ... PATH parameter ... Has a length of 1 through 254 characters, not including the slash. ... Why? Similarly, SVC 99, GUPI as far as I know, allows syntax for PDS member names which JCL treats as syntax error. Why? If the name is invalid (as an IBM rep has asserted) why does DYNALLOC not report an error. Don't these development groups talk to each other? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: eWEEK Article highlights weaknesses in Mainframe Security
Thanks for all the responses. I wasn't aware of any vulnerabilities, patched or otherwise. I don't handle our mainframe's security, another department does that. Frightening. Regards, Eric Verwijs Programmeur-analyste, RPC, SV et solutions de paiement - Direction générale de l'innovation, information et technologie Emploi et Développement social Canada / Gouvernement du Canada frederick.verw...@hrsdc-rhdcc.gc.ca Téléphone 819-654-0934 Télécopieur 819-654-1009 Programmer Analyst, CPP, OAS, and Payment Solutions - Innovation, Information and Technology Branch Employment and Social Development Canada / Government of Canada frederick.verw...@hrsdc-rhdcc.gc.ca Telephone 819-654-0934 Facsimile 819-654-1009 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Overby Sent: November-01-18 2:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: eWEEK Article highlights weaknesses in Mainframe Security Disclamer: Don't shoot the messenger (I am very passionate on this topic). The fact is unpatched zero day vulnerabilities exist on all z/OS mainframe's. Don't take my word for this. Ask KRI's clients what their experience is with z/Assure VAP finding (probable) zero day integrity based code vulnerabilities. I say probable because the ISV's don't appear to share the integrity vulnerability details with anyone outside their respective organizations. They certainly do not share this information with Key Resources. So if the ISV takes longer than a couple of days to provide a patch its likely they did not have one before the vulnerability was reported. Thus you can conclude that the vulnerability was a zero day. Comment: If there were no unpatched security holes then IBM wouldn't need to release security PTFs to fix them. Response: Correct. You only need to look at the patches provided by your ISV's (IBM, CA, BMC, Rocket Sorry if I missed any one!) and you will find security and/or integrity patches. Comment: I would hope that it's a lot harder to find one than it used to be. A: No actually it is not. I started doing this in 2009. Key Resource's z/Assure VAP product regularly finds integrity based-code vulnerabilities. Most of these vulnerabilities appear to be zero day. As some people would consider my comments biased, don't take my word for it. Ask our clients if what I am saying is accurate. Question: What zero-day vulnerabilities would there be? I’ve not heard of unpatched security holes in z/OS before. Short answer: Conspiracy of Silence. Unless you are with the companies that find the vulnerability, work for the ISV support group, or are part of the ISV management or development teams you would never know about the vulnerability UNTIL you saw the patch on their patch portals. Patches normally contain no details about the vulnerability. This is how mainframe integrity based-code vulnerability management is done. These vulnerabilities are NOT reported on the National Vulnerability Database. Comment: Aside from of course, phishing and other attacks aimed at the users and not the machine itself. Answer: Nothing to do with phishing and other attacks. I am referring to integrity based-code vulnerabilities. These vulnerabilities are in SVC's, PC routines, or APF). However, a good hacker will combine vulnerabilities to achieve their goal. The hacker wants to establish a beach head in your network. From there they can traverse the network compromising system's until they get access to z/OS. With these integrity based-code vulnerabilities once they are established and able to run work on z/OS they can elevate their credentials with an integrity based-code vulnerabilities and turn off logging. "Run work" would roughly translate to: a) FTP JCL to z/OS b) Logon to TSO or something similar c) Submit JCL through RJE or NJE (google metasploit NJE for attach vectors)there are documented attacks using this technique. Feel free to contact me offline to continue this discussion. Ray Overby On 10/30/2018 7:43 PM, Seymour J Metz wrote: > If there were no unpatched security holes then IBM wouldn't need to release > security PTFs to fix them. I would hope that it's a lot harder to find one > than it used to be. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Eric Verwijs > Sent: Tuesday, October 30, 2018 10:59 AM > To: IBM-MAIN@listserv.ua.edu > Subject: eWEEK Article highlights weaknesses in Mainframe Security > >
Re: bpxwdyn("INFO DD(UFSOUT) INRTPATH(dir)") truncates directory names containing spaces
>W dniu 2018-11-01 o 23:46, Paul Gilmartin pisze: >> On Thu, 1 Nov 2018 22:37:32 +0100, R.S. wrote: >> >>> While it's interesting issue, ...wouldn't it be practical to avoid >>> spaces in pathname? >>> My€0.02 >>> >> Like any circumvention, it mqy be practical, but the underlying >> defect should be fixed. >> >> It's socially responsible to report such problems to spare one's >> peers the cost of re-encountering them. >[...] > >Agreed. My question should be rephrased to something like "are you aware >you can circumvent the problem by changing pathname? Can you change it?" >Of course "out of curiosity" issues are worth discussion and solution, >but usually do not block someone's work. > >Regards >-- >Radoslaw Skorupka >Lodz, Poland Customers are free to use such circumventions, vendors have to assume that their customers would prefer not to. Full disclosure - I have no idea if my colleague's original code was intended to run on customer systems or is for internal use only. Chris Bowen Macro 4 Limited A Division of Unicom Global -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S23E
My fault I had inadvertently left Both EXTR and ECB on the attach My code as documented with just ECB= on the attach worked just fine Thanks to Tony Hameric who helped me with This apologies to others On Nov 2, 2018, at 12:48 PM, Michael Stein wrote: >> Joseph Reichman >> I know system 23E is for invalid TCB it seems to me that TCB is valid >> could any confirm that the following is the correct sequence of step to >> terminate a TASK. > > A TCB is destroyed when the task terminates unless it was attached with > EXTR or ECB in which case it is destroyed when the DETACH is issued. > > Looking up the S23E > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m015090.htm > > During processing of a DETACH macro, the system found an error in the > input parameters. > > Register 15 contains a hexadecimal reason code that explains the error: > > Code Explanation > > 00 The protection key of the address does not match the key of the issuer > of the DETACH. > > 04 Access register 1 was nonzero for a caller in access register address > space control (ASC) mode. > > 08 The task control block (TCB) specified in the input parameter list > is not a subtask of the caller's TCB. > > I don't know which case you have as I don't know the value in R15 at > the time of the abend, but perhaps the above might give you some ideas. > > One possible reason for the R15 = 8 case other than just a bad TCB > address is that you've already issued the DETACH before and that TCB > has already been destroyed. > >> I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am >> using END_ECB I use to tell the subtask to return via BR 14 >> >> DETACH_LOOP DS 0H >> LR1,END_ECB >> POST (R1) Post it >> WAIT ECB=SYSECB >> MVI TASK_ADDR,X'00' >> DETACH TASK_ADDR >> LA R7,THREAD_LEN(,R7)Next >> BCT R6,DETACH_LOOP > > So END_ECB is for main to subtask notification (to terminate) and SYSECB > is the ECB specified in the ATTACH ECB= parm. > > And you stored the value in R1 from the ATTACH in TASK_ADDR. > > And you are not running AR mode (or at least AR1 is zero?). > >> In my code running under TESTAUTH I made a breakpoint after the wait >> ECB=SYSECB and I go directly to my recovery routine with a 23E makes me >> think it’s not the DETACH > > Is that the first time around the loop? > > Does TASK_ADDR point to a TCB? > > Look at the code generated by the assembler. Is it using R7 to base > your reference to TASK_ADDR or some other register (and thus always > using the same address...) > >> Not sure more so I posted the code if anyone code confirm the logic >> is right ? > > You didn't post enough (all?) of the code nor the R15 value at the S23E > abend point so it's not enough. The ATTACH along with the construction > of the R7 based storage areas are likely to be critical. If it's too > long for an email you could post it somewhere on the web and send a link > to the list. > >> Is your suggestion to use EXTR as opposed to ECB because you suspect >> the validity of the TCB and the TCB is passed to the exit in R1 > > The abend indicates a problem with the code. This needs to be fixed, > just changing to EXTR isn't fixing it. > > Also I wouldn't rush to use EXTR. The EXTR routine is asynchronous to > your main task (which it runs on and interupts) so the EXTR routine would > need a way to communicate with your main task too. I'd just use ECB on > the ATTACH. > >> More so the EXTR will get control after the subtask does a BR R14 > > Yes, but the EXTR routine then needs to communicate with the main routine. > Your main routine is NOT running while the EXTR routine is running but > but you don't know where the main routine is stopped. > > You would need to notify the main routine somehow that the EXTR had > happened. When the asynchronous exit routine (EXTR) exits your main > routine will then run (or continue waiting, or whatever it was doing). > > Unless you do something in the EXTR routine the main routine will never > know the EXTR routine ran... > >> Back to the EXTR when the exit (EXTR) does a BR 14 to z/os, z/os >> will resume executing my code in my clean up routine as besides task >> termination I have to release CSA storage among other things > > Your main routine will become dispatchable again however if it > was waiting it will remain waiting... > >> I still think I am going to need a ECB or actually 4 to say I’m >> done or else the main task might finish first looking at the registers > > Yes, with ATTACH ECB you need an end of task ECB for each task. > >> None have any info from main task or subtask Rob I’m not trying to >> complicate things >> >> But as I said the main task needs to know when things are done may have >> to store ECB Address in TCBUSER and have to go key 0 > > Your R7 workarea should be enough. Besides TCBUSER doesn't belong to you. > USER in
Re: S23E
> Joseph Reichman > I know system 23E is for invalid TCB it seems to me that TCB is valid > could any confirm that the following is the correct sequence of step to > terminate a TASK. A TCB is destroyed when the task terminates unless it was attached with EXTR or ECB in which case it is destroyed when the DETACH is issued. Looking up the S23E https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m015090.htm During processing of a DETACH macro, the system found an error in the input parameters. Register 15 contains a hexadecimal reason code that explains the error: Code Explanation 00 The protection key of the address does not match the key of the issuer of the DETACH. 04 Access register 1 was nonzero for a caller in access register address space control (ASC) mode. 08 The task control block (TCB) specified in the input parameter list is not a subtask of the caller's TCB. I don't know which case you have as I don't know the value in R15 at the time of the abend, but perhaps the above might give you some ideas. One possible reason for the R15 = 8 case other than just a bad TCB address is that you've already issued the DETACH before and that TCB has already been destroyed. > I have 4 tasks I do an ATTACH with ECB =, SYSECB is the ECB, I am > using END_ECB I use to tell the subtask to return via BR 14 > > DETACH_LOOP DS 0H > LR1,END_ECB > POST (R1) Post it > WAIT ECB=SYSECB > MVI TASK_ADDR,X'00' > DETACH TASK_ADDR > LA R7,THREAD_LEN(,R7)Next > BCT R6,DETACH_LOOP So END_ECB is for main to subtask notification (to terminate) and SYSECB is the ECB specified in the ATTACH ECB= parm. And you stored the value in R1 from the ATTACH in TASK_ADDR. And you are not running AR mode (or at least AR1 is zero?). > In my code running under TESTAUTH I made a breakpoint after the wait > ECB=SYSECB and I go directly to my recovery routine with a 23E makes me > think it’s not the DETACH Is that the first time around the loop? Does TASK_ADDR point to a TCB? Look at the code generated by the assembler. Is it using R7 to base your reference to TASK_ADDR or some other register (and thus always using the same address...) > Not sure more so I posted the code if anyone code confirm the logic > is right ? You didn't post enough (all?) of the code nor the R15 value at the S23E abend point so it's not enough. The ATTACH along with the construction of the R7 based storage areas are likely to be critical. If it's too long for an email you could post it somewhere on the web and send a link to the list. > Is your suggestion to use EXTR as opposed to ECB because you suspect > the validity of the TCB and the TCB is passed to the exit in R1 The abend indicates a problem with the code. This needs to be fixed, just changing to EXTR isn't fixing it. Also I wouldn't rush to use EXTR. The EXTR routine is asynchronous to your main task (which it runs on and interupts) so the EXTR routine would need a way to communicate with your main task too. I'd just use ECB on the ATTACH. > More so the EXTR will get control after the subtask does a BR R14 Yes, but the EXTR routine then needs to communicate with the main routine. Your main routine is NOT running while the EXTR routine is running but but you don't know where the main routine is stopped. You would need to notify the main routine somehow that the EXTR had happened. When the asynchronous exit routine (EXTR) exits your main routine will then run (or continue waiting, or whatever it was doing). Unless you do something in the EXTR routine the main routine will never know the EXTR routine ran... > Back to the EXTR when the exit (EXTR) does a BR 14 to z/os, z/os > will resume executing my code in my clean up routine as besides task > termination I have to release CSA storage among other things Your main routine will become dispatchable again however if it was waiting it will remain waiting... > I still think I am going to need a ECB or actually 4 to say I’m > done or else the main task might finish first looking at the registers Yes, with ATTACH ECB you need an end of task ECB for each task. > None have any info from main task or subtask Rob I’m not trying to > complicate things > > But as I said the main task needs to know when things are done may have > to store ECB Address in TCBUSER and have to go key 0 Your R7 workarea should be enough. Besides TCBUSER doesn't belong to you. USER in this context means "not IBM use", so it's the site or organization not a single programmer. There's only one TCBUSER (in each TCB). > If there was an easier way There is... We haven't seen your attach code, but you should be passing a parm value in R1 to the subtask your are attaching. This could be your R7 area address. As Rob Scott said: r> (1) Design your own structure that describes your subtask so that r> you can anchor your own control
Re: z/OS BDAM question
Nah - it's actually how they are on the IBM manual page - weird. On Fri, 2 Nov 2018 at 15:38, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On 2018-11-02, at 05:39:38, R.S. wrote: > > ... > > Content-Transfer-Encoding: 8bit > > Content-Type: text/plain; charset="utf-8"; format=flowed > > > > ... 16␠777␠215 tracks ... > > > I had to look it up: > The following table lists some symbols, in decreasing order by > practical usefulness. > Their shapes vary by font; especially the last one varies a lot. > ␣ U+2423 OPEN BOX > ␢ U+2422 BLANK SYMBOL > ␠ U+2420 SYMBOL FOR SPACE > > Eek! Do they always write numbers that way in Poland? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
On 2018-11-02, at 05:39:38, R.S. wrote: > ... > Content-Transfer-Encoding: 8bit > Content-Type: text/plain; charset="utf-8"; format=flowed > > ... 16␠777␠215 tracks ... > I had to look it up: The following table lists some symbols, in decreasing order by practical usefulness. Their shapes vary by font; especially the last one varies a lot. ␣ U+2423 OPEN BOX ␢ U+2422 BLANK SYMBOL ␠ U+2420 SYMBOL FOR SPACE Eek! Do they always write numbers that way in Poland? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Profiles specific to user
I would love to see that RACF screen... . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Lowe Sent: Friday, November 02, 2018 7:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Profiles specific to user On Fri, 2 Nov 2018 10:25:27 +, Sankaranarayanan, Vignesh wrote: >Hello lists, > >I've look around a bit and also realise there's a screen within the RACF >panels itself to do the following: >Show all dataset profiles that a user has some access to. > >Is it possible to produce this as a report by parsing DBU00? >Found this - http://www.oocities.org/steveneeland/ICE69.txt >.. but it lists only profiles that explicitly have that ID in the access list. > >Is there a way to report all the profiles (DATASET class or otherwise) >an ID has access to through > > 1. direct mentions in the user list > 2. one of the user's connected groups 3. lenient UACC > You could try using the RACF SEARCH command. You will need to manipulate the SEARCH command and specify the various RACF CLASSES but it should do what you want. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Profiles specific to user
On Fri, 2 Nov 2018 10:25:27 +, Sankaranarayanan, Vignesh wrote: >Hello lists, > >I've look around a bit and also realise there's a screen within the RACF >panels itself to do the following: >Show all dataset profiles that a user has some access to. > >Is it possible to produce this as a report by parsing DBU00? >Found this - http://www.oocities.org/steveneeland/ICE69.txt >.. but it lists only profiles that explicitly have that ID in the access list. > >Is there a way to report all the profiles (DATASET class or otherwise) an ID >has access to through > > 1. direct mentions in the user list > 2. one of the user's connected groups > 3. lenient UACC > You could try using the RACF SEARCH command. You will need to manipulate the SEARCH command and specify the various RACF CLASSES but it should do what you want. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Another poster (sorry I deleted the post so can't credit him) already stated that the addressable range depends on the method you use to access the data set. Yes relative track addressing is 2 bytes and limited to 64K tracks. But relative block addressing is 3 bytes and so limited to 16M blocks. So depending on your block size you can address more than the physical limit of the data set. However, as Curtis has just pointed out, Adabas itself doesn't use BDAM, it uses EXCP/EXCPVR. And yes Curtis you are correct - most of our Adabas data sets are DSORG=DA but some of them are indeed DSORG=PS. Because I inherited these systems I'm not quite sure why. Must be something to do with the way they were first allocated and formatted (maybe different releases of Adabas), but it doesn't make a difference, they both work fine. Cheers, Mick. On Fri, 2 Nov 2018 at 12:30, Giliad Wilf < 00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > Interesting. > I recall two statements, probably from two different sources: > > One states that BDAM does not support large format datasets. > > The other states that DA datasets accessed by relative track address are > limited to 65536 tracks. > > ...so, I must assume ADABAS has a way for accessing records of a dataset > that large... > > On Fri, 2 Nov 2018 11:32:23 +, Mick Graley > wrote: > > >Hi All, > > > >I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > >I inherited a number of Adabas databases and they use DSORG=DA. > >One of my larger databases has a data storage component that is 240,525 > >tracks (16,035 cylinders) in 9 extents across 8 volumes. > > > >Organization . . . : DA > >Record format . . . : F > >Record length . . . : 5064 > >Block size . . . . : 5064 > >1st extent cylinders: 363 > >Secondary cylinders : 1668 > >Allocated cylinders : 16,035 > >Allocated extents . : 9 > > > >The rules are documented here: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > > > >Cheers, > > > >Mick. > > > > > >On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > > > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > are > >> usually physically equivalent to DSORG PS, and often are so designated. > >> However, most DA files I've seen are indeed RECFM=F. > >> > >> sas > >> > >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: > >> > >> > Datacom may use some method of "direct access," but the datasets > >> > themselves are RECFM=F. > >> > >> -- > >> 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: VOLCAT split
It is 170 cyls in 14 extents with 3011 CIsplits and 157 CAsplits after 11 years. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 02 November, 2018 14:16 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VOLCAT split > > W dniu 2018-11-02 o 13:41, Vernooij, Kees (ITOPT1) - KLM pisze: > > Ok, interesting to hear from David Jousma, that the limit might be at > 50. > > We have 125000 at the moment, so we don't have to worry now. > > I understand it not as hard limit, rather performance degradation. > IMHO it depends on tape activity significantly, I cannot imagine any > performance problem for my setup (maybe I should?). > Obviously it's still better to prepare than to be surprised. > > BTW: how big is your VOLCAT.VGENERAL? Is it fragmented (CI/CA splits) ? > > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) > według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you > have printed out or saved). > This message may contain legally protected information, which may be > used exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00- > 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National > Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share > capital amounting to PLN 169,248,488 as at 1 January 2018. > > -- > 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: VOLCAT split
W dniu 2018-11-02 o 13:41, Vernooij, Kees (ITOPT1) - KLM pisze: Ok, interesting to hear from David Jousma, that the limit might be at 50. We have 125000 at the moment, so we don't have to worry now. I understand it not as hard limit, rather performance degradation. IMHO it depends on tape activity significantly, I cannot imagine any performance problem for my setup (maybe I should?). Obviously it's still better to prepare than to be surprised. BTW: how big is your VOLCAT.VGENERAL? Is it fragmented (CI/CA splits) ? -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
On Nov 2, 2018, at 7:29 AM, Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > > ...so, I must assume ADABAS has a way for accessing records of a dataset that > large... Actually, current ADABAS versions don’t use an access method; they write their own channel programs and issue EXCP. I think there’s an option to use VSAM on EAVs. All our ADABAS container datasets are defined as PS in the VTOC, but that doesn’t really matter. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VOLCAT split
Ok, interesting to hear from David Jousma, that the limit might be at 50. We have 125000 at the moment, so we don't have to worry now. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 02 November, 2018 12:34 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VOLCAT split > > W dniu 2018-11-02 o 09:11, Vernooij, Kees (ITOPT1) - KLM pisze: > > Just out of curiosity: why do you want to split VOLCAT? > > I'm going to use virtual tapes. Real tape volumes are huge (4/12TB), so > there are few of them. > Virtual tapes are much smaller and tend to not be filled up (it does't > make sense), so the number of volume entries can explode. > I want to prepare for that before the problem occurs. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) > według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you > have printed out or saved). > This message may contain legally protected information, which may be > used exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00- > 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National > Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share > capital amounting to PLN 169,248,488 as at 1 January 2018. > > -- > 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: z/OS BDAM question
Interesting. I recall two statements, probably from two different sources: One states that BDAM does not support large format datasets. The other states that DA datasets accessed by relative track address are limited to 65536 tracks. ...so, I must assume ADABAS has a way for accessing records of a dataset that large... On Fri, 2 Nov 2018 11:32:23 +, Mick Graley wrote: >Hi All, > >I can confirm that there is no 64K tracks limit on DSORG=DA data sets. >I inherited a number of Adabas databases and they use DSORG=DA. >One of my larger databases has a data storage component that is 240,525 >tracks (16,035 cylinders) in 9 extents across 8 volumes. > >Organization . . . : DA >Record format . . . : F >Record length . . . : 5064 >Block size . . . . : 5064 >1st extent cylinders: 363 >Secondary cylinders : 1668 >Allocated cylinders : 16,035 >Allocated extents . : 9 > >The rules are documented here: >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > >Cheers, > >Mick. > > >On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are >> usually physically equivalent to DSORG PS, and often are so designated. >> However, most DA files I've seen are indeed RECFM=F. >> >> sas >> >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: >> >> > Datacom may use some method of "direct access," but the datasets >> > themselves are RECFM=F. >> >> -- >> 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: z/OS BDAM question
It is a little bit more complex. There is third flavour or DSORG=PO, it is DSNTYPE=HFS. ;-) HFS is also constrained to single volume when non-SMS-managed. In the past it was simply single volume. Last, but not least: a database structure (table, tablespace, index) may or may not be constrained by limito of single dataset. For example, it was possible to create more-than-4GB objects, while VSAM limit was 4GB. Now it is usually EA VSAM, but it is still possible to use multiple datasets per object. Backing to the dataset limitations - PDS is the only dataset type/subtype which is really constrained to 64kTRK, because it is both single-volume, and 64k limit susceptible. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 13:18, Mick Graley pisze: Hi Radoslaw, That's true, but I believe the OP was asking whether the entire data set was limited to 64K tracks and I believe only PDS and PDS/E are limited to one volume. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4002.htm None of my database data sets (DB2, IMS, Adabas) are limited to one volume. Cheers, Mick. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Service Link
This link works for me this morning: https://www-304.ibm.com/ibmlink/servicelink/servicelink.wss?lc=en _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Friday, November 2, 2018 8:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM Service Link **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Is anyone else receiving "500 Internal Server Error" trying to get into Service Link? FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Service Link
I am getting that error trying to access the Service Request tool this morning Bonnie Barthel Senior IT Specialist GTS, Solutions, Delivery and Transformation cobon...@vtext.com 719.649.7888 Mobile 720.396.6755 Office bonnie.bart...@us.ibm.com IBM Services From: "PINION, RICHARD W." To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/02/2018 06:15 AM Subject:IBM Service Link Sent by:IBM Mainframe Discussion List Is anyone else receiving "500 Internal Server Error" trying to get into Service Link? FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- 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: z/OS BDAM question
Hi Radoslaw, That's true, but I believe the OP was asking whether the entire data set was limited to 64K tracks and I believe only PDS and PDS/E are limited to one volume. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4002.htm None of my database data sets (DB2, IMS, Adabas) are limited to one volume. Cheers, Mick. On Fri, 2 Nov 2018 at 11:58, R.S. wrote: > Mick, > You are still missing the point: 64k TRK limit is PER VOLUME. It regards > PDS, (basic) PS, and DA. > In other words, BDAM datasets are 64k TRK constrained as some other > datasets are. > Of course some (PDS) datasets cannot be multivolume, while DA (and PS) > can be, but that's different story. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > > W dniu 2018-11-02 o 12:51, Mick Graley pisze: > > Hi Radoslaw, > > If you combine all the rules for direct data sets across 2 or 3 pages of > > the manual you get: > > 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents > > across all volumes. > > Which suggests to me a limit of 3,866,565 tracks. > > Cheers, > > Mick. > > > > > > On Fri, 2 Nov 2018 at 11:40, R.S. > wrote: > > > >> Documentations says the following: > >> > >> /Many types of data sets *are limited* to 65␠535 total tracks allocated > >> on any one volume, and if a greater number of tracks is required, this > >> attempt to create a data set will fail./ > >> > >> // > >> /Data sets that *are not limited* to 65␠535 total tracks allocated on > >> any one volume are: / > >> > >>* /A large format sequential; but cannot occupy more than 16␠777␠215 > >> tracks on a single volume. / > >>* /Extended-format sequential/ > >>* /UNIX files/ > >>* /PDSE/ > >>* /VSAM/ > >> > >> ...lack od BDAM files here > >> > >> I think, you missed very important point: 64k tracks *PER VOLUME*. The > >> limit is not per dataset. > >> > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> > >> W dniu 2018-11-02 o 12:32, Mick Graley pisze: > >>> Hi All, > >>> > >>> I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > >>> I inherited a number of Adabas databases and they use DSORG=DA. > >>> One of my larger databases has a data storage component that is 240,525 > >>> tracks (16,035 cylinders) in 9 extents across 8 volumes. > >>> > >>> Organization . . . : DA > >>> Record format . . . : F > >>> Record length . . . : 5064 > >>> Block size . . . . : 5064 > >>> 1st extent cylinders: 363 > >>> Secondary cylinders : 1668 > >>> Allocated cylinders : 16,035 > >>> Allocated extents . : 9 > >>> > >>> The rules are documented here: > >>> > >> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > >>> Cheers, > >>> > >>> Mick. > >>> > >>> > >>> On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > >>> > BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > >> are > usually physically equivalent to DSORG PS, and often are so > designated. > However, most DA files I've seen are indeed RECFM=F. > > sas > > >> > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with
IBM Service Link
Is anyone else receiving "500 Internal Server Error" trying to get into Service Link? FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Mick, You are still missing the point: 64k TRK limit is PER VOLUME. It regards PDS, (basic) PS, and DA. In other words, BDAM datasets are 64k TRK constrained as some other datasets are. Of course some (PDS) datasets cannot be multivolume, while DA (and PS) can be, but that's different story. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:51, Mick Graley pisze: Hi Radoslaw, If you combine all the rules for direct data sets across 2 or 3 pages of the manual you get: 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents across all volumes. Which suggests to me a limit of 3,866,565 tracks. Cheers, Mick. On Fri, 2 Nov 2018 at 11:40, R.S. wrote: Documentations says the following: /Many types of data sets *are limited* to 65␠535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail./ // /Data sets that *are not limited* to 65␠535 total tracks allocated on any one volume are: / * /A large format sequential; but cannot occupy more than 16␠777␠215 tracks on a single volume. / * /Extended-format sequential/ * /UNIX files/ * /PDSE/ * /VSAM/ ...lack od BDAM files here I think, you missed very important point: 64k tracks *PER VOLUME*. The limit is not per dataset. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:32, Mick Graley pisze: Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are usually physically equivalent to DSORG PS, and often are so designated. However, most DA files I've seen are indeed RECFM=F. sas == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Hi Radoslaw, If you combine all the rules for direct data sets across 2 or 3 pages of the manual you get: 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents across all volumes. Which suggests to me a limit of 3,866,565 tracks. Cheers, Mick. On Fri, 2 Nov 2018 at 11:40, R.S. wrote: > Documentations says the following: > > /Many types of data sets *are limited* to 65␠535 total tracks allocated > on any one volume, and if a greater number of tracks is required, this > attempt to create a data set will fail./ > > // > /Data sets that *are not limited* to 65␠535 total tracks allocated on > any one volume are: / > > * /A large format sequential; but cannot occupy more than 16␠777␠215 > tracks on a single volume. / > * /Extended-format sequential/ > * /UNIX files/ > * /PDSE/ > * /VSAM/ > > ...lack od BDAM files here > > I think, you missed very important point: 64k tracks *PER VOLUME*. The > limit is not per dataset. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2018-11-02 o 12:32, Mick Graley pisze: > > Hi All, > > > > I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > > I inherited a number of Adabas databases and they use DSORG=DA. > > One of my larger databases has a data storage component that is 240,525 > > tracks (16,035 cylinders) in 9 extents across 8 volumes. > > > > Organization . . . : DA > > Record format . . . : F > > Record length . . . : 5064 > > Block size . . . . : 5064 > > 1st extent cylinders: 363 > > Secondary cylinders : 1668 > > Allocated cylinders : 16,035 > > Allocated extents . : 9 > > > > The rules are documented here: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > > > > Cheers, > > > > Mick. > > > > > > On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > > > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > are > >> usually physically equivalent to DSORG PS, and often are so designated. > >> However, most DA files I've seen are indeed RECFM=F. > >> > >> sas > >> > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > > > -- > 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: z/OS BDAM question
Documentations says the following: /Many types of data sets *are limited* to 65␠535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail./ // /Data sets that *are not limited* to 65␠535 total tracks allocated on any one volume are: / * /A large format sequential; but cannot occupy more than 16␠777␠215 tracks on a single volume. / * /Extended-format sequential/ * /UNIX files/ * /PDSE/ * /VSAM/ ...lack od BDAM files here I think, you missed very important point: 64k tracks *PER VOLUME*. The limit is not per dataset. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:32, Mick Graley pisze: Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are usually physically equivalent to DSORG PS, and often are so designated. However, most DA files I've seen are indeed RECFM=F. sas == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VOLCAT split
W dniu 2018-11-02 o 09:11, Vernooij, Kees (ITOPT1) - KLM pisze: Just out of curiosity: why do you want to split VOLCAT? I'm going to use virtual tapes. Real tape volumes are huge (4/12TB), so there are few of them. Virtual tapes are much smaller and tend to not be filled up (it does't make sense), so the number of volume entries can explode. I want to prepare for that before the problem occurs. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are > usually physically equivalent to DSORG PS, and often are so designated. > However, most DA files I've seen are indeed RECFM=F. > > sas > > On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: > > > Datacom may use some method of "direct access," but the datasets > > themselves are RECFM=F. > > -- > 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: bpxwdyn("INFO DD(UFSOUT) INRTPATH(dir)") truncates directory names containing spaces
W dniu 2018-11-01 o 23:46, Paul Gilmartin pisze: On Thu, 1 Nov 2018 22:37:32 +0100, R.S. wrote: While it's interesting issue, ...wouldn't it be practical to avoid spaces in pathname? My€0.02 Like any circumvention, it mqy be practical, but the underlying defect should be fixed. It's socially responsible to report such problems to spare one's peers the cost of re-encountering them. [...] Agreed. My question should be rephrased to something like "are you aware you can circumvent the problem by changing pathname? Can you change it?" Of course "out of curiosity" issues are worth discussion and solution, but usually do not block someone's work. Regards -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VOLCAT split
We've got over 50 entries in our volcat.vgeneral and have had some performance issues. For now we bumped up the STRNO to 10 and that has helped some.It's hard to stop all tape processing in our environment to move entries out of vgeneral. Our storage guys have committed to creating new VOLCAT.Vn when they start adding new ranges. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Friday, November 2, 2018 5:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VOLCAT split **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I guessed so too, but if so, I am interested in number of volsers that hits the limit of 1 volcat.vgeneral. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Giliad Wilf > Sent: 02 November, 2018 10:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VOLCAT split > > Maybe it became too "crowded" and one sees alarming message > IEC361I...or it became a performance issue... > > On Fri, 2 Nov 2018 08:11:38 +, Vernooij, Kees (ITOPT1) - KLM > wrote: > > >Just out of curiosity: why do you want to split VOLCAT? > > > >Kees. > > > > > > > >> -Original Message- > >> From: IBM Mainframe Discussion List > >> [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of R.S. > >> Sent: 01 November, 2018 21:50 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: VOLCAT split > >> > >> I have single file volcat, that means hlq.VOLCAT.VGENERAL. > >> How can I split the general volcat into specific volcats? > >> > >> Anther question: how can I move volcat (general) to another volume? > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > == > >> > >> Je li nie jeste adresatem tej wiadomo ci: > >> > >> - powiadom nas o tym w mailu zwrotnym (dzi kujemy!), > >> - usu trwale t wiadomo (i wszystkie kopie, kt re wydrukowa e > >> lub zapisa e na dysku). > >> Wiadomo ta mo e zawiera chronione prawem informacje, kt re mo e > >> wykorzysta tylko adresat.Przypominamy, e ka dy, kto > >> rozpowszechnia (kopiuje, rozprowadza) t wiadomo lub podejmuje > >> podobne dzia ania, narusza prawo i mo e podlega karze. > >> > >> mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 > >> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. S d Rejonowy dla m. > st. > >> Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, KRS > >> 025237, NIP: 526-021-50-88. Kapita zak adowy (op acony w > ca o ci) > >> wed ug stanu na 01.01.2018 r. wynosi 169.248.488 z otych. > >> > >> If you are not the addressee of this message: > >> > >> - let us know by replying to this e-mail (thank you!), > >> - delete this message permanently (including all the copies which > >> you have printed out or saved). > >> This message may contain legally protected information, which may > >> be used exclusively by the addressee.Please be reminded that anyone > >> who disseminates (copies, distributes) this message or takes any > >> similar action, violates the law and may be penalised. > >> > >> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00- > >> 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court > for > >> the Capital City of Warsaw, 12th Commercial Division of the > >> National Court Register, KRS 025237, NIP: 526-021-50-88. Fully > >> paid-up > share > >> capital amounting to PLN 169,248,488 as at 1 January 2018. > >> > >> --- > >> -- > - > >> 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
Profiles specific to user
Hello lists, I've look around a bit and also realise there's a screen within the RACF panels itself to do the following: Show all dataset profiles that a user has some access to. Is it possible to produce this as a report by parsing DBU00? Found this - http://www.oocities.org/steveneeland/ICE69.txt .. but it lists only profiles that explicitly have that ID in the access list. Is there a way to report all the profiles (DATASET class or otherwise) an ID has access to through 1. direct mentions in the user list 2. one of the user's connected groups 3. lenient UACC As always, thank you so much for your suggestions! Note that I can't run this through Vanguard or zSecure or some such... just have plain old zOS components to exploit. - Vignesh Mainframe Infrastructure MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VOLCAT split
I guessed so too, but if so, I am interested in number of volsers that hits the limit of 1 volcat.vgeneral. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Giliad Wilf > Sent: 02 November, 2018 10:06 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VOLCAT split > > Maybe it became too "crowded" and one sees alarming message IEC361I...or > it became a performance issue... > > On Fri, 2 Nov 2018 08:11:38 +, Vernooij, Kees (ITOPT1) - KLM > wrote: > > >Just out of curiosity: why do you want to split VOLCAT? > > > >Kees. > > > > > > > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of R.S. > >> Sent: 01 November, 2018 21:50 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: VOLCAT split > >> > >> I have single file volcat, that means hlq.VOLCAT.VGENERAL. > >> How can I split the general volcat into specific volcats? > >> > >> Anther question: how can I move volcat (general) to another volume? > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > == > >> > >> Je�li nie jeste� adresatem tej wiadomo�ci: > >> > >> - powiadom nas o tym w mailu zwrotnym (dzi�kujemy!), > >> - usu� trwale t� wiadomo�� (i wszystkie kopie, kt�re wydrukowa�e� lub > >> zapisa�e� na dysku). > >> Wiadomo�� ta mo�e zawiera� chronione prawem informacje, kt�re mo�e > >> wykorzysta� tylko adresat.Przypominamy, �e ka�dy, kto rozpowszechnia > >> (kopiuje, rozprowadza) t� wiadomo�� lub podejmuje podobne dzia�ania, > >> narusza prawo i mo�e podlega� karze. > >> > >> mBank S.A. z siedzib� w Warszawie, ul. Senatorska 18, 00-950 > >> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. S�d Rejonowy dla m. > st. > >> Warszawy XII Wydzia� Gospodarczy Krajowego Rejestru S�dowego, KRS > >> 025237, NIP: 526-021-50-88. Kapita� zak�adowy (op�acony w > ca�o�ci) > >> wed�ug stanu na 01.01.2018 r. wynosi 169.248.488 z�otych. > >> > >> If you are not the addressee of this message: > >> > >> - let us know by replying to this e-mail (thank you!), > >> - delete this message permanently (including all the copies which you > >> have printed out or saved). > >> This message may contain legally protected information, which may be > >> used exclusively by the addressee.Please be reminded that anyone who > >> disseminates (copies, distributes) this message or takes any similar > >> action, violates the law and may be penalised. > >> > >> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00- > >> 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court > for > >> the Capital City of Warsaw, 12th Commercial Division of the National > >> Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up > share > >> capital amounting to PLN 169,248,488 as at 1 January 2018. > >> > >> - > - > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM- > MAIN > > > >For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail > or any attachment may be disclosed, copied or distributed, and that any > other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and delete > this message. > > > >Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any > delay in receipt. > >Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: VOLCAT split
Maybe it became too "crowded" and one sees alarming message IEC361I...or it became a performance issue... On Fri, 2 Nov 2018 08:11:38 +, Vernooij, Kees (ITOPT1) - KLM wrote: >Just out of curiosity: why do you want to split VOLCAT? > >Kees. > > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of R.S. >> Sent: 01 November, 2018 21:50 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: VOLCAT split >> >> I have single file volcat, that means hlq.VOLCAT.VGENERAL. >> How can I split the general volcat into specific volcats? >> >> Anther question: how can I move volcat (general) to another volume? >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> >> >> >> == >> >> Je�li nie jeste� adresatem tej wiadomo�ci: >> >> - powiadom nas o tym w mailu zwrotnym (dzi�kujemy!), >> - usu� trwale t� wiadomo�� (i wszystkie kopie, kt�re wydrukowa�e� lub >> zapisa�e� na dysku). >> Wiadomo�� ta mo�e zawiera� chronione prawem informacje, kt�re mo�e >> wykorzysta� tylko adresat.Przypominamy, �e ka�dy, kto rozpowszechnia >> (kopiuje, rozprowadza) t� wiadomo�� lub podejmuje podobne dzia�ania, >> narusza prawo i mo�e podlega� karze. >> >> mBank S.A. z siedzib� w Warszawie, ul. Senatorska 18, 00-950 >> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. S�d Rejonowy dla m. st. >> Warszawy XII Wydzia� Gospodarczy Krajowego Rejestru S�dowego, KRS >> 025237, NIP: 526-021-50-88. Kapita� zak�adowy (op�acony w ca�o�ci) >> wed�ug stanu na 01.01.2018 r. wynosi 169.248.488 z�otych. >> >> If you are not the addressee of this message: >> >> - let us know by replying to this e-mail (thank you!), >> - delete this message permanently (including all the copies which you >> have printed out or saved). >> This message may contain legally protected information, which may be >> used exclusively by the addressee.Please be reminded that anyone who >> disseminates (copies, distributes) this message or takes any similar >> action, violates the law and may be penalised. >> >> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00- >> 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for >> the Capital City of Warsaw, 12th Commercial Division of the National >> Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share >> capital amounting to PLN 169,248,488 as at 1 January 2018. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >For information, services and offers, please visit our web site: >http://www.klm.com. This e-mail and any attachment may contain confidential >and privileged material intended for the addressee only. If you are not the >addressee, you are notified that no part of the e-mail or any attachment may >be disclosed, copied or distributed, and that any other action related to this >e-mail or attachment is strictly prohibited, and may be unlawful. If you have >received this e-mail by error, please notify the sender immediately by return >e-mail, and delete this message. > >Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its >employees shall not be liable for the incorrect or incomplete transmission of >this e-mail or any attachments, nor responsible for any delay in receipt. >Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch >Airlines) is registered in Amstelveen, The Netherlands, with registered number >33014286 > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VOLCAT split
Just out of curiosity: why do you want to split VOLCAT? Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 01 November, 2018 21:50 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VOLCAT split > > I have single file volcat, that means hlq.VOLCAT.VGENERAL. > How can I split the general volcat into specific volcats? > > Anther question: how can I move volcat (general) to another volume? > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) > według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you > have printed out or saved). > This message may contain legally protected information, which may be > used exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00- > 950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for > the Capital City of Warsaw, 12th Commercial Division of the National > Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share > capital amounting to PLN 169,248,488 as at 1 January 2018. > > -- > 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: VOLCAT split
The HLQ of hlq.VOLCAT.VGENERAL is in LOADxx. I suppose this will also be for the VOLCAT.Vx's. Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 02 November, 2018 1:55 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VOLCAT split > > Splitting is fairly easy > > Create new VOLCAT.V? then repro mergecat > > I think you just need to stop tape processing (READ and WRITE) then just > move > it. > > I am not sure there is anything in LOADxx or other IPL members, but I > would > check that out > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > R.S. > > Sent: Thursday, November 01, 2018 1:50 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: VOLCAT split > > > > I have single file volcat, that means hlq.VOLCAT.VGENERAL. > > How can I split the general volcat into specific volcats? > > > > Anther question: how can I move volcat (general) to another volume? > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > == > > > > Jeśli nie jesteś adresatem tej wiadomości: > > > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > > zapisałeś na dysku). > > Wiadomość ta może zawierać chronione prawem informacje, które może > > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza > > prawo i może podlegać karze. > > > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 > > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. > st. > > Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS > 025237, > > NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według > stanu na > > 01.01.2018 r. wynosi 169.248.488 złotych. > > > > If you are not the addressee of this message: > > > > - let us know by replying to this e-mail (thank you!), > > - delete this message permanently (including all the copies which you > have > > printed out or saved). > > This message may contain legally protected information, which may be > used > > exclusively by the addressee.Please be reminded that anyone who > disseminates > > (copies, distributes) this message or takes any similar action, > violates the > > law and may be penalised. > > > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, > 00-950 > > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for > the > > Capital City of Warsaw, 12th Commercial Division of the National Court > > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share > capital > > amounting to PLN 169,248,488 as at 1 January 2018. > > > > -- > > 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 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
