Re: ZOA Open Automation Utilities
On Fri, 21 Feb 2020 19:58:18 +, Seymour J Metz wrote: >Tear down both walls. IBM provides ANSI REXX routine in Unix System Services >that it does not provide for TSO users. > (and vice-versa for compiled Rexx?) In neither does it provide SIGNAL ON NOTREADY. Is that an ANSI requirement? Can't readily be done with a function package. Hmmm... What should lines() and chars() do for: o A data set ending with an empty line? The ironic behavior that chars() return 0 and lines() return 1? o A transient stream such as a terminal or a pipe? Issue a blocking read and not return before the answer is known? I've fought that battle with a Pascal RTL. Didn't quite win. From: Paul Gilmartin Sent: Friday, February 21, 2020 12:26 PM On Fri, 21 Feb 2020 10:45:36 -0600, Mike Fulton wrote: >The intent is to also provide these services from the language of your choice >... > Rexx? There's a formidable barrier between Unix System Services and TSO. Mr. Fulton, tear down that wall! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, 21 Feb 2020 11:52:50 -0600, Mike Fulton wrote: >... >Would you be after using REXX in the USS environment or TSO? If in USS, ... > It shouldn't matter. In fact, I'm mystified that ADDRESS SH isn't available from the TSO or IRXJCL environment when it can be synthesized with modest effort with ADDRESS SYSCALL. But why should the customer need to do that? On Fri, 21 Feb 2020 11:51:21 -0600, John McKown wrote > >IIRC, someone here said that they used NFS to mount some z/OS high level >qualifier (or maybe a node like A.B) as a "filesystem" and so access the >DSNs via a UNIX path. > Me? In fact I tried something like that years ago. My sysprog created the map entries at my request. Performance was unacceptable and inexplicable. No battle worth fighting. I reverted to keeping my data on a Solaris server. Sometimes mounted twice: text/EBCDIC but binary for compiler SYSPUNCH. The worst was when DASD overflowed with HSM recalls after a few days. Sysprog found and killed the Solaris process doing a wildcard access; and added NORECALL to the map. NORECALL has wrong granularity -- it should have an option to allow recall for specific paths as by open(), but forbid for generic as by readdir(). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM APIs in a multi-vendor world
The same environment requirements as the ARCHDEL assembler macro would be fine. Batch or OMVS (not TSO, not CICS, etc). On Fri, Feb 21, 2020 at 2:40 AM Timothy Sipples wrote: > Kirk Wolf wrote: > >I could deal with some configuration of the pseudo-volser, > >but our product doesn't run under TSO, so a "command" > >interface isn't convenient. > > What runtime environment and programming language are you using? > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > > -- > 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: Cell Pool Services CSRC4EXP
Peter
Thanks it would seem then if I would I want to have the actual storage in the
target address space I would have to schedule an SRB
I could then issue CSRCxGET from a from that address space the cell returned
could be addressed in AR mode with using the ALET
> On Feb 21, 2020, at 3:33 PM, Peter Relson wrote:
>
> What is the question? There is no question within the post.
>
> The cell storage (as opposed to the storage for the control structures
> managing the cell storage, which can be thought of as the "anchor" and the
> "extent") is not touched by the service. There is one ALET used for the
> suite of services. That is referred to as the control ALET ("cntl_alet").
> It applies to both the anchor and the extent. As one would expect, it
> does not apply to the cell storage. Whether the ALET represents an address
> space or data space is unimportant to the system.
>
> What part of the documentation is unclear, so that we can improve it
> appropriately?
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
What is the question? There is no question within the post.
The cell storage (as opposed to the storage for the control structures
managing the cell storage, which can be thought of as the "anchor" and the
"extent") is not touched by the service. There is one ALET used for the
suite of services. That is referred to as the control ALET ("cntl_alet").
It applies to both the anchor and the extent. As one would expect, it
does not apply to the cell storage. Whether the ALET represents an address
space or data space is unimportant to the system.
What part of the documentation is unclear, so that we can improve it
appropriately?
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
Tear down both walls. IBM provides ANSI REXX routine in Unix System Services that it does not provide for TSO users. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, February 21, 2020 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ZOA Open Automation Utilities On Fri, 21 Feb 2020 10:45:36 -0600, Mike Fulton wrote: >IBM Z Open Automation Utilities is a free FMID today. >We are changing this to make it a free PID: >http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en > >The goal of ZOAU is to provide access to MVS resources from the Unix System >Services environment directly through core 'atomic' services like dls (dataset >list) which works in an analagous way to ls (zFS file list) and so forth for >other MVS resources. > A laudable goal. >The intent is to also provide these services from the language of your choice >- so base 'sh' is supported but so is Python and Java, and a general DLL >interface is provided so that other language support could be provided. > Rexx? There's a formidable barrier between Unix System Services and TSO. In "z/OS TSO/E REXX Reference' see the section "TSO/E external functions". Those functions should seamlessly be made available to Rexx execs running under Unix System Services. Likewise commands such as RECEIVE. Mr. Fulton, tear down that wall! >I wrote a blog about this for those that are interested: >https://secure-web.cisco.com/1yqwpNF2gzOn-QY7HkOOpQ0JlBU4K1r--uLqHwDN15PX0mvNo4iLdtkcU76BTFcpBKcA2ASw-dUFMHcUxTMsUp1xcQlMSL24OhbFDSex_x7aF7bP9cFCVHutiMQ-r24XJxgKA35LnIx7hQhfNrFLN0ScofG3HCE95_G1lXKCTCOeM1ZsncA6fn4JDAXIGQbnlFo5mu2_iXvTW7t-gp0RJhLTS6K4S7FArJBKuqzhzhu31uneJnxfHcEGjY9BB5f_07IDL4T7Z1OUaYRFKacT4hTR5JZoeWe_4WitEPtuFjSb4EwaCdsLaDzwPYL745QTtlcF4D96_zsNooRrBVNEIoUAblv0Ts9hEZSmif52-bzvvOuO3NYQLXoR_0zovblEIq33fLH-crw4uF1lkKOtAlx6Ta9hqIod5lFLmSDTXGeGkwZeE9SzwZc_KtRgAXNRfbFSQ2o0CumldGZUqdJ0QWw/https%3A%2F%2Fmakingdeveloperslivesbetter.wordpress.com%2F -- 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: Glossary (was: ZOA ... Ansible)
Why not just "UNIX file" or "z/OS UNIX" file? From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Friday, February 21, 2020 6:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Glossary (was: ZOA ... Ansible) What's wrong with USS again? Confusion with VTAM's USS is unlikely, and neither would the Navy commissioning a new ship named USS Directory. The contexts are different. Replacing a TLA with a half-line phrase isn't viable. One term that is inherently ambiguous is "zFS file". That naturally means a VSAM LDS that holds a USS file system; not USS files, which per se, do not care what type of file system they are contained in. My opinions, but I have no objections to others having different ones. sas On Fri, Feb 21, 2020 at 12:59 AM Timothy Sipples wrote: > Paul Gilmartin wrote: > >Yes, but zFS is too specific, and at risk of change. > > Change cuts both/all ways. There's now at least one base z/OS component > that uses zFS nontrivially (and requires it) that isn't z/OS UNIX System > Services. > > How about something like this: "...a zFS or other z/OS UNIX compatible > directory/file/path..."? That'd allow for z/OS NFS, HFS (for now, in z/OS > releases that provide it), etc. if those are acceptable alternatives. > "z/OS UNIX" seems to be an acceptable short form of "z/OS UNIX System > Services," so I think that works. If for some reason the requirement is > specific to zFS, then it'd just collapse to "a zFS directory/file/path." > Here's another form, in between those two poles: > > "...a z/OS UNIX compatible directory/file/path (zFS recommended)..." > > Technical writing with clarity is hard, but I think these constructions > would be an improvement. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > -- 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: ZOA Open Automation Utilities
More every day are using member generations. Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Fulton Sent: Friday, February 21, 2020 12:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ZOA Open Automation Utilities No - we don't have that yet... Are many folks using PDSE Member Generations? -- 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: ZOA Open Automation Utilities
On Fri, Feb 21, 2020 at 12:49 PM Mike Fulton wrote: > We've been rolling this out as we need the services and dtail was just > higher priority. You can get -most- of what you need for dhead from dtail > with the right options. > But yeah - we should add dhead. > > Regarding the C DLL API, we probably need to make it easier to find. > Check here: > https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.1/extend.html Got it. Thanks! > > > thanks, mike > > -- People in sleeping bags are the soft tacos of the bear world. 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: ZOA Open Automation Utilities
We've been rolling this out as we need the services and dtail was just higher priority. You can get -most- of what you need for dhead from dtail with the right options. But yeah - we should add dhead. Regarding the C DLL API, we probably need to make it easier to find. Check here: https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.1/extend.html thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
No - we don't have that yet... Are many folks using PDSE Member Generations? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, 21 Feb 2020 at 11:55, Mike Fulton wrote: > > IBM Z Open Automation Utilities is a free FMID today. > We are changing this to make it a free PID: > http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en It's not obvious to me how I can get a copy of this. As an ISV we don't have Shopz or anything like that. Can it just be downloaded, or are things necessarily more formal? Thanks... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
I would vote for REXX support. What about PDSE Member Generation support - do the ZOA utilities understand member generations? Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, Feb 21, 2020 at 11:57 AM Mike Fulton wrote: > One other point I forgot to mention - the extensions with some of the USS > services to support datasets is nice, but as you pointed out, they are > extensions. We included 'dcp' in the list of services (dataset copy) not > because you couldn't do it without the service, but more so that there was > an explicit way to copy to/from datasets. Perhaps we should add a dcat as > well for the same reason... > I am curious why there is a "dtail" but no "dhead". I am also curious why the C DLL API is not documented. The Java and Python are. But I don't see anything about using the DLL in C or C++. Maybe I'm just blind. > > thanks, mike > > -- People in sleeping bags are the soft tacos of the bear world. 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: ZOA Open Automation Utilities
One other point I forgot to mention - the extensions with some of the USS services to support datasets is nice, but as you pointed out, they are extensions. We included 'dcp' in the list of services (dataset copy) not because you couldn't do it without the service, but more so that there was an explicit way to copy to/from datasets. Perhaps we should add a dcat as well for the same reason... thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
I personally love REXX. If you look at the actual source of the ZOA utilities, you will see some of them are written in REXX - it's the best way to get to what we need. Would you be after using REXX in the USS environment or TSO? If in USS, then that's a pretty interesting idea - and worth discussing. What would be interesting to understand would be the interface... and whether we can leverage the existing 'sh' and/or DLL interface that's available. thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, Feb 21, 2020 at 11:38 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Fri, 21 Feb 2020 17:15:29 +, Farley, Peter x23353 wrote: > > >Thanks for that link, interesting stuff. For ZOA, is there any intent to > provide support for other scripting languages, in particular for (g)awk and > perl? Currently the z/OS Unix Services version of awk uses fopen() for > input and output files so it does accidentally support regular z/OS > datasets, but it would be nice of that were made permanent and easier to > use instead of "oops, yes you can do that but we don't promise to keep it > that way in the future". > > > +1 > > Years ago, I wished on MVS-OE that the Classic data set world could be > incorporated into z/OS UNIX so functions such as open() (not just fopen()) > and shell redirection would simply work. WJS followed up, supplying the > terminology I didn't know, that the Classic data set hierarchy might > be implemented as a VFS (Virtual Filesystem). This was not a commitment > nor a SoD. > IIRC, someone here said that they used NFS to mount some z/OS high level qualifier (or maybe a node like A.B) as a "filesystem" and so access the DSNs via a UNIX path. > > >-Original Message- > >From: Mike Fulton > >Sent: Friday, February 21, 2020 11:46 AM > > > >IBM Z Open Automation Utilities is a free FMID today. > >We are changing this to make it a free PID: > http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en > > ... > >I wrote a blog about this for those that are interested: > https://makingdeveloperslivesbetter.wordpress.com/ > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- People in sleeping bags are the soft tacos of the bear world. 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: ZOA Open Automation Utilities
Hi The intent is certainly to enable other languages where there is interest - and we created the DLL interface to make it as easy as possible to do that (either by IBM or by 3rd parties). perl is a candidate that is on the 'could be done in the future' list (as always, no commitments but it's a reasonable request). For awk, I'm wondering if using the core services in a stream gives you most of what you need? I know I pipe stuff into awk all the time from the ZOA utilities to 'fix up' the output (same with grep). Curious what you think thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, 21 Feb 2020 17:15:29 +, Farley, Peter x23353 wrote: >Thanks for that link, interesting stuff. For ZOA, is there any intent to >provide support for other scripting languages, in particular for (g)awk and >perl? Currently the z/OS Unix Services version of awk uses fopen() for input >and output files so it does accidentally support regular z/OS datasets, but it >would be nice of that were made permanent and easier to use instead of "oops, >yes you can do that but we don't promise to keep it that way in the future". > +1 Years ago, I wished on MVS-OE that the Classic data set world could be incorporated into z/OS UNIX so functions such as open() (not just fopen()) and shell redirection would simply work. WJS followed up, supplying the terminology I didn't know, that the Classic data set hierarchy might be implemented as a VFS (Virtual Filesystem). This was not a commitment nor a SoD. >-Original Message- >From: Mike Fulton >Sent: Friday, February 21, 2020 11:46 AM > >IBM Z Open Automation Utilities is a free FMID today. >We are changing this to make it a free PID: >http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en > ... >I wrote a blog about this for those that are interested: >https://makingdeveloperslivesbetter.wordpress.com/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
On Fri, 21 Feb 2020 10:45:36 -0600, Mike Fulton wrote: >IBM Z Open Automation Utilities is a free FMID today. >We are changing this to make it a free PID: >http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en > >The goal of ZOAU is to provide access to MVS resources from the Unix System >Services environment directly through core 'atomic' services like dls (dataset >list) which works in an analagous way to ls (zFS file list) and so forth for >other MVS resources. > A laudable goal. >The intent is to also provide these services from the language of your choice >- so base 'sh' is supported but so is Python and Java, and a general DLL >interface is provided so that other language support could be provided. > Rexx? There's a formidable barrier between Unix System Services and TSO. In "z/OS TSO/E REXX Reference' see the section "TSO/E external functions". Those functions should seamlessly be made available to Rexx execs running under Unix System Services. Likewise commands such as RECEIVE. Mr. Fulton, tear down that wall! >I wrote a blog about this for those that are interested: >https://makingdeveloperslivesbetter.wordpress.com/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
Thanks for that link, interesting stuff. For ZOA, is there any intent to provide support for other scripting languages, in particular for (g)awk and perl? Currently the z/OS Unix Services version of awk uses fopen() for input and output files so it does accidentally support regular z/OS datasets, but it would be nice of that were made permanent and easier to use instead of "oops, yes you can do that but we don't promise to keep it that way in the future". Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Fulton Sent: Friday, February 21, 2020 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ZOA Open Automation Utilities IBM Z Open Automation Utilities is a free FMID today. We are changing this to make it a free PID: http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en The goal of ZOAU is to provide access to MVS resources from the Unix System Services environment directly through core 'atomic' services like dls (dataset list) which works in an analagous way to ls (zFS file list) and so forth for other MVS resources. The intent is to also provide these services from the language of your choice - so base 'sh' is supported but so is Python and Java, and a general DLL interface is provided so that other language support could be provided. I wrote a blog about this for those that are interested: https://makingdeveloperslivesbetter.wordpress.com/ thanks, mike -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
I agree Kirk that we have more to do. Would love to get your input on what we need to do to make this useful to you. You've listed a few - feel free to reach out to me (fult...@ca.ibm.com) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
Thanks for the input on dls. I think you are right about having a quiet form for dls - I run dls just to get file existance all the time and have to do the same redirection. If you have any other suggestions, feel free to either post them here or you can send me a note directly if you want too: fult...@ca.ibm.com thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ZOA Open Automation Utilities
IBM Z Open Automation Utilities is a free FMID today. We are changing this to make it a free PID: http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/897/ENUS220-087/index.html&lang=en&request_locale=en The goal of ZOAU is to provide access to MVS resources from the Unix System Services environment directly through core 'atomic' services like dls (dataset list) which works in an analagous way to ls (zFS file list) and so forth for other MVS resources. The intent is to also provide these services from the language of your choice - so base 'sh' is supported but so is Python and Java, and a general DLL interface is provided so that other language support could be provided. I wrote a blog about this for those that are interested: https://makingdeveloperslivesbetter.wordpress.com/ thanks, mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CBT 120
Hi Folks, Just to let you know there's another article on CBT File 120 (Updates page). The article is: BM2002FE : ONLCLIP - Changing the VOLSER of a disk pack (while the pack remains online) It isn't needed often, but sometimes it's very useful. The article goes into detail about where and when. Tools for this were written or modified very recently. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Glossary (was: ZOA ... Ansible)
? What z/OS component requires creating a zFS but doesn't use Unix System Services, and what does it use it for? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Friday, February 21, 2020 12:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Glossary (was: ZOA ... Ansible) Paul Gilmartin wrote: >Yes, but zFS is too specific, and at risk of change. Change cuts both/all ways. There's now at least one base z/OS component that uses zFS nontrivially (and requires it) that isn't z/OS UNIX System Services. How about something like this: "...a zFS or other z/OS UNIX compatible directory/file/path..."? That'd allow for z/OS NFS, HFS (for now, in z/OS releases that provide it), etc. if those are acceptable alternatives. "z/OS UNIX" seems to be an acceptable short form of "z/OS UNIX System Services," so I think that works. If for some reason the requirement is specific to zFS, then it'd just collapse to "a zFS directory/file/path." Here's another form, in between those two poles: "...a z/OS UNIX compatible directory/file/path (zFS recommended)..." Technical writing with clarity is hard, but I think these constructions would be an improvement. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- 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: Glossary (was: ZOA ... Ansible)
What's wrong with USS again? Confusion with VTAM's USS is unlikely, and neither would the Navy commissioning a new ship named USS Directory. The contexts are different. Replacing a TLA with a half-line phrase isn't viable. One term that is inherently ambiguous is "zFS file". That naturally means a VSAM LDS that holds a USS file system; not USS files, which per se, do not care what type of file system they are contained in. My opinions, but I have no objections to others having different ones. sas On Fri, Feb 21, 2020 at 12:59 AM Timothy Sipples wrote: > Paul Gilmartin wrote: > >Yes, but zFS is too specific, and at risk of change. > > Change cuts both/all ways. There's now at least one base z/OS component > that uses zFS nontrivially (and requires it) that isn't z/OS UNIX System > Services. > > How about something like this: "...a zFS or other z/OS UNIX compatible > directory/file/path..."? That'd allow for z/OS NFS, HFS (for now, in z/OS > releases that provide it), etc. if those are acceptable alternatives. > "z/OS UNIX" seems to be an acceptable short form of "z/OS UNIX System > Services," so I think that works. If for some reason the requirement is > specific to zFS, then it'd just collapse to "a zFS directory/file/path." > Here's another form, in between those two poles: > > "...a z/OS UNIX compatible directory/file/path (zFS recommended)..." > > Technical writing with clarity is hard, but I think these constructions > would be an improvement. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM APIs in a multi-vendor world
Kirk Wolf wrote: >I could deal with some configuration of the pseudo-volser, >but our product doesn't run under TSO, so a "command" >interface isn't convenient. What runtime environment and programming language are you using? - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
