Re: IKJPARS PCL/Parameters
Can you get this to work if you enter it as a quoted string? e.g. '12345688 ASID(14)' IKJIDENT should accept quoted strings according to the doc. Do I assume your comments on using the ADDRESS keyword are for IKJPOSIT? Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 26 April 2023 00:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJPARS PCL/Parameters Hi I have a PCL defined as such LISTAPCL IKJPARM ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX NY,VALIDCK=LSTVALAD What I would like it to be is a string which I treat as an address. I don't use the ADDRESS key word because I want the ability to enter a 64 bit address or up to 16 characters I have number of keywords after this one them being ASID When I enter the following string at the TSO terminal 12345688 ASID(14) IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points to the ASID string Don't understand I thought the 12345688 would match up with the first string entered at the TSO terminal 12345688 but the LSTVALAD points to ASID(14) THANKS -- 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: IKJPARS PCL/Parameters
The IKJIDENT looks okay although it would be easier to read if you broke it at a comma rather than at column 71. Please show the code that sets up IKJPARSE, starting at entry.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Tuesday, April 25, 2023 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJPARS PCL/Parameters Hi I have a PCL defined as such LISTAPCL IKJPARM ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX NY,VALIDCK=LSTVALAD What I would like it to be is a string which I treat as an address. I don't use the ADDRESS key word because I want the ability to enter a 64 bit address or up to 16 characters I have number of keywords after this one them being ASID When I enter the following string at the TSO terminal 12345688 ASID(14) IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points to the ASID string Don't understand I thought the 12345688 would match up with the first string entered at the TSO terminal 12345688 but the LSTVALAD points to ASID(14) THANKS -- 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: IKJPARS PCL/Parameters
What I would like to do is drive the validity check exit the first operand is a address and would like to verify via VSMLOC or if its 64 bit IARV64 REQUEST=LIST But the string never hits the exit "LSTVALAD" Trying to write a TESTAUTH subcommand to display data that regular L or LIST command won't do At first I am just running it as or testing it as a command processor TESTAUTH 'LOADLIB(IKJ)' CP thanks LAR1,PARMS USING PPL,R1 MVC PPLUPT,CPPLUPT MVC PPLECT,CPPLECT LAR4,MYECBGET ADDR OF ECB STR4,PPLECB L R5,=A(LISTAPCL) STR5,PPLPCL LAR6,MYANSADDR OF ANSWER PLACE STR6,PPLANS MVC PPLCBUF,CPPLCBUF STR13,PPLUWA MVC PPLVEWA,=F'0' *STR9,ATCOMTAB SAVE TCOMTAB ADDRESS LAR1,PPLUPT ADDR OF PARSE PARM LIST L R15,CVTPTR(,0) POINT TO THE CVT L R15,CVTPARS-CVT(,R15) GET IKJPARS EP BALR R14,R15 CALL IKJPARS -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Wednesday, April 26, 2023 4:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJPARS PCL/Parameters The IKJIDENT looks okay although it would be easier to read if you broke it at a comma rather than at column 71. Please show the code that sets up IKJPARSE, starting at entry.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Tuesday, April 25, 2023 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJPARS PCL/Parameters Hi I have a PCL defined as such LISTAPCL IKJPARM ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX NY,VALIDCK=LSTVALAD What I would like it to be is a string which I treat as an address. I don't use the ADDRESS key word because I want the ability to enter a 64 bit address or up to 16 characters I have number of keywords after this one them being ASID When I enter the following string at the TSO terminal 12345688 ASID(14) IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points to the ASID string Don't understand I thought the 12345688 would match up with the first string entered at the TSO terminal 12345688 but the LSTVALAD points to ASID(14) THANKS -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing C with Rexx
There is a port of PCRE, which has named captures. How hard would it be to port ooRexx 5.0, including glue code for existing applications? From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Wednesday, April 26, 2023 1:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: interfacing C with Rexx On 25/4/23 20:48, Rick Troth wrote: > good questions > > The library that I want to call is "just C", pretty clean, standard > POSIX. My development platform is PC Linux. The package gets built and > tested on other platforms as often as I can drive that, notably FreeBSD. > > I don't have access to USS for dev/test. (But if anyone is offering ...) > > There's no specific need to interrogate nor to set Rexx variables. The > goal is a function which takes arguments and returns a string. The > Rexx function has sub-functions named by the first argument. It works > a lot like Rexx/Sockets (return string is the RC followed by either an > error string or by desired results, if any). > > Interfacing with Regina is pretty easy. Regina's header in this case > is named "rexxsaa.h", so presumably adheres to SAA norms. I confess I > have NOT TRIED linking against ooRexx. Thought I should first ask > others who have tread that road. I suggest that you consider porting Regina to z/OS, which is highly portable and easy to do. I have personally done it and even have a patch file somewhere. Currently, it's compiled in ASCII mode, but it can also support EBCDIC with some modifications to the lex lexer and YACC parser. Keep in mind that z/OS REXX programming services are mainly designed for HLASM and not HLL's. The best way to achieve good performance is by creating a subcommand processor using CEEPIPI to set up a pre-initialized LE environment and writing simple HLASM glue code. Although I've done this before, it requires a lot of work and is quite tedious just to use REXX https://github.com/daveyc/RTK. > > Thanks! > > -- R; <>< > > > On 4/25/23 08:37, Jeremy Nicoll wrote: >> On Tue, 25 Apr 2023, at 13:29, Rick Troth wrote: >>> hello >>> >>> I have a project where I want to call C from Rexx. >>> I've done this with Regina several times. Can someone tell me how, or >>> point to doco, or (best) lend a hand, calling C from ooRexx? >> Do you have ooREXX running on a mainframe? >> >> Which OS? >> >> If z/OS ... Is the C program in LINKLIST? or a load lib? What >> calling (register) convention is it written with - like a TSO CP, >> or a job-step program, or what? >> >> Are you expecting the C code to access contents of rexx >> variables "by magic" or are you going to pass copies of >> their values, or their addresses in storage, or what? >> > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unlike data sets concatenation - revised
Seymour's response made me realize that my post was incomplete. I'm trying to read a concatenation of unlike data sets using QSAM. The first dataset is VBS with LRECL=200,BLKSIZE=1000 The second dataset is VBS with LRECL=230,BLKSZIE= 1150. I've coded a DCB OPEN exit that sets a re-read flag. I had a SYNAD exit but removed it. Prior to OPEN, I set the DCBOFPPC bit to 1. After the OPEN, I set up the DCB OPEN exit. I read the 1st data set and all is well. When I attempt to read the 2nd data set, my DCB OPEN exit is driven. It sets the re-read bit and then returns using R14. I get control after the GET and test the re-read bit. It is set so I do NOT process the record but go back to the GET. I blow up with an S001-4. See below. I was under the impression the technique described above prevents an S001 abend. You could read through an entire concatenation without abending and with one OPEN. Thanks in advance, Pierre. .. 08.40.17 JOB12309 +get1 08.40.17 JOB12309 +get1 08.40.17 JOB12309 +get1 08.40.17 JOB12309 +get1 08.40.17 JOB12309 +open exit 08.40.17 JOB12309 +reread1 08.40.17 JOB12309 IEC020I 001-4,TH127153,,FILEA-0002,0A97,MVSXXX, 08.40.17 JOB12309 IEC020I PIERRE.IN123456.VB230 08.40.17 JOB12309 IEC020I DCB EROPT=ABE OR AN INVALID CODE, AND/OR NO SYNAD EXIT SPECIFIED 08.40.20 JOB12309 IEA995I SYMPTOM DUMP OUTPUT 053 053 SYSTEM COMPLETION CODE=001 REASON CODE=0004 053 TIME=08.40.17 SEQ=05644 CPU= ASID=001A -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing C with Rexx
On 4/26/23 01:44, David Crayford wrote: On 25/4/23 20:48, Rick Troth wrote: good questions The library that I want to call is "just C", pretty clean, standard POSIX. My development platform is PC Linux. The package gets built and tested on other platforms as often as I can drive that, notably FreeBSD. I don't have access to USS for dev/test. (But if anyone is offering ...) There's no specific need to interrogate nor to set Rexx variables. The goal is a function which takes arguments and returns a string. The Rexx function has sub-functions named by the first argument. It works a lot like Rexx/Sockets (return string is the RC followed by either an error string or by desired results, if any). Interfacing with Regina is pretty easy. Regina's header in this case is named "rexxsaa.h", so presumably adheres to SAA norms. I confess I have NOT TRIED linking against ooRexx. Thought I should first ask others who have tread that road. I suggest that you consider porting Regina to z/OS, which is highly portable and easy to do. I have personally done it and even have a patch file somewhere. Currently, it's compiled in ASCII mode, but it can also support EBCDIC with some modifications to the lex lexer and YACC parser. Keep in mind that z/OS REXX programming services are mainly designed for HLASM and not HLL's. The best way to achieve good performance is by creating a subcommand processor using CEEPIPI to set up a pre-initialized LE environment and writing simple HLASM glue code. Although I've done this before, it requires a lot of work and is quite tedious just to use REXX https://github.com/daveyc/RTK. I did some glue code for CMS once or twice to call C from Rexx. The hardest part in that context (similar for MVS) is ensuring that LE is instantiated. (And CEEPIPI is one way to do that, evidently. Good suggestion.) Calling Rexx from C or assembler (in CMS) is almost trivial. I wonder if you could get your Regina fix into the collection at https://github.com/ZOSOpenTools/? In any case, your patch is interesting. I didn't see it under https://github.com/daveyc/. Do share! The project in this case is the message handler that I mentioned a few weeks ago: works like CMS 'XMITMSG'. It includes an 'xmitmsg' command, so could be called as a command, but seemed right to make it a function too. I'll include the Regina interface on GitHub "soon". Thanks! -- R; <>< On 4/25/23 08:37, Jeremy Nicoll wrote: On Tue, 25 Apr 2023, at 13:29, Rick Troth wrote: hello I have a project where I want to call C from Rexx. I've done this with Regina several times. Can someone tell me how, or point to doco, or (best) lend a hand, calling C from ooRexx? Do you have ooREXX running on a mainframe? Which OS? If z/OS ... Is the C program in LINKLIST? or a load lib? What calling (register) convention is it written with - like a TSO CP, or a job-step program, or what? Are you expecting the C code to access contents of rexx variables "by magic" or are you going to pass copies of their values, or their addresses in storage, or what? -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJPARS PCL/Parameters
Are you entering the string in response to this prompt? IKJ57090A ENTER COMMAND FOR CP If so, the first thing you enter on the line is treated as the name of a command, not an operand, and the operands begin with the second thing on the line. Try entering something like this instead: foo 12345688 ASID(14) It doesn't matter what the command name is, as long as it is a simple alphanumeric string. On Tue, 25 Apr 2023 19:52:54 -0400, Joseph Reichman wrote: >I have a PCL defined as such > >LISTAPCL IKJPARM > > ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX > >NY,VALIDCK=LSTVALAD > > > >What I would like it to be is a string which I treat as an address. I don't >use the ADDRESS key word because I want the ability to enter a 64 bit >address or up to 16 characters > > > >I have number of keywords after this one them being ASID > > > >When I enter the following string at the TSO terminal > > > >12345688 ASID(14) > > > > > >IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points >to the ASID string > > > >Don't understand I thought the 12345688 would match up with the first >string entered at the TSO terminal 12345688 but the LSTVALAD points to >ASID(14) > > > >THANKS > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJPARS PCL/Parameters
Thanks that worked So if I developing a subcommand for TEST/TESTAUTH For example LA ( list authorized ) to list storage not normally accessible by the list subcommand The INBUF pointer from TCOMTAB would it have the LA sub command string or only 12345688 ASID(11) Thanks > On Apr 26, 2023, at 10:13 AM, Bill Godfrey wrote: > > Are you entering the string in response to this prompt? > IKJ57090A ENTER COMMAND FOR CP > > If so, the first thing you enter on the line is treated > as the name of a command, not an operand, and > the operands begin with the second thing on the line. > Try entering something like this instead: > > foo 12345688 ASID(14) > > It doesn't matter what the command name is, as long as > it is a simple alphanumeric string. > >> On Tue, 25 Apr 2023 19:52:54 -0400, Joseph Reichman wrote: >> >> I have a PCL defined as such >> >> LISTAPCL IKJPARM >> >> ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX >> >> NY,VALIDCK=LSTVALAD >> >> >> >> What I would like it to be is a string which I treat as an address. I don't >> use the ADDRESS key word because I want the ability to enter a 64 bit >> address or up to 16 characters >> >> >> >> I have number of keywords after this one them being ASID >> >> >> >> When I enter the following string at the TSO terminal >> >> >> >> 12345688 ASID(14) >> >> >> >> >> >> IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points >> to the ASID string >> >> >> >> Don't understand I thought the 12345688 would match up with the first >> string entered at the TSO terminal 12345688 but the LSTVALAD points to >> ASID(14) >> >> >> >> THANKS >> >> > > -- > 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: Unlike data sets concatenation - revised
On Wed, Apr 26, 2023 at 08:00:07AM -0500, Pierre Fichaud wrote: > Seymour's response made me realize that my post was incomplete. Yes, source? JCL? I/O error info (CSW IOB stuff, sense data..) DCB contents: LRECL/BLKSIZE/RECFM? It's some sort of I/O error but what? . incorrect length (caused by block > blksize?) . real I/O error Thoughts which come to mind: 1. The LRECL/BLKSIZE/RECFM has 3 sources: DCB, JCL(JFCB), DSCB. I think they are used in that order. While I've never tried the unlike data set concatenation, I'd suspect that setting the "wrong" value in either the DCB or JCL(JFCB) won't get fixed by the close/open merging in the (correct) DSCB value if the original value was specified in the DCB or JCL(JFCB). So the DCB has to start out before the first open with LRECL and BLKSIZE not specified and they have to not be specified on the JCL. Then the unlike concatenation close/open can restore them and the DSCB values can be used by the next concatenation open. 2. Are there partial VBS segments at the end of the first file? 3. A separate solution (as previously seen on this list) is to put the largest LRECL/BLKSIZE on the JCL of the first dataset and not use unlike concatenation... PS: DEBLRECL in the access method DEB segment appears to hold the DCBLRECL saved during open which gets restored by close. (MVT source: IGG0201X) What does this contain during the time the first in the concatenation is open? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product’s documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willing (and is permitted) to share how they accomplished that task? Since IBM hasn't documented it (at least not so far) I guess we have to do it ourselves. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 4, 2023 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? You are probably right about that. I will start one and see what they reply. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Tuesday, April 4, 2023 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point in BPXWDYN was created that handled that problem. This all started with me writing an RCF to tell them that they didn't have a COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can write c in any language (one of those type of things). Problem is, it would confuse most COBOL programmers that, well, it would confuse most COBOL programmers, and so I suggested a few changes to solve the issue. Then one of their own people onfirmed what I said, it would be confusing to most COBOL programmers. And so it appears that IBM doesn't have many product developers that actually know COBOL. That has been my take-away from that exchange. So you may need to do an RCF, and you may go a few rounds with them. Just say'n'. Steve Thompson On 4/4/2023 1:46 PM, Farley, Peter wrote: > The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the > C language zlib library and functions. There is no material on how to use > those functions from any other language than C. > > At the very least there is no mention of COBOL COPY members for the parameter > definitions nor any mention of a COBOL-compatible link library for inclusion > in an executable module. Only the POSIX C link library and functions are > described. > > Am I missing something? Like maybe the zlib C functions are compiled with > "#pragma linkage(entryname,OS)"? There is no such statement in that manu
JES2 and zEDC compression of output
I happened to come across a PDF document from the 2020 NY Tampa Bay RUG titled Protecting SPOOL with pervasive encryption and other recent JES2 security changes. Stepping away from the encryption part, I found a section concerning JES2 compression of output, via the OUTCLASS paramter, using zEDC. The document states that JES2 can use the zEDC compression engine on the z15 with no software charge. I know that using zEDC compression for SMS managed datasets does require licensing zEDC Express software feature. Am I understanding that correctly, that JES2 will use zEDC and we don't have to pay anything extra for that? Sent with [Proton Mail](https://proton.me/) secure email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJPARS PCL/Parameters
The drill is first do a scan, then a parse. If you're using TEST[AUTH] CP, then you are prompted for a complete command and that's what you should enter. The fact that you provided a member name doesn't change that. So TEST MYPDS(FOO) CP FOO 666 ASID(1) ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Wednesday, April 26, 2023 10:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJPARS PCL/Parameters Thanks that worked So if I developing a subcommand for TEST/TESTAUTH For example LA ( list authorized ) to list storage not normally accessible by the list subcommand The INBUF pointer from TCOMTAB would it have the LA sub command string or only 12345688 ASID(11) Thanks > On Apr 26, 2023, at 10:13 AM, Bill Godfrey wrote: > > Are you entering the string in response to this prompt? > IKJ57090A ENTER COMMAND FOR CP > > If so, the first thing you enter on the line is treated > as the name of a command, not an operand, and > the operands begin with the second thing on the line. > Try entering something like this instead: > > foo 12345688 ASID(14) > > It doesn't matter what the command name is, as long as > it is a simple alphanumeric string. > >> On Tue, 25 Apr 2023 19:52:54 -0400, Joseph Reichman wrote: >> >> I have a PCL defined as such >> >> LISTAPCL IKJPARM >> >> ADDR1 IKJIDENT 'ADDRESS..',RANGE,UPPERCASE,MAXLNTH=17,FIRST=ANY,OTHER=AX >> >> NY,VALIDCK=LSTVALAD >> >> >> >> What I would like it to be is a string which I treat as an address. I don't >> use the ADDRESS key word because I want the ability to enter a 64 bit >> address or up to 16 characters >> >> >> >> I have number of keywords after this one them being ASID >> >> >> >> When I enter the following string at the TSO terminal >> >> >> >> 12345688 ASID(14) >> >> >> >> >> >> IKJPARS total ignores the string 12345688 and LSTVALDAD validity exit points >> to the ASID string >> >> >> >> Don't understand I thought the 12345688 would match up with the first >> string entered at the TSO terminal 12345688 but the LSTVALAD points to >> ASID(14) >> >> >> >> THANKS >> >> > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
I'm pretty sure that there won't be any progress without the contents of the DCB at the time of failure; the current IOB might help. And if there is a SYNADAF, its output would also help. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Michael Stein [m...@zlvfc.com] Sent: Wednesday, April 26, 2023 11:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unlike data sets concatenation - revised On Wed, Apr 26, 2023 at 08:00:07AM -0500, Pierre Fichaud wrote: > Seymour's response made me realize that my post was incomplete. Yes, source? JCL? I/O error info (CSW IOB stuff, sense data..) DCB contents: LRECL/BLKSIZE/RECFM? It's some sort of I/O error but what? . incorrect length (caused by block > blksize?) . real I/O error Thoughts which come to mind: 1. The LRECL/BLKSIZE/RECFM has 3 sources: DCB, JCL(JFCB), DSCB. I think they are used in that order. While I've never tried the unlike data set concatenation, I'd suspect that setting the "wrong" value in either the DCB or JCL(JFCB) won't get fixed by the close/open merging in the (correct) DSCB value if the original value was specified in the DCB or JCL(JFCB). So the DCB has to start out before the first open with LRECL and BLKSIZE not specified and they have to not be specified on the JCL. Then the unlike concatenation close/open can restore them and the DSCB values can be used by the next concatenation open. 2. Are there partial VBS segments at the end of the first file? 3. A separate solution (as previously seen on this list) is to put the largest LRECL/BLKSIZE on the JCL of the first dataset and not use unlike concatenation... PS: DEBLRECL in the access method DEB segment appears to hold the DCBLRECL saved during open which gets restored by close. (MVT source: IGG0201X) What does this contain during the time the first in the concatenation is open? -- 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: JES2 and zEDC compression of output
Yes. You don't need to license zEDC for JES2 to use it for spool compression. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com --- Original Message --- On Wednesday, April 26th, 2023 at 11:52 AM, rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > I happened to come across a PDF document from the 2020 NY Tampa Bay RUG > titled Protecting SPOOL with pervasive encryption and other recent JES2 > security changes. > > Stepping away from the encryption part, I found a section concerning JES2 > compression of output, via the OUTCLASS paramter, using zEDC. The document > states that JES2 can use the zEDC compression engine on the z15 with no > software charge. I know that using zEDC compression for SMS managed datasets > does require licensing zEDC Express software feature. > > Am I understanding that correctly, that JES2 will use zEDC and we don't have > to pay anything extra for that? > > Sent with Proton Mail secure email. > > -- > 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: JES2 and zEDC compression of output
Wasting more time searching the internet about zEDC I came across several articles about SMF record compression when using log streams. It sounded almost like you did not need the zEDC Express software feature. So, I coded compress for the TECH LPAR, and did a SET SMF=xx. It failed with IFA730E. So, I guess not so lucky with SMF :( Thanks for the info! Sent with Proton Mail secure email. --- Original Message --- On Wednesday, April 26th, 2023 at 12:33 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > Yes. You don't need to license zEDC for JES2 to use it for spool compression. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > --- Original Message --- > On Wednesday, April 26th, 2023 at 11:52 AM, rpinion865 > 042a019916dd-dmarc-requ...@listserv.ua.edu wrote: > > > > > I happened to come across a PDF document from the 2020 NY Tampa Bay RUG > > titled Protecting SPOOL with pervasive encryption and other recent JES2 > > security changes. > > > > Stepping away from the encryption part, I found a section concerning JES2 > > compression of output, via the OUTCLASS paramter, using zEDC. The document > > states that JES2 can use the zEDC compression engine on the z15 with no > > software charge. I know that using zEDC compression for SMS managed > > datasets does require licensing zEDC Express software feature. > > > > Am I understanding that correctly, that JES2 will use zEDC and we don't > > have to pay anything extra for that? > > > > Sent with Proton Mail secure email. > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RACF MFA
what is needed to implement MFA (Multi Factor Authentication) in RACF aside from the RACF changes? would network changes be needed also? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
Thanks. That seems like an odd place to put it. What's next, a chapter on how to call the Binder Fast Data API from COBOL? I'd think this chapter should be in the Callable Services for High Level Languages manual. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 10:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product's documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willing (and is permitted) to share how they accomplished that task? Since IBM hasn't documented it (at least not so far) I guess we have to do it ourselves. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 4, 2023 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? You are probably right about that. I will start one and see what they reply. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Tuesday, April 4, 2023 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point in BPXWDYN was created that handled that problem. This all started with me writing an RCF to tell them that they didn't have a COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can write c in any language (one of those type of things). Problem is, it would confuse most COBOL programmers that, well, it would confuse most COBOL programmers, and so I suggested a few changes to solve the issue. Then one of their own people onfirmed what I said, it would be confusing to most COBOL programmers. And so it appears that IBM doesn't have many product developers that actually know COBOL. That has been my take-away from that exchange. So you may need to do an RCF, and you may go a few rounds with them. Just say'n'. Steve Thompson On 4/4/2023 1:46 PM, Farley, Peter wrote: > The V2R5 Callable Services manual SA23-1377-50 pp 191-196 describes ONLY the > C language zlib library and functions. There is no materia
Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
I agree, but failing that they can (and should) at least put in a reference to the COBOL documentation. Yeah, calling the Binder Fast Data API (or even worse the "regular" Binder API) from COBOL would be a stretch to document. Not sure I would even attempt that one, and I have written code to use the Binder API so I (sort of) understand it. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Wednesday, April 26, 2023 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] Thanks. That seems like an odd place to put it. What's next, a chapter on how to call the Binder Fast Data API from COBOL? I'd think this chapter should be in the Callable Services for High Level Languages manual. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 10:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product's documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willing (and is permitted) to share how they accomplished that task? Since IBM hasn't documented it (at least not so far) I guess we have to do it ourselves. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 4, 2023 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? You are probably right about that. I will start one and see what they reply. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Tuesday, April 4, 2023 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point in BPXWDYN was created that handled that problem. This all started with me writing an RCF to tell them that they didn't have a COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can write c in any language (one of those type of things). Problem is, it would confuse most COBOL programmers that, well, it woul
Re: XLC architecture level question
Since this is C++, I'd stick it in a constructor for main, or (less desirable) main::init(). No LE games needed. Cheers, Ray On 2023-04-25 14:26, Charles Mills wrote: Setting ARCH is like playing Blackjack or Twenty-one: guess too low and it is sub-optimal; guess too high and you bust. Note that everything we have said here about ARCH and TUNE applies equally to COBOL as to C/C++. Of course if you are writing programs for in-house use your universe of machines to support is much smaller. The classic error is forgetting about your DR machine. At CorreLog we managed to ship a C++ build to someone who was too back-level for our ARCH. So George -- any of you who know George know that he is a good guy but a yell-er -- yelled at me that the S0C1 was totally unacceptable -- we needed an error message. I pointed out that SYSTEM COMPLETION CODE=0C1 *is* an error message, but he was not having that. So I wrote some assembler code and C++ to compare the compiled ARCH level -- you can retrieve it with __ARCH__ -- and put out our own message if there were a conflict. Obviously you need to do that just as early in your run process as possible or the train will have already left the station and run into a wall. Here's an exercise for the readers. If you want to insert some code into a C++ module such that it will run just as early as possible during the run processing, where do you put it and what else do you do? (Hint: "right after int main(int argc, char* argv[]) and cross your fingers" are NOT the right answers.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, April 25, 2023 7:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question ARCH level is a "problem" I have dealt with for 12 or so years. I say "problem" in quotes because it is not much of a problem -- you only have to revisit it once every two years, and even then it is not an urgent problem. So you don't need a solution that runs on autopilot -- you can just revisit your decision every two years or so. You need a management policy. The one I have advocated to my management is "we will support the oldest hardware supported by the oldest supported release of z/OS." I point out that while there may be lots of customers out there running z9's, they probably are not buying a whole lot of OEM products. Currently that would be ARCH(10), representing the zB/EC12, supported by z/OS V2R4. Once V2R4 goes out of service it would become -- 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: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
I've done it (called the Binder Fast Data API from COBOL). My program returns interesting data about PDSE program object modules, such as the sections, compiler versions and compile dates, binder information, user data IDRs, and so on. The hardest part was dealing with modules with enormously long section names. I've seen modules with 3,000 byte section names! (If you want to help me out, vote for Idea https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-2211 to add a Section Identifier field to the Binder API buffers) I used a COBOL program to prototype my algorithms and get everything working correctly, then rewrote in assembler. And I was making a joke, because how to call the Binder API from COBOL /is/ documented, in the same manual as the API. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I agree, but failing that they can (and should) at least put in a reference to the COBOL documentation. Yeah, calling the Binder Fast Data API (or even worse the "regular" Binder API) from COBOL would be a stretch to document. Not sure I would even attempt that one, and I have written code to use the Binder API so I (sort of) understand it. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Wednesday, April 26, 2023 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] Thanks. That seems like an odd place to put it. What's next, a chapter on how to call the Binder Fast Data API from COBOL? I'd think this chapter should be in the Callable Services for High Level Languages manual. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 10:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product's documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willi
Re: Unlike data sets concatenation - revised
Seymour, SYNAD msg 00023475 008000 7C00 0260 | .@- | 00023480 6003E840 40404040 40404040 40404040 | -.Y | 00023490.:02349F. LENGTH(X'10')--All bytes contain X'40', C' ' 000234A0 40404040 40406BE3 C8F1F2F7 F1F5F36B | ,TH127153, | 000234B0 E2C1F1F2 C5E9E3D7 6BF0C1F9 F76BC46B | SA12EZTP,0A97,D, | 000234C0 C6C9D3C5 C1404040 6BC7C5E3 4040406B | FILEA ,GET , | 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | 000234E0 F0F0F0F0 F0F1C4F1 F0F0F0F0 F0F06BD8 | 01D100,Q | 000234F0 E2C1D440 4199 44900224 D800 | SAM ..rQ... | 00023500 1C404040 F1404040 40404040 | . 1| 00023510.:02356F. LENGTH(X'60')--All bytes contain X'40', C' ' DCB 000224D8.:0224DF. LENGTH(X'08')--All bytes contain X'00' 000224E0 01D1 00F43026 002FE5A2 05025C70 | .J...4Vs..*. | 000224F0 4000 0002739002010580 5000F208 | .. .&.2. | 00022500 00B84848 008C5A6C 1AE30E68 00CA99F8 | ..!%.Tr8 | 00022510 0A018238 021903E8 30013030 00027400 | ..bY | 00022520 00C8 | ...H | 00022530 Apologies for the bad formatting. Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | A likely result from reading a block larger than the blksize. > DCB > > 000224D8.:0224DF. LENGTH(X'08')--All bytes contain X'00' > 000224E0 01D1 00F43026 002FE5A2 05025C70 | .J...4Vs..*. | > 000224F0 4000 00027390 02010580 5000F208 | .. .&.2. | > 00022500 00B84848 008C5A6C 1AE30E68 00CA99F8 | ..!%.Tr8 | > 00022510 0A018238 021903E8 30013030 00027400 | ..bY | > 00022520 00C8 | ...H | > 00022530 > The first dataset is VBS with LRECL=200,BLKSIZE=1000 > The second dataset is VBS with LRECL=230,BLKSZIE= 1150. decimal values in hex: 200 -> c8 230 -> e6 1000 -> 3e8 1150 -> 47e I see 3e8 at 22516, this is likely the BLKSIZE 1000 DCBLRECL is 18 decmal bytes from *after* blocksize (20 bytes from BLKSIZE) That's 22528 which contains 00c8 -> LRECL 200 The DCB contains the BLKSIZE/LRECL from the first dataset of the concatenation. This would result in QSAM trying to read an 1150 byte block in the second dataset with a read for 1000 bytes and getting a wrong length record I/O error. The unlike cocatenation close/open didn't merge in the new BLKSIZE and LRECL. Why not? Perhaps because they were already set before the first open... What does the *SOURCE* DCB & JCL look like? Do either specify LRECL and/or BLKSIZE? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
DCBOFLGS='30'X=DCBOFEOV+DCBOFOPN DCBLRECL='C8'X=100 DCBBLKSI==3E8'X=1000 The OPEN exit needs to OIDCBOFLGS,DCBOFPPC From: IBM Mainframe Discussion List on behalf of Pierre Fichaud Sent: Wednesday, April 26, 2023 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unlike data sets concatenation - revised Seymour, SYNAD msg 00023475 008000 7C00 0260 | .@- | 00023480 6003E840 40404040 40404040 40404040 | -.Y | 00023490.:02349F. LENGTH(X'10')--All bytes contain X'40', C' ' 000234A0 40404040 40406BE3 C8F1F2F7 F1F5F36B | ,TH127153, | 000234B0 E2C1F1F2 C5E9E3D7 6BF0C1F9 F76BC46B | SA12EZTP,0A97,D, | 000234C0 C6C9D3C5 C1404040 6BC7C5E3 4040406B | FILEA ,GET , | 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | 000234E0 F0F0F0F0 F0F1C4F1 F0F0F0F0 F0F06BD8 | 01D100,Q | 000234F0 E2C1D440 4199 44900224 D800 | SAM ..rQ... | 00023500 1C404040 F1404040 40404040 | . 1| 00023510.:02356F. LENGTH(X'60')--All bytes contain X'40', C' ' DCB 000224D8.:0224DF. LENGTH(X'08')--All bytes contain X'00' 000224E0 01D1 00F43026 002FE5A2 05025C70 | .J...4Vs..*. | 000224F0 4000 0002739002010580 5000F208 | .. .&.2. | 00022500 00B84848 008C5A6C 1AE30E68 00CA99F8 | ..!%.Tr8 | 00022510 0A018238 021903E8 30013030 00027400 | ..bY | 00022520 00C8 | ...H | 00022530 Apologies for the bad formatting. Pierre. -- 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: XLC architecture level question
> where do you put it and what else do you do? Ray and David have half of the answer. Specifically, you put it in a constructor for a static class instance. The first "user code" that C++ runs -- before int main() -- is static class constructors. What else do you do? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of M. Ray Mullins Sent: Wednesday, April 26, 2023 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC architecture level question Since this is C++, I'd stick it in a constructor for main, or (less desirable) main::init(). No LE games needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: >> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | > >A likely result from reading a block larger than the blksize. > Why does it say "RECORD" if it means "Block"? >... >What does the *SOURCE* DCB & JCL look like? Do either specify LRECL >and/or BLKSIZE? > Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 32760. LRECL likewise. Storage is cheap nowadays. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
+1 Storage is a lot cheaper than programmer time writing exits and bit-twiddling DCBs. Isn't there a BUFL parameter that accomplishes the same thing and can be used without regard to actual BLKSIZE (in the case of RECFM=FB)? CM On Wed, 26 Apr 2023 17:08:54 -0500, Paul Gilmartin wrote: >On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: > >>> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | >> >>A likely result from reading a block larger than the blksize. >> >Why does it say "RECORD" if it means "Block"? > >>... >>What does the *SOURCE* DCB & JCL look like? Do either specify LRECL >>and/or BLKSIZE? >> >Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 32760. >LRECL likewise. Storage is cheap nowadays. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
Isn't this the result of a CCW that does not have the wrong length Record suppression bit on (I think that is what it is called, been a long time since I did any CCWs and SSCH commands). Steve Thompson On 4/26/2023 6:08 PM, Paul Gilmartin wrote: On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | A likely result from reading a block larger than the blksize. Why does it say "RECORD" if it means "Block"? ... What does the *SOURCE* DCB & JCL look like? Do either specify LRECL and/or BLKSIZE? Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 32760. LRECL likewise. Storage is cheap nowadays. -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF MFA
MFA is a separately charged product from IBM, and is licensed in blocks of 500 users. So there will be a software purchase and install on top of the racf changes Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Bill Giannelli Sent: Wednesday, April 26, 2023 12:55:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF MFA what is needed to implement MFA (Multi Factor Authentication) in RACF aside from the RACF changes? would network changes be needed also? thanks Bill -- For IBM-MAIN subscribe ZjQcmQRYFpfptBannerStart CAUTION EXTERNAL EMAIL This message came from outside your organization. DO NOT open attachments or click on links from unknown senders or unexpected emails. ZjQcmQRYFpfptBannerEnd what is needed to implement MFA (Multi Factor Authentication) in RACF aside from the RACF changes? would network changes be needed also? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unlike data sets concatenation - revised
There is a BUFL parameter, but it's not needed in this case; LRECL=max, BLKSIZE=max will do the job. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, April 26, 2023 6:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unlike data sets concatenation - revised +1 Storage is a lot cheaper than programmer time writing exits and bit-twiddling DCBs. Isn't there a BUFL parameter that accomplishes the same thing and can be used without regard to actual BLKSIZE (in the case of RECFM=FB)? CM On Wed, 26 Apr 2023 17:08:54 -0500, Paul Gilmartin wrote: >On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: > >>> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | >> >>A likely result from reading a block larger than the blksize. >> >Why does it say "RECORD" if it means "Block"? > >>... >>What does the *SOURCE* DCB & JCL look like? Do either specify LRECL >>and/or BLKSIZE? >> >Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 32760. >LRECL likewise. Storage is cheap nowadays. -- 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: Unlike data sets concatenation - revised
Yes, but IBM would have given the same ABEND code had they done a READ CKD and compared. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@wkyr.net] Sent: Wednesday, April 26, 2023 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unlike data sets concatenation - revised Isn't this the result of a CCW that does not have the wrong length Record suppression bit on (I think that is what it is called, been a long time since I did any CCWs and SSCH commands). Steve Thompson On 4/26/2023 6:08 PM, Paul Gilmartin wrote: > On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: > >>> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, >>> | >> A likely result from reading a block larger than the blksize. >> > Why does it say "RECORD" if it means "Block"? > >> ... >> What does the *SOURCE* DCB & JCL look like? Do either specify LRECL >> and/or BLKSIZE? >> > Just cut the Gordian Knot and specify the largest BLKSIZE expected; even > 32760. > LRECL likewise. Storage is cheap nowadays. > -- Regards, Steve Thompson VS Strategies LLC Westfield IN 972-983-9430 cell -- 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: Unlike data sets concatenation - revised
The DASD documentation uses the term record. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu] Sent: Wednesday, April 26, 2023 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unlike data sets concatenation - revised On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: >> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, | > >A likely result from reading a block larger than the blksize. > Why does it say "RECORD" if it means "Block"? >... >What does the *SOURCE* DCB & JCL look like? Do either specify LRECL >and/or BLKSIZE? > Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 32760. LRECL likewise. Storage is cheap nowadays. -- 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: Unlike data sets concatenation - revised
A DASD record is a physical block. Contents of the block depend on the RECFM=, i.e. U for load modules, VB for variable blocked, FB for Fixed Blocked. On Wed, Apr 26, 2023 at 6:11 PM Seymour J Metz wrote: > > The DASD documentation uses the term record. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu] > Sent: Wednesday, April 26, 2023 6:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Unlike data sets concatenation - revised > > On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote: > > >> 000234D0 E6D9D5C7 4BD3C5D5 4BD9C5C3 D6D9C46B | WRNG.LEN.RECORD, > >> | > > > >A likely result from reading a block larger than the blksize. > > > Why does it say "RECORD" if it means "Block"? > > >... > >What does the *SOURCE* DCB & JCL look like? Do either specify LRECL > >and/or BLKSIZE? > > > Just cut the Gordian Knot and specify the largest BLKSIZE expected; even > 32760. > LRECL likewise. Storage is cheap nowadays. > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
The example has two bugs in it (a typo and a repeated line), but fixing those it does appear to work. A better test would have been to compress something other than just binary zeroes, and also to re-init the "input" (now output) area so you can actually "see" it work (in the debugger). Pretty cool nonetheless. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 9:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product’s documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willing (and is permitted) to share how they accomplished that task? Since IBM hasn't documented it (at least not so far) I guess we have to do it ourselves. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 4, 2023 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? You are probably right about that. I will start one and see what they reply. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Tuesday, April 4, 2023 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? A similar issue happened with BPXWDYN. COBOL can't set R0. So a new entry point in BPXWDYN was created that handled that problem. This all started with me writing an RCF to tell them that they didn't have a COBOL example. Then a C programmer (I'm guessing) wrote the COBOL code. You can write c in any language (one of those type of things). Problem is, it would confuse most COBOL programmers that, well, it would confuse most COBOL programmers, and so I suggested a few changes to solve the issue. Then one of their own people onfirmed what I said, it would be confusing to most COBOL programmers. And so it appears that IBM doesn't have many product developers that actually know COBOL. That has been my take-away from that exchange. So you may need to do an RCF, and you may go a few rounds with them. Just say'n'. Steve Thompson On 4/4/2023 1:46 PM, Farley, Peter wrote: > The V2R5 Callable Services manual SA23
Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?]
Agreed on all points: Errors: disp5ay --> display and repeated "If RC Not = 0 Then" near the end of the program code. I'll send an RCF on that one. I added a pseudo-random initialization of the zinput area based on the RANDOM function with a seed of the current CCYYMMDD date and it does work pretty well. Compressed length of 4193 for pseudo-random data for a seed of today's date vs compressed length of 351 for the binary-zero published version. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Wednesday, April 26, 2023 8:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] The example has two bugs in it (a typo and a repeated line), but fixing those it does appear to work. A better test would have been to compress something other than just binary zeroes, and also to re-init the "input" (now output) area so you can actually "see" it work (in the debugger). Pretty cool nonetheless. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Wednesday, April 26, 2023 9:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] An off-list communication from another interested party pointed me to this link to the online Enterprise COBOL Programmers Guide V6.4, which has exactly the documentation I have been requesting, at least for COBOL programmers: Chapter 36. Using zlib compression from a COBOL program https://urldefense.com/v3/__https://www.ibm.com/docs/en/cobol-zos/6.4?topic=processing-using-zlib-compression-from-cobol-program__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!MPQOKjewpZeiZ3hwB15SclkVSEuzDV9ndnOtAYGo3DUNNKpuiovZDWU3CtHrMBiVq6kdrjJ45Byhu9jlbztveCdxgEqrX_jW0w$ I checked my previously saved COBOL PDF's for V6.2 and it is there as well. Interestingly the latest PL/I Programmers Guide (V6.1) has no reference to zlib at all, and the last published VS Fortran documents (all of which are dated 1993) of course have no references to it. I will be updating my RCF to ask that the MVS manual at least reference the COBOL Programmer's Guide and chapter title as an example of non-C-language access to these functions. I'm certain that any competent PL/I or Fortran programmer could figure out what to do in their language from the COBOL example. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] To be more clear: I am asking for examples of non-C-language un-authorized HLL calls to the "zlib" un-authorized functions and a list of any COPY/INCLUDE members necessary to accomplish those calls, not the zEDC authorized functions nor the hardware-level DFLTCC instruction. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 25, 2023 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to call zEDC functions from an HLL other than C [was: RE: Unzip on z/OS ?] I submitted an RCF on the subject of examples for actually using zEDC functions from HLL's other than C not long after this message chain and received no response at all from the RCF team. A follow-up email requesting status or at least an acknowledgement that the documentation addition suggestion had been received did get a response, which was: "Thank you for reaching out to IBM about your experience with our Documentation feedback. A response is not provided for feedback sent to your product’s documentation team. All comments are received and evaluated to help improve the content experience. Any resulting updates to the product documentation are then reflected in the current release of the product. Any issues that require a response should go through IBM support." Since neither the zEDC redbook to which Tom Harper posted a link nor the MVS Callable Services for HLL's manual have any examples of how to ACTUALLY use zEDC functions from any HLL except C, has anyone on this list actually coded invocation of zEDC services from an HLL other than C who is willing (and is permitted) to share how they accomplished that task? Since IBM hasn't documented it (at least not so far) I guess we have to do it ourselves. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, April 4, 2023 2:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? You are probably right about that. I will start one and see what they reply. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Tuesday, April 4, 2023 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unzip on z/OS ? A similar issue happened with BPXWDYN. COBOL
Re: Card processing application
Worldline's Cardlink II is a(nother) card management services application. Cardlink II's customer base tends to be concentrated in Asia-Pacific. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific 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
