Re: Help please with symbols in a lower-case SET operand
Shmuel, I am trying to follow what you are asking, but am unsure Are you saying there is something in a JCL environment that should be reported as an error, but it is not, until execution? Mitch -Original Message- From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Sun, Dec 14, 2014 3:04 pm Subject: Re: Help please with symbols in a lower-case SET operand In 6785654506445698.wa.paulgboulderaim@listserv.ua.edu, on 12/12/2014 at 04:46 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: I would be delighted if, rather, the parser reported a reference to an undefined apparent symbol as a syntax error. That would break existing JCL. There seems to be a curious mix of things that work differently for no good reason aand things that are consistent with old behaviors whose reasons are no longer relevant. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Setting a lonnnnng SLIP trap
In cy1pr0101mb076351ce69bc7140c03659c2ce...@cy1pr0101mb0763.prod.exchangelabs.com, on 12/13/2014 at 06:53 PM, J O Skip Robinson jo.skip.robin...@sce.com said: Since there's no actual WTOR, I cannot invoke a second REXX to continue the conversation. What are you trying to say? If you can invoke a REPLY command then you can invoke a SLIP command, authorization permitting. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help please with symbols in a lower-case SET operand
Using Jol, it could be easily done this way: FOO=19; BAR='/my/lower/case/uss/folder/' || '%FOO/'; or more simply: BAR='/my/lower/case/uss/folder/%FOO/'; The result is: /my/lower/case/uss/folder/19/ This can be used in a Dsname field; Clement Clarke www.Oscar-jol.com. Download Jol ZOS or Win http://start.oscar-jol.com/download-store. Charles Mills wrote: How the heck do I do this? I have a variable symbol FOO that has been set to a value. I want to include it in another set symbol like so // SET BAR=/my/lower/case/uss/folder/FOO./ If I quote the operand it seems like FOO does not get substituted. If I don't quote the operand JCL barfs on the lower case letters. Help! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Jol has had * IF statements for Symbolic Variables and Return Codes, * Symbolic Variable Replacement in Card Image Files, * Nested Procedures, * Data Card Image files in Procs * Simplified JCL Syntax * 3270 CUA Compliant Full Screen Panel instruction and much for over 30 years. A few years ago, Long Parms were added too. The other day, the Windows beta version was released, and the Linux version is running. Try it - see what else is possible. Clement Clarke www.Oscar-jol.com. Download Jol ZOS or Win http://start.oscar-jol.com/download-store. Paul Gilmartin wrote: And Peter Relson mentioned it as a concern when he originated the thread. It's interesting how many features coming in z/OS 2.1 were mentioned in that thread: o Long PARMs (of course). o A load module attribute indicating a program's willingness to accept long PARMs. o PARM generated from a data set (e.g. PARMDD). o Instream data sets in PROCs o Symbol substitution in instream data sets. o System symbol substitution in batch JCL. -- gil --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting a lonnnnng SLIP trap
What comes to mind (but I might be mis-thinking a bit) is that the intent is that the OPER TSO command really should not be used; that has been true for many years. You can define a TSO ID as a console. This is far more flexible. Others can speak with far more knowledge about that than I. I don't know how TSO console fits with respect to REXX. 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: ftp rdw
On Sun, 14 Dec 2014 01:54:26 -0600, Paul Edwards mutazi...@gmail.com wrote: I don't have z/OS so I can't do this myself. Would someone who has z/OS be able to raise an issue either directly with IBM or via SHARE? The problem is that IBM's ftp has a great option to preserve RDW when transferring a binary VB file from mainframe to PC, but it doesn't have an option to reverse that process. You can see the use of the rdw option below. Are you sure that the rdw option doesn't work when sending from the PC to z/OS? I don't see anything in the documentation to indicate that the receiving z/OS would ignore it. Have you tried, from the PC: binary quote site rdw put ... I would expect that to work, assuming that the records you're sending still have the RDWs on them. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting a lonnnnng SLIP trap
On Sat, 13 Dec 2014 23:33:12 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cy1pr0101mb076351ce69bc7140c03659c2ce...@cy1pr0101mb0763.prod.exchangelabs.com, on 12/13/2014 at 06:53 PM, J O Skip Robinson jo.skip.robin...@sce.com said: Since there's no actual WTOR, I cannot invoke a second REXX to continue the conversation. What are you trying to say? If you can invoke a REPLY command then you can invoke a SLIP command, authorization permitting. From what he showed, it appears that in TSO/E OPER, the SLIP subcommand simply prompts for additional operands. At that point, if he were writing in CLIST rather than REXX he could examine the prompt, and respond with something generated by the CLIST. However, writing in REXX I don't think he can respond. (As I remember, it is possible to stack/queue additional responses, which the system would then read when the REXX exec ends. But I don't think REXX provides a way to issue them while the exec continues to run. But those are old memories, at this point.) I think (but cannot test) that his choices are to use CLIST, or to avoid using OPER within his REXX exec and use the more modern (but more complex) CONSOLE function instead. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
On Sun, 14 Dec 2014 08:54:18 -0600, Walt Farrell wrote: On Sun, 14 Dec 2014 01:54:26 -0600, Paul Edwards wrote: I don't have z/OS so I can't do this myself. Would someone who has z/OS be able to raise an issue either directly with IBM or via SHARE? The problem is that IBM's ftp has a great option to preserve RDW when transferring a binary VB file from mainframe to PC, but it doesn't have an option to reverse that process. Are you sure that the rdw option doesn't work when sending from the PC to z/OS? I don't see anything in the documentation to indicate that the receiving z/OS would ignore it. I've tried it. It doesn't do anything useful. I agree with the OP that the implementation fails its apparent intended objective; I call it moronic. But I fear a PMR would be ineffective. I imagine replies: o The documentation says that on a transfer the RDWs are treated as part of the data and appear in the data in the destination file. So on a GET the RDWs appear in the data of the file gotten to; in a PUT the RDW images in the source file appear in the data of the destination file. ∎; WAD. o In any case, changing it now would probly break existing code. o Treating 4 bytes of a record when the server has no control over the source data might cause serious I/O errors or buffer overuns. If the OP hasn't access to z/OS, his interest must be only academic. I'll suggest the alternative sequence from the remote system: BINARY QUOTE TYPE E QUOTE MODE B There is no equivalent possible with a z client and a non-z server. (Others might suggest QUOTE STRU R instead.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
On Sun, Dec 14, 2014 at 10:07 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: snip If the OP hasn't access to z/OS, his interest must be only academic. I'll suggest the alternative sequence from the remote system: BINARY QUOTE TYPE E QUOTE MODE B There is no equivalent possible with a z client and a non-z server. (Others might suggest QUOTE STRU R instead.) The above is what I do. It is a decent way to store z/OS data on an intermediate non-z/OS host. And the output from the STRU R is documented and not really all that difficult to decode on a non-z/OS system so that it _could_ be readable. Of course the usual problems about ASCII vs. EBCDIC text, z byte order, and z HFP vs IEEE floating point applies. I love that the z now supports IEEE float as BFP in addition to the older HFP floating point. -- gil -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. 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: Setting a lonnnnng SLIP trap
Right on Walt. But I swore decades ago never to write a new CLIST. I’m too old to change. ;-))) . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Sunday, December 14, 2014 7:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting a long SLIP trap On Sat, 13 Dec 2014 23:33:12 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cy1pr0101mb076351ce69bc7140c03659c2ce...@cy1pr0101mb0763.prod.exchange labs.com, on 12/13/2014 at 06:53 PM, J O Skip Robinson jo.skip.robin...@sce.com said: Since there's no actual WTOR, I cannot invoke a second REXX to continue the conversation. What are you trying to say? If you can invoke a REPLY command then you can invoke a SLIP command, authorization permitting. From what he showed, it appears that in TSO/E OPER, the SLIP subcommand simply prompts for additional operands. At that point, if he were writing in CLIST rather than REXX he could examine the prompt, and respond with something generated by the CLIST. However, writing in REXX I don't think he can respond. (As I remember, it is possible to stack/queue additional responses, which the system would then read when the REXX exec ends. But I don't think REXX provides a way to issue them while the exec continues to run. But those are old memories, at this point.) I think (but cannot test) that his choices are to use CLIST, or to avoid using OPER within his REXX exec and use the more modern (but more complex) CONSOLE function instead. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting a lonnnnng SLIP trap
On Sun, 14 Dec 2014 19:44:07 +, J O Skip Robinson jo.skip.robin...@sce.com wrote: Right on Walt. But I swore decades ago never to write a new CLIST. I'm too old to change. ;-))) Sorry, Skip, but you need the right tool for the job, and sometimes CLIST is it :) (But using Console instead of the long obsolete OPER should let you do what you want.) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
If the OP hasn't access to z/OS, his interest must be only academic. I wish to distribute VB files (developed on MVS/380) via PC, with z/OS as a target. I don't want BDW, just the RDW format that ftp produces. I'm very happy with the RDW format that IBM's ftp produces, I just want it to be reversible. I hope someone can ask IBM about this. Thanks. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
As gil indicated, in the ftp, do QUOTE STRU R BIN GET MVS.FILE On the other end, do the same, but do a PUT instead of a GET (u know that, just being complete). On the upload, u also need a QUOT SITE to set the allocation and DCB parameters as well (again just being complete) On Dec 14, 2014 9:08 PM, Paul Edwards mutazi...@gmail.com wrote: If the OP hasn't access to z/OS, his interest must be only academic. I wish to distribute VB files (developed on MVS/380) via PC, with z/OS as a target. I don't want BDW, just the RDW format that ftp produces. I'm very happy with the RDW format that IBM's ftp produces, I just want it to be reversible. I hope someone can ask IBM about this. Thanks. Paul. -- 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: ftp rdw
On Sun, 14 Dec 2014 21:08:03 -0600, Paul Edwards wrote: I wish to distribute VB files (developed on MVS/380) via PC, with z/OS as a target. I don't want BDW, just the RDW format that ftp produces. I'm very happy with the RDW format that IBM's ftp produces, I just want it to be reversible. STRU R is reversible; RDW isn't. For your objective, the remaining chore would be to synthesize STRU R on OS 380. I hope someone can ask IBM about this. STRU R should meet your objective. It's available today. Any resolution of RDW by IBM would take months and probably wouldn't be satisfactory. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting a lonnnnng SLIP trap
Walt Farrell wrote: Right on Walt. But I swore decades ago never to write a new CLIST. I'm too old to change. ;-))) Sorry, Skip, but you need the right tool for the job, and sometimes CLIST is it :) You can use REXX (or CLIST) + Console function, but, for REXX, then you need to figure out a way to obtain a WTOR and to reply to it. [1] (But using Console instead of the long obsolete OPER should let you do what you want.) Indeed, you can also call SDSF from REXX and get a list of any open WTOR and then try to reply on it. [2] So, some serious programming is still needed. I hope I'm not TRAPped in this long SLIPpery thread.. ;-) Groete / Greetings Elardus Engelbrecht [1] - Using WTOR macro, I think. [2] - Or you can issue with Console function a D R,R command and grab any output. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
