Problem mounting file system
Hi,
I am having trouble mounting a file system.
I issue the command
MOUNT FILESYSTEM('SYSV.OMVS.PTFS') MOUNTPOINT('/u/ptfs') TYPE(ZFS) MODE(RDWR)
And get
BPXF135E RETURN CODE 0081, REASON CODE EF096055. THE MOUNT FAILED FOR FILE
SYSTEM SYSV.OMVS.PTFS.
Accordint to BPXMTEXT, the meaning of EF096055 is:
zFS Thu Mar 14 14:29:55 EDT 2019
Description: Error with issuing a LOCATE call on an HFS-compat aggregate.
Action: Ensure that the zFS file system named on the MOUNT command has the
same name as the VSAM Linear Data Set (and the HFS compatibility mode
aggregate) that contains the file system.
SYSV.OMVS.PTFS exists
/u/ptfs exists, is a directory and is empty.
What is the problem?
We are running z/OS v2.3.
Gadi
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic LINKLIST impact
Tom, I envision this a something that could be done at the fetch services routine level while preserving the user interface, so that LOAD LINK end users are not affected. The awareness of which library DCB is actually being used for the fetch I/O and whether LNKLIST is ieven nvolved is surely within the fetch service code, not within the code that invokes LOAD or LINK. AFter LNKLST UPDATE of all address spaces is complete it needs to be possible to determine that no LOAD/LINK is still in progress that was initiated prior to the UPDATE (that might yet generate an I/O for the old DCBs) and that no I/Os associated with the old DCBs are still in-flilght or pending. When that is satisfied, I would think the old DCBs could be closed and deallocated safely, rather than waiting on some specified delay time which might or might not be adequate.. Something that is conceptually easy to describe may be difficult to implement, and a major redesign of a critical service like fetch processing is not a casual undertaking; but surely much simpler by several orders of magnitude than changing all code that invokes LOAD or LINK. Perhaps if it were on record as a long-term goal, someone clever would figure out how to get there incrementally. Joel C Ewing On 7/19/19 11:38 AM, Tom Marchant wrote: > On Fri, 19 Jul 2019 10:47:14 -0500, Joel C. Ewing wrote: > >> The manner >> in which services and address spaces were allowed to use LNKLST DCBs >> should have been much better constrained so that those system processes >> using a LNKLST DCB for any extended time were required to "register" >> their active and continuing usage, and each time before actual use check >> whether there is a pending request to quiesce the DCB, in which case if >> possible the service should relinquish its use of the old DCB and >> refresh its LNKLST knowledge. > Wow. You are suggesting that every program that issues LOAD, LINK, etc. > would have to be rewritten, and made considerably more complex. > >> With such a design the system should then >> be able to "advise" user address spaces to cooperate in the UPDATE >> process and know which active address spaces are holding up a safe >> UPDATE. > With such a design, LNKLST would not be transparent, but every program > that loads a module would have to coordinate with LNKLST every time. > -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help wanted | Computerworld Shark Tank
A friend had this long-ago story: he worked at Data General, on a not-yet released product. He saw an ad seeking someone with n years experience on the product. He was the only person on the planet qualified and he wasn't looking to change jobs. Uh oh. On Fri, Jul 19, 2019 at 7:37 AM Mark Regan wrote: Not directly mainframe related, but I think you will get the picture. Help wanted Looking for someone under 30 with 20+ years of experience. Nothing new. I don't remember the exact situation, but I do remember an add in the paper version of ComputerWorld not too long after MVS became available for a system programmer with "n" years of MVS experience. Where "n" was longer than MVS had been available. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP question
No it is not it's some programmers JCL. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, July 20, 2019 12:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FTP question On Fri, 19 Jul 2019 21:10:19 -0400, CarlosM Martinez wrote: >I will have to take a look at the JCL. But it seems you are correct it is a >BATCH OS/MVS SFTP to UNIX. > So it isn't your JCL? >... >Would anyone know what 65280 return code from an FTP could be? >Command: >Sh rm -f -r /u/dmc/mvs/sftp/20190719101931630131 >Failed with a return code 65280 > That looks like a PARM to BPXBATCH. If so, provide DD statements allocating STDOUT and STDERR to SYSOUT for far more information. >Thank you all >Newbe to MVS > If you are new to MVS, would logging on to a UNIX shell be a more familiar environment to you? -- 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: refresh run time libraries after APPLY
On 7/20/2019 6:53 AM, Bill Giannelli wrote: After running a SMPE APPLY, how do you determine which libraries were updated and need to be moved into run time libraries? thanks Bill Bill, The DDDEF report will give you that information. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: refresh run time libraries after APPLY
On Sat, 20 Jul 2019 05:53:04 -0500, Bill Giannelli wrote: >After running a SMPE APPLY, how do you determine which libraries were updated >and need to be moved into run time libraries? >thanks >Bill > Bill, Have a look at the 'File Allocation report' in your SMP/E APPLY output Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
refresh run time libraries after APPLY
After running a SMPE APPLY, how do you determine which libraries were updated and need to be moved into run time libraries? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
