Re: VM: redefine virtual storage from an EXEC
On Sat, 16 Jul 2022 at 17:29, Phil Smith III wrote: > > Dave: I stand (well, sit) corrected! I would have sworn I'd read the > full-screen CMS was being removed a while ago. https://www.mxg.com/thebuttonman/html/button880.htm Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VM: redefine virtual storage from an EXEC
Dave: I stand (well, sit) corrected! I would have sworn I'd read the
full-screen CMS was being removed a while ago.
.phsiii ("Senility-not just a river in Africa")
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXCOPY vs. TSO/E CALL asis
A few pages later in the manual, there is an assembler language example showing how to invoke BPXCOPY with LINK, with overriding ddnames for SYSUT1 and SYSUT2. Conspicuously and suspiciously absent from the example is an overriding ddname for SYSTSPRT. Bill On Sat, 16 Jul 2022 13:00:20 -0500, Paul Gilmartin wrote: >On Sat, 16 Jul 2022 12:32:03 -0400, Tony Harminc wrote: > >>On Fri, 15 Jul 2022 at 17:56, Paul Gilmartin wrote: >>> >>> In the z/OS UNIXI Ref. for BPXCOPY I read: >>> • The message output ddname is associated with an MVS data set. >>> The default ddname is SYSTSPRT, ... If BPXCOPY is invoked >>> from ..., a TSO/E CALL command with the asis option, ..., you can >>> specify an alternative ddname. >>[...] >> >>I'm also suspicious about the SYSTSPRT part. If it's foreground TSO, >>SYSTSPRT is not used for terminal I/O. If it's TSO in a batch job, it >>is, but it's opened by the TMP, and an application trying to reopen it >>will presumably fail. >> >It sometimes works to OPEN multiple DCBs concurrently on a single DDNAME. >It probably works poorly if RECFM is Blocked. > >And not at all in CMS where the doc for OS emulation contains the disclaimer >that if no IBM product does something, it doesn't need to work. > >But z/OS LMPUT works surprisingly well creating multiple members of >a PDSE concurrently, although ENQ EXC restricts this to a snigle job. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXCOPY vs. TSO/E CALL asis
On Sat, 16 Jul 2022 12:32:03 -0400, Tony Harminc wrote: >On Fri, 15 Jul 2022 at 17:56, Paul Gilmartin wrote: >> >> In the z/OS UNIXI Ref. for BPXCOPY I read: >> • The message output ddname is associated with an MVS data set. >> The default ddname is SYSTSPRT, ... If BPXCOPY is invoked >> from ..., a TSO/E CALL command with the asis option, ..., you can >> specify an alternative ddname. >[...] > >I'm also suspicious about the SYSTSPRT part. If it's foreground TSO, >SYSTSPRT is not used for terminal I/O. If it's TSO in a batch job, it >is, but it's opened by the TMP, and an application trying to reopen it >will presumably fail. > It sometimes works to OPEN multiple DCBs concurrently on a single DDNAME. It probably works poorly if RECFM is Blocked. And not at all in CMS where the doc for OS emulation contains the disclaimer that if no IBM product does something, it doesn't need to work. But z/OS LMPUT works surprisingly well creating multiple members of a PDSE concurrently, although ENQ EXC restricts this to a snigle job. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tool for abend testing
On 2022-07-16 10:41 AM, Willy Jensen wrote: I have a program which abends with the code in the parm field, it supports both system- and user abends. You are welcome to a copy, send me a private mail. Sample: PARM=S0C8 PARM=U123 In case it doesn't already, your program should actually cause program checks for those abend codes that represent program checks. Depending on your recovery scenario, an actual S0C3 program check could be handled differently than an ABEND with system code 0C3. One simple example is a SLIP trap with ERRTYP=PROG. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXCOPY vs. TSO/E CALL asis
On Fri, 15 Jul 2022 at 17:56, Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > In the z/OS UNIXI Ref. for BPXCOPY I read: > • The message output ddname is associated with an MVS data set. > The default ddname is SYSTSPRT, ... If BPXCOPY is invoked > from ..., a TSO/E CALL command with the asis option, ..., you can > specify an alternative ddname. [...] I'm also suspicious about the SYSTSPRT part. If it's foreground TSO, SYSTSPRT is not used for terminal I/O. If it's TSO in a batch job, it is, but it's opened by the TMP, and an application trying to reopen it will presumably fail. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXCOPY vs. TSO/E CALL asis
On Sat, 16 Jul 2022 06:39:31 -0500, Bill Godfrey wrote: >In the part about BPXCOPY, the UNIX System Services Command Reference manual >is incorrect. > >Restoring the part that you showed with ellipses, the statement is: "If >BPXCOPY is invoked from LINK, XCTL, ATTACH, a TSO/E CALL command with the asis >option, or by a CALL after a LOAD, you can specify an alternative ddname." > I elided the part I trusted in order to emphasize what I doubted. I've used the alternate DDDNAME list with ADDRESS SYSCALL ATTCHMVS to override SYSUT1. I'm least familiar with CLIST, but ASIS seems particularly irrelevant. It may pertain to UNIX pathnames. I'll submit an RCF. A few hours earlier, I had submitted an RCF questioning whether it's possible to override SYSTSPRT, even with LINK, etc. I'll watch for a response, >On Fri, 15 Jul 2022 16:56:02 -0500, Paul Gilmartin wrote: > >>In the z/OS UNIXI Ref. for BPXCOPY I read: >>• The message output ddname is associated with an MVS data set. >> The default ddname is SYSTSPRT, ... If BPXCOPY is invoked >> from ..., a TSO/E CALL command with the asis option, ..., you can >> specify an alternative ddname. >> >>In the TSO/E Commands Ref. for CALL, I read: >>CALL command ... >>parameter_string ... >>Some utilities accept multiple entry parameter lists; for example, to pass a >>list of alternate ddnames, TSO/E commands require a special multiple entry >>parameter list known as a command processor parameter list (CPPL). Neither of >>these options are supported by the CALL command, ... >> >>Is there a contradiction here? -- Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VM: redefine virtual storage from an EXEC
Phil Smith III wrote: "Your distinction, while reasonable, turns out to be a distinction without a difference: in linemode, it's the same command line, just being read by XEDIT. CMS has two modes: command line and full-screen. Anything that isn't full-screen is command line. (Yes, full-screen CMS blurred this, but it's dead, right?)" Baloney, Phil. I use full-screen CMS all the time here. :-) I think its great. Take care. DJ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tool for abend testing
I have a program which abends with the code in the parm field, it supports both system- and user abends. You are welcome to a copy, send me a private mail. Sample: PARM=S0C8 PARM=U123 You will still need some other program to do the wait, but a simple REXX in batch could do that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXCOPY vs. TSO/E CALL asis
In the part about BPXCOPY, the UNIX System Services Command Reference manual is incorrect. Restoring the part that you showed with ellipses, the statement is: "If BPXCOPY is invoked from LINK, XCTL, ATTACH, a TSO/E CALL command with the asis option, or by a CALL after a LOAD, you can specify an alternative ddname." All the other methods (LINK, etc.) of invoking BPXCOPY allow specifying alternative ddnames, but the TSO/E CALL command with the asis option does not belong in the list. Nor does it belong in the preceding paragraphs about alternative ddnames for SYSUT1 and SYSUT2. I suspect the list was mistakenly thought to be the same as the list earlier on the same page, where it says "You can invoke BPXCOPY in several ways:" followed by exactly the same list of methods. That part is not referring to alternative ddnames, so the TSO/E CALL command is correctly in the list. Bill On Fri, 15 Jul 2022 16:56:02 -0500, Paul Gilmartin wrote: >In the z/OS UNIXI Ref. for BPXCOPY I read: >• The message output ddname is associated with an MVS data set. > The default ddname is SYSTSPRT, ... If BPXCOPY is invoked > from ..., a TSO/E CALL command with the asis option, ..., you can > specify an alternative ddname. > >In the TSO/E Commands Ref. for CALL, I read: >CALL command ... >parameter_string ... >Some utilities accept multiple entry parameter lists; for example, to pass a >list of alternate ddnames, TSO/E commands require a special multiple entry >parameter list known as a command processor parameter list (CPPL). Neither of >these options are supported by the CALL command, ... > >Is there a contradiction here? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
