Formatting a ZFS > minds work differently
I found this a fascinating discussion, especially after the original ZFS problem was resolved. Why do sysprogs do things so differently? One of my "theories" is that those, like me, with awful memories for syntax and such make scripts and JCL for everything so that I NEVER start from scratch. Perhaps from doing a lot of map reading (hiking, driving and military) I have an excellent memory for place, so I can always find where I put some JCL/script which is close to what I need. And I guard my "bug-out collection" most carefully. I have worked with people who have amazing memories and they seem far more inclined to work from command lines or write everything ad hoc. And yet for all these differences we seem to get the job done. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, 5 Jul 2017 15:53:15 -0700, Tom Brennan wrote: > >I immediately coded that into a clist so I would make less typos. The >lead lady saw me working one day and said No, you need to type the >entire command out each time. Why? So you won't forget it. What if >your clist fails to work? > >Well, of course I ignored that :) > It should be in the process documentation. Alas, that might weaken, not strengthen your argument for innovation vis-a-vis a pigheaded lead who has all your time in the world to devote to the task. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
W dniu 2017-07-06 o 00:46, Steve Smith pisze: I've had the impression for a long time that *all* LINEAR datasets had a fixed 4K CISIZE (and physical block size). [...] Your impression was valid in the old days, but things had changed many years ago. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Formatting a ZFS
>Would you mind, and do you have time to open a PMR? If zFS cannot cope with >non-default CI size, it should say so clearly when asked to format a new >cluster. At the very least, the 0248 reason code must be documented. Amen. But I really really really hate SR, so I really want to avoid opening one (horror!) and then spend an enourmous amount of time 'discussing' with IBM support (that in my experience) has deteriorated a lot from the 90s (some exceptions noted) when I was IBM support myself. Especially now that I have solved the problem with all of your help. We don't have a direct internet connection, so the thought alone of sending off the dump after tersing it gives me the hives. I just don't have the time to spare. I am also sure that a lot of sysprogs feel the same way about SR. Also, while investigating this, I found other apars that said 'ZFS needs to document reason codes'. Apparently IBM hasn't learned anything from that and still does not document reason codes. Also, while investigating, I tried some variants of direct commands inside OMVS. Inside OMVS gave me 'command not found' (and I don't have the knowledge or the time to figure out how to make it find it). And when I tried the 'tools - run shell command' from inside ishell, I got the same unhelpful 'dataset not found' that I got using the batch job. Admittedly, I didn't try to *define* the dataset that way, just to format a non-conventional VSAM LDS. I just didn't know that it was unconventional at the time. In any case - all of this will make for an interesting 'user experience' presentation at the zTU in Munich in October. Or so I hope. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, 5 Jul 2017 23:37:19 -0500, Bruce Hewson wrote: > >you could also try directly in the shell > >zfsadm define -aggregate 'MVS_DATASET_NAME' -dataclass SMS_DATACLASS >-cylinders 3000 300 > What!? Just a one-line utility command!? No JOB statement? No EXEC statement? No DD statements? Lower case characters, but not quoted? Option names longer than 8 characters? More than 71 characters, but no continuation mark? How could that possibly work on a mainframe? And how could you save it in a member, in case you need to do it again the next day, or in the next decade? I guess it ain't your (grand)father's OS/360. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
Barbara, you could also try directly in the shell zfsadm define -aggregate 'MVS_DATASET_NAME' -dataclass SMS_DATACLASS -cylinders 3000 300 Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, 5 Jul 2017 18:21:32 -0700, Tom Brennan wrote: >John McKown wrote: >> Well, maybe "what if your CLIST library is lost?" would be a better >> question. Of course, most sysprogs believe in redundancy. I XMIT all my >> libraries to separate PS datasets. Which I then BINary download to my >> desktop. Which I then copy to a USB "thumb" drive. Which I then take home >> and put on my home Linux system (in ${HOME} and on both of my NAS boxes >> which are RAID protected). I do the same, but with PAX for my work UNIX >> directories. And the aforementioned are in addition to the normal DFHSM >> and ADRDSSU backups which are kept on the z/OS system. > Cloud? >>I tend to use "sed" or "awk". >> Eeew! I do that only for existing files, not ab ovo, for which I use "cat". >>> And, "Code Rexx so programmers who know only FORTRAN can >>> understand your code." >> >>Hum, and exactly how many of today's programmers know FORTRAN? I think it >>would be better to write the code so that a COBOL programmer could >>understand it. At least for z/OS & z/VSE shops. >> Partly my scientific as opposed to commercial background; partly deliberate choice of an archaic language. I imagine: "Manual transmission ..." "Maintain proficiency in long division lest your slide rule malfunction!" "Maintain proficiency making yarn by hand lest your spinning wheel break!" >And you're right, XMIT, USB drives, etc. have made it easy to back up >personal datasets like the JCL people take from job to job. A long time >ago I had a "just in case I get fired" 3480 tape at home. > Sometimes I've done that; sometimes I've taken the grandiose position that I'm too ethical. Nowadays there are too many ways to get caught. But one of the Sams has told me that cbttape.org supports stealth submissions of what might be deemed work product. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 5 July 2017 at 20:58, John McKown wrote: > Hum, and exactly how many of today's programmers know FORTRAN? I think it > would be better to write the code so that a COBOL programmer could > understand it. At least for z/OS & z/VSE shops. And as we all know, if a COBOL programmer can understand it, then a manager can understand it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
John McKown wrote: Well, maybe "what if your CLIST library is lost?" would be a better question. Of course, most sysprogs believe in redundancy. I XMIT all my libraries to separate PS datasets. Which I then BINary download to my desktop. Which I then copy to a USB "thumb" drive. Which I then take home and put on my home Linux system (in ${HOME} and on both of my NAS boxes which are RAID protected). I do the same, but with PAX for my work UNIX directories. And the aforementioned are in addition to the normal DFHSM and ADRDSSU backups which are kept on the z/OS system. Then it's back to that DEFINE command that I can apparently still type today without thinking! The clist was in a common system programmer library, probably as unlikely to be lost as SYS1.LINKLIB (knock on wood). And you're right, XMIT, USB drives, etc. have made it easy to back up personal datasets like the JCL people take from job to job. A long time ago I had a "just in case I get fired" 3480 tape at home. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, Jul 5, 2017 at 7:43 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 5 Jul 2017 15:53:15 -0700, Tom Brennan wrote: > > > >... you're going against the lead systems programmer very early in my > >career (1983). One of the grunt-work things I had to do was create an > >alias for each new TSO id. I was taught the procedure as: > > > > a) Get the next paper from the pile of new TSO id requests > > b) Logon and issue a command such as: > > DEFINE ALIAS(NAME('XYZ123') RELATE('ICFCAT.SYS123')) > > > >I immediately coded that into a clist so I would make less typos. The > >lead lady saw me working one day and said No, you need to type the > >entire command out each time. Why? So you won't forget it. What if > >your clist fails to work? > > > >Well, of course I ignored that :) > > > NIH. > > And UNIX mavens have advised me to maintain a mastery of "ex". > What if you must use a terminal lacking "vi" capability? (Same > about ISPF.) > I tend to use "sed" or "awk". > > And, "Code Rexx so programmers who know only FORTRAN can > understand your code." > Hum, and exactly how many of today's programmers know FORTRAN? I think it would be better to write the code so that a COBOL programmer could understand it. At least for z/OS & z/VSE shops. > > -- gil > > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, Jul 5, 2017 at 5:53 PM, Tom Brennan wrote: > Gibney, Dave wrote: > >> Either or both are more keystrokes than I care to do frequently on the >> fly. Typos happen. >> Write once, cut'n'paste forever. >> > > But you're going against the lead systems programmer very early in my > career (1983). One of the grunt-work things I had to do was create an > alias for each new TSO id. I was taught the procedure as: > > a) Get the next paper from the pile of new TSO id requests > b) Logon and issue a command such as: > DEFINE ALIAS(NAME('XYZ123') RELATE('ICFCAT.SYS123')) > > I immediately coded that into a clist so I would make less typos. The > lead lady saw me working one day and said No, you need to type the entire > command out each time. Why? So you won't forget it. What if your clist > fails to work? > Well, maybe "what if your CLIST library is lost?" would be a better question. Of course, most sysprogs believe in redundancy. I XMIT all my libraries to separate PS datasets. Which I then BINary download to my desktop. Which I then copy to a USB "thumb" drive. Which I then take home and put on my home Linux system (in ${HOME} and on both of my NAS boxes which are RAID protected). I do the same, but with PAX for my work UNIX directories. And the aforementioned are in addition to the normal DFHSM and ADRDSSU backups which are kept on the z/OS system. > > Well, of course I ignored that :) > > -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, 5 Jul 2017 15:53:15 -0700, Tom Brennan wrote: > >... you're going against the lead systems programmer very early in my >career (1983). One of the grunt-work things I had to do was create an >alias for each new TSO id. I was taught the procedure as: > > a) Get the next paper from the pile of new TSO id requests > b) Logon and issue a command such as: > DEFINE ALIAS(NAME('XYZ123') RELATE('ICFCAT.SYS123')) > >I immediately coded that into a clist so I would make less typos. The >lead lady saw me working one day and said No, you need to type the >entire command out each time. Why? So you won't forget it. What if >your clist fails to work? > >Well, of course I ignored that :) > NIH. And UNIX mavens have advised me to maintain a mastery of "ex". What if you must use a terminal lacking "vi" capability? (Same about ISPF.) And, "Code Rexx so programmers who know only FORTRAN can understand your code." -- 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: Formatting a ZFS
Gibney, Dave wrote: Either or both are more keystrokes than I care to do frequently on the fly. Typos happen. Write once, cut'n'paste forever. But you're going against the lead systems programmer very early in my career (1983). One of the grunt-work things I had to do was create an alias for each new TSO id. I was taught the procedure as: a) Get the next paper from the pile of new TSO id requests b) Logon and issue a command such as: DEFINE ALIAS(NAME('XYZ123') RELATE('ICFCAT.SYS123')) I immediately coded that into a clist so I would make less typos. The lead lady saw me working one day and said No, you need to type the entire command out each time. Why? So you won't forget it. What if your clist fails to work? Well, of course I ignored that :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
I've had the impression for a long time that *all* LINEAR datasets had a fixed 4K CISIZE (and physical block size). 4K seems to be the default in IDCAMS, but not the rule. Maybe there's a good reason not to stick with 4K, but it appears ZFS assumes it, and I suspect that "Window Services" also does. sas On Wed, Jul 5, 2017 at 4:24 PM, Peter Hunkeler wrote: > > > > > TSO BPXMTEXT EA0B0248 > > > > So did I, with same unsatisfying result. And as you wrote, the 0248 reason > code is not documented with the IOE message. > > > Would you mind, and do you have time to open a PMR? If zFS cannot cope > with non-default CI size, it should say so clearly when asked to format a > new cluster. At the very least, the 0248 reason code must be documented. > > > -- > Peter Hunkeler > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 5 July 2017 at 16:05, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > READY > ... > ALLOCATE DD(SYSUT1) DSN(*) > [ up to about a dozen lines of source code ] > /* > CALL 'SYS1.LINKLIB(IFOX00)' > > Showoff. Yup. That terminal as a workfile is a great trick... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Formatting a ZFS
> TSO BPXMTEXT EA0B0248 So did I, with same unsatisfying result. And as you wrote, the 0248 reason code is not documented with the IOE message. Would you mind, and do you have time to open a PMR? If zFS cannot cope with non-default CI size, it should say so clearly when asked to format a new cluster. At the very least, the 0248 reason code must be documented. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 2017-07-05, at 13:46, Gibney, Dave wrote: > Oh, I am sure it can, but most folks I know who focus interactive rather than > repeatable, don't bother. > >>> A JCL member can be available again tomorrow or sometime in the next >> decade when the task need repeating. >>> >> ??? >> >> Do you truly fail to understand that a shell script can be saved in a file >> for use >> in the next day or the next decade, even as a JCL member can? >> Much of the variation in behavior can be attributed to the difference between JCL: //NAMEJOB ... //STEPEXEC PGM=IEBGENER //SYSINDD * //SYSPRINT DD SYSOUT=(,) //SYSUT2 DD DISP=(,CATLG),UNIT=SYSALLDA,SPACE=(1000,100), // DSN=OUTPUT.FILE //SYSUT1 DD DISP=SHR,DSN=INPUT.FILE and UNIX: cp INPUT.FILE OUTPUT.FILE I'm more motivated to save the former in a member and issue the latter interactively -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 2017-07-05, at 13:53, Gibney, Dave wrote: >> >>> A JCL member can be available again tomorrow or sometime in the next >>> decade when the task need repeating. >>> >> True, but so can a shell script. ... > > Either or both are more keystrokes than I care to do frequently on the fly. > Typos happen. > Write once, cut'n'paste forever. > I suspect programmers are more alike than you allow for. I can hardly imagine a proficient UNIX programmer who won't use a script for a recurrent task. OTOH, I know a proficient Assembler programmer whom I used to watch as he: READY ... ALLOCATE DD(SYSUT1) DSN(*) [ up to about a dozen lines of source code ] /* CALL 'SYS1.LINKLIB(IFOX00)' Showoff. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, Jul 5, 2017 at 2:53 PM, Gibney, Dave wrote: > > > > mkdir ~/temp > > zfsadm define -aggregate myhlq.temp.zfs -cyl 20 10 > > zfsadm format -aggregate myhlq.temp.zfs -perms 0755 -compat -version5 > > mount -f myhlq.temp.zfs ~/temp > > # bunch of commands which use the temp space > > unmount ~/temp > > rmdir ~/temp > > tsocmd "del temp.zfs" > > > > Either or both are more keystrokes than I care to do frequently on the > fly. Typos happen. > Write once, cut'n'paste forever. > The above took me about 30 seconds to type in. 0 to 3 typos in total. I'm a decent touch typist, albeit not a professional. > > I heard it here long ago. Everyone is allocated a finite number of > keystrokes, and when they're over, the H'.. with you. > Hum, hope I got a double supply. I've been typing for over 50 years now. I learned as a teen in the late 1960s, when my mom took a keypunch class. -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of John McKown > Sent: Wednesday, July 05, 2017 12:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Formatting a ZFS > > On Wed, Jul 5, 2017 at 2:33 PM, Gibney, Dave wrote: > > > A JCL member can be available again tomorrow or sometime in the next > > decade when the task need repeating. > > > > > True, but so can a shell script. However, I think that in most cases the > majority of z/OS people are more likely to understand the JCL than a shell > script. This even though I, personally, prefer to use shell commands (yes, > I just remember them - likely means I use them too often). The main reason > being that I sometimes end up being in a UNIX environment (shell prompt > instead of TSO) and want to make a "scratch filesystem" for some temporary > space. It's easier for me to: > > mkdir ~/temp > zfsadm define -aggregate myhlq.temp.zfs -cyl 20 10 > zfsadm format -aggregate myhlq.temp.zfs -perms 0755 -compat -version5 > mount -f myhlq.temp.zfs ~/temp > # bunch of commands which use the temp space > unmount ~/temp > rmdir ~/temp > tsocmd "del temp.zfs" > > Not as easy as using a TSO ALLOC command in TSO, but simpler for me to do > than "switching mindset to TSO / JCL" to allocate & format the UNIX space. Either or both are more keystrokes than I care to do frequently on the fly. Typos happen. Write once, cut'n'paste forever. I heard it here long ago. Everyone is allocated a finite number of keystrokes, and when they're over, the H'.. with you. > > > > -- > Veni, Vidi, VISA: I came, I saw, I did a little shopping. > > Maranatha! <>< > John McKown > > -- > 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: Formatting a ZFS
On Wed, Jul 5, 2017 at 2:33 PM, Gibney, Dave wrote: > A JCL member can be available again tomorrow or sometime in the next > decade when the task need repeating. > > True, but so can a shell script. However, I think that in most cases the majority of z/OS people are more likely to understand the JCL than a shell script. This even though I, personally, prefer to use shell commands (yes, I just remember them - likely means I use them too often). The main reason being that I sometimes end up being in a UNIX environment (shell prompt instead of TSO) and want to make a "scratch filesystem" for some temporary space. It's easier for me to: mkdir ~/temp zfsadm define -aggregate myhlq.temp.zfs -cyl 20 10 zfsadm format -aggregate myhlq.temp.zfs -perms 0755 -compat -version5 mount -f myhlq.temp.zfs ~/temp # bunch of commands which use the temp space unmount ~/temp rmdir ~/temp tsocmd "del temp.zfs" Not as easy as using a TSO ALLOC command in TSO, but simpler for me to do than "switching mindset to TSO / JCL" to allocate & format the UNIX space. -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
Oh, I am sure it can, but most folks I know who focus interactive rather than repeatable, don't bother. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Wednesday, July 05, 2017 12:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Formatting a ZFS > > On 2017-07-05, at 13:33, Gibney, Dave wrote: > > > A JCL member can be available again tomorrow or sometime in the next > decade when the task need repeating. > > > ??? > > Do you truly fail to understand that a shell script can be saved in a file > for use > in the next day or the next decade, even as a JCL member can? > > >> -Original Message- > >> From: Paul Gilmartin > >> Sent: Wednesday, July 05, 2017 12:26 PM > >> > >>> ... Perhaps because it's easier to save the JCL in a dataset and > >>> modify it, rather that using a shell script. > >>> > >> I fail to discern much difference. In the former case, I tweak; SUBMIT; > CANCEL. > >> In the latter case, I tweak; ":w ! sh"; ":q!" > > -- 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: Formatting a ZFS
On 2017-07-05, at 13:33, Gibney, Dave wrote: > A JCL member can be available again tomorrow or sometime in the next decade > when the task need repeating. > ??? Do you truly fail to understand that a shell script can be saved in a file for use in the next day or the next decade, even as a JCL member can? >> -Original Message- >> From: Paul Gilmartin >> Sent: Wednesday, July 05, 2017 12:26 PM >> >>> ... Perhaps because it's easier to save the JCL in a dataset and modify >>> it, rather that using a shell script. >>> >> I fail to discern much difference. In the former case, I tweak; SUBMIT; >> CANCEL. >> In the latter case, I tweak; ":w ! sh"; ":q!" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
A JCL member can be available again tomorrow or sometime in the next decade when the task need repeating. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Wednesday, July 05, 2017 12:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Formatting a ZFS > > On Wed, 5 Jul 2017 13:00:06 -0500, John McKown wrote: > > > >... Perhaps because it's easier to save the JCL in a dataset and modify > >it, rather that using a shell script. > > > I fail to discern much difference. In the former case, I tweak; SUBMIT; > CANCEL. > In the latter case, I tweak; ":w ! sh"; ":q!" > > -- 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: Formatting a ZFS
On Wed, 5 Jul 2017 13:00:06 -0500, John McKown wrote: > >... Perhaps because it's easier to save the JCL in a >dataset and modify it, rather that using a shell script. > I fail to discern much difference. In the former case, I tweak; SUBMIT; CANCEL. In the latter case, I tweak; ":w ! sh"; ":q!" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 5 July 2017 at 08:20, Barbara Nitz wrote: > TSO BPXMTEXT EA0B0248 > > BPXMTEXT does not support reason code qualifier EA0B > > That was the first thing I tried. Seems to me zFS should support the function described in the UNIX System Services File System Interface Reference under "PFS support for reason code error text". This allows a PFS to provide a range for the high byte of reason codes it supports, and then the kernel pfsctl() call used to retrieve messages can farm the request out to the PFS rather than warn about an unknown "module ID". If I were you, and had the time and energy, I'd PMR this as a standalone issue. Why should there be undocumented reason codes at all? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, Jul 5, 2017 at 12:53 PM, J R wrote: > Well known? I only "know" you from this and the assembler list. As far > as I recall, you are the only person that has categorized yourself as weird! > I guess that I characterize myself that way since I do things a bit differently than most of the people that I know (that is, read on this and other lists). Example, using zfsadm in a UNIX shell instead of JCL in a batch job to create zFS filesystems. Both work, but "most" seen oriented towards the JCL version. Perhaps because it's easier to save the JCL in a dataset and modify it, rather that using a shell script. -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
Well known? I only "know" you from this and the assembler list. As far as I recall, you are the only person that has categorized yourself as weird! > On Jul 5, 2017, at 12:03, John McKown wrote: > > But I'm well known for doing "weird" things. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On Wed, Jul 5, 2017 at 10:52 AM, Lizette Koehler wrote: > Barbara, > > At this time, I am now formatting my zFS files a version5. According to > IBM doc this is a better way to go. > > I see you got around your Format by changing your IDCAMS definitions. It > would be nice if IBM could provide better error messages. > > Lizette > > I find doing this to be _much_ easier, for me, from an actual, true-to-life, UNIX shell prompt zfsadm define -aggregate some.lds.dataset.name.zfs -cylinders 20 10 zfsadm format -aggregate some.lds.dataset.name.zfs -compat -perms 0755 -uid 0 -group 0 -version5 mkdir /some/mount/point mount -f some.lds.dataset.name.zfs /some/mount/point But I'm well known for doing "weird" things. Using SMS, I only need the DSN and cylinders to allocate (or -megabytes, -kilobytes if I prefer) -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
Barbara, At this time, I am now formatting my zFS files a version5. According to IBM doc this is a better way to go. I see you got around your Format by changing your IDCAMS definitions. It would be nice if IBM could provide better error messages. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Barbara Nitz > Sent: Wednesday, July 05, 2017 12:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Formatting a ZFS > > I am fighting with USS. Again. > > I am installing HCR77C0 and am trying to get a ZFS formatted: > //ZFSALLOC EXEC PGM=IDCAMS > //SYSPRINT DD SYSOUT=* > //SYSINDD * > DEFINE CLUSTER( - >CONTROLINTERVALSIZE(26624) - >NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) - >LINEAR CYLINDERS(100 50) - >SHAREOPTIONS(3) - > ) > //ZFSFORMT EXEC PGM=IOEFSUTL, > // PARM='format -aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -version5' > //SYSPRINT DD SYSOUT=* > > IDCAMS output: > IDC0508I DATA ALLOCATION STATUS FOR VOLUME INST00 IS 0 > IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 > IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 > IDC0512I NAME GENERATED-(D) INSTSMP.ICSF.HCR77C0.SCSFHFS.DATA > IDC0181I STORAGECLASS USED IS x > IDC0181I DATACLASS USED IS y > IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 > > IOEFSUTL output: > HLQ INSTSMP is SMS-managed now (but I got the same error when it wasn't SMS): > Version 02.01.00 Service Level OA50873 - HZFS410. > IOEZ00760I No IOEZPRM DD specified. Parmlib search being used. > IOEZ4I Formatting to 8K block number 1300 for primary extent of > INSTSMP.ICSF.HCR77C0.SCSFHFS. > IOEZ00337E zFS kernel: non-terminating exception 2C3 occurred, reason > EA0B0248 abend psw 77C1000 906814A2 > IOEZ00033E FSUTL: could not open trace output dataset > IOEZ00334I Return code and reason code for dump is 4000 > IOEZ00598E Error 157 reason code EFE16137 received formatting aggregate > INSTSMP.ICSF.HCR77C0.SCSFHFS > > There is an SVCdump written. Every time I reran the job. Needless to say - I > was unable to find documentation for the reason code(s) received, much less > any hint what might be wrong. This job used to work, last on a system without > the 'refreshed' maintenance in (January of this year). Didn't find any ptf > which might describe my problem. > > Using this for formatting > //ZFSFORMT EXEC PGM=IOEAGFMT, > // PARM='-aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -compat' > //SYSPRINT DD SYSOUT=* > > gets me IOEZ00207E Aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS was not found > > which isn't really helpful ("An attempt was made to attach or format an > aggregate, but no VSAM linear data set could be found with the given name.") > > Does anyone have an idea what might be wrong or do I really have to go > through the crap named SR? > > HFSs still work like a charm > > Barbara > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 7/5/2017 5:37 AM, Barbara Nitz wrote: Thanks for the good laugh, Tom! Now exit, stage left, muttering: Why didn't IBM just specify in plain English that one cannot determine CISIZE instead of using an obscure, undocumented reason code and an unhelpful amount of dumps and messages?!?!? Barbara, 1. Bitte schoen. 2. Preach it, sistah! Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
TSO BPXMTEXT EA0B0248 BPXMTEXT does not support reason code qualifier EA0B That was the first thing I tried. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
TSO BPXMTEXT EA0B0248 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: Wednesday, July 5, 2017 2:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Formatting a ZFS I am fighting with USS. Again. I am installing HCR77C0 and am trying to get a ZFS formatted: //ZFSALLOC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * DEFINE CLUSTER( - CONTROLINTERVALSIZE(26624) - NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) - LINEAR CYLINDERS(100 50) - SHAREOPTIONS(3) - ) //ZFSFORMT EXEC PGM=IOEFSUTL, // PARM='format -aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -version5' //SYSPRINT DD SYSOUT=* IDCAMS output: IDC0508I DATA ALLOCATION STATUS FOR VOLUME INST00 IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0512I NAME GENERATED-(D) INSTSMP.ICSF.HCR77C0.SCSFHFS.DATA IDC0181I STORAGECLASS USED IS x IDC0181I DATACLASS USED IS y IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IOEFSUTL output: HLQ INSTSMP is SMS-managed now (but I got the same error when it wasn't SMS): Version 02.01.00 Service Level OA50873 - HZFS410. IOEZ00760I No IOEZPRM DD specified. Parmlib search being used. IOEZ4I Formatting to 8K block number 1300 for primary extent of INSTSMP.ICSF.HCR77C0.SCSFHFS. IOEZ00337E zFS kernel: non-terminating exception 2C3 occurred, reason EA0B0248 abend psw 77C1000 906814A2 IOEZ00033E FSUTL: could not open trace output dataset IOEZ00334I Return code and reason code for dump is 4000 IOEZ00598E Error 157 reason code EFE16137 received formatting aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS There is an SVCdump written. Every time I reran the job. Needless to say - I was unable to find documentation for the reason code(s) received, much less any hint what might be wrong. This job used to work, last on a system without the 'refreshed' maintenance in (January of this year). Didn't find any ptf which might describe my problem. Using this for formatting //ZFSFORMT EXEC PGM=IOEAGFMT, // PARM='-aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -compat' //SYSPRINT DD SYSOUT=* gets me IOEZ00207E Aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS was not found which isn't really helpful ("An attempt was made to attach or format an aggregate, but no VSAM linear data set could be found with the given name.") Does anyone have an idea what might be wrong or do I really have to go through the crap named SR? HFSs still work like a charm Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN
Re: Formatting a ZFS
Every zfs doc I've ever seen has CISIZE of 4096. 1. First, use IDCAMS to create a VSAM linear data set. Note: Carefully consider defining the aggregate as extended format, extended addressability, and with a secondary allocation size. If you do not use these attributes in the beginning, to add them, you will need to define and format a new zFS aggregate, migrate the data from the original file system into the new one, unmount the original, and then mount the new one. You might want to extend beyond the 4 G aggregate size because version 1.5 aggregates can be much larger than version 1.4 aggregates, or because secondary extents are required to dynamically grow the aggregate, and dynamic grow (aggrgrow) is the default. See _Dynamically growing a compatibility mode aggregate_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioea7d0041006636.htm?view=kc#ioea7d0041006636) for more information. 2. Then format the VSAM linear data set as a compatibility mode aggregate and create a file system in the aggregate using ioeagfmt (see _ioeagfmt_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioea7zcmd1031559.htm?view=kc#ioea7zcmd1031559) ). When using ioeagfmt, the user must meet one of the following authorization requirements: * Have ALTER authority to the VSAM linear data set. * Be UID 0. * Have read authority to the SUPERUSER.FILESYS.PFSCTL resource in the RACF UNIXPRIV class. Beginning in z/OS V2R1, ioeagfmt fails if the zFS PFS is not active on the system. In addition, if the zFS started task does not have the TRUSTED attribute or the OPERATIONS attribute, the DFS user ID must have at least ALTER authority to all VSAM linear data sets that contain zFS aggregates. For details, see _z/OS Security Server RACF Security Administrator's Guide_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.icha7 00/toc.htm?view=kc) . You can also create a compatibility mode aggregate using the ISHELL, or the automount facility, or the zfsadm define and zfsadm format commands. For more information about ISHELL, see _z/OS V2R2.0 UNIX System Services User's Guide_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxa400/toc.htm?view=kc) . For more information about automount, see _z/OS UNIX System Services Planning_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxb200/toc.htm?view=kc) . For more information about the zfsadm define command, see _zfsadm define_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioe a70021.htm?view=kc#ioea700-gen20) . For more information about the zfsadm format command, see _zfsadm format_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioea70022.htm?view=kc#ioea700-gen 21) . The VSAM linear data set, the aggregate, and the file system all have the same name and that name is equal to the VSAM linear data set cluster name. The zFS file system is then mounted into the z/OS® UNIX hierarchy. Rule: The Control Interval (CI) size of a VSAM linear data set that is formatted as a zFS aggregate must be 4 K. This is the default for IDCAMS. As such, it is not specified in _Figure 1_ (https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioea7d0041003067.htm?view=kc#i oea7d0041003067__ioea7d0041003169) , which shows an example of a job that creates a compatibility mode file system. Figure 1. Example job to create a compatibility mode file system //USERIDA JOB ,'Compatibility Mode', // CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1) //DEFINE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=H //SYSUDUMP DD SYSOUT=H //AMSDUMP DD SYSOUT=H //DASD0DD DISP=OLD,UNIT=3390,VOL=SER=PRV000 //SYSINDD * DEFINE CLUSTER (NAME(OMVS.PRV.COMPAT.AGGR001) - VOLUMES(PRV000) - LINEAR CYL(25 0) SHAREOPTIONS(3)) /* //CREATE EXEC PGM=IOEAGFMT,REGION=0M, // PARM=('-aggregate OMVS.PRV.COMPAT.AGGR001 -compat') //SYSPRINT DD SYSOUT=H //STDOUT DD SYSOUT=H //STDERR DD SYSOUT=H //SYSUDUMP DD SYSOUT=H //CEEDUMP DD SYSOUT=H In a message dated 7/5/2017 4:38:39 A.M. Central Daylight Time, nitz-...@gmx.net writes: Now exit, stage left, muttering: Why didn't IBM just specify in plain English that one cannot determine CISIZE instead of using an obscure, undocumented reason code and an unhelpful amount of dumps and messages?!?!? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
>Weird one. Since IOEZPARM is saying 8K block, I'd try CISIZE(8192). If >it still doesn't work, scheisse zeit. Bingo. The collective wisdom of this group is great! With CONTROLINTERVALSIZE(8192) I get the same problem as before, so I left it off completely (as Peter suggested), and the ZFS formatted just fine. I may have found this myself at a later date, since the job (without CISIZE) ran on another sysplex and I may have seen the difference one of these years. I don't know why I had this parm in in the first place. Thanks for the good laugh, Tom! Now exit, stage left, muttering: Why didn't IBM just specify in plain English that one cannot determine CISIZE instead of using an obscure, undocumented reason code and an unhelpful amount of dumps and messages?!?!? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Formatting a ZFS
> I am installing HCR77C0 and am trying to get a ZFS formatted: -- Peter Hunkeler > //ZFSALLOC EXEC PGM=IDCAMS > //SYSPRINT DD SYSOUT=* > //SYSINDD * > DEFINE CLUSTER( - > CONTROLINTERVALSIZE(26624) - > NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) - > LINEAR CYLINDERS(100 50) - > SHAREOPTIONS(3) - > ) Not that I knew it does hurt, but I never saw an example, and never had been using the CONTROLINTERVALSIZE operand for a zFS LDS cluster. Have you tried without? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Formatting a ZFS
On 7/5/2017 3:41 AM, Barbara Nitz wrote: I am fighting with USS. Again. I am installing HCR77C0 and am trying to get a ZFS formatted: //ZFSALLOC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * DEFINE CLUSTER( - CONTROLINTERVALSIZE(26624) - NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) - LINEAR CYLINDERS(100 50) - SHAREOPTIONS(3) - ) //ZFSFORMT EXEC PGM=IOEFSUTL, // PARM='format -aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -version5' //SYSPRINT DD SYSOUT=* IDCAMS output: IDC0508I DATA ALLOCATION STATUS FOR VOLUME INST00 IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0512I NAME GENERATED-(D) INSTSMP.ICSF.HCR77C0.SCSFHFS.DATA IDC0181I STORAGECLASS USED IS x IDC0181I DATACLASS USED IS y IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IOEFSUTL output: HLQ INSTSMP is SMS-managed now (but I got the same error when it wasn't SMS): Version 02.01.00 Service Level OA50873 - HZFS410. IOEZ00760I No IOEZPRM DD specified. Parmlib search being used. IOEZ4I Formatting to 8K block number 1300 for primary extent of INSTSMP.ICSF.HCR77C0.SCSFHFS. IOEZ00337E zFS kernel: non-terminating exception 2C3 occurred, reason EA0B0248 abend psw 77C1000 906814A2 IOEZ00033E FSUTL: could not open trace output dataset IOEZ00334I Return code and reason code for dump is 4000 IOEZ00598E Error 157 reason code EFE16137 received formatting aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS There is an SVCdump written. Every time I reran the job. Needless to say - I was unable to find documentation for the reason code(s) received, much less any hint what might be wrong. This job used to work, last on a system without the 'refreshed' maintenance in (January of this year). Didn't find any ptf which might describe my problem. Barbara, Weird one. Since IOEZPARM is saying 8K block, I'd try CISIZE(8192). If it still doesn't work, scheisse zeit. Tom PS. Hope to see you in Munich again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Formatting a ZFS
I am fighting with USS. Again. I am installing HCR77C0 and am trying to get a ZFS formatted: //ZFSALLOC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * DEFINE CLUSTER( - CONTROLINTERVALSIZE(26624) - NAME(INSTSMP.ICSF.HCR77C0.SCSFHFS) - LINEAR CYLINDERS(100 50) - SHAREOPTIONS(3) - ) //ZFSFORMT EXEC PGM=IOEFSUTL, // PARM='format -aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -version5' //SYSPRINT DD SYSOUT=* IDCAMS output: IDC0508I DATA ALLOCATION STATUS FOR VOLUME INST00 IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0508I DATA ALLOCATION STATUS FOR VOLUME * IS 0 IDC0512I NAME GENERATED-(D) INSTSMP.ICSF.HCR77C0.SCSFHFS.DATA IDC0181I STORAGECLASS USED IS x IDC0181I DATACLASS USED IS y IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IOEFSUTL output: HLQ INSTSMP is SMS-managed now (but I got the same error when it wasn't SMS): Version 02.01.00 Service Level OA50873 - HZFS410. IOEZ00760I No IOEZPRM DD specified. Parmlib search being used. IOEZ4I Formatting to 8K block number 1300 for primary extent of INSTSMP.ICSF.HCR77C0.SCSFHFS. IOEZ00337E zFS kernel: non-terminating exception 2C3 occurred, reason EA0B0248 abend psw 77C1000 906814A2 IOEZ00033E FSUTL: could not open trace output dataset IOEZ00334I Return code and reason code for dump is 4000 IOEZ00598E Error 157 reason code EFE16137 received formatting aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS There is an SVCdump written. Every time I reran the job. Needless to say - I was unable to find documentation for the reason code(s) received, much less any hint what might be wrong. This job used to work, last on a system without the 'refreshed' maintenance in (January of this year). Didn't find any ptf which might describe my problem. Using this for formatting //ZFSFORMT EXEC PGM=IOEAGFMT, // PARM='-aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS -compat' //SYSPRINT DD SYSOUT=* gets me IOEZ00207E Aggregate INSTSMP.ICSF.HCR77C0.SCSFHFS was not found which isn't really helpful ("An attempt was made to attach or format an aggregate, but no VSAM linear data set could be found with the given name.") Does anyone have an idea what might be wrong or do I really have to go through the crap named SR? HFSs still work like a charm Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN