Re: Passing STDENV DD to FTP via SYSIN
Hey Charles, I took you seriously the first time. I appreciate your interest
in helping.
Bottom line, I'd like to come up with a job any z/OS customer could run,
without requiring changes to any of their system files (like FTPCDATA or AT-TLS
or RACF) that would allow them to transmit files to/from an FTP site using
FTPS.
I've pretty much given up on that--I can't find a way to do it without
installing certificates used by the FTP server into their RACF/ACF2/Top Secret
databases. And even with the certificates in RACF, the only way I've gotten it
to work is force FTP to use TLS 1.2 by setting the "GSK_PROTOCOL_TLSV1_2"
environment variable to "ON" per this URL:
https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12
That page does say for FTP the STDENV dataset should be RECFM=VB. (I did try
various combinations of DD *,DCB=(...), including DCB=(RECFM=VB), but JES
didn't seem to allow that.) Gil might be on to something with the temporary
datasets not being available to spawned processes, but I've cataloged the
IEBGENER'd file and the job still fails like it doesn't find the
"GSK_PROTOCOL_TLSV1_2=ON" variable.
---
I'm not sure how to close this out, but as I've been typing this, I did figure
out how to get around the STDENV problem. I'm going to go ahead and leave what
I've said so far in case someone else comes across this in the future, but
here's a work-around:
What I was trying to do was:
//FTPXFER EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
//STDENV DD *
GSK_PROTOCOL_TLSV1_2=ON
//*
Where the 'ENVAR("_CEE_ENVFILE=DD:STDENV") is telling LE to look for
environment variables in the STDENV DD. The STDENV file wasn't being found,
but all it has is one variable name and value. So it occurred to me that I
could just put the variable and value in the PARM:
//FTPXFER EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("GSK_PROTOCOL_TLSV1_2=ON")/(EXIT')
Turns out, it works!
Thanks for all your help.
Wendell
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passing STDENV DD to FTP via SYSIN
And I mean that second paragraph as a serious question : tell me and I will try
to help; not as sarcasm. CharlesSent from a mobile; please excuse the brevity.
Original message From: Charles Mills Date:
9/10/20 3:27 PM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Passing
STDENV DD to FTP via SYSIN I have considerable experience in hacking FTP into
doing unnatural acts but not enough of a UNIX person to be totally up-to-speed
on using environment variables.What is it that you are trying to get FTP to do
that PARM= + SYSFTPD DD * + INPUT DD * will not accomplish?Charles-Original
Message-From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wendell LovewellSent: Thursday,
September 10, 2020 2:59 PMTo: ibm-m...@listserv.ua.EDUSubject: Passing STDENV
DD to FTP via SYSINHello,I'm setting up a batch job to access our FTP server
using FTPS and TLS 1.2. (Forgive me if that nomenclature is less than
perfect.)I've imported certficates, built a keyring, and come up with a
combination of FTP client parameters that will allow me to connect to the
server and upload a file://FTPXFER EXEC PGM=FTP,REGION=4292K,//
PARM=('POSIX(ON) ALL31(ON)',//
'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')//OUTPUT DD SYSOUT=*//STDENV DD
DISP=SHR,DSN=WRL1.FTPS.STDENV//*//* //STDENV DD *//*
GSK_PROTOCOL_TLSV1_2=ON//*//SYSFTPD DD *CLIENTERRCODES EXTENDEDEPSV4
TRUEEXTENSIONS AUTH_TLSFWFRIENDLY
TRUEKEYRING TCPIP/FTP.KEYRINGPASSIVEIGNOREADDR
TRUESECUREIMPLICITZOS FALSESECURE_FTP REQUIREDSECURE_MECHANISM
TLSSECURE_DATACONN PRIVATESECURE_CTRLCONN PRIVATESECURE_HOSTNAME
REQUIREDTLSMECHANISM FTPTLSRFCLEVEL CCCNONOTIFY/*//INPUT
DD *I'm trying to make this as self-contained as possible, and would like to
supply the variables via SYSIN rather than require the PS file named on the
un-commented version of the STDENV DD. BPXBATCH is the only program I can find
documented that says "//STDENV DD *" is supported. FTP, at least with the PARM
I'm using, seems to ignore
it.--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: Passing STDENV DD to FTP via SYSIN
Consistent with your comment about BPXBATCH, I suspect you will need to run FTP
(via PARM= input) under BPXBATCH (via EXEC PGM=), and then the //STDENV DD
will be read.
HTH,
Mike
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Wendell Lovewell
Sent: Thursday, September 10, 2020 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Passing STDENV DD to FTP via SYSIN
Caution! This message was sent from outside your organization.
Hello,
I'm setting up a batch job to access our FTP server using FTPS and TLS 1.2.
(Forgive me if that nomenclature is less than perfect.)
I've imported certficates, built a keyring, and come up with a combination of
FTP client parameters that will allow me to connect to the server and upload a
file:
//FTPXFER EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
//OUTPUT DD SYSOUT=*
//STDENV DD DISP=SHR,DSN=WRL1.FTPS.STDENV
//*
//* //STDENV DD *
//* GSK_PROTOCOL_TLSV1_2=ON
//*
//SYSFTPD DD *
CLIENTERRCODES EXTENDED
EPSV4TRUE
EXTENSIONS AUTH_TLS
FWFRIENDLY TRUE
KEYRING TCPIP/FTP.KEYRING
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTP REQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONNPRIVATE
SECURE_CTRLCONNPRIVATE
SECURE_HOSTNAME REQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL CCCNONOTIFY
/*
//INPUTDD *
I'm trying to make this as self-contained as possible, and would like to supply
the variables via SYSIN rather than require the PS file named on the
un-commented version of the STDENV DD. BPXBATCH is the only program I can find
documented that says "//STDENV DD *" is supported. FTP, at least with the PARM
I'm using, seems to ignore it.
Is it possible to supply STDENV to FTP via SYSIN?
I hate to admit it, but I thought "Ok, I'll just IEBGENER the variable(s) into
a VB LRECL=255 BLKSIZE=27998 file (like the one that works), and use that. But
strangely, I can't get that to work either--even though SUPERC confirms the
files match.
TIA,
Wendell
--
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: Passing STDENV DD to FTP via SYSIN
On Thu, 10 Sep 2020 16:58:52 -0500, Wendell Lovewell wrote:
>...
>//FTPXFER EXEC PGM=FTP,REGION=4292K,
>//PARM=('POSIX(ON) ALL31(ON)',
>// 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
>
>I'm trying to make this as self-contained as possible, and would like to
>supply the variables via SYSIN rather than require the PS file named on the
>un-commented version of the STDENV DD. BPXBATCH is the only program I can
>find documented that says "//STDENV DD *" is supported. FTP, at least with
>the PARM I'm using, seems to ignore it.
>
>Is it possible to supply STDENV to FTP via SYSIN?
>
Is it possible that the PGM=FTP job step task does a DYNALLOC INFO
of STDENV to extract the pathname or DSN of STDENV and passes
that to a forked child? A SYSIN might not be available to that child.
>I hate to admit it, but I thought "Ok, I'll just IEBGENER the variable(s) into
>a VB LRECL=255 BLKSIZE=27998 file (like the one that works), and use that.
>But strangely, I can't get that to work either--even though SUPERC confirms
>the files match.
>
Are you using a LRECL=255 SYSIN? That's possible if you avoid
TSO SUBMIT.
Likewise, a temporary data set might be unavailable to a child
process. If not temporary, there's the chore of cleaning it up
at job end. Perhaps DISP=(NEW,DELETE,DELETE). Must the
DSN be catalogued? That might require SMS.
Oops. Would a child address space encounter an ENQ conflict with
its own parent?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passing STDENV DD to FTP via SYSIN
I have considerable experience in hacking FTP into doing unnatural acts but not
enough of a UNIX person to be totally up-to-speed on using environment
variables.
What is it that you are trying to get FTP to do that PARM= + SYSFTPD DD * +
INPUT DD * will not accomplish?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Wendell Lovewell
Sent: Thursday, September 10, 2020 2:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Passing STDENV DD to FTP via SYSIN
Hello,
I'm setting up a batch job to access our FTP server using FTPS and TLS 1.2.
(Forgive me if that nomenclature is less than perfect.)
I've imported certficates, built a keyring, and come up with a combination of
FTP client parameters that will allow me to connect to the server and upload a
file:
//FTPXFER EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
//OUTPUT DD SYSOUT=*
//STDENV DD DISP=SHR,DSN=WRL1.FTPS.STDENV
//*
//* //STDENV DD *
//* GSK_PROTOCOL_TLSV1_2=ON
//*
//SYSFTPD DD *
CLIENTERRCODES EXTENDED
EPSV4TRUE
EXTENSIONS AUTH_TLS
FWFRIENDLY TRUE
KEYRING TCPIP/FTP.KEYRING
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTP REQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONNPRIVATE
SECURE_CTRLCONNPRIVATE
SECURE_HOSTNAME REQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL CCCNONOTIFY
/*
//INPUTDD *
I'm trying to make this as self-contained as possible, and would like to supply
the variables via SYSIN rather than require the PS file named on the
un-commented version of the STDENV DD. BPXBATCH is the only program I can find
documented that says "//STDENV DD *" is supported. FTP, at least with the PARM
I'm using, seems to ignore it.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Passing STDENV DD to FTP via SYSIN
Hello,
I'm setting up a batch job to access our FTP server using FTPS and TLS 1.2.
(Forgive me if that nomenclature is less than perfect.)
I've imported certficates, built a keyring, and come up with a combination of
FTP client parameters that will allow me to connect to the server and upload a
file:
//FTPXFER EXEC PGM=FTP,REGION=4292K,
//PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("_CEE_ENVFILE=DD:STDENV")/(EXIT')
//OUTPUT DD SYSOUT=*
//STDENV DD DISP=SHR,DSN=WRL1.FTPS.STDENV
//*
//* //STDENV DD *
//* GSK_PROTOCOL_TLSV1_2=ON
//*
//SYSFTPD DD *
CLIENTERRCODES EXTENDED
EPSV4TRUE
EXTENSIONS AUTH_TLS
FWFRIENDLY TRUE
KEYRING TCPIP/FTP.KEYRING
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTP REQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONNPRIVATE
SECURE_CTRLCONNPRIVATE
SECURE_HOSTNAME REQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL CCCNONOTIFY
/*
//INPUTDD *
I'm trying to make this as self-contained as possible, and would like to supply
the variables via SYSIN rather than require the PS file named on the
un-commented version of the STDENV DD. BPXBATCH is the only program I can find
documented that says "//STDENV DD *" is supported. FTP, at least with the PARM
I'm using, seems to ignore it.
Is it possible to supply STDENV to FTP via SYSIN?
I hate to admit it, but I thought "Ok, I'll just IEBGENER the variable(s) into
a VB LRECL=255 BLKSIZE=27998 file (like the one that works), and use that. But
strangely, I can't get that to work either--even though SUPERC confirms the
files match.
TIA,
Wendell
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Support for 128-bit arithmetic - was: Re: PL/I support of vector instructions?
On Thu, 10 Sep 2020 15:35:37 +, Seymour J Metz wrote: >Yes, you can always do multiple precision that way, but there is a performance >hit, especially from those conditional branches. Maybe we need skip >instructions such as the 7090 had. Some computer architectures have an Add-With-Carry instruction eliminating the need for some of those conditional branches. From: Thomas David Rivers Sent: Wednesday, September 9, 2020 8:35 PM Seymour J Metz wrote: > You would not need vector instructions to support FIXED BIN(127,s) (quad-word scaled or unscaled integers if s is 0.) In fact, you could do it with 370 code (our C compiler happens to do that for __int128 and __uint128.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Support for 128-bit arithmetic - was: Re: PL/I support of vector instructions?
Yes, you can always do multiple precision that way, but there is a performance
hit, especially from those conditional branches. Maybe we need skip
instructions such as the 7090 had.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Thomas David Rivers
Sent: Wednesday, September 9, 2020 8:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Support for 128-bit arithmetic - was: Re: PL/I support of vector
instructions?
Seymour J Metz wrote:
>I was asking whether it supported vector instructions for FIXED, not for
>FLOAT.; in particular, whether it supported FIXED BIN(127,0).
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>
You would not need vector instructions to support FIXED BIN(127,s)
(quad-word scaled
or unscaled integers if s is 0.)
In fact, you could do it with 370 code (our C compiler happens to do
that for __int128
and __uint128.)
The problems come when consider conversions to-from other items... the
definitions
of those conversions are pretty straight-forward. The issue is
examining all the conversion
permutations for PL/I to make sure it's implemented... then there are
the library I/O
characteristics to consider (which are mostly handled by the conversion
answers.)
Will you need a PIC that handles this, is the maximum PIC length
sufficent (_lots_
of base-10 digits in those things.) Do you need to read the values
from a FILE,
then you'll need CHAR -> FIXED BIN(127,s) conversion support... etc...
Our C compiler, as well as GCC, gets around this by saying you can
declare 128-bit
integers, and do basic arithmetic with them - but the runtime library
doesn't support them
(so formating for printing, for example, is up-to-you.) That seems to
handle the current
uses for 128-bit integral arithmetic. Of course, C doesn't have scaled
integers, making
the problem even easier there.
And - to drive the point home - let's consider this small snippet:
__int128
foo(__int128 a, __int128 b)
{
return a + b;
}
which just adds 2 128-bit signed integers. This is the 370 code that
is generated
from our C compiler:
* *** End of Prologue
* *
L 15,0(0,1)
* *** return a + b;
LM2,5,4(1)
AL5,32(0,1)
BC 12,@@gen_label0
AL4,@lit_147_0
BC 12,@@gen_label0
AL3,@lit_147_0
BC 12,@@gen_label0
AL2,@lit_147_0
@@gen_label0 DS 0H
AL4,28(0,1)
BC 12,@@gen_label1
AL3,@lit_147_0
BC 12,@@gen_label1
AL2,@lit_147_0
@@gen_label1 DS 0H
AL3,24(0,1)
BC 12,@@gen_label2
AL2,@lit_147_0
@@gen_label2 DS 0H
AL2,20(0,1)
STM 2,5,95(13)
MVC 0(16,15),95(13)
* *** }
* * Start of Epilogue
which is quite a lot!
But - if you tell the compiler it can take advantage of more recent
architectures (with
the -march=z13 option) - that same snippet generates this (in 31-bit mode):
* *** End of Prologue
* *
L 15,0(0,1)
* *** return a + b;
LMG 2,3,4(1)
ALG 3,28(0,1)
ALCG 2,20(0,1)
STMG 2,3,95(13)
MVC 0(16,15),95(13)
* *** }
* * Start of Epilogue
which is a better demonstration of how to do 128-bit arithmetic without
vector
instructions.
- Dave R. -
p.s. the return value is address via the first incoming parameter
(0(0,1)) if that helps
make sense of what's going on here.
p.p.s. This facility would be available in LE mode too, so you _could_
compile
C code with our compiler and link it with the IBM PL/I
compiler to do your
128-bit arithmetic; with careful definitions of the C
functions an PL/I EXTRNs.
But, it might just be easier to write the PL/I PROCs to do
the various arithmetic
functions on 128-bit values held in structures - or maybe
get really fancy
and use the PL/I preprocessor to generate the code for the
basic operations.
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at
http://secure-web.cisco.com/1s90SO-UjL1WSVjVvb4AkJv2WPMJEueXQpFNLATgdwd3EHMXFE1iUBqoDQZLLvjq44lHvKMhIH0JF3bAw22v3WNj-8yUJAZe7Mgiw3mCCqbA5v1O3gHj_CucREhI5F4KIDLLqDUr33WO53oJQUzaLVnobKrb_3RgZorQHbo8AoYwavGFUJTobBrLageGchvdhaZUDBXFhLq5Yo9OmJSxZEUdiHJlqxHBfnJYnbhAANAAARmUTA9ujSfQOxhWM6jGJZAzQxVgEVjcGOr_sDboqRdSP-go0uNWVfVYGNqXARC_jfL0DQAAemO7MuXOB8PmLjHHe1AdIKVh48ZnxxTqJsDP8H0MiBZZCmOsOQ8zBM-eQWXzD7b8W0cJFYBTn8uSVGX5uQUhW1HZltx4z4_NhreVNI0zIiGvR490g_NhkVUZklaCY9WfOvYn3Irz-ADe3/http%3A%2F%2Fwww.dignus.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
Re: REXX true/false (was Constant Identifiers)
Don't forget the short lived name MPPL. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of CM Poncelet Sent: Wednesday, September 9, 2020 10:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX true/false (was Constant Identifiers) Yes. My post-grad thesis was on PL/I - and on its being originally called Fortran VI in 1962, then NPL in '64, then distributed as PL/I in '66 together with OS/360. I wrote PL/I before Clist/CLIST and long before REXX. Confused am I? On 09/09/2020 05:49, Seymour J Metz wrote: > Have you ever heard of PL/I? Much of the syntax of REXX derives from PL/I, > and it has two different string types: CHARACTER and BIT. > > With regard to the built in functions, you are once again confusing the type > of a variable with its contents. Would you argue that +1 in -1 are different > data types because one is a valid input to sqrt and the other is not? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on behalf of > CM Poncelet > Sent: Tuesday, September 8, 2020 7:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX true/false (was Constant Identifiers) > > Mr Bridges, > > 1) The reason the program does not abend is it has a "SIGNAL ON SYNTAX > NAME ERROR3" coded before the "IF TRUE THEN...", which traps the abend > and resumes execution at label ERROR3. > > 2) I disagree with Mr Metz on the grounds that he argues that > "everything in REXX is a character string" - upon which I then > implicitly ask, "What is a non-character string and in what 3GL, 2GL, > 1GL language (but not 0GL, as that would be microcode) do such > non-character strings exist that do not exist in REXX?" > > It has nothing to do with EBCDIC and ASCII. It is that REXX supports all > binary strings - as in the REXX functions C2D, C2X, D2X, X2B, B2X, > BITAND, BITOR, BITXOR etc. and as applied in reading/processing > unformatted 'raw' system dumps. To argue that "everything in REXX is a > character string"is meaningless. It might be appropriate to argue that > "everything in REXX is a binary string", as that would include > "character string" - or even "everything in REXX is a string", because > that would be sufficient in itself and would not constrain all REXX > strings to have to be "character" ones. As I said, REXX supports all > binary strings - not only "character" ones. > > Not sure whether that answers your questions, but I hope it does. > > Cheers, Chris Poncelet (retired sysprog) > > > On 08/09/2020 16:27, Bob Bridges wrote: >> Mr Poncelet, I'm interested in this example. Two questions: >> >> 1) Once TRUE is set to a '1'b in the last two sections, why does the program >> not abend when it encounters "IF TRUE THEN..."? Seems to me REXX should >> complain that TRUE is not 1 or 0. >> >> 2) From your preceding posts I got the impression you were disagreeing with >> Mr Metz, that you believed REXX represented data in other forms that EBCDIC >> character strings. (EBCDIC in TSO REXX, that is; I'm not concerned with >> ASCII platforms here.) But your example seems to support his assertion. >> Did I misunderstand you? What am I missing? >> >> --- >> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 >> >> /* This is how sin happens. We don't set out to do something very wrong. We >> make up stories that sound good to ourselves about how the thing really >> isn't that wrong, or how it really isn't anybody else's business. / Before >> we lie to others, we lie to ourselves. Do that, and it can be hard to find >> the truth again, even when it is obvious nothing but the truth will do. >> -Maggie Gallagher, 2001-08-27 */ >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of CM Poncelet >> Sent: Monday, September 7, 2020 22:33 >> >> You said, "It isn't boolean; everything in REXX is a character string." >> >> I agree that "it's all strings", but not that "everything in REXX is a >> *character* string." >> >> Try the following: >> >> ARG DEBUG >> IF ABBREV(DEBUG,D,1) THEN , >> TRACE I >> >> SIGNAL ON SYNTAX NAME ERROR0 >> TRUE = 1 >> SAY 'TRUE NUMERIC = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE NUMERIC' >> IF TRUE THEN SAY 'YES, TRUE NUMERIC' >> >> ERROR0: >> SIGNAL ON SYNTAX NAME ERROR1 >> TRUE = '1' >> SAY 'TRUE CHARACTER = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE CHARACTER' >> IF TRUE THEN SAY 'YES, TRUE CHARACTER' >> >> ERROR1: >> SIGNAL ON SYNTAX NAME ERROR2 >> TRUE = '31'X >> SAY 'TRUE HEXADECIMAL = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE HEXADECIMAL' >> IF TRUE THEN SAY 'YES, TRUE HEXADECIMAL' >> >> TRUE = '00110001'B >> SAY 'TRUE BINARY HEX = 'TRUE >> SAY 'DATATYPE TRUE = 'DATATYPE(TRUE) >> IF ¬TRUE THEN SAY 'NOT TRUE
Re: REXX true/false (was Constant Identifiers)
ITYM follow on from EXEC2. Or was Mike working on REX before EXEC2? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rupert Reynolds Sent: Thursday, September 10, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX true/false (was Constant Identifiers) Confused? Difficult to say--the brash nature of this debate is clouding things. There is an example above which uses something like ''0001'B to initialise a variable. In Rexx, that is not a boolean value. Depending on which interpreter you use, it is either a byte with contents x'01', which might be printable in some character sets, or it's a string of seven characters '0', a character '1' and a character 'B'. The only numbers I've found thay work in boolean expressions are 1 and 0. There were always going to be compromises building an interpreted language to follow on from the EXEC interpreter on VM/SP. Rupert On Thu., Sep. 10, 2020, 03:06 CM Poncelet, wrote: > Yes. My post-grad thesis was on PL/I - and on its being originally > called Fortran VI in 1962, then NPL in '64, then distributed as PL/I in > '66 together with OS/360. > > I wrote PL/I before Clist/CLIST and long before REXX. > > Confused am I? > > > -- 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: REXX true/false (was Constant Identifiers)
I dunno, though, the first part of it was entertaining. And as I'm not a systems programmer (I came into mainframe security through the development door), many of the more on-topic threads here are opaque to me, so the occasional fight over COBOL or CLIST provides some diversion. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Three people may keep a secret, if two of them are dead. -Poor Richard */ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, September 10, 2020 08:34 Perfect example of bike shedding! A rambling thread where people argue over stuff that is not really useful! IBMMAIN is difficult to read these days. The good stuff is clouded by topic drift and endless arguments that go on forever. --- On 2020-09-10 8:05 PM, Rupert Reynolds wrote: > Confused? Difficult to say--the brash nature of this debate is clouding > things. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: can DIE routines invoke macro's using linkage=system
Joe, How about answering Jim Mulder's question, or do you not even try reading the documentation before posting questions to the entire IBM-Main team? You apparently knew what you were looking for. What was the difficulty with finding it? And then you didn't even indicate which service you were curious about. The answer could be different for different services. There are likely some services not appropriate to be used from a DIE. The answer has no necessary relationship to "linkage=system", although clearly something that requires issuing an SVC (aside from ABEND) cannot be used from a DIE. 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: REXX true/false (was Constant Identifiers)
On 2020-09-10 8:05 PM, Rupert Reynolds wrote: Confused? Difficult to say--the brash nature of this debate is clouding things. Perfect example of bike shedding! A rambling thread where people argue over stuff that is not really useful! IBMMAIN is difficult to read these days. The good stuff is clouded by topic drift and endless arguments that go on forever. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX true/false (was Constant Identifiers)
Confused? Difficult to say--the brash nature of this debate is clouding things. There is an example above which uses something like ''0001'B to initialise a variable. In Rexx, that is not a boolean value. Depending on which interpreter you use, it is either a byte with contents x'01', which might be printable in some character sets, or it's a string of seven characters '0', a character '1' and a character 'B'. The only numbers I've found thay work in boolean expressions are 1 and 0. There were always going to be compromises building an interpreted language to follow on from the EXEC interpreter on VM/SP. Rupert On Thu., Sep. 10, 2020, 03:06 CM Poncelet, wrote: > Yes. My post-grad thesis was on PL/I - and on its being originally > called Fortran VI in 1962, then NPL in '64, then distributed as PL/I in > '66 together with OS/360. > > I wrote PL/I before Clist/CLIST and long before REXX. > > Confused am I? > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
